Contents
スポンサードリンク
前提条件とサポートバージョン
Datadog の PostgreSQL 監視は、公式ドキュメントに記載された 現在サポートされているバージョン 上でのみ保証されています（2024 年 10 月時点）。新しいリリースが出た場合は、Datadog Integration Docs – PostgreSQL を随時確認してください。
| 項目 | 推奨バージョン |
|---|---|
| PostgreSQL 本体 | 13.x・14.x・15.x（最新パッチ） |
| Datadog Agent | 7.54 以降（Linux / Windows 共通） |
| OS | Ubuntu 22.04 LTS、Amazon Linux 2023、CentOS Stream 9、Windows Server 2019 以上 |
| パッケージマネージャ | APT、YUM/DNF、Chocolatey（Windows） |
| ネットワーク | Agent → DB の TCP 5432 を開放し、可能なら TLS/SSL を有効化 |
ポイント：上記要件を満たす環境であれば、Datadog の DBM と
pg_stat_statementsがシームレスに利用できます。
Datadog アカウント作成と API キー取得手順
1. アカウント登録
公式サインアップページ（https://app.datadoghq.com/signup）でメールアドレスとパスワードを入力し、無料トライアルまたは有料プランに申し込みます。
2. API キーの生成
- ログイン後、右上メニュー → Integrations → APIs を選択
- API Keys タブで Create API key ボタンをクリックし、用途が分かる名前（例：
postgres-monitor-prod）を付与して作成
3. Application キー（任意）
同じ画面の Application Keys セクションから必要に応じて取得します。CI/CD で Datadog API を呼び出す場合に便利です。
ベストプラクティス：API キーは機密情報です。平文でファイルに残さず、環境変数
DD_API_KEYまたはシークレット管理ツール（例：HashiCorp Vault）から注入してください。
Datadog Agent のインストールとアップグレード
2‑1. Linux (APT / YUM)
|
1 2 3 4 5 6 7 8 9 10 |
# Ubuntu/Debian 系（APT） DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=${DD_API_KEY} \ bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)" sudo systemctl enable --now datadog-agent # Amazon Linux / RHEL 系（YUM/DNF） DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=${DD_API_KEY} \ bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)" sudo systemctl restart datadog-agent |
公式リポジトリからインストールすることで、パッケージの署名検証と自動アップデートが保証されます。
2‑2. Windows (MSI)
|
1 2 3 4 5 6 7 8 9 |
$msi = "https://s3.amazonaws.com/dd-agent/msiexec/datadog-agent-7-latest.amd64.msi" Invoke-WebRequest -Uri $msi -OutFile "$env:TEMP\ddagent.msi" Start-Process msiexec.exe ` -ArgumentList "/i `"$env:TEMP\ddagent.msi`" APIKEY=$env:DD_API_KEY /quiet /norestart" ` -Wait Get-Service datadog-agent | Select-Object Status, Name |
PowerShell スクリプトは CI/CD パイプラインでも利用可能です。
2‑3. コンテナ環境 (Docker / Kubernetes)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# Docker Run（シンプル例） docker run -d --name dd-agent \ -e DD_API_KEY=${DD_API_KEY} \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ datadog/agent:7 # Kubernetes DaemonSet の抜粋 apiVersion: apps/v1 kind: DaemonSet metadata: name: datadog-agent spec: template: spec: containers: - name: agent image: datadog/agent:7 env: - name: DD_API_KEY valueFrom: secretKeyRef: name: dd-secret key: api-key |
Kubernetes では DaemonSet により全ノードでエージェントが自動展開され、Pod のメトリクスも取得できます。
PostgreSQL 監視設定 – DBM 有効化と最小構成
3‑1. DBM を有効にする datadog.yaml
|
1 2 3 4 5 6 7 |
# /etc/datadog-agent/datadog.yaml api_key: ${DD_API_KEY} site: datadoghq.com dbm: enabled: true # ← 必ず true に設定 |
3‑2. PostgreSQL 用インテグレーション postgresql.d/conf.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# /etc/datadog-agent/conf.d/postgresql.d/conf.yaml init_config: instances: - host: "db01.example.com" port: 5432 username: "datadog_mon" # 最小権限ユーザー（後述） password: "${DD_PG_PASSWORD}" # 環境変数経由で注入 dbname: "postgres" ssl: true # TLS が有効なら true tags: - "env:production" - "team:backend" |
ポイント：
passwordを直接書かずに環境変数DD_PG_PASSWORDで渡すことで、リポジトリへの機密情報流出リスクを低減します。
高度な構成 – pg_stat_statements とリモート監視
4‑1. pg_stat_statements の有効化手順
|
1 2 3 |
-- データベースに接続後実行 CREATE EXTENSION IF NOT EXISTS pg_stat_statements; |
postgresql.conf に以下を追記し、PostgreSQL を再起動します。
|
1 2 3 4 5 6 |
shared_preload_libraries = 'pg_stat_statements' track_activities = on track_counts = on track_io_timing = on log_min_duration_statement = 1000 # ミリ秒単位のスロークエリをログに残す |
pg_stat_statements が有効になると、Datadog の DBM がクエリ実行回数や平均レイテンシを詳細に取得できるようになります。
4‑2. リモート PostgreSQL の監視構成例
(1) Agent 側設定（アプリサーバー）
|
1 2 3 4 5 6 7 8 9 10 |
instances: - host: "db-remote.example.net" port: 5432 username: "datadog_mon" password: "${DD_PG_PASSWORD}" ssl: true tags: - "role:database" - "location:us-east-1" |
(2) ネットワーク接続手段
| 方法 | 説明 |
|---|---|
| VPC Peering / VPN | プライベート IP へ直接 TCP 5432 を開放。最もシンプルで低遅延。 |
| SSH トンネル | ssh -L 15432:localhost:5432 user@db-remote.example.net とローカルポート転送し、Agent が 127.0.0.1:15432 に接続。テスト環境で手軽に利用可能。 |
| AWS PrivateLink | AWS 上の DB へ安全に接続でき、ファイアウォール設定が最小限に抑えられる。 |
ベストプラクティス：DB への inbound は Agent が稼働する IP アドレスだけに限定し、不要な公開は避けます。
シークレット管理ベストプラクティス
| 項目 | 推奨実装例 |
|---|---|
| 環境変数 | DD_API_KEY・DD_PG_PASSWORD を OS の起動スクリプトや systemd ユニットの Environment= で設定。 |
| Docker / Kubernetes シークレット | Docker Compose の env_file:、K8s の Secret リソースを利用し、Pod 定義で valueFrom.secretKeyRef にマッピング。 |
| 外部シークレットストア | HashiCorp Vault、AWS Secrets Manager、Azure Key Vault などと連携し、エージェント起動時に API 経由で取得（Datadog の Secret Backend Integration を参照）。 |
| ローテーション | キーやパスワードは最低でも 90 日ごとに自動ローテーション。Vault の database シークレットエンジンを使えば、PostgreSQL 用ロールのパスワードを自動生成・更新できる。 |
| 監査ログ | 取得したシークレットは 読み取り専用 にし、アクセスは IAM ポリシーで最小権限に制限。取得ログは CloudTrail や Vault の監査機能で記録する。 |
ポイント：平文ファイルへの保存は避け、可能な限り外部シークレットストアと組み合わせることで、情報漏洩リスクを大幅に低減できます。
可視化・アラート・運用ベストプラクティス
5‑1. 主要メトリクスと活用例
| メトリクス | 主な利用シーン |
|---|---|
postgresql.queries.count |
トラフィック増加の早期検知 |
postgresql.latency.avg |
スロークエリが顕在化した際のアラート基準 |
postgresql.connections.active |
コネクションプール調整の指標 |
postgresql.cache.hit_ratio |
I/O ボトルネックの兆候 |
postgresql.errors.rate |
ネットワーク障害や認証エラーの監視 |
5‑2. 標準ダッシュボードとカスタムウィジェット
- 標準テンプレート：Integrations → PostgreSQL から「PostgreSQL Overview」ダッシュボードをインポート。
- カスタムウィジェット例（クエリレイテンシのタグ別比較）
- Add Widget → Timeseries
- メトリクス
postgresql.latency.avg、フィルタにrole:databaseとenv:productionを設定。
5‑3. アラートポリシー例（Datadog Monitor）
| 条件 | 推奨閾値 | 通知先 |
|---|---|---|
postgresql.latency.avg が 200 ms 超過（5 分間継続） |
200 ms | Slack #db-alerts |
postgresql.connections.active が max_connections の 80% 超え |
80 % | PagerDuty |
postgresql.errors.rate が 0.01（1 %）超過 |
0.01 | Email dba@example.com |
設定手順は Monitors → New Monitor → Metric で対象メトリクスと閾値を入力し、通知チャネルを選択します。
5‑4. セキュリティ対策まとめ
| 項目 | 推奨設定 |
|---|---|
| 最小権限ロール | CREATE ROLE datadog_mon LOGIN PASSWORD '•••' NOSUPERUSER NOCREATEDB NOCREATEROLE; GRANT CONNECT ON DATABASE mydb TO datadog_mon; GRANT SELECT ON ALL TABLES IN SCHEMA public TO datadog_mon; |
| TLS/SSL | ssl = on を有効化し、サーバ証明書を配置。Agent 側は ssl: true 設定で接続。 |
| ネットワーク制御 | DB の inbound は Agent が稼働する IP アドレス（または SG）だけに許可。 |
トラブルシューティングチェックリスト
- Agent 状態確認
bash
datadog-agent status - API キーの有無：
echo $DD_API_KEYで正しい値が設定されているか。 - DB 接続テスト（Linux）
bash
PGPASSWORD=$DD_PG_PASSWORD psql -h db01.example.com -U datadog_mon -d postgres -c "SELECT 1" - pg_stat_statements の有効化確認
sql
SELECT * FROM pg_extension WHERE extname='pg_stat_statements'; - SSL ハンドシェイクエラーの有無：
/var/log/datadog/agent.logにsslmode=verify-full関連メッセージが出ていないか確認。 - タグ付与漏れチェック：Datadog UI の Infrastructure → Hosts で対象インスタンスに期待通りのタグ（例：
env:production）が表示されるか。
よくある失敗：
conf.yamlにパスワードを平文で記載した結果、リポジトリ公開時に情報漏洩。上記ベストプラクティスの環境変数またはシークレット管理ツール導入で回避できます。
まとめ
- 公式サポートバージョン を確認し、対応 OS・Agent バージョンを揃えることが第一歩。
- API キーとシークレット は環境変数や外部シークレットストアで安全に管理する。
- DBM の有効化 + 最小構成ファイル だけで基本的な PostgreSQL メトリクスは自動取得可能。
pg_stat_statementsとリモート接続 により、クエリ単位の詳細分析と分散環境でもフル監視が実現できる。- 可視化・アラート設定 と 定期的なトラブルシューティング を組み合わせれば、障害発生前に予防策を講じられる。
この手順とベストプラクティスをプロジェクトに取り入れれば、Datadog 上での PostgreSQL 監視が確実かつ安全に運用できるようになります。
スポンサードリンク