はじめに
今回は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に保存していきます。