Observable AIOps のインテリジェントなモニタリングと診断の実践丨グローバルソフトウェア開発カンファレンス QCon の概要

[Yuan Chuang Conference プレビュー] 1024 プログラマーズデー (2 日前)、オープンソース中国オフィスに集合、AI について話しましょう! >>>

著者：董山東（ファンデン）

この記事は、9月5日に開催されたQCon北京2023（世界ソフトウェア開発カンファレンス）での著者による特別講演「Alibaba Cloud Observable AIOpsのインテリジェント監視と診断実践」のテキスト版です。

皆さん、おはようございます。QCon の安定性と可観測性の会場で、Alibaba Cloud の可観測性 AIOps のインテリジェントな監視と診断の実践を共有できることをとてもうれしく思います。

Alibaba Cloud Cloud Native Observability チームの Fanden です。現在、彼は主に、Observable AIOps 製品 Insights の商用構築、AIOps ソリューションの研究開発、Observable チームにおける Observable フィールドの大規模モデルの探索を担当しています。私は非常に幸運なことに、ここ数年「Gartner APM 2022」と「CAICT Root Cause Analysis Standard 2023」における ARMS の評価プロジェクトを主導することができたので、今日は評価プロセスでの経験の一部を共有したいと思います。

本日は主に以下の4つの観点からお伝えさせていただきます。

まず、観察可能なシステムにおける AIOps のコア機能が何であるかを簡単に紹介します。

2 番目の部分は今日のハイライトであり、観察可能なシナリオで定義した AIOps シナリオの 3 つの柱、つまり検出、分析、および収束の実践に焦点を当てています。このセクションでは、エンジニアリングアーキテクチャ、ビジネスアーキテクチャ、アルゴリズムモデルの概要の一部も共有します。

3 番目の部分では、観察可能な AIOps の具体的な顧客事例を通じて企業の問題点とニーズを検討します。

最後に、このカンファレンスでの複数の共有から、その多くが大規模なモデルとそのアプリケーションに関するものであることがわかります。このような傾向の下で、AIOps を実装できるシナリオと方向性を観察できます。

観測可能なシステムにおける AlOps の概要

さて、共有の最初の部分を始める前に、AIOps が現在企業によって直面している 3 つの魂の苦痛についても見てみましょう。

AIOps は飾りですか?
AIOps のビジネス価値を測定するにはどうすればよいですか?
AIOps の実装方法とそのコストはどれくらいですか?

今日の分かち合いの中で、皆さんに魂の拷問について考えていただき、何らかの答えを見つけていただければ幸いです。

近年、クラウドネイティブの概念が普及するにつれて、クラウドネイティブに注目し、言及する人が増えていることがわかります。しかし、それ自体は新しい概念ではありません。可観測性の最も初期の概念はサイバネティクスの書籍から来ており、システムを制御するための前提条件は可観測性であることが強調されています。

私たちは、新世代の観察可能な製品はアプリケーション中心でなければならず、上向きにはビジネスの成功または失敗とユーザーエクスペリエンスにリンクし、下向きにはインフラストラクチャとクラウドサービスの監視をカバーする必要があると考えています。その中で、ユーザーエクスペリエンスの重要性が強調されており、ビジネス分析、ユーザー行動分析、障害時の根本原因分析機能に重点を置いて開発する必要があります。これらの機能を実装するにはどうすればよいでしょうか? 私たちの答えは AIOps です。

最も初期の AIOps コンセプトは、2016 年に Gartner が発表したレポートに由来しており、このレポートでは、ビッグデータとアルゴリズムに基づく IT 運用と保守の概念 (アルゴリズム IT オペレーション) が初めて提案されました。人工知能の急速な台頭を受けて、ガートナーは 2017 年に AIOps の概念をビッグデータとアルゴリズムから人工知能 (IT 運用のための人工知能、AIOps) に拡張しました。ビッグデータ、機械学習、高度な分析テクノロジーを通じて、次のようなことが可能になると考えています。積極的かつ人道的かつ動的に視覚化する機能を備えており、現在の従来の IT 運用および保守 (監視、自動化、サービスデスク) 機能を直接的または間接的に改善します。したがって、公式の定義では、AIOps はモニタリング、ITSM、Ops の 3 つの主要分野にまたがります。

現在、AIOps は 2016 年から上昇し、2018/2019 年に期待のピークに達し、現在、AIOps は Dak Effect 意識曲線の絶望の谷段階にあります。

私の個人的な意見は次のとおりです。

現在の AIOps の概念は広すぎるため、実装のための明確な製品境界とコアコンピテンシー項目がなくなり、実装の明確性がさらに失われます。
一方、AIOps は、オブザーバブル製品のデータ収集、データ品質、データの豊富さに大きく依存しており、オブザーバブル製品の機能との一貫性が高くなります。ただし、AIOps の「Ops」というキーワードは、DevOps の機能と重複しすぎることがよくあります。このように他の分野に過度に依存しているため、AIOps を独立した製品として真に実装することが困難になります。

