監視対象の5,000台のサーバーのグラフを見るのにうんざりしたとき（および10,000台以上のサーバーがあったとき）

Odnoklassnikiでは、1万台を超えるサーバーで構成されるインフラストラクチャのボトルネックを探しています。 5000台のサーバーを手動で監視することにうんざりしていたとき、自動化されたソリューションが必要でした。



より正確には、そうではありません。 約20番目のサーバーが白髪時代に登場したとき、彼らはBig Brotherの使用を開始しました。これは、統計を収集して小さな写真の形で表示する最も単純な監視です。 すべてがとても簡単です。 概算でも、何らかの形で許容される変更範囲に入ることも不可能です。 写真を見てください。 これらは次のとおりです。









2人のエンジニアが週に1営業日を費やし、彼らを見て、スケジュールが「間違っている」と思われる場所にチケットを置いた。 本当に奇妙に聞こえるかもしれませんが、数台の車から始まり、なんとかして5,000インスタンスになりました。



そのため、新しい監視システムを作成しました。現在、1週間に1〜2時間、1万台のサーバーとアラートの処理に取り組んでいます。 仕組みを説明します。

なぜそれが必要ですか

インシデント管理は、作業開始のかなり前に設定されていました。 「鉄」の部分では、サーバーは正常に機能し、適切に保守されました。 問題は、ボトルネックを予測し、異常なエラーを特定することでした。 2013年、Odnoklassnikiでの失敗により、サイトが数日間利用できなくなったという事実に至りました。 このことから私たちは学び、インシデントの防止に多くの注意を払いました。



サーバー数の増加に伴い、すべてのリソースを効果的に管理し、監視して考慮するだけでなく、サイトのインフラストラクチャのボトルネックにつながる可能性のある危険な傾向をすばやく記録することも重要になりました。 また、検出された問題のエスカレーションを防ぎます。 議論されるのは、ITリソースの状態を分析および予測する方法です。

いくつかの統計

2013年の初め、Odnoklassnikiインフラストラクチャは5,000台のサーバーとストレージシステムで構成されていました。 ここに2年半の成長があります：







外部ネットワークトラフィックの量（2013〜2016）、Gbit / s：







格納されたデータの量（2013〜2016）、Tb：







アプリケーション、機器、およびビジネスメトリックのパフォーマンスは、監視チームによって年中無休で監視されます。 既に大規模なインフラストラクチャは急速に成長し続けているため、ボトルネックの問題を解決するにはかなりの時間がかかります。 そのため、運用監視だけでは不十分です。 できるだけ早くトラブルに対処するには、負荷の増加を予測する必要があります。 これは次のように行われます。監視チームは、週に1回、すべてのサーバー、アレイ、およびネットワークデバイスの動作インジケータの自動チェックを開始し、その後、機器で発生する可能性のあるすべての問題のリストを受け取ります。 リストは、システム管理者およびネットワークスペシャリストに渡されます。

監視対象

すべてのサーバーとそのアレイで、次のパラメーターを確認します。

• プロセッサの合計負荷、およびシングルコアの負荷。
• ディスク使用率（I / O使用率）およびディスクキュー（I / Oキュー）。 SSD / HDDの制限は異なるため、システムは自動的にSSD / HDDを決定します。
• 各ディスクパーティションの空き領域。
• さまざまなサービスがさまざまな方法でメモリを使用するため、メモリ使用率。 特定のグループで解決する必要があるタスクの詳細を考慮して、各サーバーグループの使用/空きメモリを計算するいくつかの式があります（デフォルトの式：Free + Buffers + Cached + SReclaimable-Shmem）。
• スワップとtmpfsを使用します。
• 負荷平均;
• サーバーネットワークインターフェイス上のトラフィック。
• GCカウント、フルGCカウント、GC時間（Java Garbage Collectionについての話）。

中央のスイッチ（コア）とルーターでは、メモリ使用量、CPU負荷、そしてもちろんトラフィックがチェックされます。 サーバーネットワークインターフェイスレベルで直接テストするため、アクセスレベルスイッチ上のアクセスポートトラフィックを監視しません。

