モニタリング

重要

PrometheusとGrafanaのインストールは、このプロジェクトの範囲を超えています。これらはシステムに正しくインストールされていることを前提としています。ただし、実験のために、 Part 4 of the Quickstart で指示を提供します。

モニタリングインスタンス

PostgreSQLインスタンスごとに、オペレーターは、HTTPを介してポート9187でmetrics という名前の Prometheus のメトリックのエクスポーターを提供します。オペレーターには、

事前定義されたメトリックセットに加えて、1つ以上のConfigMap またはSecret

リソースを介して追加クエリを定義するための高度な構成およびカスタマイズ可能なシステムが付属しています詳細については、以下のユーザー定義メトリックを参照してください。

重要

バージョン1.11から、CloudNativePGは既に`default-monitoring` と呼ばれる`ConfigMap` に by default a set of predefined metrics をインストールしています。

注釈

エクスポートされたメトリックを検査する方法の指示に従って、エクスポートされたメトリックを検査できます。

以下のセクション。

PostgreSQLで実行されるすべての監視クエリは次のとおりです。

アトミッククエリごとに1つのトランザクション
pg_monitor ロールで実行
application_name をcnpg_metrics_exporter に設定して実行
ユーザーpostgres として実行

PostgreSQLの「事前定義されたロール」セクションを参照してください: documentation

pg_monitor ロールの詳細は、

デフォルトでは、クエリーは、次のロジックに従って、Cluster リソースの指定されたbootstrap メソッドで定義された メインデータベース に対して実行されます。

using initdb クエリーはデフォルトでinitdb.database またはapp で指定されたデータベースに対して実行されます指定しない場合
using recovery クエリーはデフォルトでrecovery.database またはpostgres で指定されたデータベースに対して実行されます指定しない場合
using pg_basebackup クエリーはデフォルトでpg_basebackup.database またはpostgres で指定されたデータベースに対して実行されます指定しない場合

target_databases オプションで1つ以上のデータベースのリストを指定することにより、特定のユーザー定義メトリックのデフォルトデータベースを常にオーバーライドできます。

参考

CloudNativePGとPrometheusおよびGrafanaの統合を評価することに興味がある場合は、 Part 4 of the quickstart で簡単なセットアップガイドを見つけることができます。

Prometheus Operatorの例

特定のPostgreSQLクラスターは、 Prometheus Operator's リソース: PodMonitor を使用してモニタできます。クラスターリソース自分自身デフォルトfalseで.spec.monitoring.enablePodMonitor

〜true を設定することにより、オペレーターがクラスターを正しくポイントするPodMonitorを自動的に作成できます。

重要

自動的に作成される`PodMonitor` への変更は、次の調整サイクルでオペレーターによってオーバーライドされます。カスタマイズが必要な場合は、以下の説明に従って行うことができます。

特定のクラスターにPodMonitor を手動で展開するには、次のように定義し、必要に応じて変更することができます。

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cluster-example
spec:
  selector:
    matchLabels:
      "cnpg.io/cluster": cluster-example
  podMetricsEndpoints:
  - port: metrics

重要

一意の名前と、正しいクラスターの名前空間とラベルで上記の例を変更してください cluster-example を使用しています。

重要

このドキュメントの以前のバージョンで使用されていたラベル postgresql は非推奨であり、将来的に削除される予定です。代わりにラベル cnpg.io/cluster を使用して、インスタンスを選択してください。

事前定義されたメトリックセット

すべてのPostgreSQLインスタンスエクスポーターは、事前定義されたメトリックのセットを自動的に公開します。これらは2つの主要カテゴリに分類できます。

cnpg_collector_* で始まるPostgreSQL関連メトリックインスタンスを収容する個別のノードの数s
- 最後に失敗したバックアップと最後に使用可能なバックアップを示すタイムスタンプ、およびcluster
- フラグレプリカクラスターモードが有効または無効かを示します
- フラグ手動スイッチオーバーが必要かどうかを示すb_tran_12フェンシングが有効かどうかを示すb_tran_12フラグ有効または無効
go_* で始まるGoランタイム関連のメトリック

以下は、インスタンスのlocalhost:9187/metrics エンドポイントによって返されるメトリックのサンプルです。ご覧のとおり、Prometheusフォーマットは自己文書です。

#  HELP cnpg_collector_collection_duration_seconds Collection time duration in seconds