現段階では可観測性などの特定の分野に深く入り込み、さまざまな可観測シナリオで AIOps 機能を構築し、徐々に統一された AIOps ブランド製品を形成する方が良い選択だと思います。外国の Datadog は Watchdog を構築し、Dynatrace は Davis の AIOps ブランド製品を構築しており、どちらもこのパスの実現可能性を検証しています。

もちろん、ここ数年で、AIOps は当初の漠然とした概念から、標準化された手法を通じて現場で実装されることが増えてきており、情報通信技術アカデミーやさまざまな企業の専門家が依然として大きな役割を果たしています。 AIOps の能力成熟度モデル標準のリリースでは、観察可能な分野における根本原因分析の技術要件を構築するための評価項目のリリースも見ることができます。これらは、観察可能な AIOps を実装するためのより良いガイドとなります。

もちろん、現時点では、各観測可能な製品の AIOps の能力出力や、国内外の専門家の評価における観測可能な AIOps の理解には一定の違いがあります。

Gartner などの代表的な海外代理店は毎年 APM 分野に関する分析レポートを作成しており、クリティカルキャパシティー (CC) 評価では、IT 運用、セキュリティ運用、デジタルエクスペリエンス監視、DevOps、ビジネスおよびアプリケーションラインの 6 つの主要なシナリオカテゴリに焦点を当てています。および SRE はテスト問題の設計に使用され、各シナリオにはシミュレートされた役割と、解決する必要がある一連の問題があります。たとえば、SRE シナリオでは、次のことに対処する必要がある場合があります。

変更前後で異常は見つかるのでしょうか？
マイクロサービス例外での連鎖反応分析
リソースレベルでの根本原因分析

評価に必要なコア機能の観点から見ると、AIOps は、ユーザー行動分析、ビジネス分析、リンク全体の根本原因分析など、評価において大きな役割を果たす必要があります。Gartner の評価の焦点は、これらの機能をどのように活用するかにもあります。

国内の代表者は、情報通信技術アカデミーが今年リリースした「根本原因分析技術要件」標準を参照してください。コア評価機能項目には、情報収集、意思決定分析、結果出力が含まれます。評価では、現在の製品機能項目がどのレベルにあるかを確認するために機能項目を等級付けします。ここでの評価の焦点は、AIOps 機能があるかどうかを確認することです。

国内外の評価要件を比較すると、海外ではAIOpsを使いこなす能力が重視されているのに対し、国内では依然として能力項目の有無が重視されており、AIOps能力をさらに発展させていく必要があることが分かります。 AIOps の実装プロセスと継続的な反復実装の鍵は、AIOps 機能を引き続き有効に活用することです。

さて、ここで可観測性と可観測性 AIOps について簡単に説明しました。また、国内外における可観測性 AIOps の理解の違いについても簡単に理解しました。次に、第 2 章が今日の内容の焦点であり、インテリジェントな監視と診断における Alibaba Cloud の可観測性チームの実践を見てみましょう。

Alibaba Cloud Observable AlOps インテリジェントな監視と診断の実践

まず、観察可能な AIOps シナリオの定義について、実装の 3 つの重要なポイント (検出、分析、収束) をまとめました。

私たちは、オブザーバブル分野の製品では、これら 3 つの柱を中心に実装の実践と継続的な反復を実行する必要があると考えていますが、従来の AIOps で言及されているキャパシティプランニング、障害の自己修復、セキュリティなどは実装の考慮事項の範囲内ではありません。

その中で、実装プロセス中に各ボードに最適化できる特定の機能を要約しました。

1 つ目はシーンを検出することです。

まず、アラームシステム内の既存のアラームルールと設定するアラームルールに対してアラーム管理を実行する必要があります。問題を検出するにはどの検出オブジェクトを構成する必要があるかを整理します。以下に例を示します。ビジネス監視では、オンライン人数や成功率などのビジネスの中核指標が、設定する必要がある検出アラームオブジェクトです。アプリケーション監視では、アプリケーションの 3 つの黄金指標は RT です。 (平均遅延)、エラー率 (エラー率)、および QPS (リクエスト量) は、アラームを設定する必要がある指標です。JVM インジケーター、CPU 使用率などのインフラストラクチャリソースインジケーターなど、いくつかのインジケーターは根本原因分析で使用する必要があります。
2 番目に、アラームルールの階層設計を行う必要があり、一方では、RT などのコア指標と CPU 使用率などの早期警告指標という、コア指標と早期警告指標の階層メカニズムを構築できます。一方、コアインジケーターのルールも分類できます。たとえば、RT が 50 ミリ秒から 200 ミリ秒の場合、P3 アラームになる可能性があり、RT が 50 ミリ秒から 1 秒の場合、P1 アラームになるはずです。グレーディングメカニズムを手動で定義することに加えて、アルゴリズムを使用して適応グレーディングメカニズム機能を構築することもできます。
3つ目は、警報嵐や大規模警報の監視であり、警報の警報兆候を検知するソリューションです。
4 つ目は、手動のしきい値アラームに加えて、ビジネス指標や変動性の高い指標に対する適応型検査機能を提供するインテリジェントな検査が必要であるということです。

