arthur-1 Mackerel Advent Calendar 2023 マラソン6日目の記事です。
MackerelチームではMackerelを使ってMackerelを監視しています。今日は、MackerelチームのちょっとしたMackerel運用テクニックをご紹介します。
数が多くなってきた監視ルールを整頓したい
監視が育っていくにつれ、監視ルールは純増していくことが多いでしょう。監視の数が増えてアラート通知が増えていくと、人々は通知を無視するようになってしまいます。不要な監視ルールの棚卸しをすることで、年末気持ちよく休暇を過ごすことができるでしょう。
個人的にMackerelのリソースの中で、よく触れる機会が多いにも関わらず検索性があまり高くないものがまさに監視ルールだと思っています。アラートやホストと異なり、監視ルール一覧では現在文字列検索しかできません。
1会社1organizationという運用形態を取る場合、自分が携わるサービス以外の監視ルールも共存することになります。自分のチームに関わる監視ルールの一覧を出せないと、棚卸しに苦労することになるでしょう。
また、特定の監視ルールは通知先を変える、といった設定をする時に、監視ルールの名前のリストを見て複数選択しなければなりません。
監視ルールはそれぞれ緊急度が違う
システムの可用性に100%関係し、かつ人間の対応が必要な監視ルールだけを設定するなら、発生したアラートは全て対応すべきもの、となりますが、実際にはそうではない監視ルールも設定することになるでしょう。キャパシティプランニングの参考にしたい、異常が起こっても自動で修復されるので対応が不要、緊急ではないもののいつかはやっておきたい、閾値を適当に決めたばかりでまずは様子を見たいなど、色々な理由があると思います。
すなわち、それぞれの監視ルールには、監視ステータスであるCritical、Warningだけでは表しきれない優先度（緊急度）の差があると考えます。
監視ルールごと通知チャンネルを変える（例えば、緊急で対応しなければならない監視のSlack通知ではメンションがつく）ことで表現することも可能ですが、やはり前述したように監視ルールの名前だけを見て通知チャンネルの設定をする難しさがつきまといます。
そこで、命名規則を導入する
監視ルールをグルーピングし、またその知識をチームで共有するために、Mackerelチームでは監視ルールに命名規則を設けています。
まず、先頭に優先度を表す文字列（Alert, Infoなど）を付与することで、対応が必要か・それが緊急かどうかがわかるようにしています。アラート通知に含まれる監視ルール名の先頭を一目見るだけで、アラート対応の優先度がわかる、というねらいです。
次に監視対象のサービス・ロールを表す文字列をつけ、サービスやロールごと監視ルールをグルーピングできるようにしています。最後に、監視を区別するための監視名をつけています。
これらのセクションの区切り文字もなんとなくではなく統一することで、プログラムが解析しやすい構造化文字列となり、Mackerel APIやMackerel Terraform Providerを用いた便利ツールを作る際に役立ちます。
社内でのSREingの標準化の一環
この監視ルールの命名規則は、はてな社内でチームを横断して社内技術を標準化することを目指したSRE標準化委員会で決定されたものになります。この取り組みの一環については、ちょうど最近興味深い座談会記事が公開されましたので、ぜひこちらもご覧ください。
これを機能にする、というアイデアもある
現在命名規則を導入しているのは、監視名で頑張るworkaroundがなければ不便ということであり、すなわちなんらかの便利機能をMackerel公式として用意すべきではないか、と考えています。
僕個人の考えでは、大手パブリッククラウドのように、タグという概念を導入して汎用的にグルーピング機能を用意するのが良いのではないかと思います。例えば、監視ルールを指定して通知チャンネルを設定するときに、監視ルールを1つずつ指定するのではなく、特定のタグが付いているものをまとめて選べるとどうでしょうか。サービスやロールがより一般化されたようなイメージです。
一方で、監視の優先度などきちんと名前をつけてモデリングすることにより、ユーザーがより直感的に扱えるデザインに仕上げることもできるでしょう。例えば、Infoレベルの監視ルール・アラートという概念があり、CriticalやWarningより目立たない色で通知が来れば、監視ルール名に頼らなくてもただ様子を見たいだけのアラートであるということが直感的にわかると思います。
よろしければユーザーのみなさまにも、監視の運用ルールについてぜひお話を聞かせてください。
