[[PatternMatcher メトリクスの典型的な13種類の異常パターン]]に対して、メトリクスの意味を考慮したクラスタ指標に基づき、[[research/tsifter/TSifter]]のクラスタリングを評価する。 - [[クラスタリングの評価指標]]のPseudo F - メトリクスの意味論に基づくGround Truth - 同一クラスタに属すべきメトリクスを事前に定義する - {CPU使用、メモリ使用、ネットワーク使用}を示すメトリクス - jvmのリクエスト数とmongoのクエリ数 - cpu faultの場合 - cpu_user_seconds_totalとcpu_usage_seconds_totalは同じ。 - memory faultの場合 - memory_working_set_bytesとmemory_failures は同じではない - Ground Truthの用意 - 異なるクラスタに属してほしいメトリクスを事前に定義する - {レイテンシ、エラー} <-> {サチュレーション、トラフィック} - cpu faultの場合 - cpu_user_seconds_totalとcpu_sys_seconds_totalでは振る舞いが違うはず - Ground Truthの用意 - フェーズ１を通過した、故障サービス内のメトリクスに対して、メトリクスパターンでマッチングして取り出して、jupyterで一斉表示して確認 - okなら、Ground Truthを生成してファイル保存 - 評価指標の算出 - 母数：Ground Truthが定義されているメトリクスペアの数 - GTは、そのペアが同一クラスタか、そうでないかの2値 - 正例：同クラスタに入る - 負例：異クラスタに入る - TP TN FN FPを計算 - メトリクスの時系列データの形状に基づくGround Truth - [[PatternMatcher メトリクスの典型的な13種類の異常パターン]] - Type1とType2が同一クラスタにない状態が望ましい - Ground Truthの用意 - サービス単位でクラスタリングするため、故障サービス内の各メトリクスに対して、Type1かType2かの正解定義を与える。 - 3 fault types x 5の15個の異常ケース分ぐらい？ - 評価指標 - 同一クラスタ内のメトリクスペアのTypeが同一であれば正例、負例 - Accuracy = 正例 / メトリクスペアの総数 - クラスタ平均Accuracy = 1/k sigma AC@i - 任意のクラスタ内の過半数の要素のGround TruthのTypeがそのクラスタのType。 - クラスタのTypeに対して、クラスタ内の要素のTypeが同一であれば正例、していなければ負例 - 同一Anomaly Patternが同一クラスタに配置されているかどうか - 故障箇所候補メトリクスのTypeが他のTypeと混ざっているかどうか - クラスタリング範囲がマイクロサービス単位かpod単位かの変化をみる - 期待される結果 - 既存手法（FluxRankのDBSCAN + ピアソン相関）と比較 - 既存手法がType1とType2が同クラスタに入る可能性があることを示す。 ## データ収集手順 1. 故障注入ケースを選択 2. ケースに紐づくデータセット内から故障箇所マイクロサービス関連のメトリクスをとりだす 3. TSifter フェーズ１で異常メトリクス取得 4. 異常メトリクスに対して、knn(k=20)でクラスタリング 5. クラスタごとにbatch cofirmation。このとき、confirmしたメトリクスを覚えておき、別クラスタと重複するメトリクスは除外 --- [[クラスタリングをPrecision-Recallで評価する方法]]に基づき、ゴールドスタンダードを定義する。 1. 異常パターンごとに1クラスタ 2. 異常タイプごとに1クラスタ