PostgreSQL 모니터링의 기본 사항입니다. 알렉세이 레소프스키

Data Egret "Fundamentals of PostgreSQL 모니터링"에서 Alexey Lesovsky가 작성한 보고서 사본을 읽어 보시기 바랍니다.

이 보고서에서 Alexey Lesovsky는 사후 통계의 핵심 사항, 그 의미, 모니터링에 참여해야 하는 이유에 대해 설명합니다. 모니터링에 어떤 그래프가 들어가야 하는지, 어떻게 추가해야 하는지, 어떻게 해석해야 하는지. 이 보고서는 Postgres 문제 해결에 관심이 있는 데이터베이스 관리자, 시스템 관리자 및 개발자에게 유용합니다.

제 이름은 Alexey Lesovsky이고 Data Egret 회사를 대표합니다.

나 자신에 대한 몇 마디. 저는 오래 전에 시스템 관리자로 일을 시작했습니다.

나는 모든 종류의 다양한 Linux 시스템을 관리하고 Linux와 관련된 다양한 작업(예: 가상화, 모니터링, 프록시 작업 등)을 수행했습니다. 그러나 어느 시점에서 나는 데이터베이스, PostgreSQL에 대한 작업을 더 많이 시작했습니다. 나는 그를 정말 좋아했습니다. 그리고 어느 시점부터 저는 근무 시간의 대부분을 PostgreSQL에서 작업하기 시작했습니다. 그래서 점차적으로 저는 PostgreSQL DBA가 되었습니다.

그리고 제 경력 전반에 걸쳐 저는 항상 통계, 모니터링, 원격 측정이라는 주제에 관심을 가져왔습니다. 그리고 제가 시스템 관리자였을 때 Zabbix와 매우 긴밀하게 협력했습니다. 그리고 저는 다음과 같은 작은 스크립트 세트를 작성했습니다. zabbix 확장. 그는 그 당시 꽤 인기가 있었습니다. 그리고 Linux뿐만 아니라 다양한 구성 요소까지 매우 다양한 중요한 사항을 모니터링할 수 있었습니다.

지금은 PostgreSQL 작업을 하고 있습니다. 나는 이미 PostgreSQL 통계 작업을 할 수 있는 또 다른 글을 작성 중입니다. 그것은이라고 pgCenter (Habré에 관한 기사 - 신경과 긴장이 없는 경기 후 통계).

약간의 소개글입니다. 우리 고객, 고객은 어떤 상황에 처해 있습니까? 데이터베이스와 관련된 일종의 사고가 있습니다. 그리고 데이터베이스가 이미 복원되면 부서장이나 개발 책임자가 와서 이렇게 말합니다. "친구 여러분, 데이터베이스를 모니터링해야 합니다. 나쁜 일이 발생했기 때문에 앞으로 이런 일이 발생하지 않도록 해야 합니다." 여기에서 PostgreSQL, MySQL 또는 기타 데이터베이스를 모니터링할 수 있도록 모니터링 시스템을 선택하거나 기존 모니터링 시스템을 조정하는 흥미로운 프로세스가 시작됩니다. 그리고 동료들은 다음과 같이 제안하기 시작합니다. “이러한 데이터베이스가 있다고 들었습니다. 활용해보자." 동료들이 서로 논쟁을 벌이기 시작합니다. 결국 우리는 어떤 종류의 데이터베이스를 선택했지만 PostgreSQL 모니터링이 제대로 제공되지 않아 항상 무언가를 추가해야 한다는 것이 밝혀졌습니다. GitHub에서 일부 저장소를 가져와서 복제하고, 스크립트를 조정하고, 어떻게든 사용자 정의하세요. 그리고 결국 그것은 일종의 수작업으로 끝나게 됩니다.

따라서 이번 강연에서는 PostgreSQL뿐만 아니라 데이터베이스에 대한 모니터링을 선택하는 방법에 대한 지식을 제공하려고 합니다. 그리고 앞으로 발생할 수 있는 긴급 상황을 즉시 방지하기 위해 모니터링을 완료하여 이점을 얻을 수 있는 지식을 제공하여 데이터베이스를 유익하게 모니터링할 수 있습니다.

그리고 이 보고서에 포함될 아이디어는 DBMS이든 noSQL이든 모든 데이터베이스에 직접 적용할 수 있습니다. 따라서 PostgreSQL뿐만 아니라 PostgreSQL에서 이를 수행하는 방법에 대한 많은 레시피가 있을 것입니다. PostgreSQL이 모니터링하기 위해 가지고 있는 쿼리의 예, 엔터티의 예가 있습니다. 그리고 DBMS에 모니터링할 수 있는 동일한 기능이 있는 경우 이를 조정하고 추가할 수도 있습니다. 그러면 좋을 것입니다.

난 보고서에 나오지 않을 거야
측정항목을 전달하고 저장하는 방법에 대해 이야기합니다. 데이터를 후처리하여 사용자에게 제공하는 것에 대해서는 아무 말도 하지 않겠습니다. 그리고 나는 경고에 대해 아무 말도하지 않을 것입니다.
하지만 스토리가 진행되면서 기존 모니터링의 다양한 스크린샷을 보여주며 어떻게든 비판을 하게 됩니다. 그러나 그럼에도 불구하고 나는 이러한 제품에 대한 광고 또는 광고 방지를 생성하지 않기 위해 브랜드 이름을 지정하지 않으려고 노력할 것입니다. 따라서 모든 우연의 일치는 무작위이며 상상에 맡깁니다.

먼저 모니터링이 무엇인지 알아 보겠습니다. 모니터링은 매우 중요한 일입니다. 모두가 이것을 이해합니다. 그러나 동시에 모니터링은 비즈니스 제품과 관련이 없으며 회사의 이익에 직접적인 영향을 미치지 않으므로 항상 잔여 시간을 기준으로 모니터링에 시간을 할당합니다. 시간이 있으면 모니터링을 하고, 시간이 없으면 백로그에 넣어두고 언젠가 이 작업으로 돌아오겠습니다.

따라서 우리가 클라이언트에게 접근할 때 모니터링은 종종 불완전하고 데이터베이스 작업을 더 잘 수행하는 데 도움이 되는 흥미로운 내용이 없습니다. 따라서 모니터링은 항상 완료되어야 합니다.