次に分析シナリオです。

分析シナリオで構築できる最初の機能項目は、多次元インジケーターの主要な次元を位置付けることです。たとえば、オンライン人口の合計に異常が見つかった場合、地域 (北京) などの指標の下にある特定の次元で次元位置分析を実行することで、すべての地域のオンライン人口の指標をすぐに知ることができます。、深セン、上海）すべての地域に問題があるのでしょうか、それとも上海の局所的な問題だけなのでしょうか？これにより、障害の範囲を迅速に縮小できます。同様の機能を多次元の詳細ログと呼び出しリンクスパンで使用できます。
ビジネスのディメンション範囲を特定した後、マイクロサービスでのサービスの呼び出しやサービスのリソース依存関係の周囲で異常なノードを迅速に特定できるメカニズムが必要です。この機能項目を総称して異常なノード区切りと呼びます。この機能項目の構築により、どの POD に問題があるかを迅速に把握し、対象を絞った異常根本原因分析を行うことができます。
実際のトラブルシューティングプロセスでは、異常なノードを指定するだけで十分ですか? さらに分析とトラブルシューティングを行って、コード、メソッドスタックレベル、または呼び出された SQL コマンドレベルなど、失敗の本当の根本原因を直接特定できるでしょうか? これには、コードレベルの根本原因特定機能のサポートが必要です。
最後に、衝撃面分析機能の項目があります。これは、実装分析シナリオで多くの人が見落としがちな点です。ただし、影響面分析は多くの場合非常に重要であり、これにより、特定の障害が現在影響しているアプリケーションの数、影響を受けるトランザクションリクエストの数、および影響を受けるユーザーの数をすぐに知ることができます。これは、ユーザーエクスペリエンスを監視する分析に非常に役立ちます。もちろん、ビジネスからバックエンドサービス、ユーザー分析に至るまで、データレベルでの関連付けも必要です。たとえば、フロントエンド、バックエンド、ビジネスのユーザー ID を透過的に送信することで実現できます。

最後に、収束シナリオは、警報システムにおける発散と過度の警報の問題を解決するためによく使用されます。

まず、構築できる機能項目は、同じアラームをマージすることです。アラームが回復しない場合は、1-5-10-30 の頻度で通知を送信でき、通知には送信履歴アイテムの属性を含めることができます。
また、アラームイベントのノイズ分析を実行して、現在のアラームがどの程度の情報を伝達できるかを特定することもできます。値がないか、値が低いアラームイベントについては、ノイズと見なすことができ、ノイズをフィルタリングできます。もちろん、アラームがノイズであるかどうかを具体的に判断する方法はいくつかありますが、その実装方法については後ほど説明します。
3 番目はアラームの相関関係であり、アラームの相関関係によって必ずしもアラームの数が減るわけではありませんが、アラームの情報密度は増加します。関連するすべてのアラーム情報をアラームイベントに添付することにより、SRE は 1 つのアラームを処理するときにより多くの情報を収集できるため、トラブルシューティングが容易になります。
最後に、システムが根本原因分析を構築すると、収束中に同じ根本原因をマージできるため、真のアラーム収束を実現できます。

次に、これらの 3 軸シナリオの実装における具体的な課題と解決策のいくつかを見てみましょう。

最初の課題は、高速かつ正確なテストを構築する方法です。

従来のしきい値検出と比較したインテリジェント検出の利点は、ここ数年でますます多くの人に知られるようになったと思います。一方で、ビジネス指標のしきい値を設定するのは簡単ではありません。他方、しきい値は適切に設定する必要があります。定期的なセットのメンテナンスを行っております。対照的に、インテリジェント検出は、その履歴パターンを適応的にキャプチャして学習し、継続的に良好な検出機能を得ることができます。ただし、インテリジェントな検出ソリューションを構築するのはそれほど簡単ではありません。ここでの最大の課題は次の 2 つです。

インジケーターにはさまざまな形があります。
平均値の異常な変化、異常な傾向、さらには周期的なドリフトなど、異常の定義は明確ではありませんが、人によっては異常とみなす場合もあります。

現在業界で一般的に理解されているテストソリューションの分類を見てみましょう。

最も広く使用されているのは、同一サイクル比較、k-シグマ、箱ひげ図などの統計アルゴリズムです。

