Helmを使用したPostgreSQL監視用のNRDOTのインストールおよび設定

postgresql-otel Helmチャートを使用して、Kubernetes上でPostgreSQLの監視をインストールおよび構成できます。オプションとして、チャートは監視ロール、その権限、およびpg_stat_statements拡張機能を作成するセットアップジョブを実行することもできます。

ガイド付きインストレーション

代わりにNew Relic UIからインストールするには、one.newrelic.com > Integrations & Agents > PostgreSQL (Database 360)に移動してください。このページでは、手動インストレーションについてのみ説明します。

重要

チャートは、ネットワーク経由でリモートからPostgreSQLに到達するKubernetesデプロイメントとしてコレクターをデプロイするため、PostgreSQLのメトリクスのみをレポートします：PostgreSQLが実行されているマシンのホストやインフラストラクチャのメトリクスはレポートしません。リリースごとに1つのPostgreSQLインスタンスをモニターし（そのインスタンス上の複数のデータベースがサポートされています）、TLSやAWS IAM認証などのdb_auth資格情報プロバイダーは構成しません。

サーバーレベルの前提条件

PostgreSQL 14以降が必要です。このチャートをインストールする（またはセットアップジョブを有効にする）前に、以下のサーバーパラメーターを設定しておく必要があります。shared_preload_librariesなしではpg_stat_statementsを作成できません。また、そのパラメーターには再起動が必要なため、Kubernetesクラスタ内で実行されているものがこれを代行することはできません。

パラメータ	価値
`shared_preload_libraries`	`pg_stat_statements`
`pg_stat_statements.track`	`ALL`
`pg_stat_statements.max`	`10000`
`pg_stat_statements.save`	`on`
`track_activity_query_size`	`4096`
`track_functions`	`all`

セルフホスト型：これらをpostgresql.confに設定し、PostgreSQLを再起動します。一部のディストリビューションでは、pg_stat_statementsを利用可能にするためにpostgresql-contribパッケージをインストールする必要があります。
AWS RDSまたはAurora：これらは設定ファイルではなく、DBのパラメーターグループで設定します。track_activity_query_sizeとpg_stat_statements.maxは静的パラメーターです；apply_method: pending-rebootで適用してから、インスタンスを再起動してください。これらをすぐに適用すると、InvalidParameterCombinationで失敗します。Auroraの場合、パラメーターグループのファミリー名はエンジンのメジャーバージョンと完全に一致する必要があります（例：aurora-postgresql16）。

前提条件

有効なNew Relicのライセンスキー。
Helm 3.0以降、およびKubernetesクラスタにアクセスするように設定されたkubectl。
KubernetesクラスタからPostgreSQLホスト（またはRDSエンドポイント）およびポートへのネットワーク接続：
- セルフホスト型：PostgreSQLホストへのルーティングされたパス（VPN、ピアリング、または共有ネットワーク）、ホスト名の場合はDNS解決、そしてPostgreSQL側のpg_hba.confとファイアウォールは、接続の実際の送信元IP（ポッドのIP自体ではなく、NATゲートウェイである可能性があります）を許可する必要があります。
- AWS RDS：VPCピアリング、トランジット・ゲートウェイ、またはRDSインスタンスとの共有VPC配置を行い、RDSセキュリティ・グループでクラスタのエグレス・ソースからのPostgreSQLポート（デフォルトでは5432）を許可する必要があります。
データベースごとの権限を持つ作成済みの監視ロール、またはチャートのセットアップジョブがそれらを作成できるようにするためのPostgreSQL管理者認証情報のいずれかです。以下の監視認証情報の設定をご覧ください。

ネームスペースを作成

インストール先のネームスペースを作成します。helm install --create-namespaceは最後のインストール手順でのみネームスペースを作成するため、次の手順でシークレットを作成する前に、ネームスペースが存在している必要があります：

bash

$kubectl create namespace newrelic

ヒント