#  TYPE cnpg_collector_collection_duration_seconds gauge

cnpg_collector_collection_duration_seconds{collector="Collect.up"} 0.0031393

#  HELP cnpg_collector_collections_total Total number of times PostgreSQL was accessed for metrics.

#  TYPE cnpg_collector_collections_total counter

cnpg_collector_collections_total 2

#  HELP cnpg_collector_fencing_on 1 if the instance is fenced, 0 otherwise

#  TYPE cnpg_collector_fencing_on gauge

cnpg_collector_fencing_on 0

#  HELP cnpg_collector_nodes_used NodesUsed represents the count of distinct nodes accommodating the instances. A value of -1 suggests that the metric is not available. A value of 1 suggests that all instances are hosted on a single node, implying the absence of High Availability (HA). Ideally this value should match the number of instances in the cluster.

#  TYPE cnpg_collector_nodes_used gauge

cnpg_collector_nodes_used 3

#  HELP cnpg_collector_last_collection_error 1 if the last collection ended with error, 0 otherwise.

#  TYPE cnpg_collector_last_collection_error gauge

cnpg_collector_last_collection_error 0

#  HELP cnpg_collector_manual_switchover_required 1 if a manual switchover is required, 0 otherwise

#  TYPE cnpg_collector_manual_switchover_required gauge

cnpg_collector_manual_switchover_required 0

#  HELP cnpg_collector_pg_wal Total size in bytes of WAL segments in the /var/lib/postgresql/data/pgdata/pg_wal directory  computed as (wal_segment_size * count)

#  TYPE cnpg_collector_pg_wal gauge

cnpg_collector_pg_wal{value="count"} 9
cnpg_collector_pg_wal{value="slots_max"} NaN
cnpg_collector_pg_wal{value="keep"} 32
cnpg_collector_pg_wal{value="max"} 64
cnpg_collector_pg_wal{value="min"} 5
cnpg_collector_pg_wal{value="size"} 1.50994944e+08
cnpg_collector_pg_wal{value="volume_max"} 128
cnpg_collector_pg_wal{value="volume_size"} 2.147483648e+09

#  HELP cnpg_collector_pg_wal_archive_status Number of WAL segments in the /var/lib/postgresql/data/pgdata/pg_wal/archive_status directory (ready, done)

#  TYPE cnpg_collector_pg_wal_archive_status gauge

cnpg_collector_pg_wal_archive_status{value="done"} 6
cnpg_collector_pg_wal_archive_status{value="ready"} 0

#  HELP cnpg_collector_replica_mode 1 if the cluster is in replica mode, 0 otherwise

#  TYPE cnpg_collector_replica_mode gauge

cnpg_collector_replica_mode 0

#  HELP cnpg_collector_sync_replicas Number of requested synchronous replicas (synchronous_standby_names)

#  TYPE cnpg_collector_sync_replicas gauge

cnpg_collector_sync_replicas{value="expected"} 0
cnpg_collector_sync_replicas{value="max"} 0
cnpg_collector_sync_replicas{value="min"} 0
cnpg_collector_sync_replicas{value="observed"} 0

#  HELP cnpg_collector_up 1 if PostgreSQL is up, 0 otherwise.

#  TYPE cnpg_collector_up gauge

cnpg_collector_up{cluster="cluster-example"} 1

#  HELP cnpg_collector_postgres_version Postgres version

#  TYPE cnpg_collector_postgres_version gauge

cnpg_collector_postgres_version{cluster="cluster-example",full="16.1"} 16.1

#  HELP cnpg_collector_last_failed_backup_timestamp The last failed backup as a unix timestamp

#  TYPE cnpg_collector_last_failed_backup_timestamp gauge

cnpg_collector_last_failed_backup_timestamp 0

#  HELP cnpg_collector_last_available_backup_timestamp The last available backup as a unix timestamp

#  TYPE cnpg_collector_last_available_backup_timestamp gauge

cnpg_collector_last_available_backup_timestamp 1.63238406e+09

#  HELP cnpg_collector_first_recoverability_point The first point of recoverability for the cluster as a unix timestamp

#  TYPE cnpg_collector_first_recoverability_point gauge

cnpg_collector_first_recoverability_point 1.63238406e+09

#  HELP cnpg_collector_lo_pages Estimated number of pages in the pg_largeobject table

#  TYPE cnpg_collector_lo_pages gauge