同周期比較アルゴリズムの場合、周期ごとの比較は比較値の変化率が設定したしきい値を超えるかどうかであり、前年比は同じ期間の値が設定したしきい値を超えるかどうかです。これらのアルゴリズムは、非常に周期的で固定されたシーンでうまく機能します。

2 番目の統計アルゴリズムは k-sigma で、データ分布が正規分布に従う場合、ほとんどの点は平均値の周囲で変動します。標準偏差プラスマイナス平均の 3 倍を超える確率は 0.3% であり、これは確率の低い事象です。このタイプのアルゴリズムは、小さな確率値を異常として識別するため、k-シグマ検出アルゴリズムが進化しました。

検出アルゴリズムの 2 番目に大きなカテゴリは、EWMA、STL などのタイミング解析およびタイミング分解アルゴリズムです。STL を例にとると、あらゆる時系列を周期期間、トレンド期間、残差期間に分解できると考えられています。時系列を分解することで、トレンド項目と残差が別々に検出され、より良い検出結果が得られます。

検出アルゴリズムの 3 番目の主要カテゴリは、通常は Prophet や LSTM などの予測アルゴリズムです。これらのアルゴリズムは、過去の指標の傾向に合わせて、将来の傾向と合理的な境界を予測します。実際の値がフィッティングの上限と下限を超える場合、それらは外れ値とみなされます。Prophet を例にとると、このアルゴリズムは 4 つの主要なステップに分割できます。最初のステップでは、曲線データの変化点を選択し、トレンドの変化を自動的に検出します。従来の STL と比較して、Prophet は設定を通じて休日の日付を追加できるため、休日の影響によって引き起こされる不正確な検出の問題が解決されます。3 番目のステップでは、取得した傾向と期間を個別に近似し、それらを加算/乗算して近似曲線を取得します。最後に、予測値と実際の曲線の間の分布の差を通じて上限が計算されます。このステップは実際には検出境界の従来の EWMA 構築に似ていますが、Prophet は練習を開始するのに非常にフレンドリーです。パラメータを調整するだけで、スコア 60 ～ 80 の検出器をすぐに取得できます。興味がある場合は、それを試してみてください。

最後のカテゴリは機械学習/深層学習モデルで、検出問題を 2 分類問題と見なし、教師ありトレーニングを通じて使用可能な検出器を取得します。このタイプのアルゴリズムモデルは、特定のラベル付きデータセットがすでに存在するシナリオでの実装により適しています。もう 1 つのアイデアは、アクティブラーニングを組み合わせて通常の時系列で教師なし学習を実行して典型的な正常状態と異常状態に対処し、次にいくつかの境界ケースのラベル付け方法を組み合わせて教師ありトレーニングを実行して分類能力を向上させるというものです。サンプルが小さい場合の機械学習/深層学習モデル。

さまざまな種類の異常の定義とさまざまなアルゴリズムモデルの長所と短所を考慮して、さまざまな教師なしモデルと、いくつかのシナリオでトレーニングした xgboost モデルを組み合わせ、投票メカニズムを通じて、マルチモデル融合検出ソリューションを採用しました。、複数のモデルを統合した検出統合ソリューション。全体的な計画は 3 つの主要なステップに分かれています。

1. データ層：主にデータの検証（妥当性検証、欠損値検証）やデータの前処理（欠損値処理、正規化処理）などを行う層です。

2. アルゴリズム層:アルゴリズム層は全体として STL + マルチモデル投票ソリューションを採用します。STL を通じて、周期性と傾向の特定が実行されます。ここでは、FFT、ACF、およびフラグメント類似性の 3 つのスキームを通じてマルチサイクル判定を実装します。

3. ビジネス層:ビジネス層は主に、ビジネスのパーソナライズされた設定、特別な指標の処理、およびビジネスに焦点を当てたアルゴリズム戦略の構築を完了します。例: 外れ値の信頼レベル、異常な間隔、正常な間隔。

全体的なアルゴリズムは、次の 3 つの特徴から詳細に見ることができます。

「LSTMがもたらすロングとショートの組み合わせ」という考え方、短期的な特徴と長期的な特徴の組み合わせ

長期的な特徴検出により、検出効果が向上するだけでなく、低コストが期待される一部の検出シナリオでは、長期的なシーケンス特徴と境界計算を通じて、低コストの動的検出ソリューションを実現できます。

「分割統治」、異なる検出器と異なるタイミング

定常性が強いインジケーターの場合は、検出効率から開始し、通常、K シグマ KDE、EWMA、箱ひげ図などの複数の弱い検出器を組み合わせた強い検出器を使用します。
非定常インジケーターの場合、Insights はまずインジケーターを微分し、定常性検証に合格した後に検出用の一般的な検出モデルに変換します。
周期性の強い指標については、フーリエや相似性と組み合わせて、単一/複数サイクルの正確な識別を行い、サイクルを除いた上で一般的な異常検出を行います。
検出データセットを使用するシナリオの場合、Insights インスペクションは、xgboost、隔離されたフォレスト、および検出と識別のためのその他のアルゴリズムをサポートできます。

