[アップデート]Amazon CloudWatch Database InsightsがセルフマネージドPostgreSQLをサポートしたので自宅サーバ上のDBの情報を取得してみた

Amazon CloudWatch Database InsightsがセルフマネージドPostgreSQLに対応しました。今回の明示されているのはPostgreSQL on EC2が対象のようですが、できそうな気がしたのであえて自宅サーバ上のPostgreSQLからデータを取り込んでみました。
じゅんや
2026.09.02
 初めに昨日のアップデートでDatabase InsightsがセルフマネージドのPostgreSQLを管理できるようになりました。
https://aws.amazon.com/about-aws/whats-new/2026/08/database-insights-self-managed-postgresql/
これまでDatabase Insights(Performance Insightsの後続)はAmazon RDSの詳細分析機能として提供されてきましたが、今後はそれに限らずAmazon EC2上で管理されているPostgreSQLのデータを取り込みパフォーマンス等を分析できるようになります。

PostgreSQL単体ではGUIによる可視化機能はなく別でツールを用意する必要があったのでこれは非常に助かります。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Database-Insights-Self-Managed.html

Database Insights currently supports PostgreSQL for self-managed databases. The database can run on an Amazon EC2 instance.
ドキュメントとしてはAmazon EC2上で起動するDBを対象としている旨が明示されており、手順もそれに沿った形となっていますのでオンプレミス環境はサポートされているかは怪しそうです。
ただデータ自体はCloudWatch Agentで飛ばしているだけでEC2固有の事情は大筋の部分に絡まなさそう？なので今回はあえて自宅サーバ上からデータ飛ばしてみようと思います。

結論から言えばデータは取れ、設定はCloudWatch AgentとPostgreSQLの内の話なので大筋はEC2上で設定する場合と変わりないものの、ドキュメント上オンプレミスのサポートが明示されているわけではない点はご注意ください。
せっかくのアップデート記事なので本筋のEC2を書こうと思いましたがやってみたかったので...
 料金面についてAmazon RDSを対象とする場合スタンダードであれば無料、アドバンスドであれば有料(コア数に対する時間課金)となりますが、セルフマネージ型の場合は、データ収集量に基づいての従量課金となります。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Database-Insights-Self-Managed.html

Standard pricing for CloudWatch OpenTelemetry metrics and CloudWatch Logs applies. For more information, see Amazon CloudWatch Pricing.
なお料金に関しては本機能自体としての課金というよりはデータとしてはCloudWatch OpenTelemetryメトリクスおよびCloudWatch Logsとして収集されるのでその分の課金となります。
現時点ではCloudWatch OpenTelemetryは取り込み1GBあたり$0.5、CloudWatch Logsは取り込みに$0.72/GB、保管に対し$0.033/GB・月(圧縮後・スタンダード)という料金になります。詳細は料金表をご参照ください。
https://aws.amazon.com/jp/cloudwatch/pricing/
 設定してみる以下のドキュメントに沿って設定をします。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Database-Insights-Self-Managed-PostgreSQL.html
PostgreSQLは14以上が対象の旨が記載されていますが、CloudWatch Agentには特に指定はないもののひとまず両方とも最新バージョンを入れておきます。
OSはAlmaLinux 9.8、PostgreSQLは18.6、CloudWatch Agentは1.300072.0b1766の利用となりました。
 PostgreSQLインストール・初期設定(OS上作業)今回検証用のサーバはAlmaLinux 9.8を利用していますが、デフォルトのリポジトリだと13.xであったため外部リポジトリから追加します。
PostgreSQL公式ページにバージョン等を指定するといい感じにコマンドを作ってくれるページがあったのでこちらを元にインストールします。
https://www.postgresql.org/download/linux/redhat/
# Install the repository RPM:
sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# Install PostgreSQL:
sudo dnf install -y postgresql18-server

# Optionally initialize the database and enable automatic start:
sudo /usr/pgsql-18/bin/postgresql-18-setup initdb
sudo systemctl enable postgresql-18
sudo systemctl start postgresql-18
ここからは先ほどのAWS側のドキュメントに沿って設定します。
データの収集はpg_stat_activityおよびpg_stat_statements、各種ログからとなるのでpg_stat_statementsの有効化に加えて必要に応じてスロークエリが記録されるようにします。
今回は概ね初期値のまま取り込みます
# Required(コメントアウト部分は初期値がすでにその値)
shared_preload_libraries = 'pg_stat_statements'
#track_activities = on
track_activity_query_size = 4096 ##長いクエリが切れるからそれの対策？
#password_encryption = 'scram-sha-256'

# ロギングの有効化とローテーション設定
# ドキュメントの内容をそのまま持ち込んでいるがこの辺りは環境に応じて調整(週次ローテ)
logging_collector = on
log_directory = 'log'
log_filename = 'postgresql-%a.log'
log_rotation_age = 1d
log_rotation_size = 0
log_truncate_on_rotation = on
## スロークエリを記録する必要がある場合は必ず設定(デフォルトは-1なので記録しない)
log_min_duration_statement = 500
log_line_prefix = '%m [%p] %q%u@%d '
9月 02 13:33:59 localhost.localdomain postgres[55855]: 2026-09-02 13:33:59.160 JST [55855] FATAL:  ファイル"pg_stat_statements"にアクセスできませんでした: そのようなファイルやディレクトリはありません
これでPostgreSQLを再起動...と思ったらpg_stat_statements用のモジュール入ってなかったので追加して再起動します。
$ sudo yum install -y postgresql18-contrib
...
$ service postgresql-18 restart
少し順番が前後するのですが後述のPostgreSQL上作業でユーザを追加するのでそのユーザがアクセスできるようにpg_hba.confに設定を追加しておきます。

