【Ansible入門】Ansible でモダンな監視環境を構築してみる（2/2）

Last updated at 2026-01-06Posted at 2026-01-05

1. はじめに

この記事は前回の続きです。
前回は Prometheus / Grafana を使ってメトリクスを取得できるところまでを扱いました。
今回も引き続き Ansible を使って、Alertmanager・Loki・Promtail の設定を行い、ログ収集とアラート通知まで含めた構成を作っていきます。

この記事について

この記事は、あくまで自分の備忘録として書いているものです。
実際に手を動かしながら考えたことや、少し詰まったところも含めて、そのまま残しています。

気になるところだけ拾う、くらいの感覚で読んでもらえればと思います。

前回の振り返り

前回の記事では、Ansible を使って監視サーバの基本構成を構築しました。

Prometheus / Grafana を Docker Compose で起動
監視対象サーバに node_exporter を導入
Prometheus でターゲットが UP になり、Grafana でメトリクスを確認できる状態

今回はこの構成を前提にして、ログ収集とアラート通知（Slack）を追加していきます。

2. 今回の構成とゴール

2.1 今回の構成

ここで、今回追加する各コンポーネントについて、簡単に役割を整理しておきます。

Alertmanager
Prometheus が検知したアラートを受け取り、通知先や通知方法を制御するコンポーネントです。
今回は Slack への通知のみを行う最小構成としています。
Loki
ログの保存と検索を行うためのログ基盤です。
Prometheus と同じラベル設計を前提としており、メトリクスとログを同じ感覚で扱える点が特徴です。
promtail
各監視対象サーバ上で動作するログ収集エージェントです。
ローカルのログファイルを読み取り、HTTP 経由で Loki に転送します。
node_exporter と同様に、軽量な常駐プロセスとして動作します。

デプロイ先は以下の通りです。

監視サーバ
- Prometheus
- Grafana
- Loki ★追加
- Alertmanager ★追加
監視対象サーバ
- node_exporter
- promtail ★追加

Loki と Alertmanager は、Prometheus / Grafana と同じ監視サーバ上で、前回同様Docker Compose を使って起動します。
監視対象サーバ側では、node_exporter と同様に、promtail を常駐プロセスとして動かし、systemd 管理のサービスとして起動します。

2.2 今回のゴール

今回のゴールは以下の通りです。

監視対象サーバのログを promtail で収集できている
Loki にログが保存されている
Grafana 上でログを確認できる
Prometheus のアラートルールが評価されている
Alertmanager からSlackへ通知が飛ぶことを確認できる

前回はメトリクスが見えるところまででしたが、今回はそれに加えて、ログが残り、異常を通知できるところまで進めます。
設定はすべて Ansible で行い、手動での作業はできるだけ入れない形にしています。

3. Ansible構成の全体解説（Inventory / Playbook / Role）

この章では、今回の構成全体をあらためて確認します。
基本的なディレクトリ構成は前回と同じですが、ログ収集やアラート通知の追加にあわせて、いくつかファイルを追加・更新しています。
Ansible に直接関係しない補助的なファイルも含めて、今回の状態をそのまま載せています。

★が付いているものが、今回変更が入っている箇所です。

★追加は新規追加
★更新は既存ファイルを編集したもの

.
├── ansible.cfg
├── inventory
│   ├── group_vars 
│   │   └── all.yml ★追加
│   └── hosts.ini
├── playbooks
│   ├── common.yml
│   ├── docker.yml
│   ├── monitoring-stack.yml
│   ├── target-agent.yml
│   └── test
│       ├── makestep.yml ★追加
│       ├── test-cpu.yml ★追加
│       ├── test-disk.yml ★追加
│       ├── test-log.yml ★追加
│       └── test-memory.yml ★追加
└── roles
    ├── common
    │   └── tasks
    │       └── main.yml
    ├── docker
    │   └── tasks
    │       └── main.yml
    ├── monitoring-stack
    │   ├── files
    │   │   ├── alertmanager.yml ★追加
    │   │   ├── dashboards.yml ★追加
    │   │   ├── node-alerts.yml ★追加
    │   │   └── node_exporter.json
    │   ├── tasks
    │   │   └── main.yml
    │   └── templates
    │       ├── docker-compose.yml.j2 ★更新
    │       ├── grafana-datasource.yml.j2
    │       ├── loki-config.yml.j2 ★追加
    │       └── prometheus.yml.j2
    └── target-agent
        ├── tasks
        │   └── main.yml
        └── templates
            └── promtail-config.yml.j2 ★追加

