Elastic Stack (別名 Elasticsearch、別名 ELK) での機械学習を理解する

Elastic Stack は、非リレーショナル Elasticsearch データベース、Kibana Web インターフェイス、データ コレクターおよびプロセッサ (最も有名な Logstash、さまざまな Beats、APM など) に基づいていることを思い出してください。 リストされている製品スタック全体への優れた追加機能の XNUMX つは、機械学習アルゴリズムを使用したデータ分析です。 この記事では、これらのアルゴリズムが何であるかを理解します。 猫の下でお願いします。

機械学習はシェアウェア Elastic Stack の有料機能であり、X-Pack に含まれています。 使用を開始するには、インストール後に 30 日間の試用版をアクティブ化するだけです。 試用期間の有効期限が切れたら、サポートをリクエストして期間を延長したり、サブスクリプションを購入したりできます。 サブスクリプションのコストは、データ量ではなく、使用されるノードの数に基づいて計算されます。 いいえ、もちろん、データ量は必要なノードの数に影響しますが、それでも、このライセンスのアプローチは、企業の予算との関係でより人道的です。 高い生産性が必要ない場合は、コストを節約できます。

Elastic Stack の ML は C++ で書かれており、Elasticsearch 自体が実行される JVM の外部で実行されます。 つまり、プロセス (ちなみに、これは自動検出と呼ばれます) は、JVM が飲み込まないすべてのものを消費します。 デモスタンドでは、これはそれほど重要ではありませんが、実稼働環境では、ML タスクに個別のノードを割り当てることが重要です。

機械学習アルゴリズムはXNUMXつのカテゴリに分類されます- сучителем и 先生なしで。 Elastic Stack では、アルゴリズムは「教師なし」カテゴリに属します。 による このリンク 機械学習アルゴリズムの数学的装置を見ることができます。

分析を実行するために、機械学習アルゴリズムは Elasticsearch インデックスに保存されているデータを使用します。 Kibana インターフェイスと API の両方から分析用のタスクを作成できます。 Kibana を通じてこれを行う場合、いくつかのことを知る必要はありません。 たとえば、アルゴリズムが動作中に使用する追加のインデックスなどです。

分析プロセスで使用される追加のインデックス.ml-state — 統計モデル (分析設定) に関する情報。
.ml-anomalies-* — ML アルゴリズムの結果。
.ml-notifications — 分析結果に基づく通知の設定。

Elasticsearch データベースのデータ構造は、インデックスとそこに保存されているドキュメントで構成されます。 リレーショナル データベースと比較すると、インデックスはデータベース スキーマと比較でき、ドキュメントはテーブル内のレコードと比較できます。 この比較は条件付きであり、Elasticsearch についてしか聞いたことがない人がさらなる内容を理解しやすくするために提供されています。

API を通じても Web インターフェイスを通じて同じ機能を利用できるため、概念を明確にし理解するために、Kibana を通じて設定する方法を説明します。 左側のメニューには、新しいジョブを作成できる「機械学習」セクションがあります。 Kibana インターフェイスでは、以下の画像のようになります。 ここで、各タイプのタスクを分析し、ここで構築できる分析のタイプを示します。

単一メトリック - XNUMX つのメトリックの分析、マルチ メトリック - XNUMX つ以上のメトリックの分析。 どちらの場合も、各メトリクスは隔離された環境で分析されます。 マルチ メトリックの場合のように、このアルゴリズムでは、並列分析されたメトリックの動作は考慮されていません。 さまざまな指標の相関関係を考慮して計算を実行するには、母集団分析を使用できます。 また、アドバンストでは、特定のタスク向けに追加オプションを使用してアルゴリズムを微調整しています。

単一のメトリック

ここで実行できる最も簡単な方法は、XNUMX つのメトリックの変化を分析することです。 「ジョブの作成」をクリックすると、アルゴリズムが異常を探します。

フィールドで アグリゲーション 異常を検索するアプローチを選択できます。 たとえば、次のようなとき 最小値 典型的な値を下回る値は異常とみなされます。 食べる 最大、高平均、低、平均、個別 その他。 すべての機能の説明が見つかります リンク.

フィールドで フィールド は、分析を実行するドキュメント内の数値フィールドを示します。

フィールドで バケットスパン — 分析が実行されるタイムライン上の間隔の粒度。 自動化を信頼することも、手動で選択することもできます。 下の画像は粒度が低すぎる例です。異常を見逃してしまう可能性があります。 この設定を使用すると、異常に対するアルゴリズムの感度を変更できます。

データの収集期間は、分析の有効性に影響を与える重要な要素です。 分析中、アルゴリズムは繰り返し間隔を特定し、信頼区間 (ベースライン) を計算し、異常 (メトリクスの通常の動作からの異常な逸脱) を特定します。 たとえば:

小さなデータのベースライン:

アルゴリズムが学習するものがある場合、ベースラインは次のようになります。

タスクの開始後、アルゴリズムは標準からの異常な逸脱を判断し、異常の確率に従ってそれらをランク付けします (対応するラベルの色が括弧内に示されています)。

警告（青）：25未満
マイナー(黄色): 25-50
メジャー（オレンジ）：50-75
クリティカル(赤): 75-100

以下のグラフは、見つかった異常の例を示しています。

ここには、異常の可能性を示す 94 という数字が表示されます。 値が 100 に近いため、異常があることは明らかです。 グラフの下の列は、そこに表示されるメトリクス値の 0.000063634% という軽蔑的に小さな確率を示しています。

異常の検索に加えて、Kibana で予測を実行できます。 これは、異常と同じビューから簡単に実行できます - ボタン 予想 右上隅にあります。

