【専門家がここにいるエピソード3】大量ログ分析とインテリジェントな運用・保守

1. AIOpsとインテリジェントログセンター

1.1 AIOps の 5 つのレベル

インテリジェント ログ センターについて話すには、まずインテリジェントな運用と保守とは何かを理解する必要があります。現在、業界におけるインテリジェント運用とメンテナンスの応用は、主に次の 5 つのレベルに分かれています。

レベル 1 は最も簡単です。アイデアがあれば、試してみることができます。ネットワーク管理監視システムにアクセスし、監視指標の曲線を取得して、異常検出を試してください。

レベル 1 では、成熟した単一ポイント アプリケーションは存在しません。成熟した単一ポイント アプリケーションが存在する場合、レベル 2 に到達したことを意味します。第 2 レベルでは、前提条件として一定のインフラストラクチャ構築が必要です。単一シナリオモジュールを直列に接続してプロセスベースの AI 運用と保守を形成できるようになると、第 3 レベルに到達します。

現在、業界は基本的にレベル 2 と 3 に向けて取り組んでいる段階にあり、レベル 4 と 5 を達成するにはまだ長い道のりがあります。

周知のとおり、AI アプリケーションは強力で、テクノロジーは成熟しており、基本的に広く使用できるモジュールは音声認識と顔認識の 2 つだけです。音声認識と顔認識は、主に中国の国内市場の需要と大規模な人口基盤に基づく膨大なデータリソースにより、急速に発展する可能性があります。

運用保守分野ではデータが少なく、情報が比較的断片化されているため、AIOps の開発が遅くなります。 Logeasy が 5 年前にログ分析を開始したとき、主な理由はログ データの量が膨大だったことです。AI アルゴリズムを適用することで、インテリジェントなログ分析を実現しました。現在、LogEasy インテリジェント ログ センターは、AIOps の 5 つのレベルのうちレベル 2 とレベル 3 の間にあります。

1.2 スマートログセンターの紹介

より高度な AIOps 機能を誰もが実現できるようにするために、Logeasy はインテリジェント ログ センターを作成しました。次の図は、インテリジェント ログ センターの全体アーキテクチャ図です。

AIにおいて重要なのはデータだということは誰もが知っています。したがって、まず第一に、できるだけ多くの種類のデータを収集し、処理し、分析する能力を持たなければなりません。

LogEasy は、Linux、Windows、AIX、HPUX などのさまざまなプラットフォームでのデータ収集をサポートしています。ODBC、Syslog、APM、さらにはモバイル アプリ データからもデータを収集できます。その後、一部の CMDB データとプロセス作業指示データを組み合わせることで、業務運用および保守レベルでの相関分析を簡単に実現できます。

取り込み後、ログを正規化するための ETL メソッドが数十種類あります。ログ自体は構造化されていませんが、ログ分析にはフォーマットされたデータが必要です。ETL が完了すると、その後の分析が簡単に実行できます。

このステップには、データの感度低下とビジネス ログの連結が含まれます。タイムスタンプの設計が不合理な一部のログについては、LogEasy が自動的に完了し、その後の分析を容易にします。

データを検索する場合、業界で主流のオープンソースソリューションは ES です。しかし、ESオープンソースエンジンは一般的な検索エンジンであるため、ログ処理のいくつかの特殊な要件を満たすことは困難です。Javaで開発されており、メモリ消費とパフォーマンスの最適化の余地が大きく、大量のログデータに直面すると、ESは対応できないことがよくあります。

上記の理由に基づき、Logeasy は独自の Beaver 検索エンジンを開発しました。これは一般的なエンジンよりも 5 倍以上高速で、膨大なデータへのリアルタイム アクセスを保証します。また、さまざまなシナリオに対応するアルゴリズムを備えた統計分析用の SPL 命令も数百種類あります。検索エンジンは AIOps の頭脳とも言えます。

当社では、インテリジェントログセンター「LogEasy」をはじめ、ログをベースに開発されたインテリジェント運用保守アプリケーション「Lynxee」、大画面「Galaxee」、データファクトリーなどを展開しています。セキュリティ監査やビジネス相関分析などのソリューションもインテリジェント ログ センターをベースとして実装されます。

