SmartMonitoring-Odnoklassnikiのビジネスロジックの監視

現在、オドノクラシニキには、地理的に分散した4つのデータセンター、11,000台のサーバー、1000台以上のネットワークデバイス、180のサービスがあります。 サービスとは、写真、ビデオ、音楽、テープなどを意味します。毎日、何千万人ものユニークなユーザーがサイトを訪れます。 そして、このすべての経済のために、彼らが何をしているかを監視する必要があります。

• 機器のインストール、ディスクの変更、ハードウェアインシデントの解決を行うエンジニアのチーム。
• これらのインシデントを探しているだけで、他のチームに作業を任せる監視チーム。
• ネットワーク管理者、彼らはネットワークで働き、機器を設定します。
• システム管理者は、ポータルを管理および構成します。
• 開発者。

サーバーをインストールして構成しますが、サーバーが非常に多いため、毎日何かが壊れることは避けられません。 この場合の主なタスクは、ユーザーよりも早く故障を確認することです。 したがって、監視チーム全体がポータル全体の運用を担当します。 彼らはチャートを見て、異常を見つけ、インシデントを開始し、Zabbix + JIRAバンドルを使用して作成された「自動インシデント」を配布します。 ビジネスロジックを監視するだけでなく、自動的に分析します。 これについては後で詳しく説明します。



グラフの表示と異常の検索に専念しましょう。 私たちのスケジュールは何ですか、 異常とは何ですか、 インシデントとは何ですか？







このグラフは、テープのロード時間（ns）を示しています。 現在の日は赤で表示されます。 アクティビティテープのロード時間がジャンプしました。 これは私たちにとっての出来事です。つまり、ある時点でユーザーがサイトの主要部分であるアクティビティフィードをゆっくりロードした可能性があります。 すべての主要なインシデントは、そのような飛躍から正確に始まります。最初の事件、次に2回ですが、最終的にはすべてが壊れます。 したがって、監視チームはジャンプを検出し、すべての既知の情報を使用してJIRAでチケットを作成する必要があります。 すべてのサービスとデータベースをチェックして、理由を見つけてください。 何が壊れているかを知るまで、何を修理する必要があるのか​​わかりません。 チャート上でジャンプの理由を手動で見つけるには、数十、時には数百の他のチャートを調べる必要があります。

過去への遠足

以前は、ポータルがあらゆる点ではるかに小さかったときに、グラフ付きのダッシュボードを作成しましたが、そのうちダッシュボードはほとんどなく、約100〜200個しかありませんでした。 しかし、Odnoklassnikiは成長および発展し、ますます多くの新しいサービスが登場し、より多くのスケジュールがありました。



新しいサービスが開始されたとしましょう。 それを作ったプログラマーは、すべての側面から監視されているサービスに興味がありました。 そのため、彼は監視チームに多くのチャートを提供し、次のように述べました。 しかし、その時点では、あまり多くのグラフを表示できませんでした。 各サービスに数十個ある場合、タスクはすぐに不可能になります。 したがって、最も重要な（サービスの作成者による）チャートのみを選択して監視しました。 しかし、サービスが開始されたときに、インシデントが「重要でない」チャートでのみ目立つことがありました。これはメインダッシュボードにはありません。 その結果、インシデントを見逃しました。



ある時点で、監視チームは650個のグラフを処理し、4つのダッシュボードに分割しました。各グラフは、チームのメンバーが特定の間隔で見ていました。 各ダッシュボードの表示間隔は独自のものです（15分から1時間）。 8時間のシフト中に、平均で7000のスケジュールがアテンダントを通過しました。 たくさん。 これで何かをしなければなりませんでした。 結局、何千ものスケジュールを監視するだけでなく、インシデントを調査することも必要でした。 開発者と管理者が問題の解決策に接続し、接続しているため、それは本当に難しくて長いです（そしてOdnoklassnikiの巨大なシステムでは、ハードウェアまたはソフトウェアに関するいくつかの問題が絶えず発生するため、大規模システムの公理です）。 さらに、意志で手動で監視するかどうかにかかわらず、何かが常にスキップされていました。



最初の1時間に650枚の写真を見ると、すべてに反応するようなものですが、2、3、4時間目が変わると目がぼやけ、脳が疲れ、異常を見逃し始めます。 その結果、上記のすべての問題を解決するシステムを作成することにしました。



すべてのOdnoklassnikiサービスは相互にやり取りします。 たとえば、写真サービスとは、クラス、評価、コメントなどのサービスを指します。 簡単に説明します。詳細はこちらをご覧ください。 実際にやり取りするのはサービスではなく、これらのサービスを提供するサーバーです。 具体的には、2つの特定のサーバー間のリクエストに関する統計情報を収集し始めました。