複数の弱い検出器を使用して強力な検出器を形成する「投票メカニズム」

K シグマ、箱ひげ図アルゴリズム、KDE、EWMA など、業界で一般的な弱いアルゴリズムはすべて、フュージョンソリューションの基本的な検出器です。さまざまな弱い検出器を使用して、投票戦略に基づいて強力な検出器アルゴリズムが構築および最適化されました。

要約すると、このような「投票メカニズム」、「分割統治」、および「長い特徴と短い特徴の組み合わせ」の指導の下で、ほとんどのモデルを監視されないままにしながら、3 つの黄金指標の検出において概ね良好な結果を達成しました。異常サンプルの正解率は 95%、再現率は 90% であり、全体の正解率は評価スコア 95% を上回っています

クラウドネイティブ環境では、サービス間のトポロジが複雑で、アプリケーションが直接的または間接的に数百のマイクロサービスを呼び出す可能性があるため、根本原因を迅速、正確、かつ低コストで特定する必要があります。「Three Banaxe」実装シナリオにおける 2 番目に大きな課題は、マイクロサービスシナリオで根本原因分析を迅速かつコスト効率よく実装する方法です。

現在、一般的な根本原因の場所は次の 3 つのカテゴリに分類できます。

1 つ目は、多次元のポジショニングです。多次元の KPI に異常が発生した場合、根本原因の次元を特定する方法は、指標ドリルダウン分析とも呼ばれます。

2 番目のタイプは相関支援測位です。このタイプの測位では、障害が発生したときに、指標間の関係 (CMDB 相関、アルゴリズムには類似性、頻出項目マイニングなど) を使用して、異なる指標間の相関関係が見つかります。

最後の解決策は、トポロジ/コールリンクのポジショニングです。このタイプの根本原因分析には、通常、明確なサービスコールトポロジダイアグラムとリアルタイムコールリンクが含まれます。トポロジーグラフに基づくランダムウォーク/全体モデリングなどのスキーム。

ここでは、マイクロサービスレベルでの根本原因分析を 2 つの重要なポイントに分けて説明します。最初の重要なポイントは、異常なノードを低コストで特定する方法です。

ここで提供する解決策は、マイクロサービスのトポロジーを水平方向と垂直方向に整理することです。レベルはサービス間の呼び出しに分割されます。サービスとリソースに依存するデプロイメントに垂直に分割されます。それぞれが 1 対多の関係になる場合があります。このような並べ替えの後、トポロジマップ全体を取得しなくても、レイヤーごとのドリルダウン分析を構築できます。つまり、現在の階層のノード情報と次の階層のノード情報だけが必要となる。この利点は、データ抽出のコストが全体的なモデリングのコストよりもはるかに小さいことであり、本質的にはトポロジマップ上のプルーニングのレイヤーです。

各レイヤーの具体的なドリルダウン分析については、マイクロサービスシナリオに基づいてアトリビューションアルゴリズムモデルを設計しました。2 要素アトリビューションアルゴリズムを例にとると、RT クラスコールインジケーターの場合、RT で例外が発生した場合、サービスリクエストの量とリクエスト時間の 2 つの要素を考慮する必要があります。2 つの要因を分解することで、各要因の変化が最終的な全体的な結果の変化に及ぼす影響を正確に知ることができます。このようにして、レイヤーごとのドリルダウンと属性アルゴリズムモデルを通じて、低コストで正確な異常ノードの境界設定を実現できます。

2つ目のポイントは、根本原因分析を構築する過程で、どのような分析体制を提供すべきかを常に考えていることです。例外ノードと例外関連情報を提供するだけで十分ですか? 現在の業界の多くのソリューションは、第1層と最終層で実装されており、異常ノードや異常情報を提供した後は、運用保守の専門家の判断に依存することが多くなっています。

私たちはさらに一歩進んで、運用および保守の専門家の多くの分析ステップとプロセスをデシジョンツリーを通じてモデル化しました。このようにして、異常なノードを特定した後、異常なノード内のコード、メソッドスタック呼び出し、インジケーター、例外ログ、その他の情報をさらに分析し、コードレベルで根本原因分析を達成できます。

全体的なソリューションは、アルゴリズム + エキスパートシステムのデシジョンツリーモデリングに基づいており、まずサービスの依存関係の寄与を水平方向に分析し、インフラストラクチャの異常を垂直方向に分析して障害を特定し、特定の異常なノードを特定します。エキスパートプラグインの分析を通じて、特定の異常ノードの下で典型的な障害のプラグインベースの詳細な分析を実装することができ、それによってノードの境界からコードレベルまでの根本原因分析機能を全体的に実現します。