インテリジェントログセンターは、大画面ディスプレイ、アラームプッシュ、オンデマンドスクリプト実行、パブリックデータAPI、サードパーティプラットフォームと接続することができ、この部分はAIOpsの手腕と言えます。

上記のすべてが一緒になってインテリジェント ログ センター全体を形成し、これは AIOps の中央制御 (または中間プラットフォーム) とも見なすことができます。

LogEasy には、Cisco、F5、Topsec などの各種ネットワーク機器ログ、Oracle、MySQL などのデータベース ログ、Nginx、Apache などのミドルウェア ログなど、直接インポートしてインストールできる数百種類のデータ収集および分析ソリューションがあります。これらの組み込みのデータ収集および分析ソリューションにより、データの収集と処理にかかる時間を節約できます。

実際には、データセンターの運用と保守では、データの収集と処理に 70% 以上の時間が費やされていることがわかりました。実際に処理されると、分析プロセスは依然として非常に高速です。これは、人工知能作業の 80% がデータクリーニングであるという AI の定義と一致しています。

2. ログに関する AIOps シナリオとアルゴリズムの原理の紹介

2.1AIOpsシナリオ

AIOps シナリオに関しては、次の図に示すように、コスト、品質、効率の 3 つの側面から計画を立てることができます。

品質保証の観点では、これまでの異常検知は運用保守エンジニアが自らの経験に基づいて判断・分析する必要がありましたが、これを実現するためにはAIを活用する必要があります。

障害の発生には常に前兆があり、遅延が徐々に増加したり、応答が徐々に遅くなったりして現れることがあります。これらの前兆と履歴データに基づいてモデルを作成し、差し迫った異常を予測することができます。

コスト管理や効率改善において直面する状況はより複雑です。コスト管理では、コストの最適化、リソースの最適化、容量計画、パフォーマンスの最適化などの複雑なシナリオに直面します。

効率改善には、高度に複雑なインテリジェントな変更、インテリジェントな質問と回答、インテリジェントな決定、容量予測などが含まれます。 Double Eleven の容量予測を例にとると、履歴データに基づいてトラフィックを推定し、ビジネス要因 (プロモーション活動による増加など) に基づいて包括的な分析を行う必要があります。それでも、見積もりは現実とは大きく異なることがよくあります。

現段階では、品質保証は依然として最も重要かつコスト効率の高い部分であり、インテリジェントに実現できる最初の部分です。当社のインテリジェントログセンターは現在、この方向に注力しています。

具体的には、品質保証の観点から、運用・保守担当者が望んでいるのは、できるだけ早く警告を発し、できるだけ早く問題を特定し、できるだけ早く修復することです。 「ログ+アルゴリズム」のAIOps実践では、具体的なプロセスは次の3つのステップです。

1. 迅速な障害検出：複数のアルゴリズムに基づく異常予測。

2. 問題の属性と場所: つまり、ログ モードを通じてまれなエラー メッセージを把握します。

3. 修復の意思決定を支援: システムの状態を複数の視点から表示することで意思決定を迅速化します。

2.2AIOps: 迅速な障害検出

障害を迅速に発見し、できるだけ早くアラームを発します。アラームの本質は、運用および保守担当者に 2 つのことを伝えることです。1 つ目は、問題があること、2 つ目は、問題の深刻度です。

ログから直接アラートを生成したり、統計分析を通じてログを時系列指標に変換したりして、アラートを監視します。アラームの優先度と重要度を統合することで、サービスの健全性が調整され、ユーザーはシステムの状態を一目で把握できるようになります。

一般的に、監視システムには 2 種類のアラームがあります。1 つはキーワードの一致、もう 1 つはサンプリング指標のしきい値比較です。一致するキーワードの重大度は、警告、重大などと一致します。しきい値の重大度は、CPU が 80% を超えた場合に中リスクのアラーム、120% を超えた場合に高リスクのアラームなど、複数のしきい値間隔を定義します。インテリジェント ログ センターでは、両方のタイプのアラームがサポートされています。

LogEasy には、ログや時系列インジケーターの監視とアラームからサービスの健全性や障害箇所まで、完全な監視プロセス セットが備わっています。これは、インテリジェント ログ センターの重要な部分であり、エンジンの上位層にあります。アラーム部分は依然として主に品質保証と AI アルゴリズムに基づいています。

2.3AIOps の問題の属性と場所

2.3.1 指標異常検出

