Zabbixの障害通知が届かない？Slack・Microsoft Teams連携で絶対に見逃さないアラート設定
夜中に鳴り響くPagerDuty、あるいは朝出社してSlackを開いた瞬間に目に飛び込んでくる「障害通知の洪水」。
そして最悪なパターン――「障害が発生していたのに、誰も気づかずにエンドユーザーからの連絡で発覚した」。
オブザーバビリティの文脈において、監視ツールが発報したアラートが人間の目（あるいは認知リソース）に届くまでには、いくつもの「死角」が存在します。特にZabbixのデフォルト設定のまま運用しているチームでは、重要なアラートがノイズの中に埋もれたり、そもそも宛先ミスで闇に消えたりすることが後を絶ちません。
この記事では、Zabbixの通知メカニズムの急所を突く形での「WebhookによるSlack/Microsoft Teams連携」の極意を伝授します。単なるチュートリアルではありません。「ノイズゼロ、見落としゼロ、そして数秒で原因の文脈を把握できる」、プロの現場で即座に採用すべき実践的な設定とベストプラクティスを解説します。
—
1. Zabbix通知の構造的欠陥と「WebHook」の正解
Zabbixから外部チャットツールに通知を送るアプローチは、歴史的にいくつかの変遷をたどってきました。
古くはシェルスクリプトやPythonスクリプトを`/usr/lib/zabbix/alertscripts/`配下に配置し、`curl`で叩く方式が主流でした。しかし、この方式はコンテナ化されたZabbix環境や、スケールアウトを前提としたモダンなインフラにおいては技術的負債でしかありません。
現代の正解：JavaScriptベースの `Webhook` メディアタイプ
Zabbix 4.4以降（特に5.0/6.0/7.0 LTSの現行世代）で標準搭載されたWebhookメディアタイプを使用するべきです。
外部スクリプトの依存関係（Pythonのバージョン、証明書エラー、OSのタイムゾーン差異など）から完全に解放され、Zabbixサーバーのプロセス内で完結するため、パフォーマンスと信頼性が圧倒的に高まります。
—
2. 【Slack/Teams】絶対に見逃さないためのメッセージ設計思想
通知を飛ばすだけで満足していませんか？
「Zabbix: サーバー負荷が高いです」というアラートは、エンジニアにとって「ただの騒音」です。現場が求めているのは、Slack/Teamsの通知を見た瞬間、3秒で次のアクション（SSHすべきか、ダッシュボードを見るべきか、寝ていていいのか）が判断できる文脈（Context）です。
理想的なメッセージのフォーマット要件
1. 視覚的緊急度（色とアイコン）: 深刻度（Disaster / High / Average）が一目でわかること。
2. ホスト名とIPアドレス: どのリソースで起きたのか（あいまいさを排除）。
3. 発生時刻と継続時間: 一過性のバーストなのか、継続的な障害なのか。
4. 直リンク: Zabbixの該当トリガー、およびGrafanaやKibanaへのダイレクトリンク。
—
3. 実装：Zabbix Webhook設定のベストプラクティス
ここでは、メンテナンス性を極限まで高めた Zabbix 6.0/7.0 LTS対応のWebhook設定（JSONエクスポートの概念をコード化） を公開します。
3-1. メディアタイプの設定（JavaScriptコードの神髄）
Zabbixの管理画面から `[管理]` > `[メディアタイプ]` > `[作成]` を選択します。
タイプに `Webhook` を指定し、以下のJavaScriptコードを「スクリプト」欄に貼り付けます。
try {
var params = JSON.parse(value),
req = new CurlHttpRequest(),
resp,
data = {},
url;
// プロキシ設定がある場合はここで指定
// req.SetProxy(‘http://proxy.example.com:8080’);
// SlackかTeamsかの判定（パラメータで切り替え可能）
url = params.alert_url;
// メッセージの深刻度に応じたカラーコードと絵文字のマッピング
var severityColor = {
‘Not classified’: ‘#95a5a6’, // 灰色
‘Information’: ‘#3498db’, // 青
‘Warning’: ‘#f1c40f’, // 黄
‘Average’: ‘#e67e22’, // オレンジ
‘High’: ‘#e74c3c’, // 赤
‘Disaster’: ‘#8e44ad’ // 紫（最悪の事態）
};
var severityEmoji = {
‘Not classified’: ‘⚪’,
‘Information’: ‘ℹ️’,
‘Warning’: ‘⚠️’,
‘Average’: ‘🔶’,
‘High’: ‘🔥’,
‘Disaster’: ‘🚨’
};
var color = severityColor[params.event_severity] || ‘#000000’;
var emoji = severityEmoji[params.event_severity] || ‘❓’;
// Slack Block Kit / Teams Adaptive Card の構築（ここでは汎用的なSlack Webhook JSON）
data = {
“channel”: params.alert_channel,
“username”: “Zabbix Observer”,
“icon_emoji”: “:zabbix:”,
“attachments”: [
{
“fallback”: params.alert_message,
“color”: color,
“blocks”: [
{
“type”: “section”,
“text”: {
“type”: “mrkdwn”,
“text”: emoji + ” [” + params.event_severity.toUpperCase() + “] ” + params.trigger_name + “”
}
},
{
“type”: “section”,
“fields”: [
{
“type”: “mrkdwn”,
“text”: “対象ホスト:\n” + params.host_name + ” (`” + params.host_ip + “`)”
},
{
“type”: “mrkdwn”,
“text”: “発生時刻:\n” + params.event_time
}
]
},
{
“type”: “actions”,
“elements”: [
{
“type”: “button”,
“text”: {
“type”: “plain_text”,
“text”: “Zabbixで確認”
},
“url”: params.zabbix_url + “tr_events.php?triggerid=” + params.trigger_id + “&eventid=” + params.event_id
}
]
}
]
}
]
};
req.AddHeader(‘Content-Type: application/json’);
// リクエスト実行
resp = req.Post(url, JSON.stringify(data));
if (req.GetStatus() < 200 || req.GetStatus() >= 300) {
throw ‘HTTP 接続エラー, ステータスコード: ‘ + req.GetStatus() + ‘, レスポンス: ‘ + resp;
}
return ‘OK’;
} catch (error) {
Zabbix.Log(4, ‘Slack notification failed: ‘ + error);
raise(‘Slack notification failed: ‘ + error);
}
3-2. メディアタイプの「入力パラメータ」定義
上記のスクリプトが参照する変数を、メディアタイプの「パラメータ」タブで以下のように定義します。ここをサボるとスクリプトがクラッシュするため注意してください。
| 名前 | 値（Zabbixマクロ） |
| :— | :— |
| `alert_url` | `https://hooks.slack.com/services/YOUR/WEBHOOK/URL` （または TeamsのWebhook URL） |
| `alert_channel` | `#infra-alerts` （Slackの場合。Teamsは不要） |
| `alert_message` | `{EVENT.NAME}` |
| `event_severity` | `{EVENT.SEVERITY}` |
| `trigger_name` | `{TRIGGER.NAME}` |
| `host_name` | `{HOST.NAME}` |
| `host_ip` | `{HOST.CONN}` |
| `event_time` | `{EVENT.DATE} {EVENT.TIME}` |
| `trigger_id` | `{TRIGGER.ID}` |
| `event_id` | `{EVENT.ID}` |
| `zabbix_url` | `https://zabbix.example.com/zabbix/` （自環境のURL） |
—
4. 深刻度に応じた通知の振り分け（ノイズ排除の極意）
「すべての警告を同じチャンネルに流す」という設計は、オンコールエンジニアをメンタル崩壊させるための特効薬です。
プロの現場では、深刻度と時間帯（デプロイ時間帯か夜間か）によって通知経路を厳密にルーティングします。
Zabbixアクションのコンディション設定
1. Critical/Disaster チャンネル (`#alert-critical`):
- 深刻度 `>= High` のみ。
- 24時間365日、即座に担当者のスマートフォンにプッシュ通知（メンション付き）を飛ばす。
2. Warning/Average チャンネル (`#alert-warning`):
- 深刻度 `Average` または `Warning`。
- 日中は通知するが、夜間（22:00〜08:00）はスレッド化するか、アラートの頻度が一定数を超えた場合のみまとめる（Zabbixのイベントタグと相関機能を利用）。
—
5. プロの現場で役立つ実践テクニック
5-1. 障害の「回復 (Recovery)」通知をノイズにしない設計
障害検知の通知と同じくらい重要なのが回復通知ですが、「復旧しました」というメッセージの嵐で本当に重要なログが流される現象が多発します。
- 対策: 回復時のメッセージには `✅ [RESOLVED]` という緑色のカラーコードを適用し、トピックのサマリーに留め、詳細なスタックトレースなどは省略します。また、短時間でフラッピング（直ぐに復旧して再発すること）を繰り返すトリガーは、Zabbixの「ヒステリシス」機能や、アクションの「実行間隔」を調整してミュートします。
5-2. 開発スピードを落とさない！設定のコード管理（Export）
Zabbixの設定をGUIだけで完結させているチームは、障害時に「誰がどこをいじったかわからない」という地獄を見ます。
完成したメディアタイプやアクションは、必ず XML/JSON形式でエクスポートし、Gitなどのバージョン管理システムでコードレビューを経て適用 しましょう。
Zabbix APIやzabbix-cli等を用いたCI/CDパイプラインへの組み込みを意識し、
監視設定の変更もプルリクエスト経由で行う文化を醸成する。
—
まとめ：今夜から「見逃さない」インフラへ
Zabbixの通知設定を最適化することは、単に「Slackに文字を流す」ことではありません。
「システムが発するシグナルを、いかにノイズレスに、かつ文脈を持たせて人間の認知限界のギリギリ手前に届けるか」という、オブザーバビリティの核心そのものです。
今日紹介したWebhookスクリプトとメッセージ設計を取り入れれば、「あれ、このアラートどういう意味だっけ？」というチャットでの無駄なやり取りは消え去り、真に素早いインシデントレスポンスが実現できます。
あなたのチームの監視体制を、今すぐアップデートしてください。