今回追加/更新したファイルについて

inventory/group_vars/all.yml
ポート番号やバージョンなど、複数 Role から参照する変数を定義
playbooks/test/makestep.yml
Chrony の makestep を実行し、時刻ズレを強制的に補正するための Playbook
playbooks/test/test-cpu.yml
CPU 使用率を意図的に上げ、メトリクスやアラートの動作確認を行うための Playbook
playbooks/test/test-disk.yml
ディスク使用率を上げ、ディスク関連アラートの確認を行うための Playbook
playbooks/test/test-log.yml
ログ確認を行うための Playbook
roles/monitoring-stack/files/alertmanager.yml
Alertmanager の通知先やルーティングを定義する設定ファイル
roles/monitoring-stack/files/dashboards.yml
Grafana にダッシュボードを自動登録するための定義ファイル
roles/monitoring-stack/files/node-alerts.yml
Prometheus のアラートルールを定義したファイル
roles/monitoring-stack/templates/docker-compose.yml.j2
既存の構成に、Loki と Alertmanager を追加するために更新した Docker Compose テンプレート
roles/monitoring-stack/templates/loki-config.yml.j2
Loki の動作設定を定義するための設定ファイルテンプレート
roles/target-agent/templates/promtail-config.yml.j2
監視対象サーバ上で動かす promtail のログ収集設定を定義するテンプレート

3.1 Inventory の構成

前回と同様に、ホスト定義はシンプルな構成のままです。

hosts.ini

Inventory/hosts.ini では、管理対象となるサーバを定義しています。
詳細な説明は前回の記事をご参照ください。

アラートの挙動を複数台で確認した方がより実務的で分かりやすいため、監視対象サーバを2台追加し、合計3台にしています。

group_vars/all.yml

group_vars/all.yml は、今回新しく追加しました。
ポート番号やツールのバージョン情報など、複数の設定ファイルで参照する値を定義します。
前回は各Role にdefaults/main.yml でそれぞれ変数定義していましたが、構成がやや複雑になってきたため、変数はすべて group_vars/all.yml に書くこととしました。

# monitoring-stack
trg01: "192.168.1.40"
trg02: "192.168.1.41"
trg03: "192.168.1.42"
prometheus_port: "9090"
grafana_port: "3000"
node_exporter_port: "9100"
loki_port: "3100"
loki_host: "192.168.1.31"

# target-agent
node_exporter_version: "1.6.1"
promtail_version: "2.9.4"

補足：変数の優先順位（Variable Precedence）について

Ansible には、変数がどこで定義されたかによって、どの値を優先的に使うか明確なルールがあります。
その中でも、実務でよく使う主要なものについて簡単に説明します。
※細かい差異や特殊なケース（Playbook vars や set_fact など）は、今回の構成では使用していないため省略

上から優先度高>低

