二度と失敗しない、またはゼロから監視システムを構築する方法

2つの仮想マシン、75サイト、数万の監視マシン、数千のメトリック、2つのデータベースと1つのActiveMQキュー、Python、あらゆる種類と色のライブラリ、パンダ、numpy、dash、flask、SQL Alchemyがありました。 システムに必要なものではなかったが、コンポーネントの収集を開始した場合、停止するのが難しくなります。 私が心配したのはJavaScriptだけでした。 JSゾンビほど無力で無責任で悪質な世界は他にありません。 遅かれ早かれ、このゴミに進むことを知っていました。

二度失敗することは不可能ですが、失敗の検出に失敗するとさらに悪化します

分散システムの監視は、落とし穴があるかなり重要なタスクです。 一方、さまざまな監視タスク用の商用およびオープンソースのソリューションが非常に多数あります。 ネコの下で、なぜオープンソリューションが私たちに合わなかったのか、成功したプロジェクトと失敗したモニタリングプロジェクトの分析からわかったこと、さらに別のアラートシステムを構築することに決めた理由について。 Pythonでのデータ分析から最終的なソリューションとシステムの構築までの段階で、ほぼすべてのコンピューターサイエンスと少しのマタナにさえ出会うという、魅力的な冒険でした。



監視問題を全体として考えると、タスクは2つの主要なグループに分けられます。

• 低レベル監視-CPU、ディスク使用量ネットワーク、Javaヒープ使用量、GCサイクルなどのパラメーターによってインフラストラクチャを監視します。 ここではすべてが非常に単純であり、多くの実用的な既製のソリューションがあります。 多くの場合、単純なしきい値で十分です。 JVMの場合、鋸歯状のJavaヒーププロットに従ってプロセスの規則性を監視できます。ピーク頻度の増加は、メモリ管理と頻繁なGCサイクルの問題を示している可能性があります。
• 高レベル監視-ユーザーセッション、トランザクション、支払いなどの量などの指標としてビジネス指標（BI）または主要業績評価指標（KPI）が選択されている場合 低レベルの監視では、ビジネスロジックのレベルでシステムで発生していることを適切に反映できません。

なぜ難しいのですか？



-複雑な分散システムの監視は、それ自体がエンジニアリングの問題です

-さまざまな問題により、システムの動作が暗黙的に変更される

-1つのシステムのさまざまなメトリック

-異なるメトリックは互いに相関しています



私は大企業のテクニカルアーキテクトとして働いていますが、実稼働システムの問題をタイムリーに検出するのに問題がありました。



規制の厳しい市場で金融取引を行っています。 システムアーキテクチャはサービス指向であり、コンポーネントには複雑なビジネスロジックがあり、会社の顧客（B2B）ごとに異なるバックエンドオプションがあります。

低レベルの監視とテストは多くの問題をカバーしていません

まず、製品が非常に複雑で設定が膨大なため、設定が正しくないと財務パフォーマンスが低下したり、ロジックの隠れたバグがシステム全体の機能に影響を与えたりする場合があります。



第二に、さまざまな国向けの特定のサードパーティ統合があり、パートナーで発生する問題が私たちに流れ始めます。 この種の問題は、低レベルの監視では検出されません。 それらを解決するには、重要な指標（KPI）を監視し、システム上の統計と比較して相関関係を探す必要があります。



同社は以前、Hewlett Packard Service Health Analyzerのソリューションを実装していましたが、これは（やや）不完全でした。 マーケティングの目論見書から判断すると、これはそれ自体を学習し、問題を早期に検出するシステムです（SHAは複数のソースからデータストリームを取得し、高度な予測アルゴリズムを適用して、潜在的な問題を発生前に警告し、診断することができます）。 実際、これは設定できないブラックボックスでした。すべての問題についてHPに連絡し、サポートエンジニアが正常に機能しない動作を行うまで数か月待たなければなりませんでした。 また、ひどいユーザーインターフェース、古いJVMエコシステム（Java 6.0）、そして最も重要なことには、多数の誤検知と（さらに悪いことに）誤検知、つまり、重大な問題が検出されなかったか、必要以上に遅くキャッチされた、非常に具体的な経済的損失で表されました。



この図は、SHAの粒度が15分であることを示しています。これは、問題が発生した場合でも最小反応時間が15分であることを意味します...







つまり、多くの場合、このように見えました...

