ZabbixでのPostgreSQL監視の設定

PostgreSQLは最新の動的に開発されるDBMSであり、非常に幅広い機能を備えているため、最も広範なタスクを解決できます。 PostgreSQLの使用とは、通常、データの処理と保存に関連するITインフラストラクチャの非常に重要なセグメントを指します。 インフラストラクチャ内のDBMSの特別な場所とそれに割り当てられたタスクの重要度を考慮すると、DBMSの動作を監視し、適切に制御するという疑問が生じます。 この点で、PostgreSQLには統計を収集および保存するための広範な内部ツールがあります。 収集された統計により、DBMSの動作中に内部で何が起こるかについてかなり詳細な画像を取得できます。 これらの統計は特別なシステムビューテーブルに保存され、常に更新されます。 これらのテーブルに対して通常のSQLクエリを実行すると、データベース、テーブル、インデックス、およびDBMSの他のサブシステムに関するさまざまなデータを取得できます。
以下では、Zabbix監視システムでPostgreSQLを監視する方法とツールについて説明します。 この監視システムは、さまざまなシステムやプロセスの最もカスタムな監視を実装する絶好の機会を提供するため、気に入っています。

監視は、統計テーブルへのSQLクエリに基づきます。 クエリ自体は、zabbixエージェントの追加の設定ファイルとして実行されます。このファイルでは、SQLクエリがいわゆるラップされています。 UserParameters-ユーザー監視パラメーター。 Zabbixのユーザーパラメーターは、非標準のもの（ここではPostgreSQLの操作パラメーターなど）の監視を構成できる優れた方法です。 各ユーザーパラメータは、 キー名とコマンドの2つの要素で構成されます。 キー名は、他のキー名と交差しない一意の名前です。 コマンドは、zabbixエージェントが実行する必要がある実際のアクションコマンドです。 拡張バージョンでは、このコマンドにさまざまなパラメーターを渡すことができます。 zabbix構成では、次のようになります。

UserParameter=custom.simple.key,/usr/local/bin/simple-script UserParameter=custom.ext.key[*],/usr/local/bin/ext-script $1 $2 

したがって、PostgreSQL統計へのすべてのクエリは、ユーザーパラメータにラップされたpsqlクライアントクエリです。

強み：

• 監視対象ノードを設定するための最小要件-最も単純な場合、設定を追加してzabbixエージェントを再起動します（難しいケースには、PostgreSQLへのアクセス権の調整が含まれます）。
• PostgreSQLに接続するためのパラメーターの設定、およびトリガーのしきい値は、Webインターフェイスのマクロ変数を介して実行されます-このように、トリガーに登り、異なるホストの異なるしきい値の場合にテンプレートを作成する必要はありません（マクロをホストに割り当てることができます）;
• 収集された幅広いデータ（接続、トランザクション時間、データベースとテーブルの統計、ストリーミング複製など）。
• データベース、テーブル、およびスタンバイサーバーの低レベルの検出。

弱点：

• 観察された多くのパラメータ、誰かが何かを無効にしたいかもしれません。
• PostgreSQLのバージョンによっては、動作しないものもあります。 特に、これはレプリケーションの監視に関するものです。 一部の機能は、古いバージョンでは使用できません。 バージョン9.2以降に注目して書かれました。
• また、いくつかの点で、インストールされた拡張機能 pg_stat_statementsおよびpg_buffercacheの存在が必要です-拡張機能がインストールされていない場合、一部のパラメーターは観察できません。

監視機能：

• チェックポイントのプロセスで割り当てられ記録されたバッファ、チェックポイント、記録時間の情報-pg_stat_bgwriter
• 共有バッファに関する一般情報-pg_buffercache拡張機能はここで必要です。 また、これらの統計情報の要求はリソースを集中的に使用するため、拡張機能のドキュメントに反映されるため、必要に応じて、ポーリング間隔を長くするか、パラメーターを完全にオフにすることもできます。
• サービスに関する一般情報-稼働時間、応答時間、キャッシュヒット率、平均リクエスト時間。
• クライアント接続とクエリ/トランザクション実行時間に関する情報-pg_stat_activity 。
• すべてのデータベースのデータベースサイズと要約統計（コミット/ロールバック、読み取り/書き込み、一時ファイル） -pg_stat_database
• プライベート統計（読み取り/書き込み、バキューム/分析などのユーティリティタスクの数） -pg_stat_user_tables 、 pg_statio_user_tables 。
• ストリーミングレプリケーションに関する情報（サーバーステータス、レプリカの数、それらの遅れ） -pg_stat_replication
• その他（テーブル内の行数、トリガーの存在、構成パラメーター、WALログ）

さらに、統計データを収集するには、postgresql.confに次のパラメーターを含める必要があることに注意してください。
track_activities-すべてのクライアントプロセスによる追跡コマンド（クエリ/ステートメント）が含まれます。
track_counts-テーブルとインデックスに関する統計の収集を含みます。

