🛐 📅 🕜 Kaleは、異常を検出して相関させるためのオープンソースツールです。 ⛹🏿 🧒🏼 👞

ITインフラストラクチャを監視するには、次のような多くのツールを使用します。

Zabbix-ハブで彼について多くの記事が書かれています低レベルの検出機能は非常に気に入っていますが、データの視覚化機能は貧弱です。
グラファイトはデータを保存するシステムであり、データを表示するための便利なインターフェースを備えています。次に、Zabbixからメトリックをインポートして、履歴を保存します。
Shinkenは、Nagiosに基づいており、Pythonで記述された監視システムです。今、私たちは彼女を見ています。 Netdotネットワークドキュメンテーションシステムからデータをインポートするのは非常に簡単で（前に書きました）、Graphiteと簡単に統合できることも気に入っています。

さまざまな監視システムの長所/短所について長い間議論することは可能ですが、私はただ一つの問題、つまり異常の特定に専念したいと思います。監視システム内のメトリックの数が数百単位で測定される場合、1つ以上のメトリックの異常な動作を追跡することは難しくありません。しかし、メトリックの数が数万または数十万単位で測定される場合、異常を自動的に検出する問題が重要になります。管理者または管理者グループは、何百ものデバイスからなる複雑なシステムの動作を手動で追跡できません。

Etsyエンジニアはかつてこの問題に遭遇し、異常を検出して相関させる独自のツールを開発しました。 ケールと呼ばれ、2つの部分で構成されています。

各部分をより詳細に検討してください。

スカイライン

Skylineは、リアルタイムの異常検出システムです。数十万のメトリックを受動的に監視するために作成されたもので、各メトリックにしきい値を設定する必要はありません。これは、監視システムでトリガーしきい値を手動で設定する必要がないことを意味します。システムは、入力されたデータを自動的に分析し、それに組み込まれたいくつかのアルゴリズムに基づいて、このデータの「異常な性質」について決定します。

スカイラインはいくつかのコンポーネントで構成されています。

地平線

Horizonは、データの収集を担当するコンポーネントです。 pickle（TCP）とMessagePack（UDP）の2つの形式のデータを受け入れます。

したがって、次のチェーンを構成できます。監視システムは、「metric_name time_stamp_value」の形式でデータをGraphiteに送信します。グラファイト側では、カーボンリレーが機能し、ピクルスデータがHorizonに送信されます。次に、Horizonはデータを受信した後、それを処理し、MessagePackを使用してエンコードし、Redisに送信します。または、監視システムを構成して、データをHorizonに直接送信し、MessagePack形式で事前にエンコードすることができます。さらに、最新のプログラミング言語のほとんどの言語には、 MessagePackを操作するためのモジュールがあります。

また、Horizonは古いメトリクスを定期的にトリミングおよび削除します。これを行わないと、すべての空きメモリがすぐに使い果たされます。

設定では、無視されるメトリックのリストを指定することもできます。

レディス

Redisは別のコンポーネントですが、Skylineはそれなしでは機能しません。その中に、彼はすべてのメトリックとエンコードされた時系列を保存します。

このソリューションには長所と短所があります。一方では、RedisはすべてのデータがRAMに保存されるため、高いパフォーマンスを発揮します。データは「キー-値」の形式で保存されます。キーはメトリックの名前で、値はそれに対応するエンコードされた時系列です。一方、Redisは非常に長いラインで貧弱な仕事をしています。文字列が長いほど、パフォーマンスは低下します。実践が示しているように、1日/ 2日以上データを保存することは意味がありません。ほとんどのシステムでは、データには1時間ごと、1日ごと、1週間ごと、1か月ごとの頻度があります。ただし、数週間または数か月間データを保存すると、Redisのパフォーマンスは非常に低くなります。この問題を解決するには、たとえばredis-timeseriesライブラリなどを使用して、時系列を保存する別の方法を使用できます。

アナライザー