데이터베이스는 정보의 저장소이기 때문에 모니터링이 필요한 복잡한 것입니다. 그리고 정보는 회사에 매우 중요하므로 어떤 경우에도 손실될 수 없습니다. 그러나 동시에 데이터베이스는 매우 복잡한 소프트웨어이기도 합니다. 그들은 많은 수의 구성 요소로 구성됩니다. 그리고 이러한 구성 요소 중 상당수를 모니터링해야 합니다.

PostgreSQL에 관해 구체적으로 이야기하는 경우에는 많은 수의 구성 요소로 구성된 체계 형태로 표현될 수 있습니다. 이러한 구성 요소는 서로 상호 작용합니다. 동시에 PostgreSQL에는 소위 Stats Collector 하위 시스템이 있어 이러한 하위 시스템의 작동에 대한 통계를 수집하고 관리자나 사용자가 이러한 통계를 볼 수 있도록 일종의 인터페이스를 제공할 수 있습니다.

이러한 통계는 특정 기능 및 보기 세트의 형태로 제공됩니다. 테이블이라고 부를 수도 있습니다. 즉, 일반 psql 클라이언트를 사용하여 데이터베이스에 연결하고, 이러한 기능과 보기를 선택하고, PostgreSQL 하위 시스템의 작동에 대한 특정 수치를 얻을 수 있습니다.

이러한 숫자를 즐겨 사용하는 모니터링 시스템에 추가하고, 그래프를 그리고, 기능을 추가하고, 장기적으로 분석을 얻을 수 있습니다.

하지만 이 보고서에서는 이 모든 기능을 완전히 다루지는 않을 것입니다. 왜냐하면 하루 종일 걸릴 수 있기 때문입니다. 문자 그대로 두 가지, 세 가지 또는 네 가지 사항을 다루고 이러한 사항이 모니터링을 개선하는 데 어떻게 도움이 되는지 알려 드리겠습니다.

데이터베이스 모니터링에 관해 이야기한다면 무엇을 모니터링해야 할까요? 우선, 데이터베이스는 클라이언트에게 데이터에 대한 액세스를 제공하는 서비스이고 가용성을 모니터링하고 일부 질적, 양적 특성도 제공해야 하기 때문에 가용성을 모니터링해야 합니다.

또한 데이터베이스에 연결하는 클라이언트는 일반 클라이언트일 수도 있고 데이터베이스에 해를 끼칠 수 있는 유해한 클라이언트일 수도 있으므로 모니터링해야 합니다. 또한 이들의 활동을 모니터링하고 추적해야 합니다.

클라이언트가 데이터베이스에 연결되면 클라이언트가 데이터 작업을 시작한다는 것이 분명하므로 클라이언트가 데이터를 사용하는 방식, 즉 어떤 테이블을 사용하고 어느 정도 인덱스를 사용하는지 모니터링해야 합니다. 즉, 고객이 생성하는 워크로드를 평가해야 합니다.

그러나 워크로드도 물론 요청으로 구성됩니다. 애플리케이션은 데이터베이스에 연결하고 쿼리를 사용하여 데이터에 액세스하므로 데이터베이스에 있는 쿼리를 평가하고, 쿼리의 적절성을 모니터링하고, 비뚤게 작성되지 않았는지, 일부 옵션을 다시 작성하여 더 빠르게 작동하도록 만드는 것이 중요합니다. 그리고 더 나은 성능으로.

데이터베이스에 대해 이야기하고 있으므로 데이터베이스는 항상 백그라운드 프로세스입니다. 백그라운드 프로세스는 데이터베이스 성능을 좋은 수준으로 유지하는 데 도움이 되므로 자체적으로 작동하려면 일정량의 리소스가 필요합니다. 동시에 클라이언트 요청 리소스와 겹칠 수 있으므로 탐욕스러운 백그라운드 프로세스가 클라이언트 요청 성능에 직접적인 영향을 미칠 수 있습니다. 따라서 백그라운드 프로세스 측면에서 왜곡이 없도록 모니터링하고 추적해야 합니다.

그리고 데이터베이스 모니터링 측면에서 이 모든 것은 시스템 측정항목에 남아 있습니다. 그러나 대부분의 인프라가 클라우드로 이동하고 있다는 점을 고려하면 개별 호스트의 시스템 지표는 항상 백그라운드로 사라집니다. 그러나 데이터베이스에서는 여전히 관련성이 있으며 시스템 메트릭을 모니터링하는 것도 필요합니다.

시스템 측정항목을 사용하면 모든 것이 어느 정도 괜찮습니다. 모든 최신 모니터링 시스템은 이미 이러한 측정항목을 지원하지만 일반적으로 일부 구성 요소는 여전히 충분하지 않으며 일부 항목을 추가해야 합니다. 나는 또한 그것들을 다룰 것이고, 그것들에 관한 여러 슬라이드가 있을 것입니다.

계획의 첫 번째 포인트는 접근성입니다. 접근성이란 무엇입니까? 내가 이해하는 가용성은 서비스 연결에 대한 베이스의 능력입니다. 즉, 베이스가 올라가고 서비스로서 클라이언트의 연결을 허용합니다. 그리고 이러한 접근성은 특정 특성으로 평가될 수 있습니다. 이러한 특성을 대시보드에 표시하는 것은 매우 편리합니다.

대시보드가 ​​무엇인지는 누구나 알고 있습니다. 필요한 정보가 요약되어 있는 화면을 한 번 살펴봤을 때입니다. 그리고 데이터베이스에 문제가 있는지 여부를 즉시 판단할 수 있습니다.
따라서 데이터베이스의 가용성 및 기타 주요 특성은 항상 대시보드에 표시되어 이 정보를 항상 가까이에서 사용할 수 있도록 해야 합니다. 사고 조사에 이미 도움이 되는 일부 추가 세부 정보는 일부 긴급 상황을 조사할 때 이미 보조 대시보드에 배치되거나 타사 모니터링 시스템으로 연결되는 드릴다운 링크에 숨겨져 있어야 합니다.

잘 알려진 모니터링 시스템의 예입니다. 이것은 매우 멋진 모니터링 시스템입니다. 그녀는 많은 데이터를 수집하지만 내 관점에서는 그녀는 대시보드에 대한 개념이 이상합니다. '대시보드 만들기' 링크가 있습니다. 하지만 대시보드를 만들면 두 개의 열로 구성된 목록, 즉 그래프 목록이 생성됩니다. 그리고 무언가를 봐야 할 때 마우스로 클릭하고 스크롤하고 원하는 차트를 찾기 시작합니다. 그리고 시간이 걸립니다. 즉, 대시보드가 ​​없습니다. 차트 목록만 있습니다.