巨人の肩の上

多くの企業が監視システムの構築を試みてきました。 これらは常に成功例ではありませんでした。

Etsy-ケールシステム

Etsyは、手作り商品のオンラインマーケットプレイスです。 本社はニューヨークにあります。 同社は、サーバーから250,000以上の異なるメトリックを収集し、高度な数学的アルゴリズムを使用してメトリックの異常を探そうとしました。 しかし...



ケールに会いましょう。







Kaleの問題の1つは、システムがさまざまなテクノロジースタックを使用していたことです。 図では、4つの異なるスタックと2つのフレームワークを見ることができます。 システムを開発および保守するには、これらのスタックに精通した高度なスキルを持つエンジニアが必要でした。 バグを見つけるには、多くのスタックの知識も必要でした。



2番目の問題は、監視アプローチ自体です。 ケールは異常を探していました。 しかし、250,000個のメトリックがある場合、各ティックについて数百の異常が統計的に観察されます。 境界を広げると、問題はなくなります。 絞り込むと、大量の誤検知が発生します。



Etsyエンジニアは誤検知の数と戦おうとしましたが、3年の開発の後、プロジェクトは終了しました。 Andrew Cleggによるこのテーマに関する良いビデオがあります。



このビデオから1つのスライドをハイライトします。







異常を見つけることは、単に異常値を見つけること以上のものです。 異常値の放出は、通常の運用における実際の生産データで観察されます。 すべての異常がすべてのレベルで不安を含むとは限りません。



普遍的なアプローチは何にも適していません。 無料のランチはありません。 そのため、HPのSHAソリューションは正常に機能せず、ユニバーサルツールになろうとします。



そして興味深いことに、これらの問題を解決するための可能なアプローチ。



ビジネスの異常とユーザーメトリックに関するアラートを送信する

根本原因分析に他のメトリックを使用します。

Google SREチームBorgMon

サイト信頼性エンジニアリングの本には、Googleシステムの生産を監視する問題に関する章全体があります。 要するに、

• Googleは、ポストホック分析用の優れたツールを備えた、よりシンプルで高速な監視システムを目指しました。
• 彼らの目標は、しきい値を自動的に学習したり、相関関係を自動的に探したりする魔法のシステムを避けることでした。 人は、システムで何が起こっているか、どのルールによってアラートが生成されるかをよく理解する必要があります。
• 問題対応システムのルールは可能な限りシンプルに保たれました。 彼らは、シンプルでローカライズされた深刻な異常に対して非常に速い応答時間を与えました。
  
  
• 人は、システムで何が起こっているか、どのルールによってアラートが生成されるかをよく理解する必要があります。

Googleは、これらの原則に基づいて成功したBorgMonシステムを構築しました。

時系列

時系列は、時間でインデックス付けされた一連のデータです。 シャンペンの生産から店舗での販売やオンライントランザクションまでの経済プロセスをいくつか考えた場合、それらにはいくつかの共通の特性があります。プロセスは定期的で、周期性があり、通常は季節とトレンドラインがあります。 この情報を使用すると、分析を簡素化できます。



トランザクションの数に関する実際のデータを毎週取得します。 顕著な規則性が見られます（2つのピークはパフォーマンステストです）。 毎日の規則性に加えて、金曜日と週末にアクティビティが増加し、その後アクティビティは次の週末まで減少し始めます。







Habréでは、このテーマに関する多くの優れた資料がありました 。たとえば、 こちらです。



メディアには、時系列モデリング（英語）： 時系列モデリングの紹介があります。



簡単に言うと、各測定には信号成分と測定/ノイズ誤差が含まれます。 プロセス自体と収集されたメトリックの両方に影響する多くの要因があります。



ポイント= Sig + err



信号を記述するモデルがあります。 測定からモデルを差し引くと、モデルが信号をよりよく捉えるほど、引き算の結果が定常ノイズまたはホワイトノイズになりやすくなります。これはすでに簡単に確認できます。



メディアに関する記事で、線形回帰とセグメント回帰のモデル化の例を挙げました。



監視システムについては、平均とスプレッドの移動統計を使用したモデリングを選択しました。 移動平均は、本質的にノイズを平滑化し、メインのトレンドラインを残すローパスフィルターです。 60分のウィンドウでの移動平均（ピークが削除された）後の、別の週のトランザクション数に関するデータを次に示します。