現在、ダウンストリームの依存関係の問題、SQL の遅さの問題、不均一なトラフィックの問題など、さまざまなシナリオに対応するデシジョンツリーモデリング用のエキスパートプラグインを実装しています。これらのシナリオに対して、コードレベルで根本原因の特定を実装しています。

最後に、分析シナリオで、具体的なユースケースを見てみましょう。

1 つ目は、特定のユーザーアプリケーションの RT インジケーターが突然異常に増加することです。従来の手動検出とトラブルシューティングでは、まずこのアプリケーションに関連するアラームを設定する必要があります。アラームを受信した後、手動で異常情報を収集する必要があります。ログを確認します。、アラームを確認し、市場を読み取り、一時的なコマンドを実行します。そして、システムの導入状況やさまざまなドメイン知識などを理解することで、根本原因の分析と特定が可能になります。

インテリジェントな監視と診断に関しては、異常なイベントがインテリジェントに識別され、設定を必要とせずに重大度レベルが決定されます。ユーザーに通知を送信する際に、根本原因の分析が行われました。根本原因診断レポートでは、この消費時間の急激な増加の理由を列挙しました。下流アプリケーション B の一部のインターフェイスで SQL リクエストの実行にかかる時間が急激に増加し、それが上流アプリケーションの RT の高さを引き起こしました。

この情報に基づいて、ユーザーはすぐに確認し、最終的に、問題の原因が SQL インデックスの障害であることがわかりました。

Banaxe が解決する 3 番目の課題は、アラームが多すぎる問題をどのように解決するかです。まず、アラームが多すぎる理由を分析してみましょう。一般に次の 3 つの理由があります。

不正確な検出により、保守的なアラーム設定が行われます。
一定量のアラームノイズがシステム内に当然存在します。
関連するアラームは複数の場所で構成されています。たとえば、アラームがマシン上で構成され、アラームがマシン上のサービス上で構成されている場合、アラームはマシンとサービス上の複数の場所に表示されます。実際、根本的な原因は同じです。故障の原因。

収束手法を通じてアラーム内の一部のノイズを特定でき、発散アラームは相関手法と根本原因のマージを通じて解決できます。

まず、業界の現在のシナリオにおけるいくつかのコンバージェンスソリューションを見てみましょう。

1 つ目は、共通のアラームタイトルやアラームの内容など、アラームイベントの内容に対して同様のクラスタリングを実行することです。多くの場合、アラームコンテンツの関連性は選択したフィールドに依存し、多くのアラームコンテンツはテンプレートを通じて生成されるため、テキストの類似性に多くの干渉が生じ、精度が低下します。

2 番目の方法は、アラームによって生成された時系列に対して同様の相関関係を実行することです。これら 2 つのスキームは比較的単純で直接的ですが、欠点は、構築された相関関係であることが多く、あまり決定論的ではないことです。関連情報として表示できます。

3 番目の方法は、過去のアラーム項目から頻繁に発生する項目をマイニングして、さまざまなアラームオブジェクト間に特定の相関関係があるかどうかを判断することです。この解決策は、一見したところまだ理にかなっていますが、実際の実装プロセスでは、実際には、頻繁に同時に出現する相関関係が複数含まれている可能性があることがわかります。この方法で単に相関関係を構築するだけでは精度が低くなります。

当社のコンバージェンスソリューションは、複数のテクノロジーオプションの利点を組み合わせて、イベント処理および分析フローを構築します。最も核となる部分は次のとおりです。

アラームイベントの全体的なフィルタリングは、インテリジェントなアラームノイズ認識に基づいており、ノイズとして識別されたものはダウングレードしたり、フィルタリングして除外したりすることもできます。
アラームイベントの収束には、次の 2 つの側面の関連情報が含まれます。

1 つ目は、アラームオブジェクトの過去のアラームイベントを関連付けることです。これにより、運用およびメンテナンスの専門家に過去のアラーム情報、対処の提案などを提供できます。

2 つ目は、アラームオブジェクトの現在の関連情報 (上流および下流のトポロジマップ、関連するアラームインジケータなど) を関連付けることです。

収束中のケースは、アラームイベントのノイズ識別です。

どのアラームも、次の 4 つのタイプのいずれかに分類できます。

ノイズ:現在のアラームはほとんど役に立たず、不要です。
新規性:予期しないアラームイベント、またはこれまでに見られなかった、またはめったに見られなかったアラーム
重要:主要インジケーターのアラーム
異常：アラームの発生頻度が変化した例：あるアラームイベントはノイズですが、以前は1日5回発生していたのが、現在は1日50回発生するようになりました。そうなると、これはシステムにおける重要な変更を意味する可能性があります。

ノイズイベントを分類することで、NLP アルゴリズムと情報エントロピーモデルを使用して、アラームに含まれる情報量を計算できます。

全体は 4 つのステップに分かれています。