이 대시보드에 무엇을 추가해야 합니까? 응답 시간과 같은 특성으로 시작할 수 있습니다. PostgreSQL에는 pg_stat_statements 뷰가 있습니다. 기본적으로 비활성화되어 있지만 항상 활성화하고 사용해야 하는 중요한 시스템 보기 중 하나입니다. 데이터베이스에서 실행된 모든 실행 쿼리에 대한 정보를 저장합니다.

따라서 위 필드를 사용하여 모든 요청의 총 실행 시간을 요청 수로 나눌 수 있다는 사실부터 시작할 수 있습니다. 하지만 이것은 병원의 평균 온도입니다. 최소 쿼리 실행 시간, 최대 및 중앙값과 같은 다른 필드에서 시작할 수 있습니다. 그리고 백분위수를 작성할 수도 있는데, PostgreSQL에는 이에 상응하는 기능이 있습니다. 그리고 이미 완료된 요청에 대한 데이터베이스의 응답 시간을 특징짓는 몇 가지 숫자를 얻을 수 있습니다. 즉, 가짜 요청 'select 1'을 실행하지 않고 응답 시간을 살펴보지만 이미 완료된 요청에 대한 응답 시간을 분석하여 그립니다. 별도의 수치를 사용하거나 이를 기반으로 그래프를 작성합니다.

현재 시스템에서 생성되는 오류 수를 모니터링하는 것도 중요합니다. 이를 위해 pg_stat_database 뷰를 사용할 수 있습니다. xact_rollback 필드에 중점을 둡니다. 이 필드에는 데이터베이스에서 발생하는 롤백 수뿐만 아니라 오류 수도 고려됩니다. 상대적으로 말하면 이 수치를 대시보드에 표시하고 현재 얼마나 많은 오류가 있는지 확인할 수 있습니다. 오류가 많다면 로그를 살펴보고 어떤 오류인지, 왜 발생하는지 살펴보고 투자해서 해결해 보는 것도 좋은 이유가 될 것입니다.

타코미터와 같은 것을 추가할 수 있습니다. 이는 초당 트랜잭션 수와 초당 요청 수입니다. 상대적으로 말하자면, 이러한 숫자를 데이터베이스의 현재 성능으로 사용하고 요청이 최고조에 달했는지, 트랜잭션이 최고조에 달했는지, 또는 반대로 일부 백엔드가 실패하여 데이터베이스가 과소로드되었는지 여부를 관찰할 수 있습니다. 항상 이 수치를 보고 우리 프로젝트에서는 이런 종류의 성능이 정상이지만 위와 아래의 값은 이미 일종의 문제가 있고 이해할 수 없는 값이라는 것을 기억하는 것이 중요합니다. 너무 높다.

트랜잭션 수를 추정하기 위해 다시 pg_stat_database 뷰를 참조할 수 있습니다. 커밋 수와 롤백 수를 추가하고 초당 트랜잭션 수를 얻을 수 있습니다.

여러 요청이 하나의 거래에 포함될 수 있다는 것을 모두가 이해하고 있습니까? 따라서 TPS와 QPS는 약간 다릅니다.

초당 요청 수는 pg_stat_statements에서 얻을 수 있으며 완료된 모든 요청의 합계를 간단히 계산할 수 있습니다. 현재 값을 이전 값과 비교하고 빼서 델타를 구하고 수량을 구하는 것이 분명합니다.

원하는 경우 추가 측정항목을 추가할 수 있으며, 이는 데이터베이스의 가용성을 평가하고 가동 중지 시간이 있었는지 여부를 모니터링하는 데도 도움이 됩니다.

이러한 지표 중 하나는 가동 시간입니다. 그러나 PostgreSQL의 가동 시간은 약간 까다롭습니다. 그 이유를 말씀드리겠습니다. PostgreSQL이 시작되면 가동 시간 보고가 시작됩니다. 그러나 예를 들어 밤에 일부 작업이 실행 중일 때 OOM-killer가 나타나 PostgreSQL 하위 프로세스를 강제 종료했다면 이 경우 PostgreSQL은 모든 클라이언트의 연결을 종료하고 샤딩된 메모리 영역을 재설정한 후 복구를 시작합니다. 마지막 체크포인트. 그리고 체크포인트로부터의 복구가 지속되는 동안 데이터베이스는 연결을 허용하지 않습니다. 즉, 이 상황은 다운타임으로 평가될 수 있습니다. 그러나 가동 시간 카운터는 첫 번째 순간부터 포스트마스터 시작 시간을 고려하기 때문에 재설정되지 않습니다. 따라서 이러한 상황은 건너뛸 수 있습니다.

진공청소기 작업자 수도 모니터링해야 합니다. PostgreSQL의 autovacuum이 무엇인지 다들 알고 계시나요? 이것은 PostgreSQL의 흥미로운 하위 시스템입니다. 그녀에 대한 많은 기사가 작성되었으며 많은 보고서가 작성되었습니다. 진공과 그것이 어떻게 작동해야 하는지에 관해 많은 논의가 있습니다. 많은 사람들은 그것을 필요악이라고 생각합니다. 그러나 그것이 바로 그 방법입니다. 이는 트랜잭션에 필요하지 않은 오래된 버전의 행을 정리하고 새 행에 대한 테이블 및 인덱스의 공간을 확보하는 일종의 가비지 수집기와 유사합니다.

왜 모니터링해야 합니까? 진공청소기가 때로 많이 아프기 때문이죠. 많은 양의 리소스를 소비하고 결과적으로 클라이언트 요청이 어려워지기 시작합니다.

그리고 이는 다음 섹션에서 설명할 pg_stat_activity 뷰를 통해 모니터링해야 합니다. 이 보기에는 데이터베이스의 현재 활동이 표시됩니다. 그리고 이 활동을 통해 현재 작동 중인 진공청소기의 수를 추적할 수 있습니다. 우리는 진공을 추적하고 한계를 초과한 경우 이것이 PostgreSQL 설정을 조사하고 어떻게든 진공의 작동을 최적화해야 하는 이유인지 확인할 수 있습니다.