アナライザー-このコンポーネントはデータ分析を担当します。 Redisからメトリックの一般リストを受け取り、いくつかのプロセスを開始します。各プロセスは独自のメトリックを割り当てます。各プロセスは、いくつかのアルゴリズムを使用してデータを分析します。アルゴリズムは1つずつ、メトリックを分析して結果を報告します-メトリックは異常であるかどうか。それらのほとんどが、メトリックに現在異常があると報告した場合、それは異常と見なされます。 1つまたは複数のアルゴリズムのみが「投票」された場合、異常はカウントされません。設定でしきい値を指定できます-メトリックが異常として分類される前に動作する必要があるアルゴリズムの数。デフォルトでは、6です。

現在、次のアルゴリズムを実装しています。

平均偏差（平均絶対偏差）;
グラブスのテスト
最初の1時間の平均（最初の1時間の平均）。
平均からの標準偏差。
移動平均からの標準偏差。
最小二乗法;
ヒストグラムの外れ値（ヒストグラムのビン）;
コルモゴロフ同意基準（K – Sテスト）。

それらのほとんどは、コントロールカードと3シグマのルールに基づいています。この記事の最後にビデオが投稿されているレポートから、いくつかのアルゴリズムの動作原理について学ぶことができます。また、Anton Lebedevich-mabrek.github.ioのブログの資料に精通することをお勧めします。また、Skylineの開発にも貢献しています。

アルゴリズムは、新しいものをカスタマイズ、変更、削除、または追加できます。それらはすべて、1つのalgorithm.pyファイルに収集されます。計算では、 SciPyおよびNumPyライブラリを使用します。最後については、Habrに関する良い記事があります。

異常なデータに加えて、データ分析の結果として次のステータスも割り当てることができます。

TooShort ：時系列が短すぎて結論を出すことができません。
不完全 ：時系列の秒単位の長さが、設定で指定された全期間（通常86400秒）よりも短い。
古い：時系列は長い間更新されていません（秒単位の時間は設定で設定されています）。
退屈：時系列の値はしばらくの間変更されていません（設定で設定）。

Webアプリケーションで画像が形成されるデータに基づいて、すべての異常なメトリックがファイルに分類されます。

Analyzerは通知も送信できます。現在利用可能な目標は、mail、 HipChat 、 PagerDutyです。

フラスコwebapp

異常なメトリックを表示するには、Flaskフレームワークを使用してPythonで作成された小さなWebアプリケーションが使用されます。これは非常に簡単です。上部には、過去1時間と2日の2つのグラフが表示されます。グラフの下には、すべての異常なメトリックのリストがあります。メトリックの1つにカーソルを合わせると、グラフの図が変わります。クリックすると、Oculusウィンドウが開きます。これについては後で説明します。

オクルス

Oculusは異常の相関関係を検索し、Skylineと連動して機能します。 Skylineが異常を検出し、Webインターフェイスに表示すると、異常なメトリックの名前をクリックすると、Oculusは元のメトリックと相関するすべてのメトリックを表示します。

簡単に説明すると、検索アルゴリズムは次のように説明できます。最初に、一連の初期値、たとえば一連の形式[960、350、350、432、390、76、105、715、715]が正規化されます。最大値が求められます-25に対応し、最小値が0に対応します。したがって、データは0から25までの整数の制限で比例配分されます。その結果、 [25、8、8、10、9、0、1、18、18]の形式の一連のデータが得られます。次に、正規化されたシリーズは、 sdec （シャープダウン）、 dec （ダウン）、 s （正確）、 inc （アップ）、 sinc （シャープアップ）の5ワードを使用してエンコードされます。結果は[sdec、flat、inc、dec、sdec、inc、sinc、flat]の形式のシリーズです。

次に、ElasticSearchを使用して、元のフォームに類似したすべてのメトリックが検索されます。 ElasticSearchのデータは次のように保存されます。