インストールとセットアップ。
構成する必要があるものはすべてGithubリポジトリにあります。

 # git clone https://github.com/lesovsky/zabbix-extensions/ # cp zabbix-extensions/files/postgresql/postgresql.conf /etc/zabbix/zabbix_agentd.d/ 

さらに、エージェントからのリクエストを満たすためには、pg_hba設定で適切なアクセスを定義する必要があることに注意する必要があります-エージェントはターゲットデータベースでpostgresサービスとの接続を確立し、リクエストを実行できなければなりません。 最も単純な場合、次の行をpg_hba.confに追加する必要があります（ファイルの場所はディストリビューションによって異なる場合があります）-postgresに代わってlocalhostでmydbデータベースに接続できます。

 host mydb postgres 127.0.0.1/32 trust 

pg_hba.confを変更した後、postgresqlサービスがリロード（pg_ctl reload）を行う必要があることは忘れられません。 ただし、これは最も簡単なオプションであり、完全に安全ではないため、パスワードまたはより複雑なアクセススキームを使用する場合は、 pg_hbaと.pgpassを再度注意深く読んでください 。

したがって、構成ファイルはコピーされ、メイン構成にロードするために残ります。メインエージェント構成ファイルに、追加の構成ファイルが置かれている場所を示すパスを含むInclude行があることを確認します。 次に、エージェントを再起動します。その後、最も簡単なチェックを実行して作業を確認できます。pgsql.pingを使用し、角括弧内でpostgresへの接続オプションを指定します。これはクライアントにpsqlに渡されます。

 # systemctl restart zabbix-agent.service # zabbix-get -s 127.0.0.1 -k pgsql.ping['-h 127.0.0.1 -p 5432 -U postgres -d mydb'] 

アクセスを正しく登録すると、ミリ秒単位のサービス応答時間が返されます。 空の文字列が返された場合、pg_hbaへのアクセスに問題があります。 ストリングZBX_NOTSUPPORTEDが返された場合-構成がロードされなかった場合、エージェント構成、含めるパス、および構成に設定された権限を確認してください。

検証チームが正しい答えを返すと、テンプレートをダウンロードしてWebインターフェイスにアップロードし、ターゲットホストに割り当てることができます。 リポジトリ（postgresql-extended-template.xml）からテンプレートをダウンロードすることもできます。 インポート後、テンプレートのマクロ設定タブに移動して構成する必要があります。

以下はリストと簡単な説明です。

• PG_CONNINFO-これらは、リクエストの実行時にpsqlクライアントに渡される接続パラメーターです。 これは最も重要なマクロです postgresサービスに接続するためのパラメーターを定義します。 デフォルトで指定された行は、どのような場合でも多かれ少なかれ普遍的ですが、複数のサーバーがあり、各サーバーの設定が異なる場合、zabbixのホストに同じ名前のマクロを定義し、個別の値に設定できます。 チェックすると、ホストマクロがテンプレートマクロより優先されます。
• PG_CONNINFO_STANDBY-これらは、スタンバイサーバーへの要求を実行するときにpsqlユーティリティに渡される接続パラメーターです（レプリケーションラグを決定）。
• PG_CACHE_HIT_RATIO-これは、キャッシュで成功したヒットの割合に関するトリガーのしきい値です。 ヒットの割合がこのマークを下回っている場合、トリガーは機能します。
• PG_CHECKPOINTS_REQ_THRESHOLD-オンデマンドチェックポイントのしきい値
• PG_CONFLICTS_THRESHOLD-スタンバイサーバーで要求を実行するときに発生した競合のしきい値。
• PG_CONN_IDLE_IN_TRANSACTION-トランザクションをオープンし、同時に何もしない（不良トランザクション）接続のしきい値。
• PG_CONN_TOTAL_PCT-可能な最大接続数に対するオープン接続の割合のしきい値（100％の場合、すべてが終了すると）。
• PG_CONN_WAITING-他のリクエストが完了するのを待つブロックされたリクエストのしきい値。
• PG_DATABASE_SIZE_THRESHOLD-データベースサイズのしきい値。
• PG_DEADLOCKS_THRESHOLD-デッドロックのしきい値（残念ながら自動的に解決されますが、コードの記述が不十分である直接的な証拠であるため、可用性を認識することをお勧めします）。
• PG_LONG_QUERY_THRESHOLD-クエリ実行時間のしきい値。 実行時間がこのマークより長いリクエストがある場合、トリガーは機能します。
• PG_PING_THRESHOLD_MS-サービスの応答時間のしきい値。
• PG_SR_LAG_BYTE-レプリケーションラグのしきい値（バイト単位）。
• PG_SR_LAG_SEC-レプリケーションラグのしきい値（秒単位）。
• PG_UPTIME_THRESHOLD-稼働時間のしきい値（マークよりも低い稼働時間がサービスの再起動を意味する場合）。

トリガーのテキストから、これらのしきい値が必要な理由が明らかになるはずです。