cnpg_collector_lo_pages{datname="app"} 0
cnpg_collector_lo_pages{datname="postgres"} 78

#  HELP cnpg_collector_wal_buffers_full Number of times WAL data was written to disk because WAL buffers became full. Only available on PG 14+

#  TYPE cnpg_collector_wal_buffers_full gauge

cnpg_collector_wal_buffers_full{stats_reset="2023-06-19T10:51:27.473259Z"} 6472

#  HELP cnpg_collector_wal_bytes Total amount of WAL generated in bytes. Only available on PG 14+

#  TYPE cnpg_collector_wal_bytes gauge

cnpg_collector_wal_bytes{stats_reset="2023-06-19T10:51:27.473259Z"} 1.0035147e+07

#  HELP cnpg_collector_wal_fpi Total number of WAL full page images generated. Only available on PG 14+

#  TYPE cnpg_collector_wal_fpi gauge

cnpg_collector_wal_fpi{stats_reset="2023-06-19T10:51:27.473259Z"} 1474

#  HELP cnpg_collector_wal_records Total number of WAL records generated. Only available on PG 14+

#  TYPE cnpg_collector_wal_records gauge

cnpg_collector_wal_records{stats_reset="2023-06-19T10:51:27.473259Z"} 26178

#  HELP cnpg_collector_wal_sync Number of times WAL files were synced to disk via issue_xlog_fsync request (if fsync is on and wal_sync_method is either fdatasync, fsync or fsync_writethrough, otherwise zero). Only available on PG 14+

#  TYPE cnpg_collector_wal_sync gauge

cnpg_collector_wal_sync{stats_reset="2023-06-19T10:51:27.473259Z"} 37

#  HELP cnpg_collector_wal_sync_time Total amount of time spent syncing WAL files to disk via issue_xlog_fsync request, in milliseconds (if track_wal_io_timing is enabled, fsync is on, and wal_sync_method is either fdatasync, fsync or fsync_writethrough, otherwise zero). Only available on PG 14+

#  TYPE cnpg_collector_wal_sync_time gauge

cnpg_collector_wal_sync_time{stats_reset="2023-06-19T10:51:27.473259Z"} 0

#  HELP cnpg_collector_wal_write Number of times WAL buffers were written out to disk via XLogWrite request. Only available on PG 14+

#  TYPE cnpg_collector_wal_write gauge

cnpg_collector_wal_write{stats_reset="2023-06-19T10:51:27.473259Z"} 7243

#  HELP cnpg_collector_wal_write_time Total amount of time spent writing WAL buffers to disk via XLogWrite request, in milliseconds (if track_wal_io_timing is enabled, otherwise zero). This includes the sync time when wal_sync_method is either open_datasync or open_sync. Only available on PG 14+

#  TYPE cnpg_collector_wal_write_time gauge

cnpg_collector_wal_write_time{stats_reset="2023-06-19T10:51:27.473259Z"} 0

#  HELP cnpg_last_error 1 if the last collection ended with error, 0 otherwise.

#  TYPE cnpg_last_error gauge

cnpg_last_error 0

#  HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.

#  TYPE go_gc_duration_seconds summary

go_gc_duration_seconds{quantile="0"} 5.01e-05
go_gc_duration_seconds{quantile="0.25"} 7.27e-05
go_gc_duration_seconds{quantile="0.5"} 0.0001748
go_gc_duration_seconds{quantile="0.75"} 0.0002959
go_gc_duration_seconds{quantile="1"} 0.0012776
go_gc_duration_seconds_sum 0.0035741
go_gc_duration_seconds_count 13

#  HELP go_goroutines Number of goroutines that currently exist.

#  TYPE go_goroutines gauge

go_goroutines 25

#  HELP go_info Information about the Go environment.

#  TYPE go_info gauge

go_info{version="go1.20.5"} 1

#  HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.

#  TYPE go_memstats_alloc_bytes gauge

go_memstats_alloc_bytes 4.493744e+06

#  HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.

#  TYPE go_memstats_alloc_bytes_total counter

go_memstats_alloc_bytes_total 2.1698216e+07

#  HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.

#  TYPE go_memstats_buck_hash_sys_bytes gauge

go_memstats_buck_hash_sys_bytes 1.456234e+06

#  HELP go_memstats_frees_total Total number of frees.

#  TYPE go_memstats_frees_total counter

go_memstats_frees_total 172118