ステップ 1:自然言語処理とドメイン語彙データベースに基づいて、イベントコンテンツの単語ベクトル化を完了し、イベントの最小粒度測定を達成します。
ステップ 2:情報理論における情報エントロピーの概念に基づいて、tfidf モデルと組み合わせて、単語ベクトルの情報エントロピー値と重要度測定モデルを構築します。
ステップ 3: sigmod を使用して、イベントの非線形で正規化された「情報エントロピー」測定を完了します。
ステップ 4:過去のイベントの処理記録とフィードバックを組み合わせて、反復トレーニングと検証のためのモデルを構築します。

2 つ目の重要な点は、アラームイベントを関連付けることができることです。ここでは、さまざまな角度から情報を関連付けることを試みます。これには、リソース層関連の実践、アプリケーション層関連の実践、ネットワーク呼び出し関連のイベント、時間枠内の変更イベントなど、トポロジに基づく決定的な関連付けが含まれます。第 2 に、時系列の類似性やアラームテキストの類似性などの類似性に基づいて関連付けを構築できます。最後に、歴史上の同じイベントの発生、その時の処理者と処理記録などの歴史的相関関係もあります。

さて、ここでは、検出、分析、収束の 3 ステップのシナリオの実践を共有しました。以下に、より一般的なものをいくつか紹介しましょう。現在、観察可能な AIOps を 0 から 1 まで構築したい場合は、次のコンテンツをそのまま使用できると思います。

1 つ目は、一般化された AIOps アルゴリズムモデルです。ここでは、Sanbanax シーンのアルゴリズムを要約して比較し、一般的な時空の複雑さ、サンプルの複雑さ、解釈可能性などの複数の観点から比較します。時間の都合上、ここではアルゴリズムの比較については詳しく説明しません。内容に興味がない学生は、会議後に PPT から詳細な比較分析を行うことができます。

2 つ目は、AIOps が使用できるエンジニアリングアーキテクチャです。

AI プロジェクトでは、多くの場合、主要な部分はデータレイヤー、オフラインモデリング、オンラインサービスの 3 つの主要な部分です。

データ層では、統一インターフェイスを構築することで、時系列データベース、ログトレースライブラリ、イベントセンターと対話します。

特定の AIOP シナリオの要件が明確になった後、多くの場合、最初にオフラインモデリングを実行し、統合データインターフェイスを通じて対応するデータを取得し、それをオフラインデータセットにクリーンアップします。次に、特定のモデルに従ってモデリングと反復トレーニングを実施します。

使用可能なモデルをトレーニングした後、アルゴリズムプラットフォームを通じてリリースできます。アルゴリズムサービスリリースはこちら FCソリューションは主に運用保守フリーで、マルチバージョン機能のA/Bテストが簡単に実施できるのでおすすめです。

オンラインサービス層では、特定のビジネスロジック、フィードバックメカニズム、自己監視機能が構築されます。ビジネスロジックとアルゴリズムサービスは、API を通じて対話できます。

オブザーバブル AIOps のビジネスロジックアーキテクチャについては、次を参照してください。

1 つ目は、統合 API を通じて監視可能なデータソースと対話する必要があることです。もう 1 つ強調すべき点は、検出用のデータオブジェクトモデル、根本原因分析用のオブジェクトモデルなどを含むデータモデルであり、これらは統一された定義を持つ必要があります。

インテリジェント検出に接続すると、システムはスケジュールされた検査を実行するためのスケジュールされたタスクを作成できます。検査中に例外が検出されると、その例外は候補例外オブジェクトライブラリに追加されます。このとき、分析モジュールは同期/非同期でトリガーできます。

分析モジュールには、前述の多次元分析、マイクロサービス根本原因位置分析、影響範囲分析、相関分析などが含まれます。

同時に、異常候補ライブラリに対して、システムにはタイミングコンバージェンスロジックがあり、スケジュールされた方法で候補故障ライブラリ内の故障の収束計算を実行し、収束したデータを同期して故障ライブラリに更新します。

最後に、リアルタイムアラームとダッシュボード表示の収束問題リストは、障害ライブラリと対話します。

さて、観察可能な AIOps のインテリジェントな監視と診断の実践を詳しく見て、一般化されたエンジニアリングアーキテクチャ、ビジネスアーキテクチャ、アルゴリズムモデルの比較を紹介した後、パブリッククラウド上の特定のケースを見てみましょう。

観察可能な AlOps 特有のケース

Transsion Holdings は、Spring Cloud を使用して包括的なアプリケーションマイクロサービスを実装しており、アプリケーションは Alibaba Cloud Container Service ACK 上で動作し、ヨーロッパ、アジア、その他の地域に分散されており、真のマルチリージョンサービスシステムを実現しています。このシステムの場合、完全な監視可能なシステムを構築することは非常に困難です。これには主に次の 4 つの主要な問題点が含まれます。