PostgreSQL의 또 다른 특징은 PostgreSQL이 긴 트랜잭션으로 인해 매우 고통스럽다는 것입니다. 특히 오랜 시간 동안 아무 일도 하지 않는 거래에서는 더욱 그렇습니다. 이는 소위 트랜잭션 유휴 상태 상태입니다. 이러한 트랜잭션은 잠금을 유지하고 진공이 작동하는 것을 방지합니다. 결과적으로 테이블이 부풀어 오르고 크기도 커집니다. 그리고 이러한 테이블을 사용하는 쿼리는 더 느리게 작동하기 시작합니다. 이전 버전의 행을 모두 메모리에서 디스크로 옮겨야 하기 때문입니다. 따라서 시간, 가장 긴 트랜잭션 기간, 가장 긴 진공 요청도 모니터링해야 합니다. 그리고 OLTP 로드에 대해 이미 10-20-30분 이상 매우 오랫동안 실행 중인 일부 프로세스가 있는 경우 해당 프로세스에 주의를 기울여 강제로 종료하거나 애플리케이션을 최적화하여 호출되지 않으며 너무 오래 기다리지 않습니다. 분석 워크로드의 경우 10~20~30분이 일반적이며 더 긴 경우도 있습니다.

다음으로 연결된 클라이언트 옵션이 있습니다. 이미 대시보드를 만들고 여기에 주요 가용성 지표를 게시한 경우 연결된 클라이언트에 대한 추가 정보를 거기에 추가할 수도 있습니다.

연결된 클라이언트에 대한 정보는 PostgreSQL 관점에서 볼 때 클라이언트가 다르기 때문에 중요합니다. 좋은 고객도 있고 나쁜 고객도 있습니다.

간단한 예입니다. 고객이 애플리케이션을 이해합니다. 애플리케이션은 데이터베이스에 연결되어 즉시 요청을 보내기 시작하고, 데이터베이스는 이를 처리하고 실행하며 결과를 클라이언트에 반환합니다. 이들은 훌륭하고 올바른 고객입니다.

클라이언트가 연결되어 연결을 유지하지만 아무 작업도 수행하지 않는 상황이 있습니다. 유휴 상태입니다.

하지만 나쁜 고객도 있습니다. 예를 들어, 동일한 클라이언트가 연결되어 트랜잭션을 열고 데이터베이스에서 작업을 수행한 다음 외부 소스에 액세스하거나 그곳에서 수신된 데이터를 처리하기 위해 코드로 들어갑니다. 그러나 그는 거래를 종료하지 않았습니다. 그리고 트랜잭션은 데이터베이스에 정지되고 라인에 잠금이 설정됩니다. 이것은 나쁜 상태입니다. 그리고 갑자기 내부 어딘가의 애플리케이션이 예외로 인해 실패하는 경우 트랜잭션은 매우 오랫동안 열려 있을 수 있습니다. 이는 PostgreSQL 성능에 직접적인 영향을 미칩니다. PostgreSQL은 속도가 느려집니다. 따라서 이러한 클라이언트를 적시에 추적하고 해당 작업을 강제로 종료하는 것이 중요합니다. 그리고 그러한 상황이 발생하지 않도록 애플리케이션을 최적화해야 합니다.

다른 나쁜 클라이언트가 클라이언트를 기다리고 있습니다. 그러나 상황 때문에 그들은 나빠진다. 예를 들어 간단한 유휴 트랜잭션이 있습니다. 트랜잭션을 열고 일부 라인에 잠금을 적용한 다음 코드 어딘가에서 실패하여 트랜잭션이 정지될 수 있습니다. 다른 클라이언트가 와서 동일한 데이터를 요청하지만 정지된 트랜잭션이 이미 일부 필수 행에 잠금을 보유하고 있기 때문에 잠금에 직면하게 됩니다. 그리고 두 번째 트랜잭션은 첫 번째 트랜잭션이 완료될 때까지 기다리거나 관리자가 강제로 닫을 때까지 기다리게 됩니다. 따라서 보류 중인 트랜잭션이 누적되어 데이터베이스 연결 제한을 채울 수 있습니다. 그리고 한도가 가득 차면 애플리케이션은 더 이상 데이터베이스에서 작동할 수 없습니다. 이것은 이미 프로젝트의 긴급 상황입니다. 따라서 불량 클라이언트를 적시에 추적하고 대응해야 합니다.

모니터링의 또 다른 예입니다. 그리고 여기에는 이미 괜찮은 대시보드가 ​​있습니다. 위에 연결에 대한 정보가 있습니다. DB 연결 – 8개. 그리고 그게 전부입니다. 어떤 클라이언트가 활성 상태인지, 어떤 클라이언트가 아무것도 하지 않고 유휴 상태인지에 대한 정보가 없습니다. 보류 중인 트랜잭션 및 보류 중인 연결에 대한 정보가 없습니다. 즉, 이것은 연결 수를 보여주는 수치이고 그게 전부입니다. 그런 다음 스스로 추측하십시오.

따라서 이 정보를 모니터링에 추가하려면 pg_stat_activity 시스템 뷰에 접근해야 합니다. PostgreSQL에서 많은 시간을 보낸다면 이것은 PostgreSQL의 현재 활동, 즉 그 안에서 무슨 일이 일어나고 있는지 보여주기 때문에 친구가 되어야 할 매우 좋은 보기입니다. 각 프로세스에는 이 프로세스에 대한 정보를 표시하는 별도의 줄이 있습니다. 연결이 이루어진 호스트, 사용자, 이름, 트랜잭션이 시작된 시기, 현재 실행 중인 요청, 마지막으로 실행된 요청 등이 표시됩니다. 따라서 stat 필드를 사용하여 클라이언트의 상태를 평가할 수 있습니다. 상대적으로 말하자면, 이 필드를 기준으로 그룹화하여 현재 데이터베이스에 있는 통계와 데이터베이스에 이 통계가 있는 연결 수를 얻을 수 있습니다. 그리고 이미 수신된 수치를 모니터링에 전송하고 이를 기반으로 그래프를 그릴 수 있습니다.
거래 기간을 평가하는 것도 중요합니다. 진공 기간을 평가하는 것이 중요하다고 이미 말했지만 거래도 같은 방식으로 평가됩니다. xact_start 및 query_start 필드가 있습니다. 상대적으로 말하면 트랜잭션 시작 시간과 요청 시작 시간을 표시합니다. 현재 타임스탬프를 표시하는 now() 함수를 사용하여 트랜잭션과 요청 타임스탬프를 뺍니다. 그리고 우리는 거래 기간, 요청 기간을 얻습니다.