#  HELP go_memstats_gc_cpu_fraction The fraction of this programs available CPU time used by the GC since the program started.

#  TYPE go_memstats_gc_cpu_fraction gauge

go_memstats_gc_cpu_fraction 1.0749468700447189e-05

#  HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.

#  TYPE go_memstats_gc_sys_bytes gauge

go_memstats_gc_sys_bytes 5.530048e+06

#  HELP go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use.

#  TYPE go_memstats_heap_alloc_bytes gauge

go_memstats_heap_alloc_bytes 4.493744e+06

#  HELP go_memstats_heap_idle_bytes Number of heap bytes waiting to be used.

#  TYPE go_memstats_heap_idle_bytes gauge

go_memstats_heap_idle_bytes 5.8236928e+07

#  HELP go_memstats_heap_inuse_bytes Number of heap bytes that are in use.

#  TYPE go_memstats_heap_inuse_bytes gauge

go_memstats_heap_inuse_bytes 7.528448e+06

#  HELP go_memstats_heap_objects Number of allocated objects.

#  TYPE go_memstats_heap_objects gauge

go_memstats_heap_objects 26306

#  HELP go_memstats_heap_released_bytes Number of heap bytes released to OS.

#  TYPE go_memstats_heap_released_bytes gauge

go_memstats_heap_released_bytes 5.7401344e+07

#  HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from system.

#  TYPE go_memstats_heap_sys_bytes gauge

go_memstats_heap_sys_bytes 6.5765376e+07

#  HELP go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection.

#  TYPE go_memstats_last_gc_time_seconds gauge

go_memstats_last_gc_time_seconds 1.6311727586032727e+09

#  HELP go_memstats_lookups_total Total number of pointer lookups.

#  TYPE go_memstats_lookups_total counter

go_memstats_lookups_total 0

#  HELP go_memstats_mallocs_total Total number of mallocs.

#  TYPE go_memstats_mallocs_total counter

go_memstats_mallocs_total 198424

#  HELP go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures.

#  TYPE go_memstats_mcache_inuse_bytes gauge

go_memstats_mcache_inuse_bytes 14400

#  HELP go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system.

#  TYPE go_memstats_mcache_sys_bytes gauge

go_memstats_mcache_sys_bytes 16384

#  HELP go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures.

#  TYPE go_memstats_mspan_inuse_bytes gauge

go_memstats_mspan_inuse_bytes 191896

#  HELP go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system.

#  TYPE go_memstats_mspan_sys_bytes gauge

go_memstats_mspan_sys_bytes 212992

#  HELP go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place.

#  TYPE go_memstats_next_gc_bytes gauge

go_memstats_next_gc_bytes 8.689632e+06

#  HELP go_memstats_other_sys_bytes Number of bytes used for other system allocations.

#  TYPE go_memstats_other_sys_bytes gauge

go_memstats_other_sys_bytes 2.566622e+06

#  HELP go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator.

#  TYPE go_memstats_stack_inuse_bytes gauge

go_memstats_stack_inuse_bytes 1.343488e+06

#  HELP go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator.

#  TYPE go_memstats_stack_sys_bytes gauge

go_memstats_stack_sys_bytes 1.343488e+06

#  HELP go_memstats_sys_bytes Number of bytes obtained from system.

#  TYPE go_memstats_sys_bytes gauge

go_memstats_sys_bytes 7.6891144e+07

#  HELP go_threads Number of OS threads created.

#  TYPE go_threads gauge

go_threads 18

注釈

cnpg_collector_postgres_version は、PostgreSQLの`Major.Minor` バージョンを含むGaugeVecメトリックです。フルセマンティックバージョン`Major.Minor.Patch` は、 full という名前のラベルフィールドの1つ内にあります。

注釈

cnpg_collector_first_recoverability_point および`cnpg_collector_last_available_backup_timestamp` は、オブジェクトストアへの最初のバックアップまで0になります。これはWALアーカイブとは別です。

ユーザー定義メトリック

この機能は現在 ベータ 状態であり、フォーマットは queries.yaml file (release 0.12)

PostgreSQL Prometheus Exporterの。

カスタムメトリックは、次の例のように、.spec.monitoring.customQueriesConfigMap またはcustomQueriesSecret セクションの下のCluster 定義で作成したConfigmap /Secret を参照することにより、ユーザーが定義できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
  namespace: test