• 通信方向：どのサーバーがどのサーバーにアクセスしていますか。
• リクエストの数。
• 失敗したリクエストの数。
• クエリ実行時間。
• サーバーが通信する方法。

たとえば、これは、通常のWebサーバーと典型的なビジネスロジックサーバーとの相互作用のグラフの外観です。 グラフは、それらの間のリクエストの数を示します。







サーバーが相互に通信する方法を知っていれば、次のようなポータル全体のグラフを作成できます。







しかし、1つの小さな問題があります。11,000台のサーバーがあります。 そのようなグラフは巨大になり、構築して視覚化することは困難です。 解決策は明白です。 各サーバーは、インフラストラクチャで役割を果たします。つまり、独自の（マイクロ）サービス、合計280個の要素（ニュースフィード、プライベートメッセージ、ソーシャルグラフ（フレンドシップグラフなど）など）を備えています。サーバーインフラストラクチャの接続、物理サーバーを機能別にグループ化することを決定しました。実際、Odnoklassnikiでこのサブシステムまたはそのサブシステムにサービスを提供するクラスターを強調しています。 Webサーバー、キャッシュ、ビジネスロジックサーバーなどの大規模なマイクロサービスをデータセンターに分割しました。



このようなクラスターによるグループ化の結果、グラフは大幅に減少しました。約300の頂点と、それらの間の2.5千のエッジが残っていました。 これにより、Odnoklassnikiポータルが実際にどのように機能するかのグラフを作成できました。







マイクロサービスは円形に配置されています。 ラインは相互接続です。 この図では、1つのマイクロサービスが強調表示されています（右上）。 緑の線-このマイクロサービスの行き先、茶色の線-誰が行きますか。 グラフのトポロジを適切に視覚化しないと、何らかの方法でグラフを使用することが困難だったため、グラフの頂点をさまざまな方法で平面に配置しようとしました。 彼らはそれを動的にし、問題のある接続、つまり異常があるグラフ上の接続を強調すると考えましたが、これは機能しません：グラフは非常に大きいです。



しかし、なぜグラフ全体を常に表示するのでしょうか？ 元のタスクに戻り、実際のインシデント時にそれを確認することにしました。 そして数日後、そのような事件が現れました-パーソナルメッセージングシステムで異常が発生しました。ユーザーはメッセージを書きたいと思っていましたが、彼の通信履歴は非常に長い間ロードされました。 素晴らしいケース！ 異常のある接続のみを残して、グラフを再構築することにしました。 取得したものは次のとおりです。







青色は2つのマイクロサービス間の時間を示し（各マイクロサービスには異なる数のサーバーがあります）、黄色は要求の数を示し、紫色はエラーを示します。 これがグラフの単なる新しいビューではないことがすぐに明らかになりました。 グラフは本当に問題を指摘していました。 問題が明らかになりました ！ ドライナンバーの言語で言えば、記載されているインシデント発生時のモバイルWebサーバーからメッセージサービスサーバーへのリクエストの期間は約0.5ミリ秒増加しました。 ビジネスロジックサーバーからメッセージングプロキシへの応答時間は10ミリ秒です。 そして最も重要なことは、データウェアハウスでのクエリの平均遅延が40ミリ秒増加したことです。 エラーが発生し、データベースへの呼び出しが少なくなりました。おそらく、すべてのユーザーがメッセージ履歴の読み込みの終了を待っているわけではなく、通信ウィンドウを閉じました。 このグラフは、すぐにどこを掘るかを示しています。これは、通信の履歴を保存するmessaging-conversation-cdbクラスタです。 言い換えれば、理由は明らかです。グラフの最後のリンクは、時間の増加が最も重要な場所です。



このアプローチをさらに数回テストした結果、機能することがわかりました。 問題のある関係のグラフを構築するというアイデアが本当に気に入ったので、サーバーの相互作用の統計だけで停止するのではなく、システムをさらに開発することにしました。 また、時間、エラー、リクエスト、トラフィックなど、Webサーバーからのコンテンツのリターンの統計情報の分析も開始しました。 支払い（お金）の監視を追加しました。多くの場合、支払いアグリゲーターの問題を自分よりも早く見つけ、「幸福の手紙」を送信することでそれらについて通知します。 さらに、モバイルバージョンとWebバージョンの両方でログインを国別に監視し始め、さまざまな技術チャートを追加しました。 その結果、現在10万件のチャートをリアルタイムで監視しています。 これは本当にたくさんあります！