Extra vars（ansible-playbook -e vars=hoge）
Playbook 実行時にコマンドラインから渡す変数
Ansible の中で最も優先順位が高く、他のすべての変数定義を上書きする
一時的な検証や、その場限りの値変更に向いている
Inventory host_vars（host_vars/server1.yml など）
特定のホストにのみ適用する変数定義
同じグループに属していても、この定義があれば個別の値が優先される
Inventory group_vars（group_vars/all.yml など）
グループ単位で適用される変数定義
Role defaults よりも優先度が高く、複数 Role から参照される共通設定をまとめるのに向いている
Role defaults（roles/*/defaults/main.yml）
最も優先順位が低い変数定義
値が明示的に指定されていない場合のデフォルトとして機能する

実際のところ、簡単な検証などであれば、ansible-playbook 実行時に -e オプションで変数を渡して済ませてしまうことも多いです。一時的に値を変えたいだけであれば、この方法が一番楽です。
今回は、共通で使う変数は group_vars/all.yml に集約しています。

3.2 監視サーバ側の変更点（monitoring-stack ロール）

3.2.1 新規追加コンポーネント

今回、監視サーバ側で新たに追加したのは以下の2つです。

Loki（ログ保存）
Alertmanager（アラート通知）
どちらも Prometheus / Grafana と同様に、Docker Compose で動かしてます。

3.2.2 ディレクトリ構成と設定ファイルの増加

Loki と Alertmanager を追加したことで、監視サーバ側のディレクトリと設定ファイルが増えてます。
主な追加 / 変更点は以下です。

Loki 用ディレクトリ
Alertmanager 用ディレクトリ
Prometheus のアラートルールファイル
Grafana の Provisioning 設定

前回と同様に、ファイル管理系は ansible.builtin.file モジュールを使用してます。

3.2.3 docker-compose.yml の変更点

今回追加するLoki / Alertmanager は、コンテナで動かすため、docker-compose.ymlにサービス定義を追加しています。

3.2.4 Prometheus で追加した最小限の設定

Alertmanagerを追加したことでPrometheus側にも最低限の設定変更を行っています。
主な変更点は、2点です。

アラートルールファイルの読み込み設定
Alertmanagerへの転送先定義

3.3 監視対象サーバ側の変更点（target-agent ロール）

監視サーバ側に Loki を追加したことで、監視対象サーバ側にも変更が入ります。追加要素はシンプルで、promtail を入れるだけです。

3.3.1 promtail の追加

promtailは、ローカルのログファイルを読み、Lokiに転送します。

構成としては、node_exporter と同じく systemd 管理にしています。
コンテナで動かす選択肢もありますが、監視対象サーバでは以下の理由から systemd管理を採用してます。

構成をシンプルに保ちたい
監視対象サーバにdocker依存を持ち込みたくない

また、promtailやnode_exporterは単一バイナリで完結する軽量なエージェントなので、コンテナ化によるメリットが小さいところも理由の一つです。

3.3.2 target-agent ロールの変更点

target-agent ロールには、もともと node_exporter のセットアップ処理だけ入れてました。今回そこに、promtail の処理を追加しています。promtail の処理でやることは以下です。

promtail 用ディレクトリの作成
バイナリの配置
設定ファイルの配置
systemd unit の作成と起動
流れとしては node_exporter とほぼ同じです。

3.3.3 Loki との接続について

promtail からのログ送信先は、監視サーバ上の Loki です。
inventoryやgroup_varsで定義した監視サーバのIP宛に、HTTPでログを送る形にしています。
実装としては promtail の configファイル（promtail-config.yml.j2）に以下のように、接続先を記述しているだけです。
※loki_hostはgroup_vars/all.yml で監視サーバのIP:192.168.1.31を指定

clients:
  - url: http://{{ loki_host }}:3100/loki/api/v1/push

3.3.4 収集するログについて

今回の構成では、promtail で /var/log/messages に出力される OS 標準ログのみを収集しています。
systemd, journald のログや、アプリケーションログの収集は行っていません。まずは、OS レベルのログが Loki に送信され、Grafana から確認できる状態を作ることを目的としてます。

4. Playbook の実行と動作確認

Prometheus / Grafana 自体は前回の記事で構築済みのため、ここでは 今回追加・変更した設定内容と、その反映ポイントにフォーカスします。

4.1 tasks/main.yml の変更点

まずは各ロールのtasks/main.yml (メイン処理)の変更点を見ていきます。

4.1.1 monitoring-stack main.yml 変更点

以下は、今回の main.yml の中から、追加・変更された部分を抜粋したものです。
※前回から変わっていない処理は省略

# ➀Loki用ディレクトリ作成
- name: Create Loki directories
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: root
    group: root
    mode: "0755"
  loop:
    - /opt/monitoring/loki
    - /opt/monitoring/loki/data
    - /opt/monitoring/loki/config

# ➁Loki設定ファイル配置
- name: Deploy Loki config
  ansible.builtin.template:
    src: loki-config.yml.j2
    dest: /opt/monitoring/loki/config/loki-config.yml

# ➂Alertmanager設定ファイル配置
- name: Deploy Alertmanager config
  ansible.builtin.copy:
    src: alertmanager.yml
    dest: /opt/monitoring/alertmanager/alertmanager.yml

# ➃Prometheusアラートルール配置
- name: Deploy Prometheus alert rules
  ansible.builtin.copy:
    src: node-alerts.yml
    dest: /opt/monitoring/prometheus/config/rules/node-alerts.yml

# ➄docker-compose.yml 更新
- name: Deploy docker-compose file
  ansible.builtin.template:
    src: docker-compose.yml.j2
    dest: /opt/monitoring/docker-compose.yml

① Loki 用ディレクトリの作成
data は受信したログやインデックスなどの実データを保存するためのディレクトリで、config は Loki の動作設定を管理するためのディレクトリです。ディレクトリやファイルの生成は引き続き ansible.builtin.file を使います。

② Loki の設定ファイル配置
loki-config.yml.j2 から実体の設定ファイルを生成します。ログの保存先や、最小構成での動作設定はここで定義しています。.j2 のテンプレートファイルを呼び出すため、ansible.builtin.templateを使います。

③ Alertmanager の設定ファイル配置
Alertmanager の設定は、通知先の定義だけでなく、アラートの発生・復旧を含めた条件分岐そのものを設定ファイル内に記述しています。

alertmanager.ymlは、以下のような内容です。

global:
  resolve_timeout: 5m

route:
  receiver: slack-notifications
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 1h

receivers:
- name: slack-notifications
  slack_configs:
  - api_url: https://hooks.slack.com/services/hogehoge/hogehoge/hogehoge
    channel: "#all-alert-test"
    send_resolved: true
    title: "{{ .CommonAnnotations.summary }}"
    text: >-
      {{ if eq .Status "firing" }}
      :red_circle: *障害発生*
      {{ else }}
      :green_circle: *復旧*
      {{ end }}

      {{ range .Alerts }}
      ・{{ .Labels.instance }} : {{ .Annotations.description }}
      （Severity: {{ .Labels.severity }}）
      {{ end }}

アラート通知文を書いているため、設定ファイル内で {{ if }} や {{ else }} といった二重波括弧を使った条件分岐が多く使われます。
これを Ansible の Jinja2 テンプレートとして扱うと、変数展開と衝突してエラーになりやすいため、今回はテンプレート化は行わず、静的ファイルとして配置しています。roles/monitoring-stack/files/alertmanager.yml に設定ファイルを置き、ansible.builtin.copy でシンプルにコピーする動きをしています。

④ Prometheus のアラートルール配置
Prometheus が評価するアラートルールを配置します。

node-alerts.yml は、以下のような内容です。

groups:
- name: node-alerts
  rules:

  - alert: NodeDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Node Down"
      description: "{{ $labels.instance }} が応答していません"

  - alert: HighCpuUsage
    expr: |
      100 - (avg by (instance) (
        rate(node_cpu_seconds_total{mode="idle"}[5m])
      ) * 100) > 90
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "High CPU usage"
      description: "{{ $labels.instance }} の CPU 使用率が 90% を超えています"

③で説明した Alertmanager の設定ファイルと同様に、ここでも二重波括弧を使った記述が含まれます。
そのため、このファイルも Jinja2 テンプレートにはせず、静的ファイルとして roles/monitoring-stack/files/node-alerts.yml に配置し、ansible.builtin.copy で Prometheus のルールディレクトリにコピーしています。

⑤ docker-compose.yml の更新
既存の Compose 定義に、Loki と Alertmanager のサービスを追加しました。

4.1.2 target-agent main.yml 変更点

前回の記事では node_exporter のセットアップのみでしたが、今回は promtail を追加するための処理をrole/target-agent/tasks/main.yml に追加しています。
以下は、今回の main.yml から promtail 追加に関係する部分のみを抜粋したものです。
※node_exporter に関する既存処理は省略

# ➀ promtail作業ディレクトリ作成
- name: Create promtail directories
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: root
    group: root
    mode: '0755'
  loop:
    - /opt/monitoring/promtail
    - /opt/monitoring/promtail/config

# ➁ promtailバイナリをダウンロード
- name: Download promtail binary
  ansible.builtin.get_url:
    url: "https://github.com/grafana/loki/releases/download/v{{ promtail_version }}/promtail-linux-amd64.zip"
    dest: /opt/monitoring/promtail/promtail.zip

# ➂ promtailを展開
- name: Unzip promtail
  ansible.builtin.unarchive:
    src: /opt/monitoring/promtail/promtail.zip
    dest: /opt/monitoring/promtail
    remote_src: true

# ➃ promtailバイナリ配置
- name: Install promtail binary
  ansible.builtin.copy:
    src: /opt/monitoring/promtail/promtail-linux-amd64
    dest: /usr/local/bin/promtail
    owner: root
    group: root
    mode: '0755'
    remote_src: true

# ➄ promtail設定ファイル配置
- name: Copy promtail config
  ansible.builtin.template:
    src: promtail-config.yml.j2
    dest: /opt/monitoring/promtail/config/promtail.yml
    owner: root
    group: root
    mode: '0644'

# ➅ promtail systemd unit作成
- name: Create promtail systemd unit
  ansible.builtin.copy:
    dest: /etc/systemd/system/promtail.service
    content: |
      [Unit]
      Description=Promtail
      After=network.target

      [Service]
      ExecStart=/usr/local/bin/promtail \
        -config.file=/opt/monitoring/promtail/config/promtail.yml
      Restart=always

      [Install]
      WantedBy=multi-user.target

# ➆ systemd reload & Start
- name: Reload systemd
  ansible.builtin.systemd:
    daemon_reload: true

- name: Enable and start promtail
  ansible.builtin.systemd:
    name: promtail
    state: started
    enabled: true

① promtail 用ディレクトリの作成
promtail の設定ファイル配置先として /opt/promtail を作成しています。

② promtail バイナリのダウンロード
Grafana Loki の公式リリースから promtail を取得します。node_exporter と同様に、GitHub Releases をそのまま使っています。

③ promtail の展開
ダウンロードした zip を展開します。特に変わったことはしておらず、単純に unarchive しています。

④ promtail バイナリ配置
展開した実行バイナリを /usr/local/bin/promtail に配置します。systemd から直接呼び出すため、/bin に置いています。

➄ promtail 設定ファイルの配置
ログ収集の設定は j2 テンプレートから生成しています。ここで、収集対象ログと Loki への送信先を定義してます。

promtail-config.yml.j2 は、以下のような内容です。

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://{{ loki_host }}:3100/loki/api/v1/push

scrape_configs:
  - job_name: varlogs
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/messages

⑥ promtail の systemd unit 作成
systemd のため、最低限のsystemd unit ファイルを作成してます。
content | を使うことで設定ファイルを用意せずに、echo > のような感覚で定義できます。

⑦ systemd reload と起動
unit ファイル配置後に systemd を reload し、
promtail を有効化・起動しています。

補足：copy / template / content の使い分けについて

Ansible でファイルを配置する方法はいくつかありますが、実際に触ってみるとどのモジュールを使うかで迷うことが多々あります。
それぞれ使い分けは以下の通りです。

ansible.builtin.copy
- 静的な設定ファイルそのまま配置する場合
ansible.builtin.template
- 変数を展開して設定ファイルを配置する場合
content |
- 短くて、使いまわさない定義を、簡単に書きたい場合

今のところは、この基準で選んでおけば大きく迷うことはなさそうです。

4.2 Playbook の実行

今回実行するのは、以下の 2 つの Playbook です。

監視サーバ側：monitoring-stack
監視対象サーバ側：target-agent

4.2.1 monitoring-stack playbook の実行

ansible-playbook -i inventory/hosts.ini playbooks/monitoring-stack.yml

実行後↓

PLAY RECAP ***********************************************************
lab-mon-01                 : ok=18   changed=8    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

failed=0 となっており、エラーなく Playbook の実行が完了しました。
ok の数が多いのは、前回の記事ですでに構築済みの Prometheus / Grafana に関するタスクが再実行されなかったためです。

docker psで loki と alertmanager が up状態で問題なくコンテナが動いています。

[user@lab-mon-01 monitoring]$ docker ps
CONTAINER ID   IMAGE                      COMMAND                  CREATED         STATUS         PORTS                                         NAMES
f634a8ed34f6   grafana/loki:latest        "/usr/bin/loki -conf "   2 minutes ago   Up 2 minutes   0.0.0.0:3100->3100/tcp, [::]:3100->3100/tcp   loki
6b7e5bb53547   prom/alertmanager:latest   "/bin/alertmanager - "   2 minutes ago   Up 2 minutes   0.0.0.0:9093->9093/tcp, [::]:9093->9093/tcp   alertmanager
5c55fbc5cbbe   prom/prometheus:latest     "/bin/prometheus --c…   3 days ago      Up 3 days      0.0.0.0:9090->9090/tcp, [::]:9090->9090/tcp   prometheus
67932dcc9840   grafana/grafana:latest     "/run.sh"                3 days ago      Up 10 hours    0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp   grafana

4.2.2 target-agent Playbook の実行

続いて、監視対象サーバ側の Playbook を実行します。

ansible-playbook -i inventory/hosts.ini playbooks/target-agent.yml

実行後↓

PLAY RECAP ***********************************************************
lab-trg-01                 : ok=16   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
lab-trg-02                 : ok=16   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
lab-trg-03                 : ok=16   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

failed=0 となっており、エラーなく Playbook の実行が完了してます。okの数が多いのは先ほどと同様で、node_exporter関連のタスクが再実行されなかったためです。

実行後、各監視対象サーバで promtail が起動していることを確認します。

[user@lab-trg-01 ~]$ systemctl status promtail
  promtail.service - Promtail
     Active: active (running)
     
[user@lab-trg-02 ~]$ systemctl status promtail
  promtail.service - Promtail
     Active: active (running)
     
[user@lab-trg-03 ~]$ systemctl status promtail
  promtail.service - Promtail
     Active: active (running)

4.3 playbook 実行後の動作確認

実際に監視サーバへアクセスしてwebUIなど確認していきます。

4.3.1 Prometheus 側の確認

まずは Prometheus 側が正常に動作しているか、以下2点を確認します。

Targets 画面で、各監視対象サーバが UP 状態になっている
アラートルール（node-alerts.yml）が読み込まれている

前回構築した構成を壊すことなく、Alertmanager 追加後も Prometheus が正常に動作していることが分かります。
/etc/prometheus/rules/node-alerts.yml に記述した以下のアラートルールも正常に読み込まれてます。
ホストダウン監視
CPU使用率監視
メモリ使用率監視
ディスク使用率監視

prometheus の Alerts 画面では、読み込まれているアラートルールを確認できます。各ルールを展開すると、設定した内容がそのまま表示されます。

アラート判定に使われている PromQL（expr)
annotations で定義した summary / description
条件を満たし続ける時間として指定した値
severity などのラベル情報

4.3.2 Alertmanager（Slack 通知）の確認

Alertmanager から Slack へアラート通知が正しく送信されるかを確認します。

まず、Prometheus 側で定義したアラートルールに引っかかるようにアラートを発火させます。
今回は、検証用 Playbook を実行し、監視対象サーバの CPU / メモリ / ディスク を上げることでアラートを発火させます。

trg-01：CPU 使用率
trg-02：メモリ使用率
trg-03：ディスク使用率

Grafana を確認すると、CPU・メモリ・ディスクの各メトリクスが急上昇してます。

そして、5分の継続検知を経て、slack経由でアラート通知を受信しました。
trg-01 からは CPU、trg-02 からはメモリ、trg-03 からはディスク使用率のアラートが、それぞれ正しく通知されています。

改行が一部ずれてるところがありますが、各サーバからそれぞれのアラートが出ていることがわかります。

これにより、Prometheus → Alertmanager → Slack の通知経路が正常に動作していることを確認できました。
せっかくなので復旧時の通知も確認します。
Alertmanager の設定で send_resolved: true を指定しているため、復旧時にも通知が送信されるようにしています。

:green_circle: がそのまま文字列として表示されていますが、復旧通知自体は問題なく送信されており、動作としては問題なさそうです。

4.3.3 Loki / Promtail の確認

最後に、ログ収集が正しく動作しているかを確認します。
今回の構成は各監視対象サーバ上で promtail を動かし、ローカルログを Loki に転送しています。

クエリを実行すると、各監視対象サーバのログが表示されます。今回は /var/log/messages を収集対象としているため、OS レベルのログが確認できます。

動作確認のため、監視対象サーバの /var/log/messages にログを書き込む検証用 Playbook を作成し、実行しました。
ログが Loki 経由で Grafana 上に反映されていることが分かります。

Loki 側（Grafana）でログを確認できているため、各監視対象サーバ上で promtail が正常に動作し、ログを転送できていることも確認できます。

以上で、Playbook 実行後の動作確認は完了です。

4.3.4 動作確認のまとめ

今回追加した各コンポーネントについて、以下の点を一通り確認できました。

Prometheus
- 監視対象サーバがすべて UP 状態であること
- 追加したアラートルールが正しく読み込まれていること
Alertmanager
- Prometheus からアラートを受信できていること
- Slack へ通知が送信されること
- アラート復旧時にも通知が送信されること
Loki / Promtail
- 監視対象サーバのログが Loki に送信されていること
- Grafana からログを参照できること

メトリクス監視・ログ収集・アラート通知の一連の流れが、問題なく動作していることを確認できました。

5. まとめ

前回の記事では Prometheus / Grafana を中心とした監視基盤を作り、
今回は Alertmanager / Loki / Promtail を追加しました。メトリクス監視だけでなく、ログ収集とアラート通知まで含めた構成を、Ansible ですべて自動化構築できるようになりました。

改めて感じたのは、やはり playbook を自分で書いていくことの大切さです。AI にコードを書かせることはできますが、ディレクトリ構成や Role の分け方まで理解せずに進めると、あとかの保守や設定変更がかなりつらくなります。今回のように手を動かしながら組むことで、構成全体を自分の言葉で説明できるようになるのは大きな収穫でした。

また、Ansible を通して Prometheus、Grafana、Loki といったモダンな監視ツールに一通り触れられたのも大きな副産物でした。

ひとまず今回はここまでですが、Ansible で監視・ログ・通知を一通り触れたのはかなり良い経験でした。
また気が向いたら、この構成をベースにいろいろ試してみようと思います。

最後までお読みいただきありがとうございました。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up