「SRE」は近年非常に人気の高い書籍です。その中には、いわゆる「ゴールデンインジケーター」と呼ばれる、お勧めする価値のある概念があります。

ホスト デバイス レベル、アプリケーション サービス レベル、クラスター、エンドツーエンドなど、その健全性状態は、レイテンシ、トラフィック、エラー、飽和度の 4 つの最も重要な角度から測定できます。

Logeasy では、SPL ステートメントを使用して、さまざまなログ データを対応するインジケーター データにすばやく変換できます。包括的なインジケーター データ カバレッジを実現するには、赤のフィルター条件を変更するだけで済みます。

指標データが得られたので、次のステップは、過去の状況に基づいて問題をインテリジェントに発見できるように、指標をインテリジェントに検出する方法を検討することです。

指標は多岐にわたるため、単一の普遍的なアルゴリズムを持つことは困難です。したがって、LogEasy では、さまざまなシナリオのニーズを満たすためにさまざまなアルゴリズムを使用できます。以下は、いくつかのアルゴリズムの原理の簡単な紹介です。

CVAEアルゴリズム

VAE がディープラーニングの一種であることは誰もが知っています。一般的に、インターネットでこのアルゴリズムの説明を検索すると、すべて画像認識の方法について説明しています。

この指標は非常に単純な曲線なので、この曲線をスライディング ウィンドウの形で小さな曲線に分割し、それらを組み合わせて特徴マトリックスを形成します。次に、多層エンコードとデコードを入力し、繰り返し反復して、より優れたモデルを取得します。

効果を高めるために、トレーニング データにいくつかのノイズ エラーを積極的に追加することもできます。

そして、実際のテストでは、テストデータをエンコードおよびデコードして得られた小さなシミュレートされた曲線の分布を実際のデータと比較し、重大な偏差があるかどうかを確認します。シミュレートされた曲線は正規分布しているので、この偏差は 3Sigma です。

このアルゴリズムは、強い周期性を持つ指標を検出するのに非常に適しています。一般的に言えば、ビジネス訪問など、多数の人々の行動によって生成されるデータは非常に適しています。

この分野でも、時間機能の処理を強化するという革新が起こっています。人間の行動には必ず大小さまざまな周期があることがわかっています。今日と昨日、今週の月曜日と先週の月曜日、毎月1日、毎年の春節、毎年の6月18日と重陽など、これらはすべてアルゴリズムによって学習され、重点的に強化される行動です。

iForestアルゴリズム

2 つ目は iForest アルゴリズムです。これは、異常検出に特化して使用されるランダム フォレスト アルゴリズムのバリエーションです。

これは、ホストの CPU、メモリなど、時間と強く相関していない一部の指標に適しています。データ自体は非常に離散的で、規則性はありません。主な懸念事項は、データに明らかな逸脱がないことです。

この種の指標は数多くあり、アルゴリズムが十分迅速に検出する必要があります。

KDE アルゴリズム

3 つ目は、特殊なタイプのシナリオを対象とする KDE アルゴリズムです。

一部のサービスは24時間年中無休で運営されていないことを理解しています。たとえば、株式市場は毎日午前 9 時に開き、午後 5 時に終了します。市場が閉まっているときは、証券会社の関連システムの営業指標は完全にゼロになります。終了段階と開始段階は明確に区別されており、通常のアルゴリズムでは、この 2 つの遷移の瞬間にほぼ確実に誤報が発生します。

同様に、財務管理など金融の場面も多く、週末の2日間は業務のアウトプットがないことも事実です。

そのため、各日の各時点の周囲で、その日の次元に応じていくつかのポイントを選択し、セットを形成してカーネル密度分析を実行し、その日のすべてのポイントを組み合わせて最終的な KDE モデルを取得します。

このモデルは、3D マップ上に無数の正規分布が積み重なって形成される山々に似ています。そのため、検査時に、時間に対応する値が平らな領域に表示された場合は、明らかに異常です。

GRBTアルゴリズム

GRBT アルゴリズムでは、時系列データの統計的特徴とタイムスタンプの特徴を同時に抽出します。 KDE や iForest と比較すると、その使用シナリオはより広範囲で、変異とビジネス目的の両方に使用できます。

