EssentialPostgreSQLモニタリング-パート1

PostgreSQLデプロイメントのどのメトリックを監視する必要がありますか？この一連のブログ投稿は、Postgresサーバーの正常性と安定性を確保するために実装する必要のある基本的な監視アクションの最小限の開始セットを提供することを目的としています。

最初の部分では、クラスターレベルのパラメーターについて説明します。

パート1：クラスターレベル

Postgresの専門用語では、クラスター は、singlePostgresサーバーインスタンスによって管理されるデータベースのセットです。レプリケーションやWALアーカイブなどの機能はクラスターレベルで機能します。

1。トランザクションIDの範囲

通常のクライアントの観点からは、PostgreSQLクラスターのデータファイルには、最後にコミットされたトランザクションによって変更されたデータのスナップショットが含まれているように見えます。ただし、PostgresのMVCCアーキテクチャにより、物理ファイルには最新のトランザクションのデータだけでなく、最新のトランザクションで終わる一連のトランザクションのデータが含まれています。 （通常のバキューム 古いトランザクションのデータを削除します。）

各トランザクションには、トランザクションIDと呼ばれる一意の32ビット整数識別子があります。 。さまざまな理由から、最初と最後のトランザクションIDの差は2未満、つまり約20億である必要があります。この制限を十分に下回る範囲を維持することは、必須 –そうでなければ何が起こるかについてのこの現実の物語を読んでください。

アクション：トランザクションIDの範囲を継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出します。

方法：

-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
       regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
  FROM pg_control_checkpoint();

-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
  FROM pg_database;

2。バックエンドの数

各バックエンドは、サーバーに接続されているクライアント、またはシステムバックエンドプロセス（自動バキュームワーカー、バックグラウンドライターなど）のいずれかを表します。各バックエンドは、メモリや開いているファイル記述子などのOSリソースを消費するOSプロセスでもあります。バックエンドが多すぎると、通常、クライアントが多すぎるか、実行時間の長いクエリが多すぎると、OSリソースに圧力がかかり、すべてのクライアントのクエリ応答時間が遅くなる可能性があります。

アクション：毎日/週の最大バックエンド数を監視し、増加する傾向を調査します。

方法：

-- returns the count of currently running backends
SELECT count(*)
  FROM pg_stat_activity;

3。非アクティブなレプリケーションスロット

スロットに接続されているレプリケーションクライアントが切断されると、レプリケーションスロットは「非アクティブ」としてマークされます。非アクティブなレプリケーションスロットでは、WALファイルが保持されます。これは、クライアントが再接続してスロットがアクティブになったときに、クライアントに送信する必要があるためです。実際、WALファイル数が減少しないかどうかを最初に確認するのは、非アクティブなレプリケーションスロットがあるかどうかを確認することです。

多くの場合、非アクティブなレプリケーションスロットは、削除されたバックアップクライアント、停止されたスレーブ、プロモーション、フェイルオーバーなどの結果です。

アクション：非アクティブなレプリケーションスロットを継続的にチェックし、存在する場合はアラートを出します。

方法：

-- returns the count of inactive replication slots
SELECT count(*)
  FROM pg_replication_slots
 WHERE NOT active;

4。ロックを待機しているバックエンド

SQLステートメントは、明示的または暗黙的に他のSQLステートメントを待機させることができます。たとえば、「SELECT .. FOR UPDATE」を実行すると、選択した行のロックが明示的に宣言され、「UPDATE」を実行すると、暗黙的な行専用ロックが設定されます。ロックが発生すると、最初のステートメントがロックを解放するまで待機してから、実行を続行する必要があります。

これは、毎週のレポート実行中のアプリケーションパフォーマンスの低下、トランザクション/Webページのタイムアウトなどとして現れる可能性があります。

ある程度のロックは避けられませんが、ロックを待機するバックエンドの増加傾向は、通常、クエリまたはアプリケーションロジックの再構築を必要とします。

アクション：毎日/週にロックを待機しているバックエンドの最大数を監視し、増加する傾向を調査します。

方法：

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE wait_event = 'Lock';

5。トランザクションでのバックエンドのアイドリング

長時間実行されるトランザクションは、PostgreSQLの世界ではあまり良くありません。それらは、WALファイルの蓄積を引き起こし、自動バキュームと手動バキュームを防ぎ、リソースを使い果たす可能性があります。完了するまでに長い時間がかかる本物のトランザクションについては何もできませんが、アプリケーション/スクリプトの動作に問題がある場合や、トランザクションを開始しても閉じない場合があるpsqlクライアントなどの場合があります。このようなクライアントにサービスを提供するバックエンドは、「トランザクションのアイドリング」として表示されます。