긴 트랜잭션이 보이면 이미 완료해야 합니다. OLTP 로드의 경우 긴 트랜잭션은 이미 1-2-3분을 초과합니다.. OLAP 워크로드의 경우 긴 트랜잭션이 일반적이지만 완료하는 데 XNUMX시간 이상이 걸린다면 이는 어딘가에 불균형이 있다는 신호이기도 합니다.

클라이언트가 데이터베이스에 연결되면 데이터 작업을 시작합니다. 테이블에 액세스하고 인덱스에 액세스하여 테이블에서 데이터를 가져옵니다. 그리고 클라이언트가 이 데이터와 상호 작용하는 방식을 평가하는 것이 중요합니다.

이는 작업량을 평가하고 어떤 테이블이 "가장 인기 있는" 테이블인지 대략적으로 이해하는 데 필요합니다. 예를 들어, 일종의 빠른 SSD 스토리지에 "핫" 테이블을 배치하려는 상황에 필요합니다. 예를 들어, 오랫동안 사용하지 않은 일부 아카이브 테이블은 일종의 "콜드" 아카이브, SATA 드라이브로 이동하여 그곳에 보관할 수 있으며 필요에 따라 액세스할 수 있습니다.

이는 릴리스 및 배포 후 이상 현상을 감지하는 데에도 유용합니다. 프로젝트가 몇 가지 새로운 기능을 출시했다고 가정해 보겠습니다. 예를 들어, 데이터베이스 작업을 위한 새로운 기능을 추가했습니다. 그리고 테이블 사용량 그래프를 그리면 이러한 그래프에서 이러한 이상 현상을 쉽게 감지할 수 있습니다. 예를 들어 버스트를 업데이트하거나 버스트를 삭제합니다. 그것은 매우 눈에 띄게 될 것입니다.

또한 "부동" 통계에서 이상 징후를 감지할 수도 있습니다. 무슨 뜻이에요? PostgreSQL에는 매우 강력하고 우수한 쿼리 플래너가 있습니다. 그리고 개발자들은 개발에 많은 시간을 할애합니다. 그는 어떻게 일합니까? 좋은 계획을 세우기 위해 PostgreSQL은 특정 시간 간격과 특정 빈도로 테이블의 데이터 분포에 대한 통계를 수집합니다. 가장 일반적인 값은 고유 값의 수, 테이블의 NULL에 대한 정보, 많은 정보입니다.

플래너는 이러한 통계를 바탕으로 여러 쿼리를 구성하고 가장 최적의 쿼리를 선택하며, 이 쿼리 계획을 사용하여 쿼리 자체를 실행하고 데이터를 반환합니다.

그리고 통계가 "부동"되는 일이 발생합니다. 테이블의 품질 및 수량 데이터가 어떻게 든 변경되었지만 통계가 수집되지 않았습니다. 그리고 형성된 계획이 최적이 아닐 수도 있습니다. 그리고 테이블을 기반으로 수집된 모니터링을 기반으로 우리의 계획이 최적이 아닌 것으로 판명되면 이러한 이상 현상을 확인할 수 있습니다. 예를 들어, 데이터가 질적으로 변경되고 인덱스 대신 테이블을 통한 순차적 전달이 사용되기 시작했습니다. 쿼리가 100개의 행만 반환해야 하는 경우(100개 제한) 이 쿼리에 대해 전체 검색이 수행됩니다. 그리고 이는 항상 성능에 매우 나쁜 영향을 미칩니다.

그리고 우리는 이것을 모니터링에서 볼 수 있습니다. 그리고 이미 이 쿼리를 보고 이에 대한 설명을 실행하고 통계를 수집하고 새로운 추가 인덱스를 구축합니다. 그리고 이미 이 문제에 대응하고 있습니다. 그것이 중요한 이유입니다.

모니터링의 또 다른 예입니다. 워낙 인기가 많아서 알아보시는 분들이 많은 것 같아요. 누가 프로젝트에서 그것을 사용합니까? 프로 메테우스? Prometheus와 함께 이 제품을 사용하는 사람은 누구입니까? 사실 이 모니터링의 표준 저장소에는 PostgreSQL 작업을 위한 대시보드가 ​​있습니다. postgres_exporter 프로메테우스. 그러나 한 가지 나쁜 세부 사항이 있습니다.

여러 그래프가 있습니다. 그리고 바이트는 단위로 표시됩니다. 즉, 5개의 그래프가 있습니다. 데이터 삽입, 데이터 업데이트, 데이터 삭제, 데이터 가져오기 및 데이터 반환이 있습니다. 단위 측정은 바이트입니다. 그러나 문제는 PostgreSQL의 통계가 데이터를 튜플(행)로 반환한다는 것입니다. 따라서 이러한 그래프는 작업 부하를 여러 번, 수십 번 과소평가하는 매우 좋은 방법입니다. 튜플은 바이트가 아니고, 튜플은 문자열이며, 많은 바이트이고 항상 가변 길이이기 때문입니다. 즉, 튜플을 사용하여 작업량을 바이트 단위로 계산하는 것은 비현실적이거나 매우 어려운 작업입니다. 따라서 대시보드나 내장 모니터링을 사용할 때 올바르게 작동하고 올바르게 평가된 데이터를 반환한다는 점을 이해하는 것이 항상 중요합니다.

이 테이블에 대한 통계를 얻는 방법은 무엇입니까? 이를 위해 PostgreSQL에는 특정 뷰 계열이 있습니다. 그리고 메인뷰는 pg_stat_user_tables. User_tables - 이는 사용자를 대신하여 생성된 테이블을 의미합니다. 대조적으로, PostgreSQL 자체에서 사용되는 시스템 뷰가 있습니다. 그리고 시스템 및 사용자 테이블을 모두 포함하는 요약 테이블 Alltables가 있습니다. 당신이 가장 좋아하는 것부터 시작할 수 있습니다.

위 필드를 사용하여 삽입, 업데이트 및 삭제 횟수를 추정할 수 있습니다. 제가 사용한 대시보드의 예에서는 이러한 필드를 사용하여 워크로드의 특성을 평가합니다. 따라서 우리는 이를 기반으로 구축할 수도 있습니다. 하지만 이는 바이트가 아닌 튜플이므로 바이트 단위로만 수행할 수는 없다는 점을 기억할 가치가 있습니다.