どちらも決定木フォレストであるため、このアルゴリズムの原理は以前の iForest と似ていることがわかります。ただし、iForest は毎回部分的なサンプリング反復を実行しますが、Boosting は前回の反復の結果に基づいて毎回カットオフ ポイントを再選択します。

ただし、これは教師あり学習です。これをうまく活用するには、トレーニング サンプルに特定の異常ポイントをマークしておく必要があります。

さまざまなシナリオには、さまざまなアルゴリズムが存在します。運用および保守担当者は、実際の違いに基づいてさまざまなアルゴリズムを選択することで、より優れたアルゴリズム カバレッジを実現できます。

Logeasyでは、今後も運用保守構成選択アルゴリズムの作業負荷を最小限に抑えるため、指標データタイプの自動判定の研究を進めていきます。

2.3.2 ログ異常検出

指標の異常に加えて、ログの異常もあります。前述したように、最も一般的なログアラートはキーワードの一致です。しかし、ほとんどのシステム開発者は、そのような標準化された方法でログを書き込みません。

2016年、中国科学院の『ソフトウェアジャーナル』は、国立国防科学技術大学の「大規模ソフトウェアシステムログに関する研究レビュー」と題する論文を掲載し、国内外の多くの調査と分析を引用した。興味深いデータがいくつかあります:

ログコードは他のコードの約 2 倍の頻度で更新されます。

ログ変更の約 4 分の 1 は、ログに新しいプログラム変数を書き込むことを伴います。

ログ変更の約半分は、ログ メッセージの静的テキストの変更です。

これらの研究は、一般的に Hadoop、OpenStack などの大規模な分散プロジェクトに基づいています。企業内のシステム開発の状況は、これらの有名なプロジェクトよりもはるかに深刻なはずです。そのため、人がログを出力する場合、特に標準化することが難しく、ログの形式が変わることも多々あります...

したがって、キーワードや固定の正規表現の抽出に頼るだけでは、長期的なシナリオでログの異常を検出するには不十分です。現時点では、AI アルゴリズムの支援が必要です。

ログパターンを取得するための階層的クラスタリング

Logeasyのアイデアは、階層的クラスタリングを使用することです。

まず、ログに対して最も基本的な単語分割とタイプ判定を実行し、それらをクラスタ化してマージします。クラスタリングは、最長の部分文字列、テキストの頻度などを使用して実行できます。クラスタリングでは、さまざまな部分がワイルドカードに置き換えられます。この図と同様に、8 つのログは最初に 4 つのログ形式にマージされ、次に 2 つにマージされ、最後に 1 つにマージされます。

研究分野では、一般的にこのログ形式のツリー構造をパターンツリーと呼びます。

もちろん、練習するときには、本当に上限まで計算する必要はありません。一般的に言えば、パターンの数が同様の割合で収束したとき、またはパターン内のワイルドカードの数が同様のときに停止できます。

ログモードの使用

ログモードを取得します。具体的にどのように使用しますか?一般的に言えば、障害箇所特定と異常検出の 2 つの用途があります。

障害箇所

1つは障害箇所を特定するときです。たとえば、キーワードのみを使用してエラー ログを確認すると、数百または数千のエントリが表示される場合があります。一つずつ読んで、何ページもめくらなければならないとしたら、かなり時間がかかります。コンテンツに多くの単語が含まれている場合、見逃してしまう可能性があります。

パターンツリーの情報は、キーワードに一致するログのパターンを直接表示できます。情報は3つまたは5つしかない場合もあり、一目で読み取ることができます。どこに問題があるのか​​をすぐに把握し、次のステップに進むことができます。

異常検出

もう一つの用途としては、取得したデータをログ収集のリアルタイム処理フローに読み込んで異常検知を行い、問題を事前に発見することです。このとき、パターンに加えて、パラメータや割合も検出できます。

上の図は最も単純な例です。ログは 3 つあり、パターンは *are<NUM> です。このパターンに一致するログも検出できます。最初の数字は we または you のみで、3 番目の数字は平均 93.3、標準偏差 9.4 の正規分布区間内にのみ収まります。

次に、ログを収集し、パターンが正当かどうかを確認します。合法である場合は、各パラメータ位置の値が合法かどうかを確認します。まだ合法である場合は、この期間中のこのモードのログの数をチェックして、以前と比較して正常かどうかを確認します。

