## Memo > (i) エラーログを時系列としてモデル化し、(iii) 回帰と条件付き独立性に基づく因果関係解析手法を用いて、ドメイン知識やサービストポロジーに依存せず、単に実行時ログデータを用いて、影響を受けるサービス間の因果関係を推論することである。 - [[2020__ICSOC__Localization of Operational Faults in Cloud Applications by Mining Causal Dependencies in Logs using Golden Signals]]と関連？ - 特定粒度はエラーメッセージ（テンプレート） - 2フェーズのアプローチ - 1) 故障したサービスを特定する - 因果関係グラフに基づくアプローチ - 因果グラフ構築 [[PCアルゴリズム]] - 条件付き独立性検定 [[G2検定]] - 因果方向の決定 [[Granger因果性|Granger因果]]検定 ？ - 3つのバリエーション - CG-GS - GS(Golden Signal)ノードを引き起こすすべてのノードにFaultyマーク - CG-PR - 因果グラフに対するPageRank - CG-PPR - ノードの重み（因果スコア）を考慮した因果グラフに対して、Personalized PageRank - Faultyマークをつけたノードにselfエッジとbackwardエッジを追加 - [[2013__PER__Root Cause Detection in a Service-Oriented Architecture|MonitorRank]]の手法 - **因果スコアをどのように計算するかが論文中に記述されていない** - おそらく、Granger因果検定のP値か、ピアソンの相関係数ではないか。 - ハイブリッドアプローチ - 依存関係グラフが利用可能な場合 - DG-PPR - DGを因果グラフで更新したのちにPersonalized PageRank - 2) 故障したサービス内の 原因となるエラーメッセージ(テンプレート)を特定 - TGS - 最上位サービスについて、Granger因果により、エラーテンプレートとGSノードの因果を推定する - TPR - Top-3サービスのエラーテンプレートとゴールデンシグナルノード間で因果関係グラフを構築する -> PageRank - ホップ数を考慮した独自の評価指標 - 評価結果 - PC、Blinear、Blassoのうち、PCがよい 条件付き独立性検定としてG2検定を使っているとのことなので、よくわからないですね… In this paper, two types of Granger causality approaches are used: (1) regression based and, (2) conditional independence testing. の記述のあとに、(2)としてPCアルゴリズム+G2検定がでてきます。(1)としてはVARモデルのGranger Causality（Blinear）、とBayesian Lasso-Granger（BLasso）の２つのバリエーションが紹介されていますね。(1)はGranger causalityアプローチですが、(2)はどう考えても違うので変だなと思いました。 これらを比較した実験の結果、PCアルゴリズム+G2検定が最良とでているようです。 causality scoreの間違いでした。いずれにしても、このcausality scoreが計算できないとこの論文の手法を実装できないですね… causality scoreは、SLIメトリクス（Golden Signals）に対するそれ以外のメトリクスの因果効果の大きさを示すようなんですが… granger causality testのp値でも使う causality scoreはエッジではなく、ノードに対する重みとして扱い、Personalized PageRankで中心性スコアを算出するようです。 ## Abstract クラウドネイティブアプリケーションでは、運用上の障害の多くがSLO（Service Level Objectives）の違反となり、障害と呼ばれています。SLOは、可用性、スループット、頻度、応答時間、品質という、測定可能な特定の特性に基づいて定義されます。SLOは、可用性、スループット、頻度、応答時間、品質という特定の測定可能な特性に基づいて定義されます。レイテンシー、トラフィック、エラー、サチュレーションという4つの測定基準は、アプリケーションのほとんどの停止をカバーします。これらは[[SREゴールデンシグナル]]と呼ばれています。クラウドネイティブアプリケーションは動的で複雑なため、サイトリライアビリティエンジニア（[[notes/sre/SRE]]）は問題の特定、特に障害の特定に苦労します。障害の特定は、SREが自分のドメインの知識と経験に頼って試行錯誤することが多い。この作業は非常に手間がかかり，停電の平均解決時間(MTTR)が長くなることが多い．本論文では、ゴールデンシグナルサービスのエラーとエラーログの間の因果関係を確立し、さらに因果関係グラフの[[PageRank]]中心性を利用して、障害のあるマイクロサービスのランク付けリストを生成する、軽量の障害特定システムについて説明します。 [[2021__CLOUD__Causal Modeling based Fault Localization in Cloud Systems using Golden Signals__translations]]