spec:
  instances: 3

  storage:
    size: 1Gi

  monitoring:
    customQueriesConfigMap:
      - name: example-monitoring
        key: custom-queries

customQueriesConfigMap /customQueriesSecret セクションには、カスタムクエリーが定義されているキーを指定するConfigMap /Secret 参照のリストが含まれています。参照されるリソースは、 クラスター リソースと同じ名前空間に作成する必要があることに注意してください。

注釈

ConfigMapsとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`cnpg.io/reload` を持つラベルをそれに追加できます。それ以外の場合、 kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

重要

ユーザー定義メトリックが既存のメトリックを上書きすると、インスタンスマネージャーはjson警告ログを出力します。これには、メッセージ`Query with the same name already found. Overwriting the existing one.` と上書きされたクエリー名を含むキー`queryName` が含まれます。

ユーザー定義メトリックの例

ここでは、上記のCluster の例で参照される、単一のカスタムクエリーを含むConfigMap の例を示します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-monitoring
  namespace: test
  labels:
    cnpg.io/reload: ""
data:
  custom-queries: |
    pg_replication:
      query: "SELECT CASE WHEN NOT pg_is_in_recovery()
              THEN 0
              ELSE GREATEST (0,
                EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())))
              END AS lag,
              pg_is_in_recovery() AS in_recovery,
              EXISTS (TABLE pg_stat_wal_receiver) AS is_wal_receiver_up,
              (SELECT count(*) FROM pg_stat_replication) AS streaming_replicas"

      metrics:
        - lag:
            usage: "GAUGE"
            description: "Replication lag behind primary in seconds"
        - in_recovery:
            usage: "GAUGE"
            description: "Whether the instance is in recovery"
        - is_wal_receiver_up:
            usage: "GAUGE"
            description: "Whether the instance wal_receiver is up"
        - streaming_replicas:
            usage: "GAUGE"
            description: "Number of streaming replicas connected to the instance"

基本的なモニタリングクエリーのリストは、 default-monitoring.yaml

これはCloudNativePG展開に既にインストールされています: メトリックのデフォルトセットを参照してください。

複数のデータベースで実行されているユーザー定義メトリックの例

target_databases オプションが複数のデータベースをリストする場合、メトリックは各データベースから収集されます。

target_databases のリストで シェルのようなパターン つまり * 、? または[] を指定することにより、特定のクエリーに対してデータベース自動検出を有効にできます。提供されている場合、オペレーターは、 SELECT datname FROM pg_database WHERE datallowconn AND NOT datistemplate の実行によって返されたすべてのデータベースを追加し、 path.Match() ルールに従ってパターンと一致することにより、ターゲットデータベースのリストを展開します。

注釈

* 文字はyamlに special meaning があるため、このようなパターンが含まれる場合、target_databases 値を引用符で`"*"` する必要があります。

返されるラベルには、常にデータベースの名前を含めることをお勧めします。たとえば、次の例のようにcurrent_database() ファンクションを使用します。

some_query: |
  query: |
    SELECT
     current_database() as datname,
     count(*) as rows
    FROM some_table
  metrics:
    - datname:
        usage: "LABEL"
        description: "Name of current database"
    - rows:
        usage: "GAUGE"
        description: "number of rows"
  target_databases:
    - albert
    - bb
    - freddie

これにより、次のメトリックが公開されます。

cnpg_some_query_rows{datname="albert"} 2
cnpg_some_query_rows{datname="bb"} 5
cnpg_some_query_rows{datname="freddie"} 10

次に、自動検出を有効にしたクエリーの例を示します。これは、 template1 データベースでも実行されますそれ以外の場合、前述のクエリーによって返されません。

some_query: |
  query: |
    SELECT
     current_database() as datname,
     count(*) as rows
    FROM some_table
  metrics:
    - datname:
        usage: "LABEL"
        description: "Name of current database"
    - rows:
        usage: "GAUGE"
        description: "number of rows"
  target_databases:
    - "*"
    - "template1"

上記の例では、次のメトリックを生成しますデータベースが存在する場合。

cnpg_some_query_rows{datname="albert"} 2
cnpg_some_query_rows{datname="bb"} 5
cnpg_some_query_rows{datname="freddie"} 10
cnpg_some_query_rows{datname="template1"} 7
cnpg_some_query_rows{datname="postgres"} 42

ユーザー定義メトリックの構造