以下のすべてのコマンドで-nを渡す必要がないように、現在のkubectlコンテキストのデフォルトのネームスペースとして設定します：

bash

$kubectl config set-context --current --namespace=newrelic

監視資格情報の設定

チャートのセットアップ・ジョブでPostgreSQL監視ロールを作成するかどうか、作成しない場合はその認証情報をどのように提供するかを決定します：

この方法ではセットアップ・ジョブがないため、ここで監視ロールが作成されることはありません。チャートをインストールする前に、スーパーユーザーとしてご自身で作成してください。クラスタレベルでこれを1回実行してください：

CREATE USER newrelic WITH LOGIN PASSWORD '<password>';
ALTER ROLE newrelic INHERIT;   -- required on PG15+, a no-op on PG14

次に、postgresql.databasesにリストする予定のすべてのデータベースでこれを実行します：

CREATE SCHEMA IF NOT EXISTS otel;
GRANT USAGE ON SCHEMA otel TO newrelic;
GRANT USAGE ON SCHEMA public TO newrelic;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO newrelic;
GRANT pg_monitor TO newrelic;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

詳細については、セルフホスト型PostgreSQL または RDS上のPostgreSQL の データベースユーザーと権限の構成 ステップを参照してください。

次のステップで、監視用のユーザー名とパスワードを直接values.yamlに設定します。

この方法では、セットアップジョブもありません。上記のプレーン資格情報メソッドとまったく同じように、まず監視ロールとデータベースごとの権限をご自身で作成してください。唯一の違いは資格情報の保存場所です：values.yamlにプレーンテキストで保存する代わりに、Kubernetesシークレットに保存します：

bash

$kubectl create secret generic postgres-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

この方法では、チャートのセットアップジョブが監視ロールを作成し、postgresql.databases内のすべてのデータベースに対して、otelスキーマを作成し、USAGE/SELECT/pg_monitorを付与し、pg_stat_statements拡張機能を作成します。監視と管理者の両方の資格情報は、Kubernetesシークレットとして提供する必要があります：セットアップジョブはプレーンテキストの管理者資格情報を受け入れることはなく、セットアップジョブを有効にするにはシークレットベースの監視資格情報も必要になります。