ユーザ名はドキュメントに従いcw_monitorとしてますが任意で問題なさそうです。またアクセスはローカルのCloudWatch Agent上からなのでlocalhost上からのアクセスでOKです。
host    all       cw_monitor   127.0.0.1/32    scram-sha-256
host    all       cw_monitor   ::1/128         scram-sha-256
 PostgreSQL上作業ここからはPostgreSQL上での作業になります。
大きく必要なのは先ほど追加してpg_stat_statementsの有効化、およびモニタリングに利用されるDBユーザの作成です。
ユーザ名はドキュメントと同じでcw_monitorにしておきますがCloudWatch Agent側で指定可能な値なので環境でネーミングルール等があればそれに従って問題ありません。
-- sudo su - postgres && psql
-- pg_stat_statementsの有効化
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
-- cw_monitorの作成と権限付与
-- どうしても記録させたくないテーブルがあればREVOKEすることもできそうですがどこまで影響があるかは別途要検証
CREATE ROLE cw_monitor WITH LOGIN PASSWORD '******';
GRANT pg_monitor TO cw_monitor;

GRANT USAGE ON SCHEMA public TO cw_monitor;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO cw_monitor;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO cw_monitor;
これはPostgreSQLの仕様的にどうしようもないのですが、上記実行後テーブルが作成された場合cw_monitorユーザに権限はつかないので別途付与する必要がありますのでその点はご注意ください。

(自動化するとしたらpg_cronで定期的に実行するとかでしょうか？）
cw_monitorでクエリを実行して...権限は大丈夫そうですね。
[postgres@localhost ~]$ psql -h localhost -U cw_monitor -d postgres -c "SELECT count(*) FROM pg_stat_activity;"
ユーザー cw_monitor のパスワード:
 count
-------
     9
(1 行)

[postgres@localhost ~]$ psql -h localhost -U cw_monitor -d postgres -c "SELECT count(*) FROM pg_stat_statements;"
ユーザー cw_monitor のパスワード:
 count
-------
     9
(1 行)
 CloudWatch Agentのインストール・設定以下のコマンドでインストールします。環境がAlmaLinuxで標準リポジトリ上にはないのでS3上から取得してインストールします。

また今回はEC2環境ではなくIAMロールが利用できないためaws-cliを別途インストールしアクセスキーを設定しておきます。
アクセスキーの発行とそのユーザの作成については割愛しますがCloudWatchAgentServerPolicyがついていればOKです。
$ sudo yum install -y https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm
...
$ sudo yum install aws-cli
...
$ aws configure --profile AmazonCloudWatchAgent
/opt/aws/amazon-cloudwatch-agent/etc/pgpassに先ほど作成したcw_monitorの接続情報を書き込んだファイルを用意します。必要に応じてcwagentだけに読み取り権限を与えましょう。

配置先はCloudWatch Agent側の設定ファイルで指定できますので上記以外その他のパスでも可能です。
# sudo chmod 600 /opt/aws/amazon-cloudwatch-agent/etc/pgpass
# sudo chown cwagent:cwagent /opt/aws/amazon-cloudwatch-agent/etc/pgpass
localhost:5432:*:cw_monitor:your-password
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.jsonにDBの接続情報を飛ばすための設定を書き込みます。password_fileは上記で作成したファイルパスです。
{
  "agent": {
    "region": "ap-northeast-1"
  },
  "opentelemetry": {
    "collect": {
      "database_insights": {
        "postgresql": [
          {
            "endpoint": "localhost:5432",
            "instance_name": "postgresql-insights-dev",
            "username": "cw_monitor",
            "password_file": "/opt/aws/amazon-cloudwatch-agent/etc/pgpass",
            "logs": {
              "file_path": "/var/lib/pgsql/18/data/log/postgresql-*.log"
            }
          }
        ]
      }
    }
  }
}
これで起動しましょう！デフォルトのモードがEC2でメタデータを取得しようとするのでEC2外環境の今回は-m OnPremを指定します。
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config  -s -m OnPrem -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
 Database Insights上での確認さて設定はここまでなのでこれでうまく取れてれば良いのですが...うまく自宅サーバから上のデータでも取れてそうです。

種別もサービスプロバイダもSelf-managedとして検出されています。
ログの方も/aws/self-managed-database-insights/postgresql/から始まる２種が出力されています。
中身を見る限りraw-eventsがOTeLデータでserver-logsがPostgreSQLのログっぽいです。
Database Insightsの方確認するとこのデータによるメトリクスやログを確認できます。
DB負荷分析も機能的にはできそうであるのですがAASが0.01で負荷詳細の内訳の表示が確認できませんでした...。
pg_stat_statementsやpg_stat_activityは見えているはずでEC2のメタデータのような固有の部分は絡まないはずなので少し調べてわかりそうであれば追記します。
 終わりに非RDS環境からのPostgreSQLのデータをCloudWatch上に取り込みDatabase Insights上で表示してみました。
Amazon RDSはサービスの時間単価自体はEC2と比べれば高いサービスで費用の兼ね合いでEC2にWebサーバと同居で載せているような場合であっても、別に可視化ツールを用意せずにAWS上で完結できるので非常に良いアップデートだと思います。
料金も取り込んだログの容量に対する課金なため小規模であればそこまでかからないかとは思いますが、実は短期ローテーションで回しているだけで大量のログが出ているようなケースについては予期せぬ高額な課金が発生する可能性もありますのでその点はご注意ください。
今回は本来サポートされていない外部サーバからのデータを取り込んでみましたが、一応データとして飛ばせて取り込めるので全機能を使えるかはわからないですがお試しで飛ばしてみてできる範囲で使ってみるのも面白いかもしれません。