Monitoring ========== .. raw:: html .. Note:: PrometheusとGrafanaのインストールは、このプロジェクトの範囲を超えています。これらはシステムに正しくインストールされていることを前提としています。ただし、実験のために、 :ref:`Part 4 of the Quickstart ` で指示を提供します。 　 モニタリングインスタンス ------------------------ PostgreSQLインスタンスごとに、オペレーターは、HTTPまたはHTTPS、ポート9187で\ ``metrics`` という名前の `Prometheus `_ のメトリックのエクスポーターを提供します。オペレーターには、 :ref:`事前定義されたメトリックセット <事前定義されたメトリックセット>` に加えて、1つ以上の\ ``ConfigMap`` または\ ``Secret`` リソースを介して追加クエリを定義するための高度な構成およびカスタマイズ可能なシステムが付属しています詳細については、以下の :ref:`ユーザー定義メトリック <ユーザー定義メトリック>` を参照してください。 .. Note:: CloudNativePGは、デフォルトで、 :ref:`メトリックのデフォルトセット <メトリックのデフォルトセット>` のセットをインストールします ``cnpg-default-monitoring`` という名前の\ ``ConfigMap`` で。 　 .. Note:: :ref:`エクスポートされたメトリックを検査する方法 <エクスポートされたメトリックを検査する方法>` の指示に従って、エクスポートされたメトリックを検査できます。 以下のセクション。 　 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つ以上のデータベースのリストを指定することにより、特定のユーザー定義メトリックのデフォルトデータベースを常にオーバーライドできます。 .. Note:: CloudNativePGとPrometheusおよびGrafanaの統合を評価することに興味がある場合は、 :ref:`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が構成されている名前空間に必ずデプロイしてください。 .. code:: yaml apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: cluster-example spec: selector: matchLabels: cnpg.io/cluster: cluster-example podMetricsEndpoints: - port: metrics .. Note:: - `metadata.name` `PodMonitor` に一意の名前を付けます。 - `spec.namespaceSelector` これを使用して、PostgreSQLクラスターが実行されている名前空間を指定します。 - `spec.selector.matchLabels` `cnpg.io/cluster: ` ラベルを使用して、PostgreSQLインスタンスを正しくターゲットとする必要があります。 　 ``PodMonitor`` 自動作成の非推奨 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Warning "Feature Deprecation Notice":: `Cluster` リソースの`.spec.monitoring.enablePodMonitor` フィールドは非推奨であり、オペレーターの将来のバージョンでは削除される予定です。 現在この機能を使用している場合、 ``.spec.monitoring.enablePodMonitor`` を削除または\ ``false`` に設定し、上記のようにクラスターの\ ``PodMonitor`` リソースを手動で作成することを強くお勧めします。この変更により、監視構成の完全な所有権が保証され、オペレーターによって管理または上書きされるのを防ぎます。 メトリックポートでTLSを有効にする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ メトリックポートでTLS通信を有効にするには、 ``.spec.monitoring.tls.enabled`` 設定を\ ``true`` に構成します。この設定により、メトリックエクスポーターは、PostgreSQLが使用するものと同じサーバー証明書を使用して、ポート5432での通信を安全にします。 .. Note:: `.spec.monitoring.tls.enabled` 設定を変更すると、クラスターのローリング再起動がトリガーされます。 　 ``PodMonitor`` がオペレーター\ ``.spec.monitoring.enablePodMonitor`` を\ ``true`` に設定して管理されている場合、TLSを介してメトリックにアクセスするために必要な構成が自動的に含まれます。 TLS経由でメトリックを読み取るのに適した\ ``PodMonitor`` を手動で展開するには、次のように定義し、必要に応じて調整します。 .. code:: yaml 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 .. Note:: 一意の名前、および正しいクラスターの名前空間とラベルたとえば `cluster-example` などを使用して上記の例を変更していることを確認します。 　 .. Note:: メトリックエンドポイントの`serverName` フィールドは、サーバー証明書で定義された名前のいずれかと一致する必要があります。デフォルトの証明書が使用されている場合、`serverName` 値は`-rw` 形式である必要があります。 　 事前定義されたメトリックセット ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ すべてのPostgreSQLインスタンスエクスポーターは、事前定義されたメトリックのセットを自動的に公開します。これらは2つの主要カテゴリに分類できます。 - ``cnpg_collector_*`` で始まるPostgreSQL関連メトリックインスタンスを収容する個別のノードの数s - 最後に失敗したバックアップと最後に使用可能なバックアップを示すタイムスタンプ、およびcluster - フラグ レプリカクラスターモードが有効または無効かを示します - フラグ 手動スイッチオーバーが必要かどうかを示すb_tran_12フェンシングが有効かどうかを示すb_tran_12フラグ有効または無効 - ``go_*`` で始まるGoランタイム関連のメトリック 以下は、インスタンスの\ ``localhost:9187/metrics`` エンドポイントによって返されるメトリックのサンプルです。ご覧のとおり、Prometheusフォーマットは自己文書です。 .. code:: text ## 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 .. Note:: `cnpg_collector_postgres_version` は、PostgreSQLの`Major.Minor` バージョンを含むGaugeVecメトリックです。フルセマンティックバージョン`Major.Minor.Patch` は、 `full` という名前のラベルフィールドの1つ内にあります。 　 .. Warning:: メトリック`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`` を参照することにより、ユーザーが定義できます。 .. code:: yaml 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`` 参照のリストが含まれています。参照されるリソースは、 **クラスター** リソースと同じ名前空間に作成する必要があることに注意してください。 .. Note:: ConfigMapとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`cnpg.io/reload` を持つラベルをそれに追加できます。それ以外の場合、 `kubectl cnpg reload` サブコマンドを使用してインスタンスをリロードする必要があります。 　 .. Note:: ユーザー定義メトリックが既存のメトリックを上書きすると、インスタンスマネージャーはjson警告ログを出力します。これには、メッセージ`Query with the same name already found. Overwriting the existing one.` と上書きされたクエリー名を含むキー`queryName` が含まれます。 　 ユーザー定義メトリックの例 ^^^^^^^^^^^^^^^^^^^^^^^^^^ ここでは、上記の\ ``Cluster`` の例で参照される、単一のカスタムクエリーを含む\ ``ConfigMap`` の例を示します。 .. code:: yaml 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展開に既にインストールされています :ref:`メトリックのデフォルトセット <メトリックのデフォルトセット>` を参照してください。 述語クエリーを使用したユーザー定義メトリックの例 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``predicate_query`` オプションを使用すると、ユーザーは\ ``query`` を実行して、指定された条件でのみメトリックを収集できます。これを行うには、ユーザーは単一の\ ``boolean`` 列で最大1つの行を返す述語照会を提供する必要があります。 述語クエリーは、メインクエリーと同じトランザクションで、同じデータベースに対して実行されます。 .. code:: yaml 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() `_ ルールに従ってパターンと一致することにより、ターゲットデータベースのリストを展開します。 .. Note:: `*` 文字はyamlに `special meaning `_ があるため、このようなパターンが含まれる場合、`target_databases` 値を引用符で`"*"` する必要があります。 　 返されるラベルには、常にデータベースの名前を含めることをお勧めします。たとえば、次の例のように\ ``current_database()`` ファンクションを使用します。 .. code:: yaml 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 これにより、次のメトリックが公開されます。 .. code:: text cnpg_some_query_rows{datname="albert"} 2 cnpg_some_query_rows{datname="bb"} 5 cnpg_some_query_rows{datname="freddie"} 10 次に、自動検出を有効にしたクエリーの例を示します。これは、 ``template1`` データベースでも実行されますそれ以外の場合、前述のクエリーによって返されません。 .. code:: yaml 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" 上記の例では、次のメトリックを生成しますデータベースが存在する場合。 .. code:: text 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 ユーザー定義メトリックの構造 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ すべてのカスタムクエリーには、次の基本構造があります。 .. code:: yaml : query: "" metrics: - : usage: "" description: "" 次に、使用可能なすべてのフィールドの簡単な説明を示します。 - ```` プロメテウスの名前 metric - ``name`` オーバーライド\ ```` 、定義されている場合 - ``query`` メトリックを生成するためにターゲットデータベースで実行するSQLクエリー - ``primary`` プライマリインスタンスでのみクエリーを実行するかどうか - edb_fortran_21 Prometheus PostgreSQLエクスポータの構文との互換性-非推奨) - ``runonserver`` クエリを実行するPostgreSQLのバージョンを制限するセマンティックバージョンレンジ例 ``">=11.0.0"`` または\ ``">=12.0.0 <=15.0.0"`` - ``target_databases`` ``query`` または :ref:`複数のデータベースで実行されているユーザー定義メトリックの例 <複数のデータベースで実行されているユーザー定義メトリックの例>` を実行するデータベースのリスト 自動検出を有効にします。デフォルトのデータベースが提供されている場合は上書きします。 - ``predicate_query`` ターゲットデータベースで実行する最大1つの行と1つの\ ``boolean`` 列を返すSQLクエリー。システムは述語を評価し、\ ``true`` が\ ``query`` を実行するかどうかを評価します。 - ``metrics`` エクスポートされたすべての列のリストを含むセクション。次のように定義されます。 - ```` クエリーによって返された列の名前 - ``name`` メトリック内の列の\ ``ColumnName`` をオーバーライドします定義されている場合 - ``usage`` 以下に説明する値のいずれか - ``description`` メトリックの説明 - ``metrics_mapping`` ``usage`` が\ ``MAPPEDMETRIC`` に設定されている場合のオプションの列マッピング ``usage`` の可能な値は次のとおりです。 .. csv-table:: :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`` によって返されます。 .. code:: text cnpg__{= ... } .. Note:: `LabelColumnName` は、 `usage` が`LABEL` に設定されたメトリックとその`Value` 　 上記の\ ``pg_replication`` の例を考慮すると、エクスポーターのエンドポイントは、呼び出されると次の出力を結果ます。 .. code:: text ## 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で定義された一連のモニタリングクエリーをクラスターに自動的に注入するように構成できます。 :ref:`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`` に設定します。 .. Note:: `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 `_ メトリックを内部公開します。 .. Note:: :ref:`エクスポートされたメトリックを検査する方法 <エクスポートされたメトリックを検査する方法>` の指示に従って、エクスポートされたメトリックを検査できます。 以下のセクション。 　 現在、オペレーターはデフォルトの\ ``kubebuilder`` メトリックを公開しています。 `kubebuilder documentation `_ を参照 詳細については、 Prometheusでのオペレーターのモニタリング ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `PodMonitor `_ を定義することにより、 `Prometheus Operator `_ を使用してオペレーターをモニタできます。 次のように、オペレーターポッドをポイントしますオペレーターと同じ名前空間に適用されることに注意してください。 .. code:: yaml kubectl -n cnpg-system apply -f - < tls.key: 次に、オペレーターの展開を更新してシークレットをマウントし、環境変数を構成します。 .. code:: yaml 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 .. Note:: `METRICS_CERT_DIR` が設定されている場合、オペレーターはメトリックサーバーのTLSを自動的に有効にします。 `https` スキームを使用するようにPodMonitor構成を更新する必要もあります。 　 TLSが有効になった\ ``PodMonitor`` 構成の例 .. code:: yaml 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インスタンスマネージャープライマリまたはレプリカまたはオペレーターによってエクスポートされたメトリックを検査する方法に関する基本的な手順を提供します。 .. Note:: 以下の例では、デフォルトの名前空間で、`cnpg-system` 名前空間にインストールされたオペレーターを使用して作業していると仮定しています。ユースケースに合わせて調整してください。 　 ポート転送を使用する ^^^^^^^^^^^^^^^^^^^^ メトリックを検査する最も簡単な方法は、関係するポッドのメトリックポートをポート転送することです。 たとえば、 ``cluster-example`` の\ ``-1`` インスタンスのメトリックを検査するには、9187ポートをポート転送します。 .. code:: sh kubectl port-forward cluster-example-1 9187:9187 ポート転送がアクティブになると、メトリックは、Webブラウザーで、構成に応じてHTTPまたはHTTPSを使用して、アドレス\ ``localhost:9187/metrics`` で簡単に検査できます。 オペレーターポッドは、ポート8080でメトリックもエクスポートします。インスタンスと同様に、オペレーター名前空間にあるオペレーターポッドをポート転送します。 .. code:: sh kubectl -n cnpg-system port-forward pod/ 8080:8080 ポート転送がアクティブになると、メトリックはブラウザー `localhost:8080/metrics `_ で簡単に表示できます。 カールを使用する ^^^^^^^^^^^^^^^^ 次のコマンドを使用して\ ``curl`` ポッドを作成します。 .. code:: yaml kubectl apply -f - <:9187/metrics たとえば、PostgreSQLクラスターが\ ``cluster-example`` と呼ばれ、クラスター内の最初のポッドのエクスポートされたメトリックを取得する場合、次のコマンドを実行してそのポッドのIPをプログラム的に取得できます。 .. code:: shell POD_IP=$(kubectl get pod cluster-example-1 --template {{.status.podIP}}) そして、実行します。 .. code:: shell kubectl exec -ti curl -- curl -s ${POD_IP}:9187/metrics TLSメトリックを有効にした場合、代わりに実行します。 .. code:: shell kubectl exec -ti curl -- curl -sk https://${POD_IP}:9187/metrics オペレーターのメトリックにアクセスするには、オペレーターが実行されているポッドをポイントし、ターゲットとしてTCPポート8080を使用する必要があります。 メトリックの検査が終了したら、\ ``curl`` ポッドを削除することを忘れてください。 .. code:: shell kubectl delete -f curl.yaml 補助リソース ------------ .. Note:: これらのリソースは、説明と実験のために提供されており、実稼働システムへのいかなる種類の推奨を表すものではありません 　 `doc/src/samples/monitoring/ `_ ディレクトリには、可観測性のための一連のサンプルファイルがあります。 :ref:`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 `_ を参照してください。 詳細ページ。