Monitoring

注釈

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

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

PostgreSQLインスタンスごとに、オペレーターは、HTTPまたはHTTPS、ポート9187でmetrics という名前の Prometheus のメトリックのエクスポーターを提供します。オペレーターには、 事前定義されたメトリックセット に加えて、1つ以上のConfigMap またはSecret リソースを介して追加クエリを定義するための高度な構成およびカスタマイズ可能なシステムが付属しています詳細については、以下の ユーザー定義メトリック を参照してください。

注釈

CloudNativePGは、デフォルトで、 メトリックのデフォルトセット のセットをインストールします

cnpg-default-monitoring という名前のConfigMap で。

注釈

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

以下のセクション。

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 で簡単なセットアップガイドを見つけることができます。

出力キャッシュ

デフォルトでは、モニタリングクエリの出力は30秒間キャッシュされます。これは、リソース効率を向上させ、プロメテウスエンドポイントがスクレイピングされるたびにPostgreSQLが監視クエリを実行しないようにするために行われます。

キャッシュ自分自身は、 cache_hits 、cache_misses 、およびlast_update_timestamp メトリックで観察できます。

cluster.spec.monitoring.metricsQueriesTTL をゼロに設定するとキャッシュが無効になり、その場合、メトリックはすべてのメトリックエンドポイントスクレイピングで実行されます。

Prometheusオペレーターを使用したモニタリング

Prometheus Operator's を使用して、特定のPostgreSQLクラスターをモニタできます。

PodMonitor 。

推奨されるアプローチは、CloudNativePGクラスターごとにPodMonitor を手動で作成および管理することです。この方法では、監視構成とライフサイクルを完全に制御できます。

PodMonitor の作成

クラスターをモニタするには、次のようにPodMonitor リソースを定義します。 PodMonitor リソースを検索するようにPrometheus Operatorが構成されている名前空間に必ずデプロイしてください。

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

注釈

• metadata.name PodMonitor に一意の名前を付けます。 - spec.namespaceSelector これを使用して、PostgreSQLクラスターが実行されている名前空間を指定します。 - spec.selector.matchLabels cnpg.io/cluster: <cluster-name> ラベルを使用して、PostgreSQLインスタンスを正しくターゲットとする必要があります。

PodMonitor 自動作成の非推奨

現在この機能を使用している場合、 .spec.monitoring.enablePodMonitor を削除またはfalse に設定し、上記のようにクラスターのPodMonitor リソースを手動で作成することを強くお勧めします。この変更により、監視構成の完全な所有権が保証され、オペレーターによって管理または上書きされるのを防ぎます。

メトリックポートでTLSを有効にする

メトリックポートでTLS通信を有効にするには、 .spec.monitoring.tls.enabled 設定をtrue に構成します。この設定により、メトリックエクスポーターは、PostgreSQLが使用するものと同じサーバー証明書を使用して、ポート5432での通信を安全にします。

注釈

.spec.monitoring.tls.enabled 設定を変更すると、クラスターのローリング再起動がトリガーされます。

PodMonitor がオペレーター.spec.monitoring.enablePodMonitor をtrue に設定して管理されている場合、TLSを介してメトリックにアクセスするために必要な構成が自動的に含まれます。

TLS経由でメトリックを読み取るのに適したPodMonitor を手動で展開するには、次のように定義し、必要に応じて調整します。

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cluster-example
spec:
  selector:
    matchLabels:
      "cnpg.io/cluster": cluster-example
  podMetricsEndpoints:
  - port: metrics
    scheme: https
    tlsConfig:
      ca:
        secret:
          name: cluster-example-ca
          key: ca.crt
      serverName: cluster-example-rw

注釈

一意の名前、および正しいクラスターの名前空間とラベルたとえば cluster-example などを使用して上記の例を変更していることを確認します。

注釈