이 데이터를 기반으로 소위 TopN 테이블을 구축할 수 있습니다. 예를 들어 상위 5개, 상위 10개입니다. 그리고 다른 것보다 더 많이 재활용되는 핫 테이블을 추적할 수도 있습니다. 예를 들어 삽입을 위한 5개의 "핫" 테이블이 있습니다. 그리고 이러한 TopN 테이블을 사용하여 워크로드를 평가하고 릴리스, 업데이트 및 배포 후 워크로드 급증을 평가할 수 있습니다.

개발자가 새로운 기능을 출시하는 경우가 있는데, 데이터 양을 추가하기로 결정했지만 이것이 어떤 영향을 미칠지 예측하지 못했기 때문에 테이블 크기가 커지기 시작하기 때문에 테이블 크기를 평가하는 것도 중요합니다. 데이터베이스의 크기. 그러한 경우는 우리에게도 놀라운 일입니다.

이제 작은 질문이 있습니다. 데이터베이스 서버의 로드를 발견하면 어떤 질문이 떠오르나요? 다음 질문은 무엇입니까?

그러나 실제로 다음과 같은 질문이 발생합니다. 로드로 인해 어떤 요청이 발생합니까? 즉, 부하로 인해 발생하는 프로세스를 살펴보는 것은 흥미롭지 않습니다. 호스트에 데이터베이스가 있으면 데이터베이스가 그곳에서 실행되고 있고 데이터베이스만 그곳에서 삭제될 것이 분명합니다. Top을 열면 PostgreSQL에서 작업 중인 프로세스 목록이 표시됩니다. Top에서는 그들이 무엇을 하고 있는지 명확하지 않습니다.

따라서 일반적으로 쿼리를 튜닝하면 PostgreSQL이나 운영 체제 구성을 튜닝하거나 심지어 하드웨어를 튜닝하는 것보다 더 많은 이익을 얻을 수 있으므로 가장 높은 로드를 유발하는 쿼리를 찾아야 합니다. 내 추정에 따르면 이는 약 80-85-90%입니다. 그리고 이것은 훨씬 더 빨리 이루어집니다. 구성을 수정하거나, 특히 데이터베이스를 다시 시작할 수 없는 경우 다시 시작을 예약하거나, 하드웨어를 추가하는 것보다 요청을 수정하는 것이 더 빠릅니다. 쿼리를 어딘가에 다시 작성하거나 인덱스를 추가하여 이 쿼리에서 더 나은 결과를 얻는 것이 더 쉽습니다.

따라서 요청과 그 적절성을 모니터링할 필요가 있습니다. 모니터링의 또 다른 예를 들어보겠습니다. 그리고 여기도 모니터링이 뛰어난 것 같습니다. 복제에 대한 정보가 있고, 처리량, 차단, 리소스 활용도에 대한 정보가 있습니다. 모든 것이 정상이지만 요청에 대한 정보가 없습니다. 우리 데이터베이스에서 어떤 쿼리가 실행되고 있는지, 얼마나 오랫동안 실행되고 있는지, 이러한 쿼리가 몇 개인지는 명확하지 않습니다. 모니터링에는 항상 이 정보가 필요합니다.

그리고 이 정보를 얻으려면 pg_stat_statements 모듈을 사용할 수 있습니다. 이를 기반으로 다양한 그래프를 구축할 수 있습니다. 예를 들어 가장 자주 실행되는 쿼리, 즉 가장 자주 실행되는 쿼리에 대한 정보를 얻을 수 있습니다. 예, 배포 후에 이를 살펴보고 요청이 급증하는지 파악하는 것도 매우 유용합니다.

가장 긴 쿼리, 즉 완료하는 데 가장 오랜 시간이 걸리는 쿼리를 모니터링할 수 있습니다. 프로세서에서 실행되며 I/O를 소비합니다. total_time,mean_time, blk_write_time 및 blk_read_time 필드를 사용하여 이를 평가할 수도 있습니다.

리소스 사용 측면에서 가장 과중한 요청, 즉 디스크에서 읽는 요청, 메모리를 사용하는 요청, 또는 반대로 일종의 쓰기 부하를 생성하는 요청을 평가하고 모니터링할 수 있습니다.

우리는 가장 관대한 요청을 평가할 수 있습니다. 이는 많은 수의 행을 반환하는 쿼리입니다. 예를 들어 제한 설정을 잊어버린 요청이 있을 수 있습니다. 그리고 단순히 쿼리된 테이블 전체에 걸쳐 테이블 또는 쿼리의 전체 내용을 반환합니다.

또한 임시 파일이나 임시 테이블을 사용하는 쿼리를 모니터링할 수도 있습니다.

그리고 여전히 백그라운드 프로세스가 있습니다. 백그라운드 프로세스는 기본적으로 체크포인트이거나 체크포인트라고도 하며 autovacuum 및 복제입니다.

모니터링의 또 다른 예입니다. 왼쪽에 유지 관리 탭이 있습니다. 해당 탭으로 이동하여 유용한 정보를 확인하시기 바랍니다. 하지만 여기는 진공작업과 통계 수집의 시간일 뿐, 그 이상은 아니다. 이는 매우 빈약한 정보이므로 데이터베이스에서 백그라운드 프로세스가 어떻게 작동하는지, 해당 작업에 문제가 있는지에 대한 정보가 항상 필요합니다.

체크포인트를 볼 때 체크포인트는 샤딩된 메모리 영역에서 더티 페이지를 디스크로 플러시한 다음 체크포인트를 생성한다는 점을 기억해야 합니다. 그리고 이 체크포인트는 PostgreSQL이 긴급 상황으로 인해 갑자기 종료된 경우 복구 장소로 사용될 수 있습니다.

따라서 모든 "더티" 페이지를 디스크로 플러시하려면 일정량의 쓰기 작업을 수행해야 합니다. 그리고 일반적으로 메모리가 많은 시스템에서는 이는 많은 양입니다. 그리고 짧은 간격으로 체크포인트를 매우 자주 수행하면 디스크 성능이 크게 저하됩니다. 그리고 클라이언트 요청은 리소스 부족으로 인해 어려움을 겪게 됩니다. 그들은 자원을 놓고 경쟁하고 생산성이 부족합니다.