トランザクションでアイドリングしているバックエンドは、システムの安定性に影響を及ぼし始める前に、検出してシャットダウンする必要があります。

アクション：トランザクションでアイドリングしているバックエンドの数を継続的に監視し、見つかったかどうかを確認します。

方法：

-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE state = 'idle in transaction';

6。アクティブ接続のレプリケーションラグ

アクティブなストリーミングレプリケーションクライアント（ホットスタンバイなど）またはアクティブな論理レプリケーションクライアントがある場合、PostgresはWAL送信者と呼ばれるシステムバックエンドを実行します。 アクティブな（接続された）クライアントごとに。 WAL送信者は、クライアントが必要とするWALレコードデータを送信する責任があります。

レプリケーションクライアントは通常、プライマリにできる限り追いつくようにします。ただし、場合によっては、プライマリ側のWAL生成率が、クライアントがそれらを消費できる率よりも高くなることがあります。これにより、レプリケーションラグが発生します。 レプリケーション接続ごとに。

PostgreSQLは、書き込みラグ（送信されたがクライアントのディスクに書き込まれなかったバイト数）、フラッシュラグ（書き込まれたがクライアントのディスクにフラッシュされなかったバイト数）、および再生ラグ（フラッシュされたがクライアントのディスクに再生されなかったバイト数）を照会するメカニズムを提供します。データベースファイル）アクティブなWAL送信者ごとに。

アクション：アクティブな接続のレプリケーションラグを継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出します。

方法：

-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
       flush_lsn - write_lsn AS flush_lag,
       replay_lsn - flush_lsn AS replay_lag
  FROM pg_stat_replication;

7。レプリケーションスロットのレプリケーションラグ

レプリケーションクライアントは遅れるだけでなく、クラッシュ、トポロジの変更、または人為的エラーのために完全に消滅する可能性があります。また、クライアントが常にオンラインであるとは限らない設計による場合もあります。

クライアントがレプリケーションスロットによってバックアップされている場合、クライアントが中断したところから再開するために必要なすべてのWALファイルはPostgreSQLによって保持されます。 WALファイルは無期限に保持されます–制限を設定する方法はありません。クライアントが再接続するときは、保持されているすべてのデータをクライアントファーストにストリーミングする必要があります。これには、プライマリで大量のディスクおよびネットワークトラフィックが含まれる可能性があります。これらの理由から、スロットレベルでもラグを監視する必要があります。

（注：WAL送信者プロセスは、クライアントが接続されている場合にのみ実行され、クライアントが切断されると終了します。クライアントが切断されている場合、クライアントがどれだけ遅れているかを測定するWAL送信者の方法は機能しません。）

アクション：論理レプリケーションスロットのレプリケーションラグを継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出します。

方法：

-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
  FROM pg_replication_slots;

8。 WALファイル数

WALファイルの管理は、特にWALarchivingまたはストリーミングレプリケーションクライアントを使用している場合、厄介な作業になる可能性があります。 WALファイル数は明らかな理由なしに増加し始める可能性があり、WALアーカイブプロセスはWAL生成率に追いついていない可能性があり、WALファイルの合計サイズはテラバイトに達する可能性があります。

少なくとも、データベースディレクトリに存在するWALファイルの数を監視し、その数が展開に適していることを確認する必要があります。

アクション：WALファイル数を継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出します。

方法：

-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
  FROM pg_ls_waldir();

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';

-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'

9。すぐにアーカイブできるWALファイル数

WALアーカイブが有効になっている場合、PostgreSQLはnewWALファイルが生成されるたびにユーザースクリプトを呼び出します。スクリプトは、呼び出された単一のWALファイルを「アーカイブ」することになっています（通常、スクリプトは別のサーバーまたはS3バケットにコピーされます）。スクリプトがそのジョブを実行するのに時間がかかりすぎる場合、または失敗した場合、WALファイルのセットはアーカイブされます。

アクション：WALのアーカイブ準備完了ファイル数を継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出します。

方法：

-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
  FROM pg_ls_archive_statusdir()
 WHERE name ~ '^[0-9A-F]{24}.ready$';

-- same, for v10+
SELECT count(*)
  FROM pg_ls_dir('pg_wal/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .ready