システム構成

すべてのログはデータウェアハウスに書き込まれます。 これは、 Druidに基づいて構築された集中統計リポジトリシステムです。 日中に3兆のイベントが発生し、集計後、30億のレコード、つまり約600 GBになります。 .NETで記述されたデータコレクターサービスは、システムに必要なデータを取得し（すべてのグラフを監視するわけではなく、他の目的で作成されるグラフもあります）、データ分析用に準備されたMSSQL上のデータベースであるストレージに保存します。 Anomaly Detectorは、データと分析をキャプチャし、数値シーケンスの異常の検索を支援します。 彼が異常を見つけた場合、結果をマークし、ストレージに戻します。 Application Server（これも.NETで記述されています）は、見つかった異常に関するデータと追加のサービス（JIRA、ポータル管理システム、LiveInternetなど、インターネット全体のアクティビティを調べます）のストレージに移動し、すべての情報を準備してWebクライアントに渡します。



ここで最も興味深いモジュールであるAnomaly Detectorは、.NETで記述されたサービスです。 これがその仕組みです。







入力は、トレーニング用のシステムに必要なものです。







これらは、42日前の7、14、...、同時に6週間かかった値です（つまり、今日が月曜日の場合、月曜日はすべてトレーニングサンプルに移動します）。 現在分析中の時点での値に加えて、左右の2つの隣接する値を取ります。 これは、サンプルの正規分布に対して行われます。 その時点でシステムがいくつかの値を異常としてマークした場合、それらの値はサンプルに含まれません。



次に、 Grubbsテストを適用します。数値シーケンスで異常値を探し、これが異常かどうかを示します。 異常の例を次に示します。これはOdnoklassnikiコンポーネントの1つのロード時間のグラフです。







グラフから、午前6時30分に異常が発生したことがわかります。 これが、Grubbsテストに基づいたシステムの見方です。







左側には、同じ期間の早い方の値があります。左右に2つの値があります。 以下は現在の値です。 Grubbsのテストでは、これは異常であり、異常値が検出されています。 次に、フィルタリングを行います。 Grubbsテストはすべてを検出するため、フィルタリングは誤検知との戦いですが、私たちにとっては常に異常とは限りません。 これらは「偽の異常」です。

わずかなトレンド偏差

グラフは、マイクロサービス接続の1つの平均クエリ時間を示しています。 赤い線（問題の日）は、残りの日のすぐ上にあります。 ここには実際に逸脱があり、Grubbsテストはそれを見つけますが、私たちにとっては重要ではありません。 状況は2つあります。異常を検出することは重要ですが、誤検出はありません。 経験的に、時間の20％の偏差と、要求に応じて15％の偏差は重要ではないという結論に達しました。 確かに、すべての接続ではなく、メインの接続でのみです。 したがって、この場合、接続は異常としてマークされません。 ただし、Webサーバーからビジネスロジックサーバーまでの時間など、重要な接続のグラフである場合、ユーザーへの影響はほとんどないため、異常としてマークされます。 気付く前に理解する必要があります。

ノイズの多いグラフィックス

非常にノイズの多いグラフでは、データ集計を使用します。つまり、システムは、異常がレーダーに連続して数回衝突した場合にのみ、グラフに異常があると言います。 問題について少し後で学ぶことは重要ではありません。主なことは、私たちが学ぶことであり、これが間違いなく問題であることです。 しかし、ジャンプが十分に大きい場合、トレンドの急激な変化だけでなく短期的なプラグもキャッチすることが重要であるため、ルールは機能しません：それらはしばしば深刻な問題につながります。

ポータルの更新

更新中、サーバーのグループはローテーションから削除され、停止されます。 つまり、それからの要求とゼロへの要求がゼロになり、システムはそのようなケースを異常として示します（そして正しく行います）。 これはユーザーにはまったく影響しないため、誤検知。 8つのサーバーグループがあり、2つが表示されているとします。 2つが撤回され、全負荷が他のグループに移されました。 誤検知が発生しないように、切り替えを行いました。更新中にオンにして、データセンターによって切断されているマイクロサービスの合計を確認します。 そのようなグループによるクエリの数のグラフがどのように（美しく）見えるかを以下に示します。

ネットワーキング

ネットワークで作業する場合、 ユニキャストストームが頻繁に発生し、ネットワークを詰まらせるため、2つのマイクロサービスの相互作用時間はほとんどの場合長続きしませんが、大幅にジャンプします。 したがって、データセンターでのユニキャストストームの発生を追跡します（一度に多くのパケットが送信されましたか？）。 ストームが検出された場合、それが発生したデータセンターを表示し、当直者が理由を見つけます。