また、移動分散を収集して、モデルの許容境界を設定します。 その結果、サルバドール・ダリから何かを得ました。







ここにもう1週間のデータを入力すると、すぐに外れ値が表示されます。







これで、アラートシステムを構築するために必要なものがすべて揃いました。

重要な余談。

ケールプロジェクトの経験は非常に重要なポイントを示しています。 すでに述べたように、ユニットメトリックの異常は常に発生するため、アラートはメトリックの異常や異常値の検索と同じではありません。



実際、2つの論理レベルがあります。



-1つ目は、メトリックの異常の検索と、異常が見つかった場合の違反の通知の送信です。 これは、情報発信のレベルです。

-2番目のレベルは、違反に関する情報を受け取り、これが重大なインシデントであるかどうかを判断するコンポーネントです。



これが、問題を検討する際の人間の行動です。 私たちは何かを見て、標準からの逸脱を見つけたら、もう一度見てから、観察に基づいて決定を下します。



プロジェクトの最初に、KapacitorにはPythonでカスタム関数を定義する機能があるため、試してみることにしました。 ただし、各関数は個別のプロセスに存在するため、数百および数千のメトリックのオーバーヘッドが発生します。 これと他のいくつかの問題により、それを拒否することが決定されました。



Pythonは、データ分析、高速ライブラリ（パンダ、numpyなど）、Webソリューションの優れたサポートのための優れたエコシステムがあるため、独自のシステムを構築するためのメインスタックとして選ばれました。 名前を付けます。



私にとって、これはPythonで完全に実装された最初の大きなプロジェクトでした。 私自身はJavaの世界からPythonに来ました。 1つのシステムの動物園スタックを増やしたくはありませんでしたが、最終的には報われました。

一般的なアーキテクチャ。

システムは、Python VMでプロセスをスピンインする疎結合コンポーネントまたはサービスのセットとして構築されます。 これは、一般的な論理パーティション（イベントエミッタ/ルールエンジン）に自然であり、他の利点もあります。



各コンポーネントは、限られた数の特定のことを行います。 将来的には、これにより、コアロジックに影響を与えたり、それを壊すことを恐れることなく、システムを迅速に拡張し、新しいユーザーインターフェイスを追加できるようになります。 コンポーネント間には、かなり明確な境界が描かれています。



分散展開は、監視するサイトの近くにエージェントをローカルに配置する必要がある場合や、多数の異なるシステムをまとめて集約する場合に便利です。



システム全体が非同期である必要があるため、通信はメッセージに基づいて構築する必要があります。

ActiveMQをメッセージキューとして選択しましたが、たとえばRabbitMQに変更する場合は、すべてのコンポーネントが標準のSTOMPプロトコルを使用して通信するため、問題はありません。







イベントストリーマは、統計モデルを保存し、特定の頻度でデータを選択し、外れ値を見つけるコンポーネントです。 それはかなり簡単です：







ワーカーは、1つのメトリックの1つのモデルとメタ情報を保存する主要な作業単位です。 コネクタの日付と、データの送信先のハンドラで構成されます。 ハンドラーは統計モデルでそれらをテストし、違反を検出した場合、イベントをキューに送信するエージェントに渡します。



ワーカーは互いに完全に独立しており、各サイクルはスレッドプールを通じて実行されます。 ほとんどの時間はI / O操作に費やされるため、グローバルインタープリターロックPythonは結果に大きな影響を与えません。 スレッドの数は構成で設定されます。 現在の構成では、最適な数は8スレッドでした。







それでは、Consumerパートに移りましょう。 コンポーネントはキュー内のトピックにサブスクライブされ、メッセージが到着すると、ティックと各サイトに関連付けられた辞書に追加されます。 システムはすべてのイベントを特定のウィンドウに保存し、新しいメッセージを受信すると、最も古いものを削除します。 辞書全体を表示しないために、キーはタイムスタンプでソートされた優先度キューに保存されます。







アーキテクチャ的には、コンポーネントは次のようになります。







各メッセージはルールエンジンに送信され、ここから楽しみが始まります。 開発の最初の段階で、コードのルールを厳密に設定しました。1つのメトリックが低下し、もう1つのメトリックが大きくなると、アラートを送信します。 しかし、このソリューションは普遍的ではなく、あらゆる拡張機能のコードを取得する必要があります。 したがって、ルールを設定する何らかの種類の言語が必要でした。 ここで、抽象構文木を思い出し、ルールを記述するための簡単な言語を定義する必要がありました。