すべてのカスタムクエリーには、次の基本構造があります。

<MetricName>:
      query: "<SQLQuery>"
      metrics:
        - <ColumnName>:
            usage: "<MetricType>"
            description: "<MetricDescription>"

次に、使用可能なすべてのフィールドの簡単な説明を示します。

<MetricName> プロメテウスの名前 metric
- query メトリックを生成するためにターゲットデータベースで実行するSQLクエリー
- primary プライマリインスタンスでのみクエリーを実行するかどうか
- master primary と同じPrometheus PostgreSQLエクスポータの構文との互換性のため- 非推奨)
- runonserver クエリを実行するPostgreSQLのバージョンを制限するセマンティックバージョンレンジたとえば ">=11.0.0" または">=12.0.0 <=15.0.0"
- target_databases query を実行するデータベースのリストに対して、または shell-like pattern

自動検出を有効にします。デフォルトのデータベースが提供されている場合は上書きします。 - metrics 次のように定義されたエクスポートされたすべての列のリストを含むセクション - <ColumnName> クエリーによって返された列の名前 - usage 以下で説明する値のいずれか - description メトリックの説明 - metrics_mapping usage がMAPPEDMETRIC に設定されている場合のオプションの列マッピング

usage の可能な値は次のとおりです。

:header: Column Usage Label,Description :widths: 10,30 :align: left :class: longtable
DISCARD	この列は無視する必要があります
LABEL	この列をラベルとして使用します
COUNTER	この列をカウンターとして使用する
GAUGE	この列をゲージとして使用します
MAPPEDMETRIC	指定されたテキスト値のマッピングでこの列を使用します
DURATION	この列をテキストの長さミリ秒単位として使用します
HISTOGRAM	この列をヒストグラムとして使用します

Metric Types にアクセスしてください。

詳細については、Prometheusのドキュメントから。

ユーザー定義メトリックの出力

カスタム定義メトリックは、次の形式でPrometheusエクスポータエンドポイント:9187/metrics によって返されます。

cnpg_<MetricName>_<ColumnName>{<LabelColumnName>=<LabelColumnValue> ... } <ColumnValue>

注釈

LabelColumnName は、 usage が`LABEL` に設定されたメトリックとその`Value`

上記のpg_replication の例を考慮すると、エクスポーターのエンドポイントは、呼び出されると次の出力を結果ます。

#  HELP cnpg_pg_replication_in_recovery Whether the instance is in recovery

#  TYPE cnpg_pg_replication_in_recovery gauge

cnpg_pg_replication_in_recovery 0
#  HELP cnpg_pg_replication_lag Replication lag behind primary in seconds

#  TYPE cnpg_pg_replication_lag gauge

cnpg_pg_replication_lag 0
#  HELP cnpg_pg_replication_streaming_replicas Number of streaming replicas connected to the instance

#  TYPE cnpg_pg_replication_streaming_replicas gauge

cnpg_pg_replication_streaming_replicas 2
#  HELP cnpg_pg_replication_is_wal_receiver_up Whether the instance wal_receiver is up

#  TYPE cnpg_pg_replication_is_wal_receiver_up gauge

cnpg_pg_replication_is_wal_receiver_up 0

メトリックのデフォルトセット

オペレーターは、オペレーターの名前空間内のConfigMapまたはSecretで定義された一連のモニタリングクエリーをクラスターに自動的に注入するように構成できます。: オペレーター設定のMONITORING_QUERIES_CONFIGMAP

またはMONITORING_QUERIES_SECRET キーを、それぞれConfigMapまたはSecretの名前に設定する必要があります。オペレーターはqueries キーの内容を使用します。

queries コンテンツを変更すると、それを使用するデプロイされたすべてのクラスターにすぐに反映されます。

オペレーターインストールマニフェストには、すべてのクラスターが使用するcnpg-default-monitoring と呼ばれる事前定義されたConfigMapが付属しています。 MONITORING_QUERIES_CONFIGMAP は、オペレーター構成でデフォルトでcnpg-default-monitoring に設定されます。

デフォルトのメトリックセットを無効にする場合は、次のことができます。

オペレーターレベルで無効にするオペレーターConfigMapで MONITORING_QUERIES_CONFIGMAP / MONITORING_QUERIES_SECRET キーを"" 空の文字列に設定します。オペレーターのConfigMapを変更するには、オペレーターの再起動が必要です。
特定のクラスターで無効にします。クラスターで.spec.monitoring.disableDefaultQueries をtrue に設定します。