これら 3 つの検出レベルは、パターン異常、数値異常、時系列指標異常を統合することと同等です。

このスクリーンショットは、ログ異常検出の履歴リストです。ご覧のとおり、INFO レベルでも、これまで見たことのない奇妙なログが存在する可能性があり、細心の注意が必要です。

もちろん、ログの量が非常に多いため、トレーニング サンプルではいくつかの通常の状況が簡単に見逃される可能性があります。そのため、オンライン化の初期段階では、反復的なアノテーション最適化プロセスが必要になります。初期サンプルを継続的に強化します。

これまで、AI アルゴリズム、つまり異常を検出し、異常を特定する方法について多くのことを話してきました。残念ながら、現時点では、理想的な根本原因を見つけるまで異常を特定するのは非常に困難です。特定のマシンの問題を特定するには、クラウド プラットフォームやコンテナ プラットフォームのインジケーター コレクションに頼るのが一般的であり、分析のためにはマシンにログインする必要があります。

ログの観点から、特定のマシンのログセクションに問題があることがわかりますが、根本原因を100%特定できておらず、さらにクエリと分析が必要です。

したがって、インテリジェント ログ センターを構築するには、より包括的な統計分析と高速クエリ機能も提供して、グローバルかつ詳細な動作状況の監視を完了し、変更をリアルタイムでキャプチャする必要があります。

3. ログ分析の実践とケーススタディ

3.1 ビジネストランザクションのリアルタイム統計分析

前述のVAEアルゴリズムに対応しており、ビジネス取引量などの指標を監視するのに最適であると言えます。

ダッシュボードの視覚化効果を利用して、ビジネス取引量のさまざまな側面について非常に詳細な統計分析を実行できます。こうすることで、変更があった場合に一目で確認できます。

もちろん、取引分析の共通ディメンションは比較的少なく明確であるため、決定木アルゴリズムを使用して、特定の省の特定のオペレータの特定の携帯電話モデルがゆっくりとオープンするなど、より明らかな変化を引き起こしたディメンションを自動的に特定できます。

実際には、パフォーマンス最適化のための根本原因分析が見つかったとしても、その後の最適化コストが比較的高く、費用対効果を考慮して断念される可能性が高くなります。

取引量インジケーターは主に、このようなリアルタイムの統計と監視に使用されます。

3.2 ビジネスモニタリング - 多層ビジネス指標の掘り下げ

より複雑なビジネス構造のシナリオでは、エンドユーザー レベルでトランザクション ディメンションを確認するだけでは、障害を特定するのに十分ではない可能性があります。また、内部の業務フローの関係の観点からも問題を調査する必要があります。このとき、トポロジー図を使用してシステムの動作状態を観察することができます。

稼働状態に異常が発生した場合、各層の状況と調査経路をドリリングとジャンプにより直列に接続します。非常に基本的な運用および保守担当者であっても、上級エンジニアが定義したパスに従って問題を巧みにトラブルシューティングできます。

3.3 ビジネスモニタリング - コールチェーン表示分析

ビジネス分析のもう 1 つのレベルは、現在普及している Tracing コール チェーン システムに似た、ユーザー指向の分析です。

トレースデータもインテリジェント ログ センターによって適切にサポートされます。これを基に、非常に優れた表示を実現できます。

Logeasy は、標準の呼び出しチェーン テーブルとシーケンス図分析を提供します。これは業界では比較的珍しい手法ですが、シーケンス図は研究開発担当者がシステムを設計する際に非常に馴染みのある手法であるため、研究開発担当者にとっては非常に使いやすいものです。

3.4 ユーザー側の監視 - DNS/CDN ログ分析

システムに加えて、DNS および CDN ベンダーからログを取得したり、独自のモバイル アプリ ログを収集して、エンドツーエンドの状況を把握および監視したりすることもできます。

上記スクリーンショットは、10TB レベルのログボリュームのリアルタイムのリターンコード傾向分析、各サイトのキャッシュレート分析、各サイトの応答時間分析、トラフィックピーク分析、さらにユーザー行動の軌跡分析、高頻度リクエスト顧客分析、人気サイト分析、ドメイン名とオペレーターの関係分析などを示しています。

さらに、これらのログに基づいてパフォーマンス監視やトラブルシューティングを実現できるほか、サードパーティメーカーへの課金による二次課金も実行できます。