따라서 지정된 필드를 사용하는 pg_stat_bgwriter를 통해 발생하는 체크포인트 수를 모니터링할 수 있습니다. 그리고 특정 기간(10-15-20분, 3분) 동안 체크포인트가 많으면(예: 4-5-XNUMX) 이는 이미 문제가 될 수 있습니다. 그리고 이미 데이터베이스를 살펴보고 구성을 살펴보아야 합니다. 이렇게 많은 체크포인트가 발생하는 원인은 무엇입니까? 어쩌면 어떤 종류의 대규모 녹음이 진행되고 있을 수도 있습니다. 이미 워크로드 그래프를 추가했기 때문에 워크로드를 평가할 수 있습니다. 우리는 이미 체크포인트 매개변수를 조정하여 쿼리 성능에 큰 영향을 미치지 않도록 할 수 있습니다.

앞서 말했듯이 Autovacuum은 디스크와 쿼리 성능을 쉽게 합산할 수 있으므로 Autovacuum의 양을 예측하는 것이 항상 중요하기 때문에 다시 Autovacuum으로 돌아갑니다.

데이터베이스의 Autovacuum 작업자 수는 제한되어 있습니다. 기본적으로 그 중 XNUMX개가 있으므로 데이터베이스에서 항상 XNUMX명의 작업자가 작업한다면 이는 autovacuum이 구성되지 않았음을 의미하므로 제한을 높이고 autovacuum 설정을 수정한 후 구성에 들어가야 합니다.
우리가 어떤 진공청소기 작업자를 보유하고 있는지 평가하는 것이 중요합니다. 사용자가 시작했거나 DBA가 와서 수동으로 일종의 진공을 시작했고 이로 인해 부하가 발생했습니다. 어떤 종류의 문제가 있습니다. 또는 이것은 거래 카운터를 푸는 진공 청소기의 수입니다. 일부 PostgreSQL 버전의 경우 이는 매우 큰 진공 상태입니다. 그리고 전체 테이블을 읽고 해당 테이블의 모든 블록을 스캔하기 때문에 성능을 쉽게 추가할 수 있습니다.

그리고 물론, 진공청소 기간도 마찬가지입니다. 매우 오랫동안 작동하는 오래 지속되는 진공청소기가 있는 경우 이는 진공청소기 구성에 다시 주의를 기울이고 해당 설정을 다시 고려해야 함을 의미합니다. 테이블에 진공청소기를 오랫동안(3~4시간) 작동시키면 상황이 발생할 수 있지만, 진공청소기가 작동하는 동안 테이블에 다시 대량의 데드 로우가 쌓이는 현상이 발생하기 때문입니다. 그리고 진공청소가 완료되자마자 그는 이 테이블을 다시 진공청소기로 청소해야 합니다. 그리고 우리는 끝없는 진공상태에 빠지게 됩니다. 그리고 이 경우 진공 상태가 작업에 대처하지 못하고 유용한 데이터의 양은 동일하게 유지되지만 테이블의 크기가 점차 커지기 시작합니다. 따라서 오랜 공백 기간 동안 우리는 항상 구성을 살펴보고 최적화하려고 노력하지만 동시에 클라이언트 요청 성능이 저하되지 않도록 합니다.

요즘에는 스트리밍 복제 기능이 없는 PostgreSQL 설치가 거의 없습니다. 복제는 마스터에서 복제본으로 데이터를 이동하는 프로세스입니다.

PostgreSQL의 복제는 트랜잭션 로그를 통해 수행됩니다. 마법사가 트랜잭션 로그를 생성합니다. 트랜잭션 로그는 네트워크 연결을 통해 복제본으로 이동한 다음 복제본에서 재생됩니다. 간단 해.

따라서 pg_stat_replication 뷰는 복제 지연을 모니터링하는 데 사용됩니다. 그러나 그녀의 모든 것이 단순하지는 않습니다. 버전 10에서는 보기가 몇 가지 변경되었습니다. 첫째, 일부 필드의 이름이 변경되었습니다. 그리고 일부 필드가 추가되었습니다. 버전 10에서는 복제 지연을 초 단위로 추정할 수 있는 필드가 나타났습니다. 매우 편안합니다. 버전 10 이전에는 복제 지연을 바이트 단위로 추정할 수 있었습니다. 이 옵션은 버전 10에도 그대로 유지됩니다. 즉, 지연 시간을 바이트 단위로 추정하거나 지연 시간을 초 단위로 추정하는 등 자신에게 더 편리한 것을 선택할 수 있습니다. 많은 사람들이 두 가지를 모두 수행합니다.

그럼에도 불구하고 복제 지연을 평가하려면 트랜잭션에서 로그의 위치를 ​​알아야 합니다. 그리고 이러한 트랜잭션 로그 위치는 정확히 pg_stat_replication 뷰에 있습니다. 상대적으로 말하면 pg_xlog_location_diff() 함수를 사용하여 트랜잭션 로그에서 두 지점을 가져올 수 있습니다. 그들 사이의 델타를 계산하고 복제 지연을 바이트 단위로 가져옵니다. 매우 편리하고 간단합니다.

버전 10에서는 이 함수의 이름이 pg_wal_lsn_diff()로 변경되었습니다. 일반적으로 "xlog"라는 단어가 발견된 모든 기능, 보기 및 유틸리티에서는 "wal"이라는 값으로 대체되었습니다. 이는 뷰와 기능 모두에 적용됩니다. 이것은 정말 혁신입니다.

게다가 버전 10에서는 지연을 구체적으로 보여주는 줄이 추가되었습니다. 쓰기 지연, 플러시 지연, 재생 지연이 있습니다. 즉, 이러한 사항을 모니터링하는 것이 중요합니다. 복제 지연이 있는 것으로 확인되면 복제 지연이 발생한 이유, 출처를 조사하고 문제를 해결해야 합니다.

거의 모든 것이 시스템 측정항목과 일치합니다. 모니터링이 시작되면 시스템 측정항목으로 시작됩니다. 이는 프로세서, 메모리, 스왑, 네트워크 및 디스크를 폐기하는 것입니다. 그러나 기본적으로는 많은 매개변수가 없습니다.

재활용 프로세스에 모든 것이 순조롭게 진행된다면 디스크 재활용에 문제가 있는 것입니다. 일반적으로 모니터링 개발자는 처리량에 대한 정보를 추가합니다. iops 또는 바이트 단위일 수 있습니다. 그러나 그들은 디스크 장치의 대기 시간과 활용도를 잊어버립니다. 이는 디스크가 얼마나 로드되고 얼마나 느린지 평가할 수 있는 더 중요한 매개변수입니다. 대기 시간이 길면 디스크에 문제가 있음을 의미합니다. 활용도가 높다면 디스크가 대처할 수 없다는 의미입니다. 이는 처리량보다 더 나은 특성입니다.

