ノイジーアラートを減らすために、DatadogのSmoothing機能でグラフをなめらかにする

はじめに

私のチームではマイクロサービスの監視にDatadogを使っています。先日、ある機能をiOSユーザー向けにリリースしたことでサービスへの負荷が増加し、レイテンシーよくスパイクするようになりました。その結果、モニタリングの結果をポストするチャンネルがノイジーなアラートで溢れかえっています 😢。スパイクの原因はDB周り、ポッドのリソース調整などがあります。しかし、今は年末年始休業ということで大きな変更を伴うリリースができません。そのため、その場しのぎとして、Datadogモニターの設定を変更してノイジーな値を減らそうというわけです。 普段からDatadogを業務で触っていますが、細かい設定をいじったことはありません。今回の記事ではダッシュボード機能の Smoothing(平滑化) という関数を使用して、ノイジーなメトリクスをきれいにしていきたいと思います。

※この記事ではダッシュボード作成については取り扱いません 🙇🏻‍♂️

Smoothing機能を試す

https://docs.datadoghq.com/dashboards/functions/smoothing/

Autosmooth

これはその名の通り自動で時系列グラフをなめらかにしてくれます(便利😮)。グラフデータ間の移動平均を適切な時間範囲(スパン)で計算して、時系列グラフを作成しています。しかし、アラート用のモニターでは使用できないのが欠点です。 なぜなら、毎分計算されたスパンが時系列グラフに適用されるため、Autosmooth関数で適用された結果が一様でなくなる可能性があるためです。アラートの閾値あたりのデータがあるときに、アラートが発生したりしなかったりとノイズを発生させてしまうかもしれません。そのため、ダッシュボードにのみ使うことになります。以下のグラフのような人間の目では視認しづらいものを、平滑化してくれるため、監視の際に空目すること減りそうです 👀

image.png (77.2 kB) image.png (43.9 kB)

Exponentially weighted moving average (指数加重移動平均 / 指数平滑移動平均)

Exponentially weighted moving average (ewma) は指数加重移動平均という日本語名称で、単純な移動平均に指数関数的な重み付けを付与した計算方法です。直近のデータの重みを最大とし、データが古くなるにつれて重みが指数関数的に減っていきます。そのため、単純な移動平均より、直近のデータの変動が反映されやすくなっているのが特徴です。 Datadogでは ewma_3, ewma_5, ewma_10, ewma_20 の種類があり、接尾辞の数字は重み付けの対象データ数を指しています。データ数が多いほど古いデータの変動が反映されるため、グラフが緩やかになります。以下のグラフでは、赤色が元データで、橙色が ewma_20 となっています。見てのとおりかなり平滑化されています(最大のデータ数を指定しているので当たり前ですが😅)。指数加重移動平均は、スパイクだけでなく、システム停止時などの急なデータの動きに対するグラフへの反映が鈍くなるため、アラート発生時に即時検知したい場合は向かないのではと思っています。

image.png (29.0 kB)

Median (中央値)

Medianは対象のデータ内の中央値をグラフに適用します。 Datadogでは median_3, median_5, median_7, median_9 の種類があり、ewma_n 同様、接尾辞は対象のデータ数を指しています。以下のグラフでは、水色が元データで、紫色が median_9 となっています。スパイクの頻度が低ければ平滑化されています。 しかし、連続したスパイク値(スパイクなのか怪しい 🤔)がある場合は、多少最大値が低いですがグラフに反映されています。中央値を適用したグラフは、指数加重移動平均よりデータの反応速度は優れていますが、先述したとおりスパイクが連続してしまうと閾値を超えてアラートとして処理される可能性があります。スパイクの頻度が低く、ノイズが発生しづらいのであれば中央値を適用したグラフにすると良いと思います。

image.png (29.4 kB)

まとめ

3つの平滑化関数を試しましたが、以下の理由から、私のサービスでは Median 関数を使用するつもりです。

  • システム停止など緊急度が高いアラートに即時対応したい(指数加重移動平均では厳しい)
  • アラートのノイズを減らしたいけど、今の段階ではすべてのノイズを取り除かなくてもいい(根本原因は年明けに解決するため)

当たり前ですが、それぞれの平滑化関数には善し悪しがあるので何をモニタリングしたいのかによって使い分けると良いです。本記事では平滑化関数を組み合わせることはしませんでしたが、関数の作用を理解して意図したとおりのグラフを得られるのであれば試してみて良いかなと思っています。ただ、初見の人には学習コストがかかるので、必要にならない限りやらないとは思います。

ここまで読んでくださりありがとうございました 🥰少しでも監視について役立ててもらえると幸いです 🙌