PostgreSQL 監視
設定不要で、PostgreSQLのトランザクション、接続、レプリケーション、およびVACUUMのパフォーマンスをリアルタイムで監視できます。
なぜ監視するのか PostgreSQL?
PostgreSQLは、金融システムから地理空間アプリケーションに至るまで、重要なワークロードにおいて信頼されている、世界最先端のオープンソースリレーショナルデータベースです。PostgreSQLの監視は、長時間実行されるクエリの検出、接続の飽和状態の防止、レプリケーションの状態の追跡、およびVACUUM操作の最適化に不可欠です。XitoringのPostgreSQL統合機能は、包括的なデータベースの可観測性を提供します。
PostgreSQL 監視を、 解説
PostgreSQL 監視は、レプリケーションドリフト、暴走する autovacuum、肥大化したテーブル、idle-in-transaction セッションを、障害やデータ破損につながる前に捉えます。あらゆる Postgres ワークロード — RDS、Aurora、CloudNativePG、セルフホスト Patroni クラスタ — において、データベースごとの可視性は、60 秒で接続リークを捉えることと、顧客のチケットからそれを知ることの違いを生みます。Xitoring は Postgres を自動検出し、pg_monitor ロールでネイティブの pg_stat_* ビューにクエリを発行し、Slack、PagerDuty、Telegram、または既存のオンコールにアラートをルーティングします。
私たちが 監視するもの
アクティブ接続
PostgreSQLサーバーへの現在のアクティブ接続数。
1秒あたりのトランザクション数
コミットおよびロールバックされたトランザクションのレート。
タプル操作
全データベースで挿入、更新、削除、取得されたタプルのレート。
デッドタプル
vacuum待ちのデッドタプル数。テーブル肥大化の可能性を示します。
キャッシュヒット率
ディスクアクセスなしでshared buffersから提供されたデータリクエストの割合。
レプリケーションラグ
ストリーミングレプリケーションでプライマリから遅れているバイトまたは秒。
WAL生成レート
生成されているWrite-Ahead Logデータのレート。
ロック待機
データベースオブジェクトへのロック取得を待機しているクエリ数。
作成された一時ファイル
クエリ処理のために作成された一時ファイルの数とサイズ。
データベースサイズ
インデックスを含む各データベースが使用する総ディスク容量。
トランザクション内アイドル
オープンなトランザクション内でアイドル状態の接続。ロックを保持している可能性。
チェックポイント
チェックポイント操作の頻度と時間。
設定可能 アラートのトリガー
ダッシュボードでカスタムトリガーを設定し、PostgreSQLのメトリクスが定義した閾値を超えた瞬間に通知を受け取れるようにします。
アクティブ接続
重要なアクティブ接続がmax_connectionsに近づいたときに発動。新規接続拒否やアプリケーションエラーのリスクを示します。
レプリケーションラグ
重要なストリーミングレプリケーションが遅延したときに発動。プライマリとレプリカ間のデータ不整合リスクを示します。
デッドタプル
警告デッドタプル数が閾値を超えたときにアラート。vacuumが遅れ、テーブル肥大化が進行していることを示します。
キャッシュヒット率
警告キャッシュヒット率が閾値を下回ったときに発動。過剰なディスクI/Oと潜在的なメモリ圧迫を示します。
ロック待機
警告クエリがロック待機でブロックされたときに発動。パフォーマンス低下の競合を示します。
トランザクションレート低下
重要なトランザクションスループットが大幅に低下したときにアラート。データベースハングやパフォーマンス問題の可能性を示します。
の重要性： PostgreSQL監視
PostgreSQLは世界中の企業の重要データを処理します。適切な監視がないと、テーブル肥大化、レプリケーションのずれ、接続枯渇がデータ破損、障害、回復不能な失敗を引き起こす可能性があります。
- 長時間クエリとロック競合を早期に検出
- vacuumパフォーマンス追跡でテーブル肥大化を防止
- データ一貫性のためにストリーミングレプリケーションを監視
- プール枯渇前に接続リークを特定
- ストレージキャパシティ計画のためにWAL生成を追跡
なぜ選ぶべきか： Xitoring
XitoringはゼロコンフィグでエンタープライズグレードのPostgreSQL監視を提供します。軽量エージェントがPostgreSQLインスタンスを自動検出し、60秒以内にメトリクス収集を開始、既存の通知チャネルと統合します。
- ワンコマンドインストール — 複雑なYAMLや設定ファイルは不要
- 低遅延チェックのための15以上のグローバル監視ノード
- サーバー、データベース、稼働率を統合したダッシュボード
- Slack、PagerDuty、Telegramなどによる柔軟なアラート
- キャパシティプランニングと監査のための履歴データ保持
PostgreSQL 監視の一般的な シナリオ
PostgreSQLが今日一般的に実行されている場所 — そして誰も監視していない場合に何が問題になる可能性があるか。
マネージドクラウドデータベース (AWS, Azure, Google)
クラウドプロバイダーはバックアップとパッチ適用を処理しますが、独自のクエリが遅い、接続が不足している、またはバックアップコピーが静かにライブコピーに遅れているといったことは教えてくれません。私たちはプロバイダーがあなたに任せる問題を検知し、障害が発生してもチームが不意を突かれないようにします。
自動フェイルオーバー付きセルフホスト型データベース
メインデータベースが故障した場合、バックアップコピーは数秒で引き継ぐことになっています。しかし、静かに遅れているバックアップは、その引き継ぎを30秒の停止、あるいはさらに悪いデータ損失に変える可能性があります。私たちはすべてのコピーを監視し、必要になる前にそれが本当に引き継ぎの準備ができていることを確認します。
Kubernetes内で実行されるデータベース
Kubernetes内のデータベースは、プラットフォームによって自動的に移動、再起動、更新されます。ほとんどの場合、それは安全ですが、そうでない場合、通常は不満を抱いたユーザーから知ることになります。私たちは早期警告サインを表面化させ、チームが日常的な更新がインシデントになる前に介入できるようにします。
PostgreSQL の 前提条件
これらが揃っていることを確認してください — 揃っていれば、ほとんどの導入は 60 秒で完了します。
- PostgreSQL 12 以上（12-16 でテスト済み）がサーバー上で稼働していること
- pg_monitor ロールおよび pg_stat_database への SELECT を持つユーザー
- オプション: クエリレベルのメトリクスのために pg_stat_statements 拡張機能をロード
はじめに 議事録
Xitogent をサーバーにインストール
まだの場合は、軽量な Xitogent 監視エージェントをサーバーにインストールしてください。
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYPostgreSQL に監視ユーザーを作成
Xitogent がメトリクスを収集できるように、専用の読み取り専用ユーザーを作成します:
CREATE USER xitoring WITH PASSWORD 'your_secure_password';
GRANT pg_monitor TO xitoring;
GRANT SELECT ON pg_stat_database TO xitoring;PostgreSQL 連携を有効化
Xitoring ダッシュボードまたは CLI から、監視用の認証情報を使って PostgreSQL 連携を有効化してください。
sudo xitogent integrateアラートしきい値を設定（オプション）
レプリケーション遅延、デッドタプル、接続数などのメトリクスにカスタムしきい値を設定し、注意が必要なときに通知を受け取れるようにします。
動作確認
サーバー上でこのコマンドを実行して、Xitogent が連携を認識していることを確認してください。約 30 秒以内に新しいメトリクスがダッシュボードに流れ始めます。
sudo xitogent status代替ツールを 検討中ですか？
PostgreSQL 監視の代替ツールと比べて Xitoring がどう優れているかをご覧ください — 定額料金、より深い統合、そしてスタック全体をカバーする 1 つのエージェント。