メトリックエンドポイントの`serverName` フィールドは、サーバー証明書で定義された名前のいずれかと一致する必要があります。デフォルトの証明書が使用されている場合、serverName 値は`<cluster-name>-rw` 形式である必要があります。

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

すべての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="18.1"} 18.1

##  HELP cnpg_collector_last_failed_backup_timestamp The last failed backup as a unix timestamp (Deprecated)

##  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 (Deprecated)

##  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 (Deprecated)

##  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_last_failed_backup_timestamp` 、cnpg_collector_last_available_backup_timestamp 、および`cnpg_collector_first_recoverability_point` は、バージョン1.26から非推奨になりました。これらのメトリックは、インコアBarman Cloud非推奨やボリュームスナップショットなどのネイティブバックアップソリューションで引き続き機能します。これらの場合、オブジェクトストアへの最初のバックアップが完了するまで、 cnpg_collector_first_recoverability_point および`cnpg_collector_last_available_backup_timestamp` はゼロのままであることに注意してください。これは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 参照のリストが含まれています。参照されるリソースは、 クラスター リソースと同じ名前空間に作成する必要があることに注意してください。

注釈

ConfigMapと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展開に既にインストールされています メトリックのデフォルトセット を参照してください。

述語クエリーを使用したユーザー定義メトリックの例

predicate_query オプションを使用すると、ユーザーはquery を実行して、指定された条件でのみメトリックを収集できます。これを行うには、ユーザーは単一のboolean 列で最大1つの行を返す述語照会を提供する必要があります。

述語クエリーは、メインクエリーと同じトランザクションで、同じデータベースに対して実行されます。

some_query: |
  predicate_query: |
    SELECT
      some_bool as predicate
    FROM some_table
  query: |
    SELECT
     count(*) as rows
    FROM some_table
  metrics:
    - rows:
        usage: "GAUGE"
        description: "number of rows"

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

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

  • name オーバーライド<MetricName> 、定義されている場合

  • query メトリックを生成するためにターゲットデータベースで実行するSQLクエリー

  • primary プライマリインスタンスでのみクエリーを実行するかどうか

  • edb_fortran_21 Prometheus PostgreSQLエクスポータの構文との互換性-非推奨)

  • runonserver クエリを実行するPostgreSQLのバージョンを制限するセマンティックバージョンレンジ例 ">=11.0.0" または">=12.0.0 <=15.0.0"

  • target_databases query または 複数のデータベースで実行されているユーザー定義メトリックの例 を実行するデータベースのリスト

自動検出を有効にします。デフォルトのデータベースが提供されている場合は上書きします。 - predicate_query ターゲットデータベースで実行する最大1つの行と1つのboolean 列を返すSQLクエリー。システムは述語を評価し、true がquery を実行するかどうかを評価します。 - metrics エクスポートされたすべての列のリストを含むセクション。次のように定義されます。 - <ColumnName> クエリーによって返された列の名前 - name メトリック内の列のColumnName をオーバーライドします定義されている場合 - usage 以下に説明する値のいずれか - description メトリックの説明 - metrics_mapping usage がMAPPEDMETRIC に設定されている場合のオプションの列マッピング

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

Column Usage Label	Description
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で定義された一連のモニタリングクエリーをクラスターに自動的に注入するように構成できます。 Operator configuration の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のエクスポーターに実装されていません。

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

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

注釈

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

以下のセクション。

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

詳細については、

Prometheusでのオペレーターのモニタリング

PodMonitor を定義することにより、 Prometheus Operator を使用してオペレーターをモニタできます。

次のように、オペレーターポッドをポイントしますオペレーターと同じ名前空間に適用されることに注意してください。

kubectl -n cnpg-system apply -f - <<EOF
- --
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-controller-manager
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: cloudnative-pg
  podMetricsEndpoints:
    - port: metrics
EOF

オペレーターメトリックのTLSの有効化