監視のユーザー名とパスワードを使用してシークレットを作成します。これは、セットアップジョブが作成し、コレクターが接続に使用するIDです：
bash
```
$kubectl create secret generic postgres-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
```
セットアップジョブは、Kubernetesシークレット経由でのみ管理者資格情報を受け入れます（values.yamlにプレーンテキストのユーザー名/パスワードを含めることはできません）。この認証情報は、CREATE USER、CREATE SCHEMA、およびCREATE EXTENSIONを必要とするため、スーパーユーザー（セルフホスト）またはrds_superuserと同等のもの（RDS）である必要があります：
bash
```
$kubectl create secret generic postgres-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Helmの値を設定します

環境に合わせてpostgresql.topologyを設定してください：

価値	説明
`self-hosted`	セルフホスト型PostgreSQL、ネットワーク経由でアクセス。
`rds`	AWS RDS上のPostgreSQLまたはAurora。

postgresql.databases は必須の空ではないリストです。MySQLやSQL Serverとは異なり、PostgreSQLにはすべてのデータベースをモニターするモードはありません：1つの接続が一度に1つのデータベースをターゲットにするため、レシーバーにはどれをスクレイプするかを指示する必要があります。

前の手順で選択した資格情報メソッドに一致するvalues.yamlを使用します：

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

postgresql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  username: <YOUR_MONITORING_USERNAME>
  password: <YOUR_MONITORING_PASSWORD>
  databases:
    - <YOUR_DATABASE>
    - <ANOTHER_DATABASE>

# No setup job runs, so create the monitoring role and its
# per-database grants yourself before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

postgresql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: postgres-monitor-creds
  databases:
    - <YOUR_DATABASE>
    - <ANOTHER_DATABASE>

# No setup job runs, so the monitoring role referenced by
# this secret must already exist - create it yourself
# before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

postgresql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: postgres-monitor-creds
  databases:
    - <YOUR_DATABASE>
    - <ANOTHER_DATABASE>

setupJob:
  enabled: true
  image:
    # -- psql-capable image. No default: the official postgres
    # image bundles psql and is a reasonable choice.
    repository: postgres
    tag: "16"
    pullPolicy: IfNotPresent
  postgresAdmin:
    existingSecret: postgres-admin-creds
  # -- Also creates the otel.explain_statement SECURITY DEFINER
  # function, so the receiver can EXPLAIN write/locking queries.
  enableExplainPermissions: false
  # -- Also creates the pgvector extension in each database.
  enablePgvector: false

パラメータ	説明
`licenseKey`	New Relicライセンスキー。
`otlpEndpoint`	ご使用のリージョンのOTLP/gRPCエンドポイントは、スキームなしの単なる `host:port` として指定します： `otlp.nr-data.net:4317` （米国）または `otlp.eu01.nr-data.net:4317` （EU）。詳細については、 New Relic OTLPエンドポイントのドキュメントを参照してください。
`postgresql.server` / `postgresql.port`	クラスタから到達可能なPostgreSQLホスト（またはRDSエンドポイント）およびポート。
`postgresql.databases`	モニターするデータベースの必須の、空ではないリスト。
`postgresql.excludeDatabases`	クラスタ全体のトップクエリおよびクエリサンプルのスキャンから除外されるデータベース。デフォルトは `[rdsadmin]` で、 `topology` が `rds` の場合にのみレンダリングされます；RDSでは、監視ユーザーは `rdsadmin` に到達できないため、これを除外することで権限エラーを回避できます。
`setupJob.image.repository` / `setupJob.image.tag`	セットアップジョブで使用される `psql` 対応のイメージです。チャートにはデフォルトが付属していないため、セットアップジョブが有効になっている場合は指定する必要があります。公式の `postgres` イメージには `psql` がバンドルされており、妥当な選択肢です。
`setupJob.enableExplainPermissions`	オプション。また、 `otel.explain_statement` `SECURITY DEFINER` 関数を作成してそれに `EXECUTE` を付与し、レシーバーが書き込み権限を保持せずに、ロックおよび書き込みクエリに対して `EXPLAIN` を実行できるようにします。 `false` のままにしても安全です：レシーバーはインラインの `EXPLAIN` にフォールバックするため、これらのステートメントは単にクエリプランを取得しません。
`setupJob.enablePgvector`	オプション。また、ベクトルメトリクスのために、各モニターデータベースに `vector` 拡張機能を作成します。 `l1` 、 `hamming` 、および `jaccard` の距離関数には、pgvector 0.7.0以降が必要です。

ヒント

通常、postgresql.topQueryCollection.explainFunctionNameを設定する必要はありません。レシーバー自体のデフォルトはすでにotel.explain_statement（setupJob.enableExplainPermissionsが作成する関数そのもの）であり、チャートは空の場合にキーを省略するため、追加の設定なしで両者は一致します。レシーバーに異なる名前の関数を指定する場合にのみ、これを設定してください。

ヒント

postgresql.collectionInterval、metricsトグル、topQueryCollection/querySampleCollectionブロック、additionalReceiverConfigエスケープハッチなど、利用可能なすべての設定オプションについては、チャートのvalues.yamlを参照してください。

(オプション) 1つのリリースから複数のインスタンスをモニターする

postgresql.*の代わりに、1つのリリースで単一のコレクターポッドから複数のPostgreSQLインスタンス（セルフホスト型またはRDS）をモニターするようにpostgresqlMulti.enabled: trueを設定します。2つのモードは相互に排他的です：同じリリースでpostgresql.serverとpostgresqlMulti.enabled: trueを設定しないでください。

エントリはdatabasesではなくinstancesと呼ばれます：各インスタンスは個別のPostgreSQLサーバーであり、シングルインスタンスモードでのpostgresql.databasesの動作と同じように、それぞれが独自のネストされたdatabasesリスト（そのインスタンス上でモニターする個々のデータベース）を持ちます。

マルチインスタンスモードには、プレーンなユーザー名/パスワードのパスはありません：各インスタンスには、監視資格情報を含む独自のKubernetesシークレットが必要です。セットアップジョブに各監視ロールを作成させるかどうかも決定してください：

インストールする前に、各インスタンスの監視ロールのシークレットをご自身で作成してください（values.yamlで指定したnameと一致するように、インスタンスごとに繰り返します）：

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secret you created for it.
postgresqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  instances:
    - name: db1
      server: <YOUR_DB_1_HOST>
      port: 5432
      existingSecret: db1-monitor-creds
      databases:
        - appdb1
    - name: db2
      server: <YOUR_DB_2_HOST>
      port: 5432
      existingSecret: db2-monitor-creds
      databases:
        - appdb2

# No admin credential is configured here since the setup
# job is disabled - create each instance's monitoring role
# yourself first.
setupJob:
  enabled: false

各インスタンスには、独自の監視ロールシークレットと独自の管理者資格情報シークレットの両方が必要です（インスタンスごとに繰り返します）：

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
>kubectl create secret generic db1-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, db2-admin-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secrets you created for it.
postgresqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  instances:
    - name: db1
      server: <YOUR_DB_1_HOST>
      port: 5432
      existingSecret: db1-monitor-creds
      databases:
        - appdb1
      postgresAdmin:
        existingSecret: db1-admin-creds
    - name: db2
      server: <YOUR_DB_2_HOST>
      port: 5432
      existingSecret: db2-monitor-creds
      databases:
        - appdb2
      postgresAdmin:
        existingSecret: db2-admin-creds

setupJob:
  enabled: true
  image:
    # -- psql-capable image. No default: the official postgres
    # image bundles psql and is a reasonable choice.
    repository: postgres
    tag: "16"

パラメータ	説明
`postgresqlMulti.enabled`	1つのリリースから複数のインスタンスをモニターするには、 `postgresql.*` の代わりに `true` に設定します。デフォルトは `false` です。
`postgresqlMulti.topology`	`self-hosted` または `rds` 、 `postgresql.topology` と同じ意味であり、このリリースのすべてのインスタンスで共有されます。
`postgresqlMulti.instances`	モニターするインスタンスの一覧。各エントリには、一意の `name` 、 `server` （ `port` のデフォルトは `5432` ）、 `existingSecret` 、およびそのインスタンス上のデータベース名の必須で空ではない `databases` リストが必要です； `setupJob.enabled` が `true` の場合にのみ、エントリごとに `postgresAdmin.existingSecret` を追加します。

パラメータ

説明

postgresqlMulti.enabled

1つのリリースから複数のインスタンスをモニターするには、

postgresql.*

の代わりに

true

に設定します。デフォルトは

false

です。

postgresqlMulti.topology

self-hosted

または

rds

、

postgresql.topology

と同じ意味であり、このリリースのすべてのインスタンスで共有されます。

postgresqlMulti.instances

モニターするインスタンスの一覧。各エントリには、一意の

name

、

server

（

port

のデフォルトは

5432

）、

existingSecret

、およびそのインスタンス上のデータベース名の

必須で空ではない

databases

リストが必要です；

setupJob.enabled

が

true

の場合にのみ、エントリごとに

postgresAdmin.existingSecret

を追加します。

ヒント

setupJob.enableExplainPermissions およびsetupJob.enablePgvectorは、すべてのインスタンスのすべてのデータベースで共有される単一のトグルです；インスタンスごとに設定することはできません。スクレイプ設定（収集間隔、メトリクス、topQueryCollection/querySampleCollection）も同様に、postgresqlMulti.instances内のすべてのインスタンスに同一に適用されます；インスタンスごとのオーバーライドはありません。異なる必要があるものにはadditionalReceiverConfigを使用してください。セットアップジョブは、リリースごとに1回ではなく、インスタンスごとに1回（<release>-setup-<name>）実行されます。

Helmチャートをインストールする

New Relic Helm リポジトリを追加します。

bash

$helm repo add newrelic https://helm-charts.newrelic.com
$helm repo update

values.yamlファイルを使用してチャートをインストールします：

bash

$helm upgrade --install postgresql-otel newrelic/postgresql-otel \
>  -n newrelic \
>  --create-namespace \
>  -f values.yaml

インストレーションを確認する

セットアップジョブが完了し（有効な場合）、コレクターポッドが実行されていることを確認します：
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

データが到着していることを確認するには、クエリビルダーでこのクエリを実行してください：

SELECT count(*) FROM Metric
WHERE metricName LIKE 'postgresql.%'
AND instrumentation.provider = 'opentelemetry'
SINCE 10 minutes ago

データを探す、使う

データの収集が開始されると、New Relic UIから包括的なPostgreSQLデータベース監視にアクセスできます。

New RelicでPostgreSQLデータベースエンティティを見つけるには：

one.newrelic.com > All capabilities > Databasesに移動します。
Entity typeドロップダウンからPostgreSQL instanceを選択し、Applyをクリックします。
エンティティのリストからPostgreSQLデータベースを選択します。

NRDOTを使用したPostgreSQL監視の概要

New Relicを使用したPostgreSQL監視で利用可能なすべてのインストレーション方法をご覧ください。

CLIインストール

単一のNew Relic CLIコマンドを使用して、PostgreSQLの監視をインストールおよび設定する方法について説明します。

Ansibleのインストール

newrelic.newrelic_installを使用して、大規模なPostgreSQL監視をインストールおよび構成する方法について説明しますAnsibleロール。

Chefのインストール

newrelic-install Chefクックブックを使用して、PostgreSQLの監視を大規模にインストールおよび設定する方法について説明します。

この機械翻訳は、参考として提供されています。

Helmを使用したPostgreSQL監視用のNRDOTのインストールおよび設定

ガイド付きインストレーション

重要

サーバーレベルの前提条件

前提条件

ネームスペースを作成

ヒント

監視資格情報の設定

セットアップジョブなし：プレーンなユーザー名とパスワード

セットアップジョブなし：シークレットベースの認証情報

自動セットアップジョブ

Helmの値を設定します

セットアップジョブなし：プレーンなユーザー名とパスワード

セットアップジョブなし：シークレットベースの認証情報

自動セットアップジョブ

ヒント

ヒント

(オプション) 1つのリリースから複数のインスタンスをモニターする

セットアップジョブなし

自動セットアップジョブ

ヒント

Helmチャートをインストールする

インストレーションを確認する

データを探す、使う

NRDOTを使用したPostgreSQL監視の概要

CLIインストール

Ansibleのインストール

Chefのインストール

この機械翻訳は、参考として提供されています。

Helmを使用したPostgreSQL監視用のNRDOTのインストールおよび設定

ガイド付きインストレーション

重要

サーバーレベルの前提条件 .css-21sua1{background:none;border:none;width:0;padding:0;}

前提条件

ネームスペースを作成

ヒント

監視資格情報の設定

セットアップジョブなし：シークレットベースの認証情報

自動セットアップジョブ

Helmの値を設定します

セットアップジョブなし：プレーンなユーザー名とパスワード

セットアップジョブなし：シークレットベースの認証情報

自動セットアップジョブ

ヒント

ヒント

(オプション) 1つのリリースから複数のインスタンスをモニターする

セットアップジョブなし

自動セットアップジョブ

ヒント

Helmチャートをインストールする

インストレーションを確認する

データを探す、使う

関連ドキュメント

NRDOTを使用したPostgreSQL監視の概要

CLIインストール

Ansibleのインストール

Chefのインストール

サーバーレベルの前提条件