PostgreSQLモニタリング

最終更新日: 25 年 2020 月 XNUMX 日

LogicMonitorは、パフォーマンスを正確に評価し、統計情報を取得するためにPostgreSQLデータベースに接続します。

LogicMonitorは最初、ポート5432にサーバーがあるすべてのデバイスがPostgreSQLを実行していると想定します。 LogicMonitorに、検出したデータベースへの接続を許可するまで、そのデバイスに対して警告が表示されます。

ネットワーク経由の監視を許可する

コレクターがPostgreSQLサーバーで実行されていない場合は、PostgreSQLが次のように設定されていることを確認する必要があります。

  • ネットワーク接続を受け入れます。 デフォルトでは、PostgreSQLは「localhost」でのみリッスンするように設定されています。 postgresql.confに行を追加します。
listen_addresses = "*"
  • コレクターデバイスからのmd5認証を使用したログイン接続を許可します。 次のような行をpg_hba.confファイルに追加します。
すべてのlogicmonitor10.1.1.206 / 32md5をホストします

これにより、md10.1.1.206暗号化パスワードで認証されている場合、ユーザーlogicmonitorのホスト5からすべてのデータベースへの接続が可能になります。 10.1.1.206の代わりにコレクターホストのIPアドレスを入力してください。

PostgreSQL監視ユーザーの作成

データベースへの接続に使用するLogicMonitor用の特定のユーザーアカウントを作成することをお勧めします。

PostgreSQLデータベースでスーパーユーザーとして次の操作を実行します。

パスワード「password」を使用してユーザーlogicmonitorを作成します。

これは、ほとんどの監視を有効にするのに十分です。 ただし、XNUMXつの例外があります。

  • PostgreSQLクエリ実行時間データソースを変更して、アプリケーションの代表的な時間を提供するクエリを実行する場合、ユーザーLogicMonitorは、そのクエリを実行するための付与された権限が必要であるため、接続します。
  • 正確なサーバービジー統計と最大クエリ時間を取得するには、LogicMonitorユーザーがスーパーユーザーである必要があります。
ロールlogicmonitorスーパーユーザーを変更します。

SuperUser権限がないと、すべてのサーバーがビジー状態で表示され、最大クエリ時間は常に0になります(注:データベース内のデータの機密性によっては、付与することが適切でない場合があります) スーパーユーザ ロジックモニターユーザーへの特権:たとえば、データベースに個人の健康情報が含まれている場合。)

LogicMonitorコレクターがデータベースにアクセスするための資格情報を提供する

これらのプロパティを定義する LogicMonitor内のデバイスに適用されるように:

jdbc.postgres.user
監視に関して接続するPostgreSQLユーザー
jdbc.postgres.pass
ユーザーのパスワード
データベース名
接続するデータベース

統計収集の有効化

デフォルトでは、PostgreSQLはほとんど統計情報を報告しません。 LogicMonitor PostgreSQLモニタリングの能力を完全に実現するには、統計の収集を有効にする必要があります。 (これにより、データベースに少量のオーバーヘッドが発生します。)

PostgreSQL 8.2以前の場合、これらの設定がpostgresql.confにあることを確認してください。

stats_start_collector = on stats_command_string = on stats_block_level = on stats_row_level = on

PostgreSQL 8.3以降の場合、postgresql.confで次の設定による統計収集を有効にします。

track_counts =オンtrack_activities =オン

レプリケーション監視を有効にする

ウォームスタンバイサーバーがある場合は、レプリケーション監視を設定する必要があります。 PostgreSQLにはさまざまな種類のHAがありますが、このセクションでは、pg_standbyを使用して、ポイントインタイムリカバリ(PITR)を使用したウォームスタンバイ用にPostgreSQLが設定されていることを前提としています。 LogicMonitorは、この形式のデータベースレプリケーションを監視できますが、いくつかの問題があります。

  • データベースが完全に「稼働」しておらず、常にアーカイブログ回復モードになっている場合、SQLを介してデータベースに接続し、そのステータスを監視することはできません。
  • レプリカクラスターの状態を監視するために使用する必要のある情報はpg_controldataによって報告されますが、これはクラスターを開始したユーザー(通常はユーザーpostgres)がローカルで実行する必要があります。
  • この情報をLogicMonitorコレクターに報告したいと思います。 snmpを介してこのデータを公開するのが最も簡単ですが、snmpユーザーにはpg_controldataを実行する権限がありません。
  • リスニングポートがないため、PostgreSQLレプリケーションについてシステムを監視する必要があることを示す方法はありません。

これらの制約がある場合、ウォームスタンバイサーバーを監視するための推奨セットアップは、スタンバイサーバーの次のアクションを実行することです。

  • pg_controldataの結果を、SNMPデーモンユーザーが読み取り可能なファイルに定期的にエクスポートします。 次の行をpostgresユーザーのcrontabのcrontabに追加します。
* * * * * / usr / local / pgsql / bin / pg_controldata / usr / local / pgsql / data> \ / usr / local / pgsql / metadata

(パスは、pg_controldataバイナリの場所、およびデータディレクトリへのパスを調整する必要がある場合があることに注意してください。出力ファイルがsnmpdデーモンのユーザーによって読み取り可能であることを確認してください。)

  • 次のXNUMX行をsnmpd.confファイルに追加します。
拡張postgres-replication-lag / bin / bash -c \ '/ bin / echo $(($(date -u +%s)-$(date -u -d "$(cat / usr / local / pgsql / metadata | \ grep "最新のチェックポイントの時刻" | sed "s /.* checkpoint:* //") "+%s))) 'extend postgres-replication-state / bin / bash -c \' / bin / echo $ (cat / usr / local / pgsql / metadata | grep "cluster state") '
  • これにより、リアルタイムと最後のチェックポイントの間のラグを報告する新しいSNMPオブジェクトが追加されます。 また、クラスターの状態を報告します。 -uオプションを使用すると、日付と時刻の計算がUTCで実行されることに注意してください。 データベースが別のタイムゾーンを使用してチェックポイント時間を報告する場合、重大ではあるが一貫したエラーが発生します。 その後、あなたはしなければなりません snmpデーモンを再起動します (通常は/etc/init.d/snmpd restartによって)。

最後に、LogicMonitorのPostgreSQLレプリケーションモニターを関連するホストに関連付ける必要があります。 そうするには、 タグを追加します Postgresレプリカ デバイスのSystem.categoriesプロパティに.

PostgreSQLクエリ実行時間データソースの変更

PostgreSQLクエリ実行時間データソースでタイミングが設定されているクエリを、アプリケーションのパフォーマンスを表すクエリに変更することをお勧めします。 これを行うには、[設定] | [Postgresクエリの実行時間]データソースを見つけます。 LogicModules | データソースまたは[デバイス]ページのデータソースから[グローバル定義の編集]を選択します

PostgreSQLクエリ実行時間データソースの変更

表示されるフォームの[クエリ]フィールドを、アプリケーションのパフォーマンスを表すクエリに変更し、[送信]をクリックします。

記事上で