デフォルトでは、オペレーターはHTTPを介してポート8080 でメトリックを公開します。 TLSでこのエンドポイントを保護するには、次の手順を実行します。

1. TLS証明書 tls.crt とプライベートキー tls.key を含むKubernetesシークレットを作成します。

2. シークレットをオペレーターポッドにマウントします。

3. METRICS_CERT_DIR 環境変数を設定して、証明書がマウントされているディレクトリをポイントします。

Secret 定義の例

apiVersion: v1
kind: Secret
metadata:
  name: cnpg-metrics-cert
  namespace: cnpg-system
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-certificate>
  tls.key: <base64-encoded-key>

次に、オペレーターの展開を更新してシークレットをマウントし、環境変数を構成します。

spec:
  template:
    spec:
      containers:
      - name: manager
        env:
        - name: METRICS_CERT_DIR
          value: /run/secrets/cnpg.io/metrics
        volumeMounts:
        - mountPath: /run/secrets/cnpg.io/metrics
          name: metrics-certificates
          readOnly: true
      volumes:
      - name: metrics-certificates
        secret:
          secretName: cnpg-metrics-cert
          defaultMode: 420

注釈

METRICS_CERT_DIR が設定されている場合、オペレーターはメトリックサーバーのTLSを自動的に有効にします。 https スキームを使用するようにPodMonitor構成を更新する必要もあります。

TLSが有効になったPodMonitor 構成の例

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: cnpg-controller-manager
  namespace: cnpg-system
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: cloudnative-pg
  podMetricsEndpoints:
    - port: metrics
      scheme: https
      tlsConfig:
        insecureSkipVerify: true  # or configure proper CA validation

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

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

注釈

以下の例では、デフォルトの名前空間で、cnpg-system 名前空間にインストールされたオペレーターを使用して作業していると仮定しています。ユースケースに合わせて調整してください。

ポート転送を使用する

メトリックを検査する最も簡単な方法は、関係するポッドのメトリックポートをポート転送することです。

たとえば、 cluster-example の-1 インスタンスのメトリックを検査するには、9187ポートをポート転送します。

kubectl port-forward cluster-example-1 9187:9187

ポート転送がアクティブになると、メトリックは、Webブラウザーで、構成に応じてHTTPまたはHTTPSを使用して、アドレスlocalhost:9187/metrics で簡単に検査できます。

オペレーターポッドは、ポート8080でメトリックもエクスポートします。インスタンスと同様に、オペレーター名前空間にあるオペレーターポッドをポート転送します。

kubectl -n cnpg-system port-forward pod/<CONTROLLER-MANAGER-POD> 8080:8080

ポート転送がアクティブになると、メトリックはブラウザー localhost:8080/metrics で簡単に表示できます。

カールを使用する

次のコマンドを使用してcurl ポッドを作成します。

kubectl apply -f - <<EOF
- --
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - name: curl
    image: curlimages/curl:8.17.0
    command: [sleep, 3600]
EOF

インスタンスによってエクスポートされたメトリックを検査するには、ターゲットポッドのポート9187に接続する必要があります。ポッドのIPアドレスを知る必要があります。これは、 kubectl get pod -o wide を実行すると簡単に見つけられます。次の汎用コマンドは、目的のポッドでcurl を実行します。

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

TLSメトリックを有効にした場合、代わりに実行します。

kubectl exec -ti curl -- curl -sk https://${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 ファイルで提供します。

CloudNativePGクラスターとオペレーターのGrafanaダッシュボードは、専用のリポジトリに保存されます cloudnative-pg/grafana-dashboards

ダッシュボードJSON構成として grafana-dashboard.json 。ファイルをダウンロードし、Grafanaにインポートできます。メニューDashboard > New > Import 。

kube-prometheus-stack で使用可能な設定に関する一般的なリファレンスについては、 helm show values prometheus-community/kube-prometheus-stack を実行できます。 kube-prometheus-stack を参照してください。

詳細ページ。