PostgreSQLデプロイメントのどのメトリックを監視する必要がありますか?この一連のブログ投稿は、Postgresサーバーの正常性と安定性を確保するために実装する必要のある基本的な監視アクションの最小限の開始セットを提供することを目的としています。
これはブログシリーズの3番目で最後の部分であり、テーブル、インデックス、およびシステムレベルのメトリックをカバーしています。最初の1つはクラスターレベルのメトリックをカバーし、2つ目はデータベースレベルのメトリックをカバーしました。
通常、データベース内のデータは80-20の法則に従います。テーブルの20%にはほとんどのデータが含まれており、最もアクセスまたは変更されています。これらのテーブルに対してのみ追加の監視を設定すると、重要でありながら少量の洞察を得ることができます。
確認する価値のあるテーブルレベルの指標は次のとおりです。
1。テーブルサイズ
テーブルで使用される実際のディスクサイズを監視する必要があります。ほとんどの場合、テーブルは成長し続けるので、より興味深いのは成長率です。
多くの場合、アプリケーションの新しいバージョンのロールアウト後、またはアプリケーション自体のトラフィック/負荷/入力パターンのベースラインの変更後に、成長率が変化します。このような変更は、少なくともプロビジョニングされたハードウェアによって新しいレートが持続可能であることを確認するために調査する必要があります。
アクション:毎週/月ごとにテーブルのサイズの増加を監視し、急激な変化を調査します。
方法:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;
2。テーブルブロート
PostgresのMVCCアーキテクチャにより、古いバージョンの行はすべてのテーブルの物理データファイルに存在し、膨張と呼ばれます。 。廃止された行バージョンをクリアする操作は、バキュームと呼ばれます。 。 Postgresはautovacuumと呼ばれるバックグラウンドプロセスを実行します 、(構成可能なパラメーターに基づいて)候補テーブルを取得し、それらをバキュームします。
Bloatはテーブルの動作を遅くし、ディスクスペースを浪費し、自動真空でも逃げる可能性があります。膨張の監視は、絶対バイト数と(データ全体に対するデッドデータの)パーセンテージとして監視する必要があります。
このメトリックは、個々のテーブルレベルで、または選択したテーブル全体の集計として、またはデータベースレベルで監視できます。
アクション:テーブルの肥大化をバイトとパーセンテージで継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出し、必要に応じてVACUUMを実行します。
方法:
check_postgres orpgmetricsを使用して、肥大化の見積もりを取得します。詳細については、wikiを参照してください。
3。シーケンシャルスキャン
使用可能なインデックスを最適に使用しないクエリが実行された場合、またはテーブルに関連付けられた統計情報が古すぎる場合、Postgresはテーブルの各行を調べなければならない可能性があります。これはシーケンシャルスキャンと呼ばれます 、および一般的なケースではあまり望ましくありません。 インデックススキャンがあればよいでしょう。 、ここで、テーブルの行はインデックスルックアップを介して間接的にアクセスされます。
PostgreSQLは、テーブルが連続してスキャンされた回数と、インデックスが使用された回数を通知します。これを使用して、連続スキャンの数(完全に回避したい場合)または合計スキャンの割合として監視できます。
アクション:シーケンスを継続的に監視します。カウントまたはパーセンテージをスキャンし、値が設定されたしきい値を超えた場合にアラートを出します。
方法:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;
1。インデックスサイズ
インデックスはかなりのディスクスペースを占める可能性があります。テーブルの各インデックス自体は、テーブル自体と同じくらいのディスクフットプリントを持つ可能性があります。データベース内のインデックスの合計サイズ、または重要なテーブルのインデックスを監視することは、特にインデックスが自動プロセスによって作成される可能性がある展開で役立ちます。
不当に大きなインデックスは、肥大化、または単に不適切に設計されたインデックスが原因である可能性があります。いずれの場合も、原因を修正する(インデックスを再構築するか、クエリ/インデックスをリファクタリングする)と、クエリ時間が短縮される可能性があるため、大きなインデックスを調査する価値があります。
アクション:毎週/月ごとに興味深いインデックスの合計サイズを監視し、不当に大きい場合は調査します。
方法:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;
2。インデックスブロート
インデックスも肥大化する可能性があります。 tableworkload、インデックスタイプ、Postgresバージョンなど、肥大化したanindexがどのようになるかを決定する要因が多すぎます。肥大化したインデックスは、挿入を遅くし、ルックアップのパフォーマンスを低下させる可能性があります。インデックスの肥大化を絶対値(バイト数)とパーセンテージの両方で監視します。インデックスが肥大化しすぎた場合は、インデックスを再構築する必要があります。
アクション:インデックスの肥大化をバイトとパーセンテージで継続的に監視し、値が設定されたしきい値を超えた場合にアラートを出します。
方法:
check_postgres orpgmetricsを使用して、肥大化の見積もりを取得します。詳細については、wikiを参照してください。
3。キャッシュヒット率
PostgreSQLは、頻繁にアクセスされるインデックス(およびテーブル)の領域をメモリにキャッシュします。行を取得する場合を除いてテーブルに触れないようにクエリを調整した場合、次のステップは、クエリを実際に高速化する重要なインデックスのキャッシュ常駐を最大にすることです。
インデックスのキャッシュ使用率は、キャッシュヒット率で測定できます。これは、キャッシュから読み取られたインデックスのブロックの、読み取られたブロックの総数に対するパーセンテージです。
アクション:キャッシュヒット率のパーセンテージを継続的に監視し、値が設定されたしきい値を下回った場合にアラートを出します。重要なインデックスの低い値を調査します。
方法:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;
PostgreSQLメトリックとは別に、Postgresを実行しているマシンまたはVMのいくつかのメトリックを追跡することが重要です。これには、人気のある監視ソリューションを使用できます。また、自分でそれらを取得して追跡することもできます。
1。使用済みメモリ
最近のLinuxシステムには、複雑なメモリアカウンティングがあります。 「使用済みメモリ」を監視することをお勧めします。これは、空きとしてマークされたメモリを考慮した後に残っているメモリです。 、バッファとして 、キャッシュ 、およびスラブとして 。バッファとキャッシュはプレッシャーの下で衰退し、スラブのほとんど(通常は95%以上)も衰退します。
ただし、使用メモリは適切な期間にわたって測定する必要があります。週末に実行されるバッチジョブ、レポート、ETLなどがある場合、期間は1週間になります。監視する必要のある実際の指標は、この期間に使用された最大メモリです。
通常、データベースのサイズが大きくなると、この値は大きくなる傾向があります。最大メモリ使用量が、たとえば60〜80%など、使用可能なメモリの快適な制限内にあることを確認する必要があります。これを怠ると、メモリ不足のために分析/OLAPワークロードが失敗します。
アクション:1週間/ 2週間にわたって最大使用メモリを監視し、設定されたしきい値を超えた場合はアラートを出し、再プロビジョニングします。
ハウツー :
使用されるメモリは、MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab
で指定されます。 、ここでMem*
フィールドは/proc/meminfo
からのものです 。詳細については、このRedHatの記事を参照してください。
2。負荷平均
単純な負荷平均値は、サーバーの負荷を見積もる最も簡単で迅速な方法です。これは、Postgresサーバーに特に当てはまります。各バックエンドは個別のOSプロセスであり、実行可能な状態のサーバーを増やすと、負荷の平均値が増加するためです。
特定のPostgresサーバーの場合、負荷平均はビジネスサイクル全体で妥当な範囲内にとどまる必要があります(バッチジョブの実行を含む1週間など)。
アクション:各日/週の最大負荷平均を監視し、増加傾向を調査します。
ハウツー :
1分、5分、および15分の負荷平均は、ファイル/proc/loadavg
の最初の行の最初の3つのフィールドです。 。
3。ディスクの空き容量
リストの最後の項目は、監視する最も明白な項目です。テーブルスペース、WALファイルディレクトリ、バックアップディレクトリ、サーバーログファイルなど、PostgreSQLサーバーで使用される各ファイルシステムの空きディスク容量です。 1つのファイルシステムで作成されるファイルが多すぎる(数億)場合は、空きiノード数も監視されていることを確認してください。 iノードの不足もディスク容量が少ないと報告されています。
アクション:関連するすべてのファイルシステムの空きディスク容量とiノードの使用状況を継続的に監視し、値が設定されたしきい値を下回った場合にアラートを出します。
ハウツー :
/proc
内のファイルを読み取ることによって、ファイルシステムの空きディスク領域を直接取得することはできません。 。 stat -f /path/to/mount
を使用できます またはdf
マウントされた特定のファイルシステムの使用済みの空きディスク容量と予約済みディスク容量を確認します。
これは、このシリーズでこれまでに説明したすべてのメトリックの完全なリストです。これらは、PostgreSQLの展開で問題が発生しそうな時期を検出するために監視する必要がある、最小限の最も重要なメトリックのセットにすぎないことに注意してください。
- トランザクションIDの範囲
- バックエンドの数
- 非アクティブなレプリケーションスロット
- ロックを待機しているバックエンド
- トランザクションでのバックエンドのアイドリング
- アクティブな接続のレプリケーションラグ
- レプリケーションスロットのレプリケーションラグ
- WALファイル数
- アーカイブの準備ができたWALファイル数
- 接続されたクライアント
- サイズ
- すべてのテーブルでのテーブルの膨張
- すべてのインデックスにわたるインデックスの膨張
- 長時間実行されるトランザクション
- デッドロック
- 最古の掃除機
- 最も古い分析
- テーブルサイズ
- テーブルブロート
- シーケンシャルスキャン
- インデックスサイズ
- インデックスブロート
- キャッシュヒット率
- 使用メモリ
- 平均負荷
- 空きディスク容量
上記のセクションでは、実行中のPostgresサーバーから必要なメトリックを抽出するためのSQLステートメントを提供します。スクリプトを自分で作成したくない場合は、オープンソースツールのpgmetricsを確認してください。上記の指標などを収集し、テキストおよびJSON形式でレポートできます。
pgmetricsレポートを当社の商用サービスであるpgDashに直接送信できます。pgDashは、これらのレポートを保存および処理して、グラフを表示し、アラートを実行します。