最初の問題点は、観察オブジェクトが複雑かつ多数であることです。観察オブジェクトはさまざまなテクノロジースタックやアーキテクチャに分散されており、包括的な範囲と焦点を達成することは非常に大きな課題です。

2 つ目の問題点は、オンライン問題のトラブルシューティングの遅さです。マイクロサービス化後のビジネス構造は複雑になり、オンライン問題のトラブルシューティングには複雑なコールリンクの分析が必要になり、時間がかかります。

3 つ目は、内部プロモーションの難しさです。新しいサービスは頻繁にローンチされますが、一部の企業は、ローンチの作業負荷を軽減し、追加のプロモーションを必要とするために、観察可能なプラットフォームに接続することに消極的です。

4 番目の問題点は、監視データソースの集約が難しいことです。マルチリージョン展開後は、各リージョンに独立した監視可能なプラットフォームがあり、複数のリージョンに分散している監視可能なデータを集約することができません。

その中で、観察可能な AIOps に最も関連するのは、オンライン問題のトラブルシューティングの遅さです。私たちは、トレースリンク診断と観察可能な AIOps 機能の統合を通じて、診断効率の向上に貢献できることを楽しみにしています。

これら 4 つの問題点に対処するために、ARMS が提供するソリューションは次のとおりです。

1. 非侵入型アクセスソリューション:アプリケーションのデプロイ時に 2 行のアノテーションを追加するだけで、エージェントが自動的に挿入され、フルリンク監視が実現されます。コードへの侵入はなく、運用保守チームは介入しません。観察可能なプラットフォームの促進にエネルギーを費やす必要がある。

2. 統一指標システムの提供： ARMS と可観測監視 Prometheus 版により、リソース層、コンテナ層、サービス層、アプリケーション層、ユーザーエクスペリエンス層をカバーする統一指標システムを構築し、点在する単一点から大規模な。

3. フルリンクの追跡と診断: ARMS アプリケーション監視にアクセスすると、サービスの健全性ステータスと依存関係を簡単に確認できます。オンラインで問題が発生した場合、呼び出しチェーン全体を迅速に追跡してコードレベルで特定できるため、トラブルシューティングの効率が大幅に向上します。

4. グローバルデータ集約:可観測監視 Prometheus バージョンのグローバル集約インスタンスとインテリジェントアラームセンターを通じて、世界中に展開されているビジネスシステムを統一した方法で表示し、警告することができます。

最後に、Transsion Holdings は新たな観察可能な技術機能を確立した後、問題診断の効率を向上させただけでなく、ユーザーエクスペリエンスも大幅に向上させました。Observable AIOps が提供する異常検出機能とインテリジェントな診断機能もお客様に認められています。

大規模モデルの時代、観測可能な AlOps はどこへ向かうのでしょうか?

最後に、大規模モデルの時代、観測可能な AIOps はどこへ向かうのでしょうか? 今回の QCon 共有トピックからもわかるように、大規模モデルとそのアプリケーションは非常に人気があり、大規模モデルを通じて元のアプリケーションシナリオを再構築する方法を誰もが考えています。

可観測性の分野では、大型モデルが新たな変化をもたらしており、現在、海外の可観測メーカーが chatgpt を利用して自社の大型可観測モデルのデモを行っています。主に grok のようなものが含まれます: new relic. chatgpt が普及し始めた 4 月から 5 月にかけて、観測可能な分野で最初の生成 AI アシスタントとして知られる Grok を最初に起動しました。

Datadog は長年にわたって可観測性分野のリーダーであり、その強力な製品機能は多くの競合他社に模倣されてきました。今年の Dash Conference では、インフラストラクチャ、ベクトルデータベース、モデルの展開から運用と保守、モデル開発、タスクオーケストレーションまでを含む、AI のためのエンドツーエンドの観察可能なソリューションを発表しました。さらに、datadog によるクエリ、洞察、行動フィードバック、監視データに関する組織的なコラボレーションを実現するために、生成 AI ロボット BITS.AI が開始されました。また、注目すべきは、クラウド製品を大規模なモデルで作り直したGoogleのDuet AIの最近の立ち上げであり、その中にはPromqlの生成など、可観測性と密接に関係する事柄が私たちの実践と重なる部分もあります。

将来的には、一方では、大規模なモデルとラングチェーンのアーキテクチャを通じて、観察可能な分野でコパイロット（副操縦士）を構築し、日常的な質問応答、データクエリを実現し、観察可能な実践ツールボックスを呼び出して完成させたいと考えています。一連のアプリケーションシナリオ。その一方で、エージェントと組み合わせて大規模モデルの一般的な理解能力を高め、メインドライバーの能力を構築し、検出、分析、および収束シナリオにおけるモデルの能力をさらに向上させることに期待しています。

皆さん、ありがとうございました。今日の私の分かち合いはこれで終わりです。最初に魂の 3 つの質問を復習します。この講義を聞いた後の皆さんの答えや感想を楽しみにしています。