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