分析

データはSNMPを使用してすべてのホストから収集され、DWH（データウェアハウス）システムに蓄積されます。 OdnoklassnikiのBI記事：データ収集とDWHへの配信で、HabrのDWHについて以前に話しました。 各データセンターには、これらの統計を収集するための独自のサーバーがあります。 デバイスからの統計は毎分収集されます。 データは90分ごとにDWHにアップロードされます。 各データセンターは独自のデータセットを生成し、そのボリュームはアップロードごとに300〜800 Mbで、これは1週間あたり300 GBです。 データは近似されていないため、問題が発生した正確な時間を見つけることができ、その原因を見つけるのに役立ちます。



すべてのサーバーは、インフラストラクチャでの役割に応じて、しきい値（制限）がかかっているグループに分割されます。 制限を超えると、デバイスが報告されます。 すべてのホストは、特別に開発されたサービスカタログシステムにグループ化されます。 サーバーのグループに制限がかかっているため、グループ内の新しいサーバーは同じ制限で自動的に監視され始めます。 管理者が新しいグループを作成すると、ハード制限が自動的に課され、新しいグループのサーバーがチェックされると、これが正常かどうかの判断が行われます。 プログラマがこれがサーバーのグループの通常の動作であると考えている場合、制限が上がります。 便利な制限管理のために、次のようなコントロールパネルが作成されています。







この管理パネルでは、サーバーのすべての一意のグループとその制限を確認できます。 たとえば、スクリーンショットは、achievements-cdbグループの制限を示しています。

• 最大プロセッサ負荷は35％を超えてはなりません。
• プロセッサの負荷を100％計算する式-アイドル状態。
• HDDのディスクキューの制限は、SSDの場合2、10です。

などなど。 変更の理由を説明するタスクを参照することによってのみ、制限を修正できます。 制限変更ウィンドウ：







スクリーンショットには、サーバーグループの現在の制限がすべて表示されており、変更できる可能性があります。 変更を適用できるのは、Jiraチケットフィールドが入力されている場合のみです。 タスクは、問題が解決されたフレームワーク内で書かれています。



サーバーの負荷が非常に低い夜間に、追加の負荷を作成するさまざまなサービスおよび計算タスクが実行されますが、それらはユーザーまたはポータルの機能にまったく影響を与えません。 。 サービスウィンドウは、制限を超える時間間隔です。これは問題とは見なされず、レポートには含まれません。 誤検知には、短期的なジャンプも含まれます。 サーバーとネットワークの問題は異なる部門で解決されるため、ネットワークとサーバーのチェックは分離されます。

レポートはどうなりますか

レポートは水曜日にワンクリックで収集されます。 次に、5人の「昼間」エンジニアの1人がリソースの通常の「パトロール」から撤退し、チケット管理に取り組み、レポートの読み取りを開始します。 チェックには1時間半しかかかりません。 このレポートには、インフラストラクチャで発生する可能性があるすべての問題（新しいものと古いものの両方）のリストが含まれていますが、これらはまだ解決されていません。 各問題は管理者へのアラートになる可能性があり、システム管理者はすでに解決しています-すぐにチケットを修正または開始します。







写真は初期確認ウィンドウを示しています。 ユーザーは適切なボタンをクリックして自動チェックを実行できます。「サーバー」-すべてのサーバー、「Nw CPU Mem」-ネットワークデバイスのメモリとプロセッサの使用、「Nwトラフィック」-中央のスイッチとルーターのトラフィック。



システムはJIRA（タスク管理システム）と統合されています。 問題（制限を超えている）がすでに解決されている場合は、その前にチケットへのリンクがあり、その中で問題に対して作業が実行されるか、チケットステータスで呼び出されます。 したがって、どの問題のフレームワーク内で、問題が以前に解決されたかがわかります。 解決のステータスのチケットがあります。







すべての新しい問題は、JIRAでチケットを作成して各問題を個別に解決する上級システム管理者および上級ネットワークスペシャリストに転送され、これらのチケットは対応する問題にリンクされます。 システム管理者は、任意のパラメーターで特別なチェックを実行する機会があります。サーバーグループ、パラメーター、および制限を指定するだけで十分です。システム自体は、制限を超えたすべてのサーバーを表示します。 また、制限線を使用して、サーバーのパラメーターのグラフを表示することもできます。



