arthur-1 Mackerel Advent Calendar 2023 マラソン8日目の記事です。
監視ルールを設定するのは難しい
特に監視の始めたてにおいて、どのメトリックをどのような閾値で監視するのかを決めるのは難しいです。
Mackerelはmackerel-agentをコマンド一発でインストールすると、すぐにホストが登録されある程度のシステムメトリックが見えるようになります。ここまでの敷居の低さは素晴らしいと思っていますが、ここからさらに一歩踏み出し、サービス提供に影響が生じるメトリックだけに適切な監視ルールを設定する境地に到達するには、監視サービスとしてのおもてなしがまだ足りないと感じています。
The Four Golden Signals
SREを名乗る人たちは、GoogleのSRE本を読んだことがあるでしょう。
ここには、「The Four Golden Signals」として、SREの観点で見るべき4つの信号が挙げられています：
- Latency
- Traffic
- Errors
- Saturation
Saturationの割合監視
このうちSaturationに関しては、事前に上限が分かっていて分かりやすいことが多いでしょう。Mackerelでは一部のホストメトリックが特別扱いされており、CPU・Memory・Filesystemsなどのメトリックは、式による監視機能に頼らずとも、取り得る最大値との割合（使用率）で監視することができます。すなわち、サービスを構成するそれぞれのホストでスペックが異なっても同じ監視ルールが適用可能だということです。
では、ネットワークのSaturationに関してはどうでしょうか。ネットワークの上限は一般にホストの内部からは分からないので、前述したような監視は難しいでしょう。ボトルネックがリンク速度であると分かっている場合には何とかなりそうですが特殊なケースだと思います。ホスティングサービスなどで定められた上限値を取得して、そこから決めた実数値で閾値を指定して監視することになるでしょう。
さらに、ネットワークのパフォーマンスをスケールアップさせるためにインスタンスタイプを一時的に変えてデプロイすることもあるでしょう。帯域幅の上限が可変である場合には、何らかの手法で上限をメトリック化することができれば、式による監視機能を用いて最大値との割合で監視することが可能です。そうでなければ、上限が変わるたびに監視ルールの閾値を変更することになるでしょう。
また、ホストメトリックだけでなく、ミドルウェアやVMなどの監視に関しても同じような構図があります。ミドルウェアやVMが確保するメモリの最大値を設定ファイルや実行時オプションで指定することがあるでしょう。こちらも可変な場合には、数値そのものを監視する際の閾値を変更するか、割合として監視できるように最大値をメトリックとして投稿するかのどちらかが必要になります。
自分が何らかのプラグインやインテグレーションを開発する際、上限はできる限りメトリックにして投稿するようにしようと考えています。
上限がわからなくてもSaturationは分かるのではないか？
一方で、一時期こんなアイデアを持っていたことがありました。メトリックのグラフが以下の図ようにあからさまな形、言い換えると、傾きが0に近く揺らぎも比較的小さい場合には「サチっている」と言えるのではないか、という考えです。
この手法のメリットはメトリック単体で検出することにより上限の知識が不要であるということです。しかしながら、本当の飽和状態に達するまでは検出ができないこと、GoogleがSRE本で提唱している「シンプルで高速な監視システム」から遠ざかってしまいそうだったことにより、ボツにしました。（アラートとして出るのではなく、勝手にアノテーションされるぐらいならアリかもしれませんね。）
先ほど紹介したSRE本の記事ではこのように書かれています：
to keep noise low and signal high, the elements of your monitoring system that direct to a pager need to be very simple and robust.
監視サービスに複雑で高級な機能があっても、限られた人のみが使いこなせたり、ロバスト性が損なわれていたりすると、結果として監視の価値が失われてしまうでしょう。
我々開発者はユーザーの要望に応えていくのも大事ですが、それがMackerelとして目指すべき方向性なのか、我々が掲げたい監視の理想像なのかについて熟考する必要がありそうです。一方で、アイデアを考え続けるのは無益ではないし、「顧客が本当に必要だったもの」を考える材料としても要望は非常に有益だと考えています。
