- はじめに：監視環境構築の課題
クラウド環境ではサーバ台数や構成が頻繁に変化するため、監視設定を手作業で行うと「環境差分」「作業ばらつき」が発生しやすくなります。特に、監視対象サーバへのエージェント導入（Node Exporter や CloudWatch Agent）は、毎回コマンドが異なり、担当者によって配置場所や設定方法が変わるケースも珍しくありません。
本記事では、この課題を解決するために Ansibleを用いた監視基盤の自動構築 に取り組みました。監視対象へのNode Exporter展開から、Prometheus/Grafana/Alertmanagerの立ち上げまで、すべてをAnsibleで統一した手順にしています。併せて、AWS CloudWatchとの比較検証も行いました。
- 全体アーキテクチャ
監視基盤はAWS上に構築し、PrometheusでPull型監視、CloudWatch AgentでPush型監視を実施しました。最小構成での検証です。
＜ここにアーキテクチャ図＞
（監視サーバ：Prometheus/Grafana/Alertmanager、監視対象：EC2 + Node Exporter + CloudWatch Agent）
- AWS基盤はTerraformで自動構築（概要のみ）
本検証では、AWS上に以下の最小構成をTerraformで作成しました。
VPC / Subnet
Security Group
監視対象EC2
監視サーバ用EC2
Terraformコード自体は本記事の主題ではないため割愛しますが、インフラ土台を再現性高く準備できる点は、Ansibleによる構成管理と相性が良いと感じました。
- Ansible構成：役割ごとにrolesを分割
Ansibleは、以下の3つのrolesに分割しています。
project/
ansible/
roles/
docker_engine/ # 監視サーバ側：Docker導入
monitoring_stack/ # Prometheus/Grafana/Alertmanager展開
agent_install/ # 監視対象側：NodeExporter & CWAgent
4-1. docker_engine
監視サーバ側にDocker Engine と Compose plugin を自動導入します。
手作業だとOSによって手順が変わりやすいため、Ansible化の恩恵が最も大きい部分です。
＜ここに docker_engine の task 抜粋（10行程度）＞
- 監視スタックを自動展開（Prometheus/Grafana/Alertmanager）
Docker Compose で監視基盤一式を起動する role です。
5-1. docker-compose.yml（抜粋）
Prometheus・Grafana・Alertmanager のみを最小で構成しています。
＜ここに docker-compose.yml の抜粋（Prometheus と Grafana の2サービス程度）＞
Ansibleでは、このYAMLファイルをテンプレートとして配布し、最後に docker compose up -d を実行します。
5-2. スタック起動のAnsibleタスク（抜粋）
-
name: Deploy monitoring stack
template:
src: docker-compose.yml.j2
dest: /opt/monitor/docker-compose.yml -
name: Start monitoring stack
command: docker compose up -d
args:
chdir: /opt/monitor
- Node Exporterを監視対象へ自動インストール
今回の自動化の中心であり、最も実務効果の大きい部分です。
● 手作業の課題
バージョン管理がバラバラになる
配置パス・systemdファイルが担当者で異なる
サーバ台数に比例して負荷が増える
設定ミスがインシデント時に発覚しがち
→ Ansibleで統一することで“全サーバが同じ状態”になるのが最大のメリットです。
6-1. Node Exporter 導入タスク（抜粋）
-
name: Install Node Exporter
unarchive:
src: node_exporter.tar.gz
dest: /usr/local/bin
remote_src: true -
name: Enable Node Exporter
systemd:
name: node_exporter
enabled: true
state: started
● ここでスクショ
ss -tnlp | grep 9100 が LISTEN している様子
Prometheus Targets が UP になった画面
- CloudWatch Agent の自動展開（Push型）
Node Exporter と対照的に、CloudWatch Agent はPush型の監視方式です。
AnsibleでCWAgentのパッケージ導入、設定ファイル配置、サービス起動まで統一しました。
＜ここに cwagent.json の超短い抜粋＞
（metrics_collected の1〜2項目だけ）
● 比較ポイント
Prometheus：Pull型、細かい粒度、自由度が高い
CloudWatch Agent：Push型、AWSネイティブで管理が容易
- 監視結果：Pull/Pushの違いが可視化できた
実際のメトリクス画面を比較することで、両者の特徴が明確になりました。
● Prometheus
5秒間隔で高粒度のデータを取得
Grafanaで柔軟に可視化できる
● CloudWatch
1分粒度（標準）
AWS管理のため運用負荷が軽い
＜ここに Grafana のスクショ＞
＜ここに CloudWatch メトリクスのスクショ＞
- まとめ
本検証では、Ansibleを用いて監視対象のNode Exporter導入から、Prometheus/Grafana/Alertmanagerの自動デプロイまでを一元化しました。特に、監視対象が増えた際に“inventoryへ1行追加してAnsibleを実行するだけで同じ構成を横展開できる”点は、実務での効果が非常に大きいと感じました。
また、Pull型（Prometheus）とPush型（CloudWatch Agent）の比較では、監視粒度の違いや運用負荷の差を検証により再確認できました。監視要件や組織の運用体制に応じて両方式を適切に使い分ける事が重要です。
今後はAlertmanagerの通知連携や環境ごとの変数管理、オンプレ環境とのハイブリッド監視など、より実務に近い構成への発展も検討してまいります。