[Root Cause Finder for Datadog | Zebrium](https://www.zebrium.com/blog/root-cause-finder-for-datadog-and-monitoring-tools) [[Zebrium]]のブログで、[[Datadog]]における原因診断の問題とMLでの解決策が解説されている。 ## Troubleshooting in Datadog – Example 1 <iframe width="560" height="315" src="https://www.youtube.com/embed/YGWA54nEEy0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> 1. サービスマップの確認  2. 赤いサークルをみる。 coffee-houseサービスで問題が起きていることがわかる。 3. inspectボタンからそのサービスのトレースをみる 4. そのため、顧客ID（最初に問題を訴えた顧客）と時間帯で絞り込み、最も遅いリクエストを調査する必要がある。トレースをクリックした後、このスタックトレースエラーが発見され、原因を指し示している。 5. その他のパネルとして、「logs integration with events panel」、「the synthetics integration」、「host id information inline with the trace panel」など。そして最後に、[[APM]]のランタイムメトリクスを表示する新機能を発表する前段階として、「これでいいのか」という質問を投げる。 ## But was it easy to find the root cause? - 各ステップでは、何が提示され、次に何をすべきかを慎重に判断する必要があることは説明されていない。 - 各ステップで新しい情報が現れると、ユーザーはデータを解釈し、経験、直感、スキルを駆使して、次に必要なデータは何か、どこに探しに行くべきかを判断する必要があった。もしユーザーがどの時点でも別のドリルダウン経路をとっていたら、はるかに面倒な作業になっていた。 - APMとトレーシングのデータからトラブルシューティングを開始し、サービスマップを見ることを決めただけでも、特定の選択だった。Datadogにはたくさんの選択肢がある！ - Datadogは、アプリケーションとインフラストラクチャを非常に「観察」しやすくしているが、経験の浅いユーザは、すべての可能な開始点とドリルダウンパスに圧倒され、トラブルシューティングのセッションがはるかに長く、困難になった可能性がある。 ## Troubleshooting in Datadog – Example 2 - メトリクスが閾値（これは固定閾値でも異常として検出されるものでもよい）に達したときに起動する警告ルールを多用する。一般的な問題の大半は自動的に検出される。  (ネットワークの問題の可能性をキャッチするために設定した異常モニターの例。) - しかし、この種のモニターは、実際にはネットワークの問題を検出しているわけではなく、むしろネットワークの問題の可能性が高い症状を検出しているので、原因を見つけるにはさらなるトラブルシューティングが必要。 - 原因は様々なので（ハードウェア、バグ、ユーザー負荷の変化、ミドルウェアの問題など）、システム全体の健全性を示すダッシュボードはおそらく意味があるのだろう。  - グラフの中のほぼすべての指標が、ほぼ同じ時期に変化しているように見える。では、次はどうすればいいのか？ - podごとのネットワークレートの詳細を見て、どのpodに問題があるのかを調べるか？あるいは、namespaceごとに実行されているpodを調べて、podの増加が問題の原因であるかを確認するか？それとも、上記のようにサービスマップに直接飛ぶか？ ## Troubleshooting in Datadog – Example 3 – Using Root Cause Solver  - 緑の線は、Zebriumがログから拾った異常を表している。この線は、上記のすべてのメトリクスが低下し始めたときに、ちょうどスパイクし始める。赤い縦棒は、Zebriumの[[機械学習]]が問題の原因を検出した箇所を示している。  - 原因が自動でダッシュボードに表示される。 ## How did the root cause just “show up” in the dashboard? - Zebriumは、ログに機械学習（ML）を用いて、ソフトウェアやインフラの問題の根本原因を自動で発見する。MLは、ソフトウェアに障害が発生したときにログに発生するパターンを検出するようにモデル化されている。基本的には、ログ全体から相関のある異常のクラスターを見つけ、何が起こったかを説明する10～50のログ行を発掘する。そして、NLP（[[GPT-3]]）を使って、それらを1つの文章にまとめる（これが上に示したものです）。 - この技術は、ソフトウェア障害の根本原因を正しく特定する精度が90％以上（これは、さまざまな製品で実際に発生した数百の障害に対する顧客テストに基づくもの）。このMLは、手動でのトレーニングや事前に設定されたルールを必要とせず、24時間以内に精度を達成する。 <iframe width="560" height="315" src="https://www.youtube.com/embed/JhwAFKk0wg4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>