• PostgreSQLのアクティブトランザクションをlongに-長いトランザクションまたはクエリを修正。
• PostgreSQLのキャッシュヒット率が低すぎます-キャッシュヒット率が低すぎます。
• PostgreSQLデッドロックが発生しました-デッドロックが修正されました。
• PostgreSQLは、高レベルへのトランザクション接続でアイドル状態-トランザクション状態でアイドル状態の多くの接続。
• PostgreSQLのアイドルトランザクションをlongに-トランザクション状態のidelの長いトランザクションを修正しました。
• PostgreSQLの待機接続の最大数-コミットされたクエリまたはトランザクションは保留中です。
• PostgreSQLリカバリの競合が発生しました-レプリカのリカバリ中に競合が検出されました。
• PostgreSQLが必要とするチェックポイントは頻繁に発生します-チェックポイントは頻繁に発生します。
• 長い-長い応答時間に対するPostgreSQLの応答。
• PostgreSQLサービスが実行されていません-サービスは実行されていません。
• PostgreSQLサービスが再起動されました-サービスが再起動しました。
• PostgreSQLの最大接続数-合計接続数が多すぎて、max_connectionsに近づいています。
• PostgreSQLがトランザクションを長時間待機しています-要求が長すぎるか、トランザクションが保留中です。
• PostgreSQLデータベース{#DBNAME}が大きい-データベースサイズが大きすぎます。
• {HOSTNAME}と{#HOTSTANDBY}の間のPostgreSQLストリーミングラグが高い-サーバー間のレプリケーションラグが大きすぎます。

低レベルの発見ルール

• PostgreSQLデータベースの検出-正規表現でフィルタリングする機能を備えた既存のデータベースの検出。 検出されると、サイズチャートが追加されます。
• PostgreSQLデータベーステーブルの検出-監視対象データベース内の既存のテーブルを検出し、正規表現でフィルタリングできます。 フィルターに注意して、本当に興味深いテーブルのみを追加してください。なぜなら、 このルールは、見つかったテーブルごとに21個のパラメーターを生成します。 検出されると、サイズ、スキャン、行の変更、および読み取り統計に関するグラフが追加されます。
• PostgreSQLストリーミングスタンバイディスカバリ-接続されたレプリカのディスカバリ。 検出されると、レプリケーションラグのあるスケジュールが追加されます。

使用可能なグラフ。グラフについて説明する場合、過度に多数のパラメーターでグラフをオーバーロードしないで、観測されたパラメーターをグループ化しようとしました。 したがって、pg_stat_user_tablesからの情報は4つのグラフに区切られます。

• PostgreSQL bgwriter-バッファで何が起こるかについての一般的な情報（割り当てられる量、書き込まれる量、書き込まれる方法）。
• PostgreSQLバッファ-共有バッファの状態に関する一般情報（バッファの数、使用される数、ダーティバッファの数）。
• PostgreSQLチェックポイント-発生するチェックポイントに関する情報。
• PostgreSQL接続-クライアント接続に関する情報。
• PostgreSQLサービスの応答-サービスの応答時間と平均クエリ実行時間。
• PostgreSQL要約DB統計：ブロックヒット/読み取り-キャッシュおよびディスクから読み取ります。
• PostgreSQL要約DB統計：イベント-データベース内のイベント（デッドロック、競合、コミット、ロールバック）。
• PostgreSQL要約DB統計：一時ファイル-一時ファイルに関する情報。
• PostgreSQLの要約データベースの統計：tuples-行の変更に関する一般情報。
• PostgreSQLトランザクション-クエリ実行時間。
• PostgreSQLの稼働時間-稼働時間とキャッシュヒットの割合。
• PostgreSQL先行書き込みログ-WALログに関する情報（記録ボリュームとファイル数）。
• PostgreSQL：データベース{#DBNAME}サイズ-データベースのサイズ変更に関する情報。
• PostgreSQLテーブル{#TABLENAME}メンテナンス-テーブルメンテナンス操作（autovacuum、autoanalyze、vacuum、analyze）。
• PostgreSQLテーブル{#TABLENAME} read stats-キャッシュ、ディスクからの読み取りに関する統計。
• PostgreSQLテーブル{#TABLENAME}行-行の変更。
• PostgreSQLテーブル{#TABLENAME}スキャン-スキャン情報（シーケンシャル/インデックススキャン）。
• PostgreSQLテーブル{#TABLENAME}サイズ-テーブルとそのインデックスのサイズに関する情報。
• {#HOTSTANDBY}でのPostgreSQLストリーミングレプリケーションラグ-レプリカサーバーでのレプリケーションラグのサイズ。

結論として、いくつかのグラフ例：
ここで見るように、一時ファイルはデータベースに定期的に作成されます。ログで犯人を探し、work_memを確認する必要があります。


ここでは、データベースで発生するイベント-コミット/ロールバックおよび競合/デッドロック-一般に、すべてがここで正常です。


ここで、サーバーの1つを使用したスト​​リーミングレプリケーションの状態は、秒とバイト単位の遅延時間です。


最後のスケジュールは、サービスの応答時間と平均リクエスト時間です。


それだけです、ご清聴ありがとうございました！