こんにちは！運用監視の世界へようこそ。先輩エンジニアの私と一緒に、システムの「悲鳴」を逃さず拾い上げる最高の通知基盤を作っていきましょう。
「障害が発生していたのに、Zabbixの通知メールが迷惑メールに入っていて気づくのが遅れた…」
「昔作ったメール送信スクリプトがいつの間にか動かなくなっていた…」
こうした失敗は、インフラエンジニアなら誰もが一度はヒヤッとした経験があるはずです。でも、安心してください。今のZabbixには、標準で非常に強力かつ信頼性の高い「Webhook機能」が備わっています。
この記事では、ZabbixからSlackやMicrosoft Teamsへ、「絶対に届き、ひと目で状況がわかり、次のアクションに移れるアラート」を送信するための設定手順を、基礎から実践まで丁寧に解説します。これをマスターすれば、あなたのチームの障害対応スピードは劇的に向上し、毎日の運用作業が驚くほど楽になりますよ！
—
1. なぜ「Webhook」なのか？ アーキテクチャを理解する
設定に入る前に、なぜ従来のスクリプト方式やメール通知ではなく、Webhookを使うべきなのかをサクッと理解しておきましょう。仕組みが分かると、トラブルシューティングも一気に得意になります。
[ 発生源: 障害発生 ]
│
▼
[ Zabbix Server ] ── (内部JavaScriptエンジン) ───┐
│ HTTP/HTTPS Post (JSON)
▼
[ Slack / Teams の Webhook受信API ]
│
▼
[ 担当者のチャネルへ通知 ]
従来のメール送信スクリプトでは、ZabbixサーバーのOS上にPythonやBashの環境を作り、外部ライブラリの依存関係を管理する必要がありました。OSアップデートでスクリプトが動かなくなる…なんてトラブルもよくあったのです。
しかし、現代のZabbix（v5.0以降〜最新版）は内部にJavaScript実行エンジン（Duktape/Embedded）を内蔵しています。Zabbix Server単体でSlackやTeamsのAPI（HTTPS Request）を直接叩けるため、OS環境を汚さず、高速かつ超高精度にアラートを飛ばすことができます。
—
2. 【準備編】Slack / Teams 側のWebhook URLを発行する
まずは、Zabbixからの通知を受け取る「口（URL）」をチャットツール側で作ります。
Slackの場合
1. [Slack App設定画面](https://api.slack.com/apps) にアクセスし、「Create New App」 ＞ 「From scratch」 を選択。
2. アプリ名（例: `Zabbix-Alerts`）と追加先ワークスペースを選択して作成。
3. 左メニューの 「Incoming Webhooks」 を開き、スイッチを 「On」 にします。
4. 一番下の 「Add New Webhook to Workspace」 をクリックし、通知を流したいチャネル（例: `#system-alerts`）を選択。
5. 発行された `https://hooks.slack.com/services/T…/B…/XXXX` というWebhook URLをコピーしておきます。
Microsoft Teamsの場合（最新 Workflow形式）
※Office 365 コネクタの廃止に伴い、現在はPower Automate/ワークフローを使用するのが標準です。
1. 通知を送りたいTeamsチャネルの「…」アイコンから 「ワークフロー（Workflows）」 を選択。
2. 「Webhook リクエストを受信したときにチャネルに送信する」 テンプレートを検索して選択。
3. 接続アカウント等を確認し、作成を完了させます。
4. 画面に表示される Webhook URL（`https://prod-XX.westus.logic.azure.com:443/…`） をコピーしておきます。
—
3. 【設定編】Zabbixのメディアタイプ（Media Type）を設定する
ここからZabbix側の操作に入ります。Zabbixには標準でSlackやTeams用のテンプレートが用意されていますが、構造を理解するために、本質的かつ確実な設定手順を見ていきましょう。
Zabbix管理画面の [警報 (Alerts)] ＞ [メディアタイプ (Media types)] へ移動します。
すでに一覧に「Slack」や「MS Teams」がある場合はそれを活用できますが、ここでは理解を深めるためにWebhookのパラメータ構成と内部スクリプトの核心部分を解説します。
メディアタイプの設定パラメーター
「メディアタイプの作成」をクリックし、以下のように設定します。
- 名前: `Slack Webhook Notification`
- タイプ: `Webhook`
- パラメータ:
| パラメータ名 | 値（Zabbixマクロ） | 役割 |
| :— | :— | :— |
| `URL` | `https://hooks.slack.com/services/YOUR/WEBHOOK/URL` | 先ほどコピーしたURL |
| `Subject` | `{EVENT.NAME}` | イベント名（障害内容） |
| `Message` | `{ALERT.MESSAGE}` | アクションで定義するメッセージ本体 |
| `Severity` | `{EVENT.SEVERITY}` | 障害の深刻度 (Disaster, High等) |
| `Host` | `{HOST.NAME}` | 対象ホスト名 |
スクリプト例（Zabbix内部で動くJavaScript）
ZabbixのWebhookメディアタイプ内にある「Script」フィールドには、以下のようなJavaScriptを記述します。標準テンプレートを使う場合は自動挿入されていますが、コメントを入れたコードで流れを把握しておきましょう。
try {
// 1. Zabbixのパラメータを取得
var params = JSON.parse(value),
req = new HttpRequest(),
response;
// ヘッダーをJSON形式に指定
req.addHeader(‘Content-Type: application/json’);
// 2. Slackへ送るJSONペイロードを構築
// 深刻度に応じたカラーコードの切り替え
var color = ‘#1976D2’; // デフォルト(青)
if (params.Severity === ‘High’) color = ‘#FFA000’; // 警告(オレンジ)
if (params.Severity === ‘Disaster’) color = ‘#D32F2F’; // 重大障害(赤)
var fields = {
“attachments”: [
{
“color”: color,
“title”: “🚨 [Zabbix Alert] ” + params.Subject,
“fields”: [
{ “title”: “Host”, “value”: params.Host, “short”: true },
{ “title”: “Severity”, “value”: params.Severity, “short”: true },
{ “title”: “Details”, “value”: params.Message, “short”: false }
],
“ts”: Math.floor(Date.now() / 1000)
}
]
};
// 3. HTTP POSTリクエストの送信
Zabbix.log(4, ‘[ Slack Webhook ] Sending payload: ‘ + JSON.stringify(fields));
response = req.post(params.URL, JSON.stringify(fields));
// 4. レスポンスの検証（Slackは成功時 “ok” を返す）
if (req.getStatus() !== 200) {
throw ‘Response code: ‘ + req.getStatus() + ‘ Response: ‘ + response;
}
return ‘OK’;
} catch (error) {
Zabbix.log(3, ‘[ Slack Webhook ] Notification failed: ‘ + error);
throw ‘Slack notification failed: ‘ + error;
}
これで「Zabbixからチャットへ整形されたメッセージを送る土台」が完成しました！
—
4. 【振り分け＆カスタマイズ】ノイズを減らし、重要な通知だけを飛ばす
運用監視で最も避けなければならないのは「アラートの狼少年化（アラートノイズに慣れて無視してしまうこと）」です。
深刻度（Severity）に応じて通知先をスマートに振り分ける設定を行いましょう。
手順①：ユーザーにメディアを紐付ける
1. [ユーザー (Users)] ＞ [ユーザー] から、通知を受け取るユーザー（例: `Admin`）を選択。
2. [メディア] タブを開き、「追加」をクリック。
3. タイプ: 作成した `Slack Webhook Notification` を選択。
4. 送信先: チャネル名などを記載（Webhookパラメータ側でURLを固定している場合は任意の文字列でOK）。
5. 有効な深刻度: ここがポイントです！日常的な情報通知なら「軽度(Information)」にチェックを入れ、緊急対応が必要なチャネルへ飛ばすユーザーは「重度(High)」「致命的(Disaster)」のみに絞り込みます。
手順②：アクション（Action）のメッセージを読みやすくカスタマイズする
[警報 (Alerts)] ＞ [アクション (Actions)] ＞ [トリガーアクション] で、通知時の文面をカスタマイズします。
夜中に起こされたエンジニアが、スマホ画面を一目見ただけで状況を把握できるフォーマットを設定しましょう。
障害発生時のメッセージテンプレート例:
【障害発生】{HOST.NAME} で異常を検知しました
—————————————-
■ ホスト名: {HOST.NAME} ({HOST.IP})
■ 障害内容: {EVENT.NAME}
■ 深刻度 : {EVENT.SEVERITY}
■ 発生日時: {EVENT.DATE} {EVENT.TIME}
■ 現在の値: {ITEM.LASTVALUE}
■ 状況確認・確認ボタン:
{TRIGGER.URL}
—————————————-
※速やかに一次切り分けを開始してください。
復旧（Recovery）時のメッセージテンプレート例:
【復旧完了】{HOST.NAME} の障害が解決しました
—————————————-
■ ホスト名: {HOST.NAME}
■ 復旧内容: {EVENT.NAME}
■ 障害継続時間: {EVENT.DURATION}
■ 復旧日時: {EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME}
—————————————-
※自動復旧を確認しました。静観してください。
—
5. 【動作確認】「高精度HelloWorld」で確実にテストする
設定が終わったら、本番環境を荒らさずに通知が絶対に届くかテストしましょう。
単に「メディアタイプのテストボタン」を押すだけでなく、実際にトリガーを発行させるエンドツーエンド（E2E）テストを行うのがプロのやり方です。
テストステップ
1. Zabbix UIでの単体テスト:
- [警報] ＞ [メディアタイプ] の一覧から、作成したメディアタイプの右側にある 「テスト (Test)」 をクリック。
- パラメータにテスト用の値を入れ、「テスト」ボタンを押す。
- 成功してSlack/Teamsにメッセージが届くか確認。
2. 本体連動のHelloWorldテスト（`zabbix_sender` を活用）:
監視対象のホストで仮のトラップアイテムとトリガーを作成し、コマンドラインから意図的にエラーを送り込みます。
# Zabbix Serverに対して、強制的にテスト用メトリクス（障害値）を送信する
zabbix_sender -z 127.0.0.1 -s “TestServer” -k “trap.test.metric” -o “1”
- 「1（異常値）」 を送った瞬間、数秒以内にSlack/Teamsへ赤い枠のアラートが飛んでくるはずです！
- 次に `-o “0”` （正常値）を送ると、緑色の「復旧通知」が飛ぶことを確認します。
画面に美しい通知がポンと飛んできた瞬間…きっと感動しますよ！
—
6. 先輩エンジニアが教える「現場で差がつく」プロの知見
最後に、実際の運用現場で何百もの監視設定を行ってきた私から、さらに信頼性を高めるための「秘密のノウハウ」を3つ伝授します。
① Webhookのタイムアウト値に注意！
Zabbix ServerのデフォルトのHTTPタイムアウト設定が短いと、Teamsなどの外部APIのレスポンスが遅れた際に「通知失敗」になります。
`zabbix_server.conf` 内のパラメータを以下のように調整しておくと安心です。
zabbix_server.conf
Webhookなどの外部通信のタイムアウトを伸ばす（デフォルト3秒→10秒〜15秒へ）
Timeout=15
(設定変更後は `systemctl restart zabbix-server` をお忘れなく！)
② フロッピング（アラートの乱打）を防ぐ
ネットワークの瞬断などで、「障害発生」と「復旧」が1秒間に何十回も交互に飛んでくると、チャットツールが埋め尽くされて通知上限（レートリミット）に引っかかります。
トリガー条件式に ` hysteresis `（ヒステリシス）を持たせるか、アクション設定の 「イベント重複無効化」 や 「ステップ柔軟性」 を活用して、通知に一定のインターバルを設けましょう。
③ 通知メッセージに「直リンク」を貼る
メッセージ内に `{ZABBIX.URL}` マクロを仕込んでおき、クリック一発でZabbixの当該障害グラフへジャンプできるようにしておきます。
障害対応中の「該当のホストを画面から探す5秒間」を削減することが、MTTR（平均修復時間）の短縮につながります。
—
まとめ
今回の手順を完璧にマスターすれば、もう「Zabbixのアラートが見逃される」ということはなくなります。
1. Webhookを使って、外部スクリプト不要の堅牢な連携を作る
2. 深刻度（Severity）で通知先チャネルやユーザーを適切にフィルタリングする
3. 発生時だけでなく復旧時のメッセージも美しくフォーマットする
4. `zabbix_sender` で確実にE2Eテストを実施する
運用監視は、一度しっかりとした仕組みを作り上げれば、システムだけでなくあなた自身やチームの睡眠時間と心の平和を守ってくれる強力な味方になります。
ぜひ今日から試してみてくださいね。もし途中で詰まったら、いつでもログ（`zabbix_server.log`）を確認しながら、一歩ずつ進めていきましょう。応援しています！