ルールはYAML形式で記述されていますが、独自のパーサーを追加するだけで、他のルールを使用できます。 ルールは、メトリック名または単にメトリックプレフィックスの正規表現として定義されます。 速度は、メトリックの低下率です。以下を参照してください。







コンポーネントが起動すると、ルールが読み取られ、構文ツリーが構築されます。 各メッセージを受信すると、指定されたルールに従ってこのサイトからの1ティック内のすべてのイベントがチェックされ、ルールがトリガーされるとアラートが生成されます。 複数のトリガーされたルールが存在する場合があります。



時間の経過とともに発生するインシデントのダイナミクスを考慮する場合、転倒率（重大度）と速度の変化（重大度の予測）も考慮することができます。







速度は、違反ごとに計算される角係数または離散導関数です。 同じことが、2次の離散導関数である加速にも当てはまります。

これらの値はルールで設定できます。 インシデントの総合評価では、1次および2次の累積デリバティブを考慮することができます。



履歴イベントを保存するために、ORM（SQL Alchemy）を介してデータベースが使用されます



そのため、バックエンドが機能します。 ここで、システムを管理し、特定のルールで機能するメトリックについてレポートするためのユーザーインターフェイスが必要です。



私は1つのスタックで最大に留まりたかった。 そして、ここでDash dash.plot.lyが助けになります



これは、FlaskおよびPlotly用のデータ視覚化アドインフレームワークです。 インタラクティブなWebインターフェイスは、1〜2週間ではなく、数時間で作成できます。 1行のJavascriptではなく、簡単に拡張でき、出力はReactJSベースのWebUIであり、Pythonとの完全な統合です。



WebUIを介したコンポーネントの1つは、ワーカーの開始、停止、アセンブリを制御します。 ワーカーが保存されているコンポーネントの状態、計算が終了したかどうかはわからないため、すべてのAPI呼び出しはメッセージを経由します（リモートプロシージャコールオーバーメッセージング）。







別のコンポーネントがオンデマンドの動的レポートを作成します。このレポートには、このアラートに関連付けられたメトリックが含まれます。 アラートを生成すると、プロパティの1つにレポートリンクが生成されます。 また、必要に応じて、ライブストリームを受信することもできます。







また、Grafanaとの統合が完了しました。リンクをクリックしてGrafanaに移動できます。



もう一つの瞬間があります。 ルールが機能するたびにアラートが発生するため、ダウンタイムが長いため、毎分いくつかのアラートが生成されます。 アカウンティングと重複排除のシステムが必要です。 私たちの会社にはすでにそのようなシステムがあり、そこに統合しましたが、同僚は素晴らしい代替ソリューションを見つけました。



Alertaに会います。

alertaモニタリングシステムは、複数のソースからのアラートを統合および重複排除して、「一目で」すぐに視覚化できるツールです。 1つのシステムで、他の多くの監視ツールからのアラートを1つの画面で監視できます。

アラートは、多くのソースからの信号を視覚化およびアカウンティングとともに統合および重複排除するために使用されるツールです。







これは、WebUIシステムに組み込んだユーザーインターフェイスを含む、非常に簡単に統合できる優れたツールです。 Alertには、Email、Slack、HipChatなどとの既成の統合があります。 彼女は、Grafanaでさらに視覚化するために、アラートをinfluxDBに書き戻すことができます。



最初の会議の瞬間から本番リリースまで、6か月を少し過ぎました。 古いHPアラートシステムよりも数分早く（平均12〜15）インシデントのほとんどをキャッチします。 さらに、システムは他の監視システムをすり抜けた問題を検出して通知します。



現在、ルールを微調整するために製品の統計を作成しています。 システムの開発にはさらに計画があります。たとえば、Convolution Networks（サードパーティのプロジェクト）を通じてメトリックを調べてみてください。



それは非常に興味深い冒険であり、抽象的な構文木、優先キュー、マタンなどに出会った。 現時点では、システムは5つのコンポーネント（マイクロサービス）と、アラート-7つのコンポーネントで構成されています。 同社にはこのシステムをオープンソースでリリースする意向がありますが、これにはさらに数か月かかります。



まだ進行中の冒険。