重要

MONITORING_QUERIES_CONFIGMAP / MONITORING_QUERIES_SECRET を介して指定されたConfigMapまたはSecretは、常に固定名`cnpg-default-monitoring` でクラスターの名前空間にコピーされます。そのため、デフォルトのメトリックを使用する場合は、クラスターの名前空間にこの名前でConfigMapを作成しないでください。

Prometheus Postgresエクスポーターとの違い

CloudNativePGは、PostgreSQL Prometheus Exporterからインスピレーションを得ていますが、いくつかの違いがあります。特に、 cache_seconds フィールドはCloudNativePGのエクスポーターに実装されていません。

オペレーターのモニタリング

オペレーターは、metrics という名前のポート8080でHTTPを介して Prometheus メトリックを内部公開します。

注釈

エクスポートされたメトリックを検査する方法の指示に従って、エクスポートされたメトリックを検査できます。

以下のセクション。

現在、オペレーターはデフォルトのkubebuilder メトリックを公開しています。詳細については、

kubebuilder documentation を参照してください。

Prometheus Operatorの例

オペレーターの展開は、次の PodMonitor を定義することにより、 Prometheus Operator を使用して監視できます。

リソース

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-controller-manager
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: cloudnative-pg
  podMetricsEndpoints:
    - port: metrics

エクスポートされたメトリックを検査する方法

このセクションでは、同じ名前空間でcurl を実行する一時ポッドを使用して、特定のPostgreSQLインスタンスマネージャープライマリまたはレプリカまたはオペレーターによってエクスポートされたメトリックを検査する方法に関する基本的な手順を提供します。

注釈

以下の例では、PostgreSQLクラスターと並んで、デフォルトの名前空間で作業していることを前提としています。 Kubernetesの基本的な知識を適用して、この例をユースケースに自由に調整してください。

次の内容でcurl.yaml ファイルを作成します。

apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - name: curl
    image: curlimages/curl:8.2.1
    command: [sleep, 3600]

次に、ポッドを作成します。

kubectl apply -f curl.yaml

インスタンスによってエクスポートされたメトリックを検査する場合、ターゲットポッドのポート9187に接続する必要があります。これは、実行する汎用コマンドです。ポッドの正しいIPを使用していることを確認します。

kubectl exec -ti curl -- curl -s <pod_ip>:9187/metrics

たとえば、PostgreSQLクラスターがcluster-example と呼ばれ、クラスター内の最初のポッドのエクスポートされたメトリックを取得する場合、次のコマンドを実行してそのポッドのIPをプログラム的に取得できます。

POD_IP=$(kubectl get pod cluster-example-1 --template {{.status.podIP}})

そして、実行します。

kubectl exec -ti curl -- curl -s ${POD_IP}:9187/metrics

オペレーターのメトリックにアクセスする場合は、オペレーターが実行されているポッドをポイントし、ターゲットとしてTCPポート8080を使用する必要があります。

インスペクションの最後に、curl ポッドを削除していることを確認してください。

kubectl delete -f curl.yaml

補助リソース

重要

これらのリソースは、説明と実験のために提供されており、実稼働システムへのいかなる種類の推奨を表すものではありません

doc/src/samples/monitoring/

ディレクトリには、可観測性のための一連のサンプルファイルがあります。: Part 4 of the quickstart を参照してください。

コンテキストのセクション

kube-stack-config.yaml kube-stack Helm chartインストールの構成ファイル。これにより、PrometheusがすべてのPodMonitorリソースをリッスンすることが保証されます。
prometheusrule.yaml CloudNativePGのアラートを含むPrometheusRule 。注これには、通知サービスとの相互運用は含まれません。 Prometheus documentation を参照してください。
podmonitor.yaml CloudNativePG Operator展開のPodMonitor 。

さらに、Prometheusアラートルールの「生」ソースをalerts.yaml ファイルで提供します。

Grafana dashboard

は公式のHelm Chartプロジェクトの一部になりました。

kube-prometheus-stack の構成では、kube-stack-config.yaml で提供するものより他のフィールドと設定が利用できることに注意してください。

helm show values prometheus-community/kube-prometheus-stack を実行して表示できます。詳細については、

kube-prometheus-stack を参照してください。

ページ。