{ fingerprint: dec sinc dec sdec dec sdec sinc values: 13.18 12.72 14.8 14.43 12.95 12.13 6.87 9.67 id: mini.Shinken_server.shinken.CPU_Stats.cpu_all_sys }

最初に指紋検索が実行されます。結果はサンプルであり、メトリックの数は合計数よりも桁違いに少なくなります。さらに、分析には、値を使用する高速動的時間変換（FastDTW）アルゴリズムを使用します。 FastDTWアルゴリズムに関する良い記事があります。

その結果、見つかったすべてのメトリックから元のデータと相関するデータを取得します。

Redisからデータをインポートするには、Rubyで記述されたスクリプトが使用されます。プレフィックス「mini」を持つすべてのメトリックを取得し、それらをデコードし、正規化してElasticSearchにエクスポートします。更新およびインデックス作成中に、ElasticSearch検索の速度が低下します。したがって、結果を長時間待たないために、Oculusが定期的に切り替える別のクラスターの2つのElasticSearchサーバーが使用されます。

グラフを検索して表示するには、Sinatraフレームワークを使用するWebアプリケーションを使用します。メトリックの名前で検索するか、特別なフィールドに曲線を描くだけで検索できます。

その結果、表示されるページが表示されます。

検索パラメーターに関する情報。
元のグラフのエンコードされた表現。
データが以前に保存されたデータと相関する場合、コレクションのリスト（以下を参照）。
検出されたグラフのリスト。相関スコアの昇順で並べ替えられます（スコアが小さいほど、相関するデータが多くなります）。

データをフィルター処理したり、 コレクションにグループ化したり、説明を加えたり、メモリに保存したりできます。 コレクションは、次の場合に使用されます。何らかの異常を検出し、この現象を確認するグラフのリストを取得したとします。これらのグラフを保存し、詳細な説明を付けると便利です。現在、同様の問題が将来発生した場合、Oculusはこのコレクションを見つけ、前述の説明は特定された問題を排除する原因と方法を理解するのに役立ちます。

以下の図は、ケールの操作図を示しています。

インストールと構成のプロセスは、それほど複雑ではなく、 SkylineおよびOculusのドキュメントに記載されているため、説明しません。

現時点では、システムをテストモードで起動しました。すべてのコンポーネントが1つの仮想マシンで動作します。ただし、かなり弱い構成（Intel Xeon E5440、8 Gb RAM）でも、問題のないシステムはリアルタイムで1万以上のメトリックを分析します。操作の主な難点は、異常を検出するためのパラメータを設定することです。第2種のエラー（偽陰性）はまだ発生していませんが、第1種のエラー（偽陽性）では、アルゴリズムを定期的に満たし、ニーズに合わせてカスタマイズしようとします。主な問題は、データの季節性です。季節性を考慮したHolt-Wintersの方法がありますが、いくつかの欠点があります。

1つのシーズンのみが考慮されます（実際のデータでは、複数のシーズンが存在する可能性があります-時間、日、週、年）。
数シーズンにわたってより多くのデータが必要です（したがって、この方法はSkylineには適用されません-Redisデータベースの行のサイズが大きすぎます）。
異常の場合、将来のシーズンでは徐々に減衰して考慮されます。

そのため、特に季節データを考慮して、異常を検出するためのアルゴリズムを開発する問題は未解決のままです。

参照資料

github.com/etsy/skyline

github.com/etsy/skyline/wiki

https://groups.google.com/forum/#!forum/skyline-dev

github.com/etsy/oculus

mabrek.github.io

映像

このビデオは、開発者のケールである阿部スタンウェイによるプレゼンテーションを特徴としています。

Velocity ConferenceでのJon CowieとAbe Stanwayによるレポートで、彼らは彼らの発案について話します-

スピーチの2番目の部分。

アントン・レベデビッチによる報告「負荷テストと生産における異常の検索のための実際の統計学」

Kaleは、異常を検出して相関させるためのオープンソースツールです。