モニタリング¶

重要

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

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

PostgreSQL インスタンスごとに、オペレーターは metrics という名前のポート 9187 で、HTTP 経由でパート 4 - Prometheus と Grafana を使用してクラスターを監視するのメトリックのエクスポーターを提供します。オペレーターには事前定義されたメトリックのセットが付属しており、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 メソッドによって定義されるように、メインデータベースに対して実行されます。

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

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

プロメテウスオペレーターの例¶

Prometheus Operator's リソース PodMonitor を使用して、特定の PostgreSQL

クラスターを監視できます。クラスターを正しく指す PodMonitor は、オペレーターがクラスターリソース自体で .spec.monitoring.enablePodMonitor を true に設定することで自動的に作成できます (デフォルト: false)。

重要

自動的に作成された 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 関連のメトリック。以下が含まれます。
ディスク上の WAL ファイルの数と合計サイズ - アーカイブステータスフォルダー内の .ready および .done ファイルの数 - 要求された同期レプリカの最小数と最大数、および期待値と実際に観測された値 - レプリカクラスターモードが有効かどうかを示すフラグまたは無効 - 手動切り替えが必要かどうかを示すフラグ
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_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="13.4.0"} 13.4

#  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 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.17.1"} 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 つの中にあります。

ユーザー定義の指標¶

この機能は現在 ベータ 状態であり、フォーマットは PostgreSQL Prometheus Exporter の queries.yaml file に触発されています。

カスタムメトリックは、次の例のように、.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 とシークレットを 自動的に リロードする場合は、キー cnpg.io/reload のラベルを追加できます。そうしないと、kubectl cnpg reload サブコマンドを使用してインスタンスをリロードする必要があります。

重要

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

ユーザー定義指標の例¶

上記の 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> : Prometheus メトリックの名前 - 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 : 以下で説明する値の 1 つ - 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 またはシークレットで定義された一連の監視クエリをクラスターに自動的に挿入するように構成できます。

オペレーター構成の 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 経由で: パート 4 - Prometheus と Grafana を使用してクラスターを監視するメトリックを内部的に公開します。

以下のセクション。

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

プロメテウスオペレーターの例¶

オペレーターのデプロイは、次の PodMonitor を定義することにより、プロメテウスオペレーターの例を使用して監視できます。

リソース：

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:7.84.0
    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 ヘルムチャートインストール用の構成ファイル。 Prometheus がすべての PodMonitor リソースをリッスンするようにします。
cnpg-prometheusrule.yaml : CloudNativePG のアラートを含む PrometheusRule 。注: これには、通知サービスとの相互運用は含まれません。 Prometheus documentation を参照してください。
grafana-configmap.yaml : サンプル CloudNativePG ダッシュボードの定義を含む ConfigMap。定義内のラベルに注意してください。これにより、Grafana デプロイメントが ConfigMap を確実に見つけることができます。

さらに、参照用に、Grafana ダッシュボードと Prometheus アラートルールの「生の」ソースを提供します。

alerts.yaml : アラート付きの Prometheus ルール
grafana-dashboard.json : ネイティブ Grafana JSON としての CloudNativePG ダッシュボード。

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

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

ページ。

モニタリング¶

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

プロメテウスオペレーターの例¶

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

ユーザー定義の指標¶

ユーザー定義指標の例¶

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

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

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

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

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

オペレーターの監視¶

プロメテウスオペレーターの例¶

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

補助リソース¶

前のトピックへ

次のトピックへ

目次

モニタリング¶

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

プロメテウス オペレーターの例¶

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

ユーザー定義の指標¶

ユーザー定義指標の例¶

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

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

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

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

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

オペレーターの監視¶

プロメテウス オペレーターの例¶

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

補助リソース¶

プロメテウスオペレーターの例¶

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

プロメテウスオペレーターの例¶