はじめに

本記事は
「AWS EC2 × Zabbix監視基盤構築シリーズ」
の第3回です。

今回はZabbixに設定を行い、
その後、意図的に障害を起こして、
障害を解消することを行います。

Zabbix Agentの設定

まずZabbixのエージェントが動いているか確認します。

systemctl status zabbix-agent --no-pager

activeを確認しました。

設定ファイルの変更

以下のコマンドで設定ファイルを変更します。

sudo vi /etc/zabbix/zabbix_agentd.conf

以下の項目を変更しました。
※Server,ServerActiveはデフォルトで、Hostnameのみ変更しました。

Server=127.0.0.1
ServerActive=127.0.0.1
Hostname=ec2-zabbix

設定ファイルに反映します。

sudo systemctl restart zabbix-agent

ポート10050が待受しているか確認

sudo ss -lntp | grep 10050

待受できていることが確認できました。

Zabbix UIでホスト登録

自身を監視する設定を行おうとしましたが、すでに監視されていました。

Zabbix Server インストール直後から「Zabbix server」ホストが存在しており、
テンプレートが適用された状態で監視が開始されていました。

[設定] → [ホスト]とクリックしていきます。

現在、Zabbix serverのみを監視している状態です。

テンプレートについて

監視項目はテンプレートを使用して設定を行うことが多いです。

Zabbixのテンプレートとは？

監視設定のひな型セット
このサーバでは何を、どうやって、どのくらいの頻度で、
どんな条件でアラート出すか
これらを全部まとめた設計書＋設定集がテンプレートです。

テンプレートを確認

以下の2つのテンプレートが使用されています。

Linux by Zabbix agent
Zabbix server health

つまりLinux by Zabbix agent と Zabbix server health
2つのテンプレートを使用して監視しています。

主要なデータ

いくつかの主要なデータを見てみる。
[監視データ] → [最新データ]

CPU utilization

CPUの使用率（％）を示す指標。
サーバがどの程度CPUリソースを消費しているかを把握できる。
高い状態が継続する場合、アプリケーションの負荷増大や
処理遅延の原因となるため、継続監視が重要となる。

　

Available memory

OSが即座に利用可能なメモリ量を示す指標。
Linuxではキャッシュやバッファも考慮されるため、
単純な「空きメモリ」よりも実際の余裕を把握しやすい。
この値が極端に少なくなると、スワップ発生や性能低下のリスクが高まる。

　

Disk utilization

ファイルシステムごとのディスク使用率（％）を示す指標。
ディスク容量の逼迫はアプリケーション停止や
ログ書き込み失敗の原因となるため、注意が必要である。

　

Load average (1m avg)

直近1分間の平均負荷を表す指標。
CPUコア数に対して値が大きい場合、
プロセスの待ち行列が発生している状態を示す。
CPU使用率と併せて確認することで、
処理詰まりやリソース不足の判断材料となる。

これらのメトリクスを組み合わせて確認することで、
単一指標では判断しづらいサーバの負荷状況を多角的に把握できる。

トリガー設定

検証ではテンプレートを使用せず、トリガーを設定していく。

今回作るもの

対象：/ の Disk utilization
条件：80%を超えたら障害アラート

ディスク容量の枯渇はログ書き込み失敗や
サービス停止に直結するため、
優先的に監視対象とした。

トリガー作成画面を開く

[設定] → [ホスト]をクリック。
対象ホスト(Zabbix server)の中のトリガーをクリック
右上の [トリガーの作成]をクリック

名前: Disk utilization on / is over 80% (custom)
深刻度: 警告（Warning）

条件式の追加をクリック。
アイテムの選択をクリック。
その中から、nvme0n1: Disk utilization を選択。

EC2のルートディスクは NVMe デバイスとして認識されており、
自動検出された nvme0n1: Disk utilization を用いて
ディスク使用率のトリガーを設定する。

　
条件式の last(/Zabbix server/vfs.dev.util[nvme0n1])>80 は
Zabbix server ホストにおいて、
NVMe デバイス nvme0n1 のディスク使用率の最新値が
80% を超えた場合に障害とするもの。

追加をクリックして、トリガーを追加する。

トリガー発火テスト

目的

「80%超えたら検知」が本当に動くことを確認する。

やること

ダミーファイルを作ってディスクを圧迫
Zabbixで Warning が出るのを見る
ファイル削除
自動で復旧（OKになる）ことを見る

今のディスク使用率を確認

df -h /

現在の使用率は42％。

テスト用ディレクトリを作る

あとでまとめて削除できるようにディレクトリを作成

sudo mkdir /zabbix-test
sudo chmod 777 /zabbix-test

ディスクを一時的に圧迫する

fallocate -l 3G /zabbix-test/dummy.img
# 3GB のダミーファイルを作る

ディスク使用率を確認

df -h /