活動の季節変動

これは4月30日の写真です。大きな祝日が来る前に、人々は休暇を取り、8：00からの赤い線は少し低くなりました。 そして、これはすべてのサービスのためです。 これは季節性の影響であり、何らかの方法でアルゴリズムを再構築する必要があることを理解しています。 次に、ユーザーアクティビティのおおよその偏差を知る別のアルゴリズムをオンにします。 彼はオンラインおよび他の指標を見て、それらを再解釈し、そのような肯定的な結果は表示しません。

システムはどのように機能しますか？

監視チームのメンバーは、グラフまたは接続のみを受け取り、それを使用して4つのことを実行できます。

• 既知の異常としてマークし、しばらくの間消えます。 ユーザーがその原因を知っているとしましょう。 一部のプログラマーは、「ここでいくつかの機能をオンにします。ここで時間が長くなり、2時間以内にオフにします。」 穏やかな魂を持つユーザーは、必要なフィールドのすべてを説明し、このイベントは一時的に彼を悩ませません。
• インシデントを作成します 。 システム自体で起動し、JIRAに自動的に表示されます（JIRAチケットが作成され、インシデントに関するすべての必要な情報が送信されます）。
• 新しいトレンドとして示します 。 プログラマーがサービスを何かで補完し、リクエストの期間の増加を期待しているとします。 この時点から、チャートを異なる方法で分析する必要があり、ユーザーは新しいトレンドが始まったことを示します。
• たとえば、誤検知がすり抜けた場合は何もしません 。

作業を容易にするシステムの機能：

• グラフにすでに問題が発生している場合、システムはその原因を通知します。 グラフをマークするすべてのユーザーマークを保持します。
• JIRAと連絡してください。 インシデントは監視システムで作成され、JIRAに自動的に表示されます。 システムはインシデントのステータスを確認します。ユーザーがインシデントを作成して更新するのを忘れた場合、完了時間なしに接続にインシデントがあると、そのような接続は表示されません。 この時点で問題が悪化している場合、システムはそう言います。 すでに知られている異常と同じこと。 アテンダントが既知の異常として一時的に異常を隠したが悪化した場合、システムはこれらのグラフを見る必要があることを通知します。
• 構成システムとの通信。 プログラマーがポータルを変更するためのポータル構成システムがあります。 ユーザーにはグラフが表示され、その時点でポータルにどのような変更があったかを確認できます。 これにより、どのプログラマーが問題に関与していたかを理解できるため、解決に役立ちます。
• 管理者またはプログラマーが自分の（マイクロ）サービスに何が起こったかに興味がある場合、例えば、夜間または1週間に発生した異常を確認できます。
• このシステムでは、リモートで共同で作業できます。1人のユーザーが何らかの接続を既知の異常としてマークすると、他のユーザーは異常者として誰が、なぜ異常としてマークし、何が起こったのかをすぐに確認できます。
• GUI 機能に起因すると考えています。
  
  
  
  
  
  写真はクリック可能です
  
  
  
  左側が表、右側がグラフ、上部がヘッダーです。 コンテンツ内で表と列が重複しています。 グラフの上に、アクティビティがRunetおよびOdnoklassniki全体に表示されます。 これは、アクティビティの逸脱を追跡するために必要です。 左上-ユーザーは、現在自分に未解決のインシデントがいくつあるかを確認します。 「自動インシデント」に関するタブもあります。 前述のとおり、それらはシステムによって作成された新しいインシデントの数が点灯するZabbix + JIRAバンドルを使用して作成されます：ハードウェア、ソフトウェア、ネットワーク。 右側には、処理されたリンクが含まれるタブがあります：既知の異常、インシデント、新しいトレンド。 それらに同じ生地が悪化した問題の数が表示されます。

システム結果

現在、10万のスケジュールを監視し、インシデントを見逃すことなく、調査に費やす時間を大幅に削減しています。 新しいサービスはすべて自動的に監視されます。 チームの生産性が向上しました。 管理者やプログラマは誰でもシステムにログインして、現在何が起こっているのかを確認できます。重大な問題でも小さな問題でもあります。 これは、管理者とプログラマの両方が人生を楽しむのに役立ちます。



あなたが誰かがそのようなシステムを作成する場合、私たちはあなたを助ける記事のリストを作りました。 あなたはそれらをここで見つけるでしょう。