はじめに
Zabbix Advent Calendar 2015 の 7日目 です。
ike_daiさんの誘いに乗ってエントリーさせていただきました。
今回は機能紹介や検証レポではなく、運用設計についてです。
トリガーの深刻度の扱いに関する考え方で、シンプルながらも使いやすいと思っている使い方をご紹介したいと思います。
使えそうならば、ストック, いいね!, Tweet, はてぶ などなどしてもらえると嬉しく思います。アドバイス、他のご意見ありましたら是非ください。大歓迎です。
トリガーの深刻度について
Zabbixでは以下の6種（5段階+未分類）のトリガーが用意されており、それと対になる復旧トリガーがサポートされます。
英語表記の場合、最高レベルの障害では突然の大惨事な感じで用意されておりますが、日本語ではそれとなく段階的な感じでレベルアップしているように翻訳されています。
ちなみに HP Software系では、normal，warning，minor，major，critical といったような分類が採用されており、ひょっとしたらこちらの表現のほうが馴染みが深い方もいるかもしれません。
そういった方は深刻度のカスタマイズをしてみてください。
| SEVERITY | 深刻度 | COLOUR | DEFINITION |
|---|---|---|---|
| Disaster | 致命的な障害 | Bright red | Disaster. Financial losses, etc. |
| High | 重度の障害 | Red | Something important has happened. |
| Average | 軽度の障害 | Orange | Average problem. |
| Warning | 警告 | Yellow | Be warned. |
| Information | 情報 | Light green | For information purposes. |
| Not classified | 未分類 | Grey | Unknown severity. |
テンプレートを作成する際に、トリガーの深刻度は、自由に指定することができますし、Zabbixの標準テンプレートにもそれっぽい感じで用意されています。
それでいいかと自由に任せておくと、システム管理者によってバランスもまちまちになってしまいます。
システムが増えるたび微妙なバリエーションが増え、結果的に深刻度は『なんとなくヤバい』とか『まだセーフ』といった雰囲気を伝える指標になってしまうことがあります。これをどう防ぐかというお話です。
トリガーの深刻度は先に決めておく
先ほどの課題の答えは簡単で、『あらかじめ』トリガーの深刻度を決めておきましょうということにつきます。
なんとなくでトリガーの深刻度を決めて使い始めてしまったのであれば、カオスになる前に基準を設けましょう。
運用している監視定義について深刻度の基準を再定義し、アジャストしていくのは相当しんどいです。
トリガーの深刻度を何で決めるか
ここで、どうやってZabbixのトリガーの基準を決めたらいいのだという悩みにぶつかります。
ITSMSやらITILやらに沿って所属する組織のサービスにおけるインシデントの深刻度について基準をお持ちの方も多いかもしれませんが、その指標と監視項目のアラートの基準がぴったり一致することはないと思います。
善良なシステム管理者であれば異常はより早期の段階から検知して、大事になる前に済ませておきたいと思う方も多いことでしょう。
トリガーとアクションの組み合わせの例
そこでご提案したいのが、『関係者への共有範囲をベースに深刻度の基準を設ける』アプローチになります。
Average までは技術担当者の都合で使う、High, Disaster は関係者への情報提供を迅速に行うために使う
トリガーの深刻度を3段階に分け、以下のように深刻度別に宛先を増やすだけです。これだけで重度障害は関係部署や上長にアラートが同時に通知されるレベルであるという一つの基準ができます。
- Warning以上のアラートはすべて自分のPCメールアドレスにメールする
- High以上のアラートについて、関係部署や上長にもアラートを共有する。
- 通知条件からInformationを外す。
通知条件からInformationを外しているのは意図的なものです。評価中の監視定義であったり、予兆だけ記録しておきたい監視項目においては、自分が技術担当者であっても、メール通知がほしくないケースもあるためです。
| SEVERITY | 担当者E-Mail | 共有E-mail |
|---|---|---|
| Disaster | x | x |
| High | x | x |
| Average | x | - |
| Warning | x | - |
| Information | - | - |
| Not classified | - | - |
自組織の共通テンプレートでの深刻度について
所属する組織で共通のテンプレートを用意している場合もあると思います。細かいところのこだわりは技術担当が調整する事でよいと思いますが、共通テンプレートでは、深刻度を使い過ぎない事も重要になります。
共通テンプレートとしてはHighで関係者共有されるインシデント、Warningで技術担当者にしか通知されないインシデントとして作っておくと、テンプレートのカスタマイズ性は残しつつ、一定の基準を示すことになるのではないでしょうか。
| SEVERITY | 共通テンプレ | 担当者E-Mail | 共有E-mail |
|---|---|---|---|
| Disaster | - | x | x |
| High | x | x | x |
| Average | - | x | - |
| Warning | x | x | - |
| Information | - | - | - |
| Not classified | - | - | - |
ワークアラウンド担当部署がまた異なる場合について
手順が定まっており、別部署やMSPに対応依頼を自動的にメールしたい場合もあると思います。
第3の通知先が追加されることになるので、何らかの条件とスクリプトを通して、そういったイベントだけ限定して通知するべきかと思いますが、今回は触れません。
| SEVERITY | 担当者E-Mail | 共有E-mail | 協力先への依頼 |
|---|---|---|---|
| Disaster | x | x | - |
| High | x | x | △ |
| Average | x | - | - |
| Warning | x | - | △ |
| Information | - | - | - |
| Not classified | - | - | - |
以上です。シンプルな考えですが、運用設計を固める際の参考になればうれしく思います。