予測は最大 8 週間先まで行われます。 本当にそうしたいと思っていても、設計上それはもう不可能です。

状況によっては、たとえばインフラストラクチャ上のユーザー負荷を監視する場合など、予測が非常に役立ちます。

マルチメトリック

Elastic Stack の次の ML 機能に進み、XNUMX つのバッチで複数のメトリクスを分析します。 ただし、これは、あるメトリックと別のメトリックの依存関係が分析されることを意味するものではありません。 これは単一メトリックと同じですが、XNUMX つの画面に複数のメトリックが表示され、あるメトリックが別のメトリックに与える影響を簡単に比較できます。 あるメトリクスの別のメトリクスへの依存関係の分析については、「人口」セクションで説明します。

マルチメトリックの四角形をクリックすると、設定を含むウィンドウが表示されます。 それらをさらに詳しく見てみましょう。

まず、分析とデータ集計の対象となるフィールドを選択する必要があります。 ここでの集計オプションは単一メトリクスの場合と同じです(最大、高平均、低、平均、個別 その他）。 さらに、必要に応じて、データはフィールドの XNUMX つに分割されます (フィールド 分割データ）。 この例では、これをフィールドごとに実行しました 出発地空港ID。 右側のメトリクス グラフが複数のグラフとして表示されていることに注目してください。

フィールド 重点分野（インフルエンサー） 検出された異常に直接影響します。 デフォルトでは、ここには常に少なくとも XNUMX つの値があり、さらに値を追加できます。 アルゴリズムは分析時にこれらのフィールドの影響を考慮し、最も「影響力のある」値を表示します。

起動後、Kibana インターフェイスに次のようなものが表示されます。

これはいわゆる各フィールド値の異常のヒート マップ 出発地空港IDで示した 分割データ。 単一メトリックと同様に、異常な偏差のレベルを色で示します。 たとえば、ワークステーション上で同様の分析を実行すると、疑わしいほど多数の承認を持つワークステーションなどを追跡すると便利です。 すでに書きました EventLog Windows の不審なイベントについて、ここで収集して分析することもできます。

ヒート マップの下には異常のリストがあり、それぞれから [単一メトリック] ビューに切り替えて詳細な分析を行うことができます。

人口

異なるメトリクス間の相関関係の異常を探すために、Elastic Stack には特殊な人口分析が備わっています。 これを利用すると、ターゲット システムへのリクエスト数が増加した場合などに、他のサーバーと比較してサーバーのパフォーマンスの異常な値を見つけることができます。

この図では、「Population」フィールドは、分析されたメトリックが関連する値を示しています。 この場合、それはプロセスの名前です。 その結果、各プロセスのプロセッサ負荷が相互にどのような影響を与えるかがわかります。

シングルメトリクス、マルチメトリクスの場合とは分析データのグラフが異なりますのでご注意ください。 これは、分析されたデータの値の分布の認識を改善するための設計により、Kibana で行われました。

グラフはプロセスが異常に動作したことを示しています ストレス (ちなみに、特別なユーティリティによって生成されます) サーバー上 ポイプ、この異常の発生に影響を与えた（または影響力を持つことが判明した）人物。

高機能

微調整を伴う分析。 高度な分析を使用すると、Kibana に追加の設定が表示されます。 作成メニューの「詳細」タイルをクリックすると、タブのあるこのウィンドウが表示されます。 タブ ジョブの詳細 分析の設定に直接関係しない基本的な設定があるため、意図的に省略しました。

В summary_count_field_name オプションで、集計値を含むドキュメントのフィールドの名前を指定できます。 この例では、XNUMX 分あたりのイベント数です。 で カテゴリフィールド名 変数値を含むドキュメントのフィールドの名前と値を示します。 このフィールドのマスクを使用すると、分析されたデータをサブセットに分割できます。 ボタンに注目してください 検出器の追加 前の図では。 以下はこのボタンをクリックした結果です。

ここでは、特定のタスクの異常検出機能を構成するための追加の設定ブロックを示します。 次の記事では、特定の使用例 (特にセキュリティの使用例) について説明する予定です。 例えば、 見て 分解したケースの一つ。 まれに出現する値の検索に関連して実装されます 稀な機能.

フィールドで function 特定の機能を選択して異常を検索できます。 を除外する 珍しいさらに興味深い関数がいくつかあります - 時刻 и 週の時間帯。 これらはそれぞれ、XNUMX 日または XNUMX 週間を通してメトリクスの動作の異常を特定します。 その他の分析機能 ドキュメントにあります.

В フィールド名 は、分析が実行されるドキュメントのフィールドを示します。 フィールド名別 ここで指定したドキュメント フィールドの個々の値ごとに分析結果を分離するために使用できます。 満たせば over_field_name 上で説明した人口分析が得られます。 に値を指定すると、 パーティションフィールド名、ドキュメントのこのフィールドに対して、値ごとに個別のベースラインが計算されます (値は、たとえば、サーバーの名前またはサーバー上のプロセスの場合があります)。 で 除外頻度 選ぶことができます を または なしこれは、頻繁に発生するドキュメント フィールド値を除外する (または含める) ことを意味します。

この記事では、Elastic Stack の機械学習の機能についてできる限り簡潔に説明しようとしましたが、舞台裏ではまだ多くの詳細が残されています。 Elastic Stack を使用してどのようなケースを解決できたのか、またどのようなタスクに Elastic Stack を使用しているのかをコメントで教えてください。 私たちに連絡するには、Habré の個人メッセージを使用するか、 ウェブサイト上のフィードバックフォーム.

出所： habr.com