はじめに
Splunk Observability Cloudはメトリクスから簡単にDetectorを作れて、更に機械学習によるアノマリ検出もできるので方法をまとめます。
Detectorを用いたアノマリ検出の設定
とりあえず用語の整理です。
| 英語名 | 日本語名 | 説明 |
|---|---|---|
| Detector | ディテクター | 検出器。アラート定義みたいなもの。 |
| Alert | アラート | Detectorで検出された、通常あまりよろしくない事象。 |
| Chart | チャート | メトリクスを分析・可視化したもの。グラフとか。 |
Detectorの作成
DetectorはChartまたはメトリクスから作成できます。
Chartから作成
Chartの右上に🔔アイコンがあります。ここから対象のメトリクスに対してDetectorを作成できます。
これが一番楽な方法だと思います。
Chartで定義済みのメトリクスとその条件などが既にセットされています。
Alert conditionを選びましょう。色々使えますね。
大体の意味は以下の通りです。
| Condition | 意味 |
|---|---|
| Static Threhold | 静的閾値 |
| Heartbeat Check | メトリクスが途絶えた場合に検出 |
| Resource Running Out | リソース枯渇。ディスク、メモリ使用率などが指定した値（100や0など）に近い将来到達する場合に検出 |
| Outlier Detection | 同じような動きをするメトリクス間で一つだけ異常な動きをしている場合に検出（LB配下のEC2のリソースとか） |
| Sudden Change | 突発的な動きがあった場合に検出 |
| Historical Anomaly | 過去の周期から外れた動きをしている場合に検出 |
| Custom Threshold | 複数のメトリクスの条件の組み合わせ（AND / OR）で検出 |
詳細はこちら。パラメータの説明だったり検出ロジックが書かれていたりします。
アノマリ検出の一つのSudden Changeを見てみましょうか。
センシティビティを選ぶというシンプルな設定です。
もっとチューニングさせろ！と言う場合はadvanced settingをクリックしてください。
色々でてきます。
さて、こういうアノマリ検出系にありがちな困りごとが「この設定でどれだけアラートあがるの？」ということだと思います。
それに対してSplunkが偉いのは、画面の上に出ているPreflight check機能です。
定義したDetectorを過去データに適用してみて、どれだけアラートが発生するかをシミュレートしてくれる機能です。
上の例だと、スパイクが起きてるのにアラートとして見なしていません。というのも、このメトリクスは定期的なスパイクが発生するため統計的に異常と見なしていないようです。
静的閾値で敢えてアラート発生する条件にするとこうなります。
きちんとチェックされていますね。
設定してみてバンバンアラート上がっちゃったからチューニングして、、、みたいな試行錯誤がいらなくなるのは大きいです。
設定が固まれば、次はアラートの情報追加です。
Severity、Runbook（手順書や関連ダッシュボードなどのURL）、Tip（このアラート出たらこのコマンド打て！的なの）を設定できます。
次はアラート通知先です。メール、チャット（Slack、Teams）、ServiceNowなど色々選べます。Plugin追加したらJiraとかにも送れるようです。Incident Intelligenceというのは担当者アサインと電話通知とか自動でやってくれる機能です。
最後に名前つけてActivateしておしまい。
ChartからDetectorを作成する利点のもう一つとして、Chartとアラート発生状況が紐づいて見えることです。アラートが発生したらこのように赤くなります。発生したアラートも見れます。
平和な時は緑。
アクティブなアラート一覧も確認できます。
アラートをクリックするとこんな感じ。アラート発生したとき（表示期間の変更もできます）のメトリクスの状況や、関連するダッシュボードへのリンクがあります。
メトリクスから作成
メトリクスをChartにしてないけどDetector作りたいとき（あんまりない気もしますが）もできます。
作成したDetectorを既存のChartに紐づけることもできます。
New Detectorをクリックして、
APMかIM（インフラ・ミドルウェア）のメトリクスかを選んで、
メトリクスを選びます。後の流れはChartのときと同じです。
APMの場合は任意のサービスのエラーかレイテンシーを対象にできます。リクエスト数もメトリクスとしては取っていますので定義できます。
AutoDetect
今まで新規にDetectorを作る方法を説明してきましたが、AutoDetectという、OOTBのベストプラクティス的なDetectorが用意されています。これをベースに閾値のチューニングや通知先の設定すると楽です。
APMであればエラー、レイテンシー、リクエストのSudden Changeや、KubernetesであればNodeの健全性やDeploymentがSpec通りか、など色々あって、拡充も続けられています。
補足
- 30台のホストがあった場合、全部にDetectorを仕込む必要はないです。ディスク使用率のメトリクスに対してDetectorを一つだけ仕込めば、検出したホストに対するアラートが発報されます。
- Muting rule（静観条件）も設定できます。期間指定or永続、条件指定（特定ホストのみなど）。
- Terraform使えます。
アノマリ検出シナリオ
じゃあ何にDetector仕込みますか？という話ですよね。
あまりにアラートが多いと人は見なくなる or アラート疲れを起こすので何でもかんでも仕込めばいいという話ではないです。
アクション可能なアラートであること、ということがとても重要です。何をしたらいいか分からないアラート、放っておいてもよいアラートならそもそも不要じゃないでしょうか。定義しておいて画面上で見えるようにするのはよいですが、通知して着弾した不運な誰かを疲弊させるのは避けるべきです。
それではアクションを取るべきアラートは何かと言うと、ユーザーエクスペリエンス観点（エラー、レイテンシー、SLOに基づいていれば更に良い）、ビジネスKPI観点（コンバージョンレート、売上などサービスによる）、もしくは明確にまずい事象に対して作り、通知を受け取ったらそこからフロントエンド、アプリ、インフラで原因究明していく、という流れがオブザーバビリティ的ではないかと思います。
（この話もそのうち）
まとめ
Splunk Observability CloudでDetectorを使いアノマリ検出する方法をまとめました。
クリックベースで設定できますしPreflight機能によるシミュレーション、Chartとの紐づけが便利だなと思います。