또한 이러한 통계는 프로세서 재활용과 마찬가지로 /proc 파일 시스템에서도 얻을 수 있습니다. 왜 이 정보가 모니터링에 추가되지 않는지 모르겠습니다. 그러나 그럼에도 불구하고 이를 모니터링하는 것이 중요합니다.

네트워크 인터페이스에도 동일하게 적용됩니다. 패킷, 바이트 단위의 네트워크 처리량에 대한 정보가 있지만 그럼에도 불구하고 대기 시간에 대한 정보는 없으며 활용도에 대한 정보도 없습니다. 이는 유용한 정보이기도 합니다.

모든 모니터링에는 단점이 있습니다. 그리고 어떤 종류의 모니터링을 수행하더라도 항상 특정 기준을 충족하지 못합니다. 그럼에도 불구하고 계속해서 발전하고 있고, 새로운 기능과 새로운 것들이 추가되고 있으니, 뭔가를 선택해서 마무리해 보세요.

그리고 끝내기 위해서는 제공된 통계가 무엇을 의미하는지, 그리고 이를 어떻게 문제 해결에 사용할 수 있는지에 대한 아이디어를 항상 가지고 있어야 합니다.

그리고 몇 가지 핵심 사항은 다음과 같습니다.

• 항상 가용성을 모니터링하고 대시보드를 갖추어야 데이터베이스에 모든 것이 제대로 되어 있는지 신속하게 평가할 수 있습니다.
• 나쁜 클라이언트를 걸러내고 격추시키기 위해서는 항상 어떤 클라이언트가 데이터베이스로 작업하고 있는지에 대한 아이디어가 필요합니다.
• 이러한 클라이언트가 데이터를 사용하는 방식을 평가하는 것이 중요합니다. 작업량에 대한 아이디어가 필요합니다.
• 어떤 쿼리를 사용하여 이 워크로드가 어떻게 형성되는지 평가하는 것이 중요합니다. 쿼리를 평가하고, 최적화하고, 리팩터링하고, 인덱스를 구축할 수 있습니다. 그것은 매우 중요합니다.
• 백그라운드 프로세스는 클라이언트 요청에 부정적인 영향을 미칠 수 있으므로 리소스를 너무 많이 사용하지 않는지 모니터링하는 것이 중요합니다.
• 시스템 지표를 사용하면 서버 용량 확장 및 증가에 대한 계획을 세울 수 있으므로 이를 추적하고 평가하는 것도 중요합니다.

이 주제에 관심이 있다면 다음 링크를 따라갈 수 있습니다.
http://bit.do/stats_collector - 이것은 통계 수집기의 공식 문서입니다. 모든 통계 보기에 대한 설명과 모든 필드에 대한 설명이 있습니다. 읽고, 이해하고, 분석할 수 있습니다. 그리고 이를 바탕으로 그래프를 작성하고 모니터링에 추가하세요.

요청 예시:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

이것은 우리 회사 저장소이자 내 저장소입니다. 여기에는 예제 쿼리가 포함되어 있습니다. 거기에는 시리즈의 select*에 대한 쿼리가 없습니다. 원시 숫자를 읽기 쉽고 편리한 값(예: 바이트, 시간)으로 변환할 수 있는 흥미로운 함수를 사용하는 조인이 포함된 기성 쿼리가 이미 있습니다. 이를 선택하고, 살펴보고, 분석하고, 모니터링에 추가하고, 이를 기반으로 모니터링을 구축할 수 있습니다.

질문

질문: 브랜드 광고를 하지 않겠다고 하셨는데, 프로젝트에서는 어떤 종류의 대시보드를 사용하시나요?
대답: 다양합니다. 우리가 고객을 방문했는데 그 고객은 이미 자체 모니터링을 갖고 있었습니다. 그리고 모니터링에 추가해야 할 사항을 고객에게 조언합니다. 최악의 상황은 Zabbix의 경우입니다. TopN 그래프를 구축하는 기능이 없기 때문입니다. 우리는 스스로 사용합니다 오크미터, 왜냐하면 우리는 이 사람들과 모니터링에 관해 상담을 하고 있었기 때문입니다. 그들은 우리의 기술 사양을 기반으로 PostgreSQL을 모니터링했습니다. 저는 Prometheus를 통해 데이터를 수집하고 이를 렌더링하는 나만의 애완동물 프로젝트를 작성하고 있습니다. 그라 파나. 내 임무는 Prometheus에서 나만의 내보내기 도구를 만든 다음 Grafana에서 모든 것을 렌더링하는 것입니다.

질문: AWR 보고서나... 집계와 유사한 것이 있습니까? 이런 것에 대해 알고 있나요?
대답: 네, 저는 AWR이 무엇인지 압니다. 그것은 멋진 일입니다. 현재 대략 다음 모델을 구현하는 다양한 자전거가 있습니다. 일정한 시간 간격을 두고 일부 기준선이 동일한 PostgreSQL 또는 별도의 스토리지에 기록됩니다. 인터넷에서 구글에 검색해 보면 거기에 있습니다. 그러한 개발자 중 한 명이 PostgreSQL 스레드의 sql.ru 포럼에 앉아 있습니다. 거기서 그를 잡을 수 있어요. 예, 그런 것이 있습니다. 사용할 수 있습니다. 게다가 그 안에는 pgCenter 나는 또한 당신이 같은 일을 할 수 있도록 하는 글을 쓰고 있습니다.

PS1 postgres_exporter를 사용하는 경우 어떤 대시보드를 사용하고 있습니까? 그 중 몇 가지가 있습니다. 그들은 이미 구식입니다. 어쩌면 커뮤니티에서 업데이트된 템플릿을 만들 수도 있을까요?

PS2 pganalyze는 성능 모니터링 및 자동화된 조정 제안에 초점을 맞춘 독점 SaaS 제품이므로 제거되었습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

어떤 자체 호스팅 postgresql 모니터링(대시보드 포함)이 가장 좋다고 생각하시나요?

• 30,0%Zabbix + Alexey Lesovsky 또는 zabbix 4.4 또는 libzbxpgsql + zabbix libzbxpgsql + zabbix3의 추가 기능

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalyze는 독점 SaaS이므로 삭제할 수 없습니다1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10명의 사용자가 투표했습니다. 26명의 사용자가 기권했습니다.

출처 : habr.com