サーバーがレーダーに乗る例：







通常の検証に加えて、最大のサーバーグループ（Web-フロントエンド、ビジネスロジックレベル、ユーザーデータキャッシュ）の長期予測が行われます。これらのグループの問題を解決するにはかなりのリソース（機器、時間）が必要です。



監視チームは長期予測も行いますが、これには約5分かかります。 システムによって生成されたレポートでは、監視スペシャリストは、サブグループおよびグループ全体のメインインジケーターのチャートと将来の予測を確認し、2か月から3か月以内に設定された制限を超えると、問題を解決するためのチケットも作成されます。 予測がどのように見えるかの例を次に示します。











最初の図では、WebサーバーのすべてのグループのCPU使用率が個別に表示されます。 赤い線は制限を示します。 黄色は予報です。



予測はかなり単純なアルゴリズムに基づいています。 CPU負荷予測アルゴリズムの例を次に示します。



サーバーグループごとに、7日間の増分で、次の式を使用してポイントを構築します（フロントエンドグループの例）。



∑（n-最大負荷-最小負荷）/（n-2） 、ここで：

• n-グループ内のサーバーの数。
• 最大負荷 - 負荷の最大値。各サーバーで1週間ごとに30分以上持続しました。 サーバーグループのすべての負荷値を合計します。
• min load-最大と同様に計算された最小負荷値。

より正確な予測を得るために、最大負荷のサーバーと最小負荷のサーバーを削除します。 このアルゴリズムは単純に見えるかもしれませんが、現実に非常に近いため、複雑な分析を発明することは意味がありません。 したがって、サーバーの各グループについて、近似線形関数が構築される週のポイントを取得します。



結果のチャートで、グループの拡張またはアップグレードが必要になる推定日付を確認できます。 大規模クラスターの場所が終了する日付も同様に予測されます。 写真、ビデオ、音楽のクラスターがチェックされます。







システムはスペアディスク（アレイ内のスペアディスク）を破棄し、これらの統計には含まれません。



その結果、監視チームのエンジニアがレポートを作成し、すべての問題を作成した後、マネージャーは次のタスクを管理者に任せます。

• クラスター写真を展開します。
• group1およびgroup2のドライブを増やします。
• group3のキューの問題を解決します。
• group4でGCを処理します。
• server1とserver2のトラフィックと負荷の問題を解決します。
• group5およびgroup6でのスワップの問題を解決します。

システムが問題を事前に検出し、システム管理者の作業を大幅に簡素化したため、それらの策定時のこれらのタスクはすべて重要ではありませんでした。短時間で問題を解決するためにすべてを落とす必要はありませんでした。

新しい指標

時々、新しいメトリックが必要です。 これらは、毎年1つまたは2つの新しい指標です。 多くの場合、インシデントでそれらを開始します。管理者から事前に何かが通知されていれば、インシデントは発生していなかった可能性があります。 ただし、ある種の松葉杖が必要になる場合があります。たとえば、大きな写真のリポジトリがあるサーバークラスターでは、スペースの80％が何らかの形で利用されていました。 拡張により、技術的に写真を再配布することができず、70％のカバレッジで監視したいと考えました。 2つのグループが形成されました-常にアラートを生成するほぼ完全なサーバーと、新しくてきれいなサーバー。 個別のルールの代わりに、仮想の「偽の」マシングループを開始する必要があり、これにより問題が修正されました。 別の例としては、SSDに一括で切り替える場合、通常の動作が通常のHDDとは大きく異なるディスクキューを適切に監視する必要がありました。



一般に、作業は十分に確立されており、この部分は美しく、保守が容易で、スケーラブルです。 予測システムを使用して、サーバーを突然購入しなければならないときの望ましくない状況をすでに何度か回避しています。 これは非常に良い感じのビジネスです。 また、管理者は、さまざまな小さなトラブルから保護するための別のレイヤーを取得しました。