現在の使用率は82％。
80％を超えました。

Zabbix UIで障害の検知が出ました。

復旧作業

ダミーファイルを削除

sudo rm -f /zabbix-test/dummy*.img

ディスク使用率を確認

df -h /

42％になっています。

80％を下回ったため、Zabbix UIでは障害の検知が消えました。

復旧を確認済みにする

[監視データ] → [障害] → [問題の履歴]
先ほど発生した障害を選択します。

　
障害確認のチェックボックスにチェックを入れ、更新をクリック。

　
先ほどの障害が消えました。

CPUトリガー作成

続いて、CPUトリガーの作成を行っていきます。

CPU使用率は一時的なスパイクが発生しやすいため、平均値（avg）を用いた検知とします。

先ほどと同様の手順でトリガー作成の画面まで進みます。

名前: CPU utilization is over 80% (custom)
深刻度: 警告（Warning）

条件式の追加をクリック。
アイテムの選択をクリック。
その中から、

Zabbix server: Linux: CPU utilization を選択。
関数: avg()
最新の（T）: 5m
結果: > 80
これらも入力する。

CPU使用率トリガーの説明

CPUリソースの逼迫を早期に検知するため、
CPU使用率が高い状態が一定時間継続した場合に
警告を出すトリガーを設定した。

本トリガーでは、
CPU utilization の 直近5分間の平均値 が
80% を超えた場合 に Warning として検知する。

一時的なスパイクによる誤検知を防ぐため、
最新値（last）ではなく平均値（avg）を用いており、
「CPU高負荷が継続している状態」を検知することを目的としている。

CPUトリガー発火テスト

先ほど設定したトリガーが有効になっていることを確認します。

CPU負荷ツールを準備

sudo apt update
sudo apt install -y stress

CPUに負荷をかける

stress --cpu 2

Zabbixで発火を確認

数分待つと、アラートが出ました。
CPUトリガーでは 5 分間平均（avg 5m）を使用しているため、
負荷発生直後にはアラートは表示されず、
一定時間高負荷が継続した後に Warning が発生したためです。

アラートが出たことから、一時的なスパイクではなく
継続的な高負荷状態を検知できる設定であることを確認できます。

stressを止めて、様子を見ます。

同時にtopコマンドを使用して、CPU使用率を確認しました。
使用率は0になっていたので、時間がたてばアラートは落ち着くはずです。

アラートが消えました。

復旧を確認済みにする

[監視データ] → [障害] → [問題の履歴]
先ほど発生した障害の確認をします。

障害の確認が終わり、項目がなくなりました。

メール通知設定

Warning 発生時にメールが届く
復旧時にも通知される
「監視 → 通知 → 対応」の流れを作っていきたいと思います。

メディアタイプ（メール送信方法）を確認

[管理] → [メディアタイプ]をクリック
Email が有効になっているか確認

ユーザーにメールアドレスを設定

[管理] → [ユーザー]をクリック
Adminをクリック
[メディア] タブ
[追加]

タイプ：Email
送信先：メールアドレス
有効：☑
深刻度：すべて ☑
期間：1-7,00:00-24:00
→ [追加] → [更新]

アクション（通知ルール）を作成

[設定] → [アクション] → [トリガーアクション]
[アクションの作成]

名前: Send email on Warning

[条件] → [追加]
条件: 条件タイプ：トリガーの深刻度
演算子：等しい
値：警告（Warning）

[追加]をクリック。

[実行内容] タブ → [追加]
操作タイプ：メッセージを送信
送信先ユーザー：Admin（自分）
メディアタイプ：Email

件名: [Zabbix] {TRIGGER.STATUS}: {TRIGGER.NAME}

メッセージ本文:
Host: {HOST.NAME}
Trigger: {TRIGGER.NAME}
Severity: {TRIGGER.SEVERITY}
Time: {EVENT.DATE} {EVENT.TIME}

アクションと実行内容が記入できたら、追加をクリック。

メールの受信確認について

本環境では SMTP(25/tcp) での直接送信がタイムアウトしたため、
送信制約を回避できる SES を通知基盤として採用する方針とした。
SESの記事に関しては別の機会に行う。

今回の検証で学んだこと

Zabbixではテンプレートを利用することで、
主要な監視項目を迅速に設定できる一方、
要件に応じてカスタムトリガーを追加することが重要である。
　
トリガーは設定するだけでなく、
実際に発火テストと復旧確認を行うことで、
初めて運用可能な設定となる。
　
AWS環境ではメール送信に制約があるため、
監視通知は SES などの外部サービスと
連携する前提で設計する必要がある。

まとめ

Zabbixでディスク使用率のトリガーを設定し、意図的にディスクを圧迫して、またCPUに負荷をかけて、障害検知 → 復旧までの一連の動作を確認しました。

次回はZabbixで発生したログをS3に保存していきます。