Monitoring ========== .. Important:: PrometheusとGrafanaのインストールは、このプロジェクトの範囲を超えています。これらはシステムに正しくインストールされていることを前提としています。ただし、実験のために、 :ref:`Part 4 of the Quickstart ` で指示を提供します。 モニタリングインスタンス ------------------------ PostgreSQLインスタンスごとに、オペレーターは、HTTPまたはHTTPS、ポート9187で\ ``metrics`` という名前の `Prometheus `_ のメトリックのエクスポーターを提供します。オペレーターには、 :ref:`事前定義されたメトリックセット <事前定義されたメトリックセット>` に加えて、1つ以上の\ ``ConfigMap`` または\ ``Secret`` リソースを介して追加クエリを定義するための高度な構成およびカスタマイズ可能なシステムが付属しています詳細については、以下の :ref:`ユーザー定義メトリック <ユーザー定義メトリック>` を参照してください。 .. Important:: EDB CloudNativePGクラスターは、デフォルトで、 :ref:`predefined metrics <#default-set-of-metrics>` のセットをインストールします ``default-monitoring`` という名前の\ ``ConfigMap`` で。 .. Note:: :ref:`エクスポートされたメトリックを検査する方法 <エクスポートされたメトリックを検査する方法>` の指示に従って、エクスポートされたメトリックを検査できます。 以下のセクション。 PostgreSQLで実行されるすべての監視クエリは次のとおりです。 - アトミック クエリごとに1つのトランザクション - ``pg_monitor`` ロールで実行 - ``application_name`` を\ ``cnp_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つ以上のデータベースのリストを指定することにより、特定のユーザー定義メトリックのデフォルトデータベースを常にオーバーライドできます。 .. Seealso:: EDB CloudNativePGクラスターとPrometheusおよびGrafanaとの統合を評価することに興味がある場合は、 :ref:`Part 4 of the quickstart ` で簡単なセットアップガイドを見つけることができます。 Prometheus Operatorの例 ^^^^^^^^^^^^^^^^^^^^^^^ 特定のPostgreSQLクラスターは、 `Prometheus Operator's `_ リソース `PodMonitor `_ を使用してモニタできます。 クラスターリソース自分自身デフォルト\ ``false`` で\ ``.spec.monitoring.enablePodMonitor`` 〜\ ``true`` を設定することにより、クラスターを正しくポイントする\ ``PodMonitor`` をオペレーターが自動的に作成できます。 .. Important:: 自動的に作成される`PodMonitor` への変更は、次の調整サイクルでオペレーターによってオーバーライドされます。カスタマイズが必要な場合は、以下の説明に従って行うことができます。 特定のクラスターに\ ``PodMonitor`` を手動で展開するには、次のように定義し、必要に応じて調整します。 .. code:: yaml apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: cluster-example spec: selector: matchLabels: "k8s.enterprisedb.io/cluster": cluster-example podMetricsEndpoints: - port: metrics .. Important:: 一意の名前、および正しいクラスターの名前空間とラベルたとえば `cluster-example` などを使用して上記の例を変更していることを確認します。 .. Important:: このドキュメントの以前のバージョンで使用されていた`postgresql` ラベルは非推奨であり、将来的に削除されます。代わりに`k8s.enterprisedb.io/cluster` ラベルを使用して、インスタンスを選択してください。 メトリックポートでTLSを有効にする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ メトリックポートでTLS通信を有効にするには、 ``.spec.monitoring.tls.enabled`` 設定を\ ``true`` に構成します。この設定により、メトリックエクスポーターは、PostgreSQLが使用するものと同じサーバー証明書を使用して、ポート5432での通信を安全にします。 .. Important:: `.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: "k8s.enterprisedb.io/cluster": cluster-example podMetricsEndpoints: - port: metrics scheme: https tlsConfig: ca: secret: name: cluster-example-ca key: ca.crt serverName: cluster-example-rw .. Important:: 一意の名前、および正しいクラスターの名前空間とラベルたとえば `cluster-example` などを使用して上記の例を変更していることを確認します。 .. Important:: メトリックエンドポイントの`serverName` フィールドは、サーバー証明書で定義された名前のいずれかと一致する必要があります。デフォルトの証明書が使用されている場合、`serverName` 値は`-rw` 形式である必要があります。 事前定義されたメトリックセット ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ すべてのPostgreSQLインスタンスエクスポーターは、事前定義されたメトリックのセットを自動的に公開します。これらは2つの主要カテゴリに分類できます。 - ``cnp_collector_*`` で始まるPostgreSQL関連メトリックインスタンスを収容する個別のノードの数s - 最後に失敗したバックアップと最後に使用可能なバックアップを示すタイムスタンプ、およびcluster - フラグ レプリカクラスターモードが有効または無効かを示します - フラグ 手動スイッチオーバーが必要かどうかを示すb_tran_12フェンシングが有効かどうかを示すb_tran_12フラグ有効または無効 - ``go_*`` で始まるGoランタイム関連のメトリック 以下は、インスタンスの\ ``localhost:9187/metrics`` エンドポイントによって返されるメトリックのサンプルです。ご覧のとおり、Prometheusフォーマットは自己文書です。 .. code:: text # HELP cnp_collector_collection_duration_seconds Collection time duration in seconds # TYPE cnp_collector_collection_duration_seconds gauge cnp_collector_collection_duration_seconds{collector="Collect.up"} 0.0031393 # HELP cnp_collector_collections_total Total number of times PostgreSQL was accessed for metrics. # TYPE cnp_collector_collections_total counter cnp_collector_collections_total 2 # HELP cnp_collector_fencing_on 1 if the instance is fenced, 0 otherwise # TYPE cnp_collector_fencing_on gauge cnp_collector_fencing_on 0 # HELP cnp_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 cnp_collector_nodes_used gauge cnp_collector_nodes_used 3 # HELP cnp_collector_last_collection_error 1 if the last collection ended with error, 0 otherwise. # TYPE cnp_collector_last_collection_error gauge cnp_collector_last_collection_error 0 # HELP cnp_collector_manual_switchover_required 1 if a manual switchover is required, 0 otherwise # TYPE cnp_collector_manual_switchover_required gauge cnp_collector_manual_switchover_required 0 # HELP cnp_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 cnp_collector_pg_wal gauge cnp_collector_pg_wal{value="count"} 9 cnp_collector_pg_wal{value="slots_max"} NaN cnp_collector_pg_wal{value="keep"} 32 cnp_collector_pg_wal{value="max"} 64 cnp_collector_pg_wal{value="min"} 5 cnp_collector_pg_wal{value="size"} 1.50994944e+08 cnp_collector_pg_wal{value="volume_max"} 128 cnp_collector_pg_wal{value="volume_size"} 2.147483648e+09 # HELP cnp_collector_pg_wal_archive_status Number of WAL segments in the /var/lib/postgresql/data/pgdata/pg_wal/archive_status directory (ready, done) # TYPE cnp_collector_pg_wal_archive_status gauge cnp_collector_pg_wal_archive_status{value="done"} 6 cnp_collector_pg_wal_archive_status{value="ready"} 0 # HELP cnp_collector_replica_mode 1 if the cluster is in replica mode, 0 otherwise # TYPE cnp_collector_replica_mode gauge cnp_collector_replica_mode 0 # HELP cnp_collector_sync_replicas Number of requested synchronous replicas (synchronous_standby_names) # TYPE cnp_collector_sync_replicas gauge cnp_collector_sync_replicas{value="expected"} 0 cnp_collector_sync_replicas{value="max"} 0 cnp_collector_sync_replicas{value="min"} 0 cnp_collector_sync_replicas{value="observed"} 0 # HELP cnp_collector_up 1 if PostgreSQL is up, 0 otherwise. # TYPE cnp_collector_up gauge cnp_collector_up{cluster="cluster-example"} 1 # HELP cnp_collector_postgres_version Postgres version # TYPE cnp_collector_postgres_version gauge cnp_collector_postgres_version{cluster="cluster-example",full="17.2"} 17.2 # HELP cnp_collector_last_failed_backup_timestamp The last failed backup as a unix timestamp # TYPE cnp_collector_last_failed_backup_timestamp gauge cnp_collector_last_failed_backup_timestamp 0 # HELP cnp_collector_last_available_backup_timestamp The last available backup as a unix timestamp # TYPE cnp_collector_last_available_backup_timestamp gauge cnp_collector_last_available_backup_timestamp 1.63238406e+09 # HELP cnp_collector_first_recoverability_point The first point of recoverability for the cluster as a unix timestamp # TYPE cnp_collector_first_recoverability_point gauge cnp_collector_first_recoverability_point 1.63238406e+09 # HELP cnp_collector_lo_pages Estimated number of pages in the pg_largeobject table # TYPE cnp_collector_lo_pages gauge cnp_collector_lo_pages{datname="app"} 0 cnp_collector_lo_pages{datname="postgres"} 78 # HELP cnp_collector_wal_buffers_full Number of times WAL data was written to disk because WAL buffers became full. Only available on PG 14+ # TYPE cnp_collector_wal_buffers_full gauge cnp_collector_wal_buffers_full{stats_reset="2023-06-19T10:51:27.473259Z"} 6472 # HELP cnp_collector_wal_bytes Total amount of WAL generated in bytes. Only available on PG 14+ # TYPE cnp_collector_wal_bytes gauge cnp_collector_wal_bytes{stats_reset="2023-06-19T10:51:27.473259Z"} 1.0035147e+07 # HELP cnp_collector_wal_fpi Total number of WAL full page images generated. Only available on PG 14+ # TYPE cnp_collector_wal_fpi gauge cnp_collector_wal_fpi{stats_reset="2023-06-19T10:51:27.473259Z"} 1474 # HELP cnp_collector_wal_records Total number of WAL records generated. Only available on PG 14+ # TYPE cnp_collector_wal_records gauge cnp_collector_wal_records{stats_reset="2023-06-19T10:51:27.473259Z"} 26178 # HELP cnp_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 cnp_collector_wal_sync gauge cnp_collector_wal_sync{stats_reset="2023-06-19T10:51:27.473259Z"} 37 # HELP cnp_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 cnp_collector_wal_sync_time gauge cnp_collector_wal_sync_time{stats_reset="2023-06-19T10:51:27.473259Z"} 0 # HELP cnp_collector_wal_write Number of times WAL buffers were written out to disk via XLogWrite request. Only available on PG 14+ # TYPE cnp_collector_wal_write gauge cnp_collector_wal_write{stats_reset="2023-06-19T10:51:27.473259Z"} 7243 # HELP cnp_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 cnp_collector_wal_write_time gauge cnp_collector_wal_write_time{stats_reset="2023-06-19T10:51:27.473259Z"} 0 # HELP cnp_last_error 1 if the last collection ended with error, 0 otherwise. # TYPE cnp_last_error gauge cnp_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:: `cnp_collector_postgres_version` は、 Postgres PostgreSQLまたはEPASの`Major.Minor` バージョンを含むGaugeVecメトリックです。フルセマンティックバージョン`Major.Minor.Patch` は、 `full` という名前のラベルフィールドの1つ内にあります。 .. Note:: `cnp_collector_first_recoverability_point` および`cnp_collector_last_available_backup_timestamp` は、オブジェクトストアへの最初のバックアップまで0になります。これはWALアーカイブとは別です。 ユーザー定義メトリック ^^^^^^^^^^^^^^^^^^^^^^ この機能は現在 *ベータ* 状態であり、フォーマットは `queries.yaml file (release 0.12) `_ PostgreSQL Prometheus Exporterの。 カスタムメトリックは、次の例のように、\ ``.spec.monitoring.customQueriesConfigMap`` または\ ``customQueriesSecret`` セクションの下の\ ``Cluster`` 定義で作成した\ ``Configmap`` /``Secret`` を参照することにより、ユーザーが定義できます。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.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をインスタンスによって**自動的に**リロードしたい場合は、キー`k8s.enterprisedb.io/reload` を持つラベルをそれに追加できます。それ以外の場合、 `kubectl cnp reload` サブコマンドを使用してインスタンスをリロードする必要があります。 .. Important:: ユーザー定義メトリックが既存のメトリックを上書きすると、インスタンスマネージャーは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: k8s.enterprisedb.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" 基本的なモニタリングクエリのリストは以下のとおりです。これはEDB 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 cnp_some_query_rows{datname="albert"} 2 cnp_some_query_rows{datname="bb"} 5 cnp_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 cnp_some_query_rows{datname="albert"} 2 cnp_some_query_rows{datname="bb"} 5 cnp_some_query_rows{datname="freddie"} 10 cnp_some_query_rows{datname="template1"} 7 cnp_some_query_rows{datname="postgres"} 42 ユーザー定義メトリックの構造 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ すべてのカスタムクエリーには、次の基本構造があります。 .. code:: yaml : query: "" metrics: - : usage: "" description: "" 次に、使用可能なすべてのフィールドの簡単な説明を示します。 - ```` プロメテウスの名前 metric - ``name`` オーバーライド\ ```` 、定義されている場合 - ``query`` メトリックを生成するためにターゲットデータベースで実行するSQLクエリー - ``primary`` プライマリインスタンスでのみクエリーを実行するかどうか - edb_fortran_20 Prometheus PostgreSQLエクスポータの互換性-非推奨) - ``runonserver`` クエリを実行するPostgreSQLのバージョンを制限するセマンティックバージョンレンジたとえば ``">=11.0.0"`` または\ ``">=12.0.0 <=15.0.0"`` - ``target_databases`` ``query`` を実行するデータベースのリスト、またはedb_19 edb_19 ``query`` を実行するデータベースのリスト 自動検出を有効にします。デフォルトのデータベースが提供されている場合は上書きします。 - ``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 cnp__{= ... } .. Note:: `LabelColumnName` は、 `usage` が`LABEL` に設定されたメトリックとその`Value` 上記の\ ``pg_replication`` の例を考慮すると、エクスポーターのエンドポイントは、呼び出されると次の出力を結果ます。 .. code:: text # HELP cnp_pg_replication_in_recovery Whether the instance is in recovery # TYPE cnp_pg_replication_in_recovery gauge cnp_pg_replication_in_recovery 0 # HELP cnp_pg_replication_lag Replication lag behind primary in seconds # TYPE cnp_pg_replication_lag gauge cnp_pg_replication_lag 0 # HELP cnp_pg_replication_streaming_replicas Number of streaming replicas connected to the instance # TYPE cnp_pg_replication_streaming_replicas gauge cnp_pg_replication_streaming_replicas 2 # HELP cnp_pg_replication_is_wal_receiver_up Whether the instance wal_receiver is up # TYPE cnp_pg_replication_is_wal_receiver_up gauge cnp_pg_replication_is_wal_receiver_up 0 メトリックのデフォルトセット ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ オペレーターは、オペレーターの名前空間内のConfigMapまたはSecretで定義された一連のモニタリングクエリーをクラスターに自動的に注入するように構成できます。 :ref:`Operator configuration ` の\ ``MONITORING_QUERIES_CONFIGMAP`` または\ ``MONITORING_QUERIES_SECRET`` キーを、それぞれConfigMapまたはSecretの名前に設定する必要があります。オペレーターは\ ``queries`` キーの内容を使用します。 ``queries`` コンテンツを変更すると、それを使用するデプロイされたすべてのクラスターにすぐに反映されます。 オペレーターインストールマニフェストには、すべてのクラスターが使用する\ ``postgresql-operator-default-monitoring`` と呼ばれる事前定義されたConfigMapが付属しています。 ``MONITORING_QUERIES_CONFIGMAP`` は、オペレーター構成でデフォルトで\ ``postgresql-operator-default-monitoring`` に設定されます。 デフォルトのメトリックセットを無効にする場合は、次のことができます。 - オペレーターレベルで無効にする オペレーターConfigMapで ``MONITORING_QUERIES_CONFIGMAP`` / ``MONITORING_QUERIES_SECRET`` キーを\ ``""`` 空の文字列に設定します。オペレーターのConfigMapを変更するには、オペレーターの再起動が必要です。 - 特定のクラスターで無効にします。クラスターで\ ``.spec.monitoring.disableDefaultQueries`` を\ ``true`` に設定します。 .. Important:: `MONITORING_QUERIES_CONFIGMAP` / `MONITORING_QUERIES_SECRET` を介して指定されたConfigMapまたはSecretは、常に固定名`postgresql-operator-default-monitoring` でクラスターの名前空間にコピーされます。そのため、デフォルトのメトリックを使用する場合は、クラスターの名前空間にこの名前でConfigMapを作成しないでください。 Prometheus Postgresエクスポーターとの違い ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ EDB CloudNativePGクラスターは、PostgreSQL Prometheus Exporterからインスピレーションを得ていますが、いくつかの違いがあります。特に、 ``cache_seconds`` フィールドはEDB CloudNativePG クラスターのエクスポーターに実装されていません。 オペレーターのモニタリング -------------------------- オペレーターは、\ ``metrics`` という名前のポート8080でHTTPを介して `Prometheus `_ メトリックを内部公開します。 .. Note:: :ref:`エクスポートされたメトリックを検査する方法 <エクスポートされたメトリックを検査する方法>` の指示に従って、エクスポートされたメトリックを検査できます。 以下のセクション。 現在、オペレーターはデフォルトの\ ``kubebuilder`` メトリックを公開しています。詳細については、 `kubebuilder documentation `_ を参照してください。 .. _prometheus-operatorの例-1: Prometheus Operatorの例 ^^^^^^^^^^^^^^^^^^^^^^^ オペレーターの展開は、次の `PodMonitor `_ を定義することにより、 `Prometheus Operator `_ を使用して監視できます。 リソース .. code:: yaml apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: postgresql-operator-controller-manager spec: selector: matchLabels: app.kubernetes.io/name: cloud-native-postgresql podMetricsEndpoints: - port: metrics エクスポートされたメトリックを検査する方法 ------------------------------------------ このセクションでは、同じ名前空間で\ ``curl`` を実行する一時ポッドを使用して、特定のPostgreSQLインスタンスマネージャープライマリまたはレプリカまたはオペレーターによってエクスポートされたメトリックを検査する方法に関する基本的な手順を提供します。 .. Note:: 次の例では、PostgreSQLクラスターと並んで、デフォルトの名前空間で作業していることを前提としています。 Kubernetesの基本的な知識を適用して、この例をユースケースに自由に調整してください。 次の内容で\ ``curl.yaml`` ファイルを作成します。 .. code:: yaml apiVersion: v1 kind: Pod metadata: name: curl spec: containers: - name: curl image: curlimages/curl:8.2.1 command: [sleep, 3600] 次に、ポッドを作成します。 .. code:: shell kubectl apply -f curl.yaml インスタンスによってエクスポートされたメトリックを検査する場合、ターゲットポッドのポート9187に接続する必要があります。これは、実行する汎用コマンドです。ポッドの正しいIPを使用していることを確認します。 .. code:: shell kubectl exec -ti curl -- curl -s :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 補助リソース ------------ .. Important:: これらのリソースは、説明と実験のために提供されており、実稼働システムへのいかなる種類の推奨を表すものではありません :ref:`doc/src/samples/monitoring/ ` ディレクトリには、可観測性のための一連のサンプルファイルがあります。 :ref:`Part 4 of the quickstart ` を参照してください。 コンテキストのセクション - ``kube-stack-config.yaml`` kube-stack Helm chartインストールの構成ファイル。これにより、PrometheusがすべてのPodMonitorリソースをリッスンすることが保証されます。 - ``prometheusrule.yaml`` EDB CloudNativePGクラスターのアラートを含む\ ``PrometheusRule`` 。注これには、通知サービスとの相互運用は含まれません。 `Prometheus documentation `_ を参照してください。 - ``podmonitor.yaml`` EDB CloudNativePG Cluster Operator展開の\ ``PodMonitor`` 。 さらに、Prometheusアラートルールの「生」ソースを\ ``alerts.yaml`` ファイルで提供します。 `Grafana dashboard `_ には、専用のリポジトリがあります。 ``kube-prometheus-stack`` の構成では、\ ``kube-stack-config.yaml`` で提供するものより他のフィールドと設定が利用できることに注意してください。 ``helm show values prometheus-community/kube-prometheus-stack`` を実行して表示できます。詳細については、 `kube-prometheus-stack `_ を参照してください。 ページ。 OpenShiftでのモニタリング ------------------------- Openshift 4.6以降、 :ref:`Monitoring for user-defined projects ` と呼ばれる完全なモニタリングスタックがあります これは、クラスター管理者が有効にできます。 ``Cluster`` 定義のオプション\ ``spec.monitoring.enablePodMonitor`` が\ ``true`` に設定されている場合、クラウドネイティブPostgreSQLは\ ``PodMonitor`` オブジェクトを自動的に作成します。 クラスター全体の\ ``user-defined`` モニタリングを有効にするには、最初に次の内容を使用して\ ``openshift-monitoring`` 名前空間/プロジェクトに\ ``cluster-monitoring-config`` という名前で\ ``ConfigMap`` を作成する必要があります。 .. code:: yaml apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: true ``ConfigMap`` が既に存在する場合、変数\ ``enableUserWorkload: true`` を追加するだけです。 .. Important:: これにより、クラスター全体のモニタリングが有効になります。1つの名前空間/プロジェクトでのみ必要な場合は、Red Hatの公式ドキュメントを参照するか、クラスター管理者に相談してください。 その後、これに似たものを使用して名前空間/プロジェクトに適切なPodMonitorを作成するだけです。 .. code:: yaml apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: cluster-sample spec: selector: matchLabels: postgresql: cluster-sample podMetricsEndpoints: - port: metrics .. Note:: 私たちのサービスはメトリックを指すポートを定義していないため、現在`ServiceMonitor` は使用しません。メトリックポートを追加すると、機密データが公開される可能性があります。