サービスネットワーク接続の監視

まえがき

私たちの主なプロジェクトは、ソーシャルネットワークとモバイルアプリケーションでの広告インプレッションの最適化です。 各バナー表示は、異なるサーバー、場合によっては異なるデータセンターにある十分に多数のサービスの相互作用の結果です。 当然、サーバーとサービス間の通信を監視するタスクがあります。 このタスクの形式、適切なソリューション、適切でないソリューションについて-さらに説明します。

ネットワーク構造：フロントエンド、バックエンド、サービス

他の多くのWebアプリケーションと同様に、私たちのアプリケーションはフロントエンド（FE）、バックエンド（BE）、およびサービスで構成されています。 フロントエンドはクライアントからの接続を受け入れ、バックエンドに転送します。バックエンドはサービスを呼び出してクライアントに応答します。 私たちの場合、FE-ほとんどの場合-nginx、BE-Tomcat。 このアーキテクチャはかなり標準的なものであり、フロントエンド、バックエンド、およびサービス間でリクエストをルーティングする方法を決定する必要がある場合、非標準の開始点です。



この場合、ルーティングはCMDB構成データベースによって制御されます。 このデータベースには、ネットワークの物理デバイス（データセンター、物理サーバーなど）とアプリケーションの論理デバイス（サービスとインターフェイスが配置されているコンテナー、物理サーバー、FEおよびBEをクラスターに分割し、トラフィックを処理できるサーバー）の両方が反映されますどれがそうでないかなど）



CMDB情報は2つの方法で使用できます。 最初の-条件付き「オフライン」は、数分ごとに、スクリプトがCMDBから必要な情報を選択し、たとえば、nginxに必要なアップストリームのものを含む最新の構成を構築するという事実から成ります。 CMDBにアクセスする2番目の方法の仕組みについては、次のセクションで説明します。

CMDB、短縮名、名前によるサービスの検索

CMDBを使用する2番目の方法は、定期的ではなく即時にCMDBの変更を反映するため、オンラインとして任意に指定できます（CMDBの上の短期キャッシュを考慮）。この方法は、主にバックエンドが必要なサービスを見つけて、それ自体は、DNSの使用に基づいています。 説明の写真からこれがどのように行われるかを理解する最も簡単な方法：

1. host58にあるbe5バックエンドはデータベースに接続する必要があります。データベースサービス名はdb1（短いDNS名）です
2. 名前db1.be5.host58.example.comは、resolv.confのデータから、名前db1から作成されます。 リゾルバーはPowerDNS要求を送信します
3. db1.be5.host58という名前のpDNSプラグインは、host58にあるbe5コンテナーがdb1サービスを探していると結論付けます
4. CMDBデータは、host58に最も近いdb1サービスを提供する実行中のコンテナーのIPをリストするために使用されます
5. be5のサービスは、受信したリストから任意のアドレスを選択し、db1サービスにアクセスします

中間結果の要約：フロントエンド、バックエンド、サービスは、CMDBの単一の情報源を使用してお互いを見つけます。 アドレスを取得するには、構成の構築とDNSクエリの2つの方法があります。

物理的なネットワーク構造、通信の問題

ホスティングプロバイダーからサーバーをレンタルします。 異なるデータセンターの構造は同じです。フロントエンド、バックエンド、またはサービスを備えたコンテナが実行されている物理ホストのセットです。 何らかの理由で必要なサービスが別のデータセンターでのみ利用可能な場合、任意のコンポーネントからのリクエストは、他のホスト、さらには別のデータセンターに送信できます。 合計で、6つのデータセンターに配置されており、各データセンターには約100または2つのサーバーがあり、各サーバーには最大4つまたは5つのコンテナーがあります。 合計で、約1,000のホストと約5,000のコンテナーを取得します。



ネットワーク構造全体が手元にないため、リンク、スイッチ、チャネル負荷などを監視できません。 同じ理由で（ネットワークは手元にありません）、サーバー間の通信にipsecを使用します。 IPsecは、2つのホスト間（またはコンテナー間のみ）の通信が失われるという形で驚きを示すことがあります。 同様の驚きがプロバイダーのインフラストラクチャによって提示されます。 いずれにせよ、私たちが知ることができるのは、ホストまたはコンテナのセットの一部で1つのホスト（またはそのコンテナ）が利用できないという事実だけです。 さらに、利用できないという事実は、アプリケーションレベルで常に現れるわけではありません。サービスが複製され、利用可能なサーバーから要求を満たすことができます。 また、中央サーバーからのpingを使用してこのような問題を監視することはできません-彼は単にそれらに気付かないでしょう。



サーバーの数が数十に制限されていたとき、気にしませんでした。各ホストから他のすべての人に送信されるpingと損失の追跡によって接続を確認しました。 ホストの数が1000に近づくと、この簡単な方法は機能しなくなります。

1. ping時間が長すぎる、または：
2. 監視のためのネットワーク消費が顕著になります（1台のサーバーから1秒に1000台のサーバーに送信される標準のpingは、メガビットの帯域幅を必要とします。
3. 「誰が誰を見るか、または見ない」処理および分析のためのホスト上のCPU消費が大きくなる
4. コンテナ間の接続性は監視されません-ipsecの問題やルート設定は見られず、コンテナレベルでの問題につながります

これらすべての問題を1回のヒットで解決するには、「すべて」ではなく、相互にアクセスするコンポーネント間の関係のみを監視する必要があります。 したがって、ここで発生する最初のタスクは、特定のコンポーネントがアクセスしているコンポーネントを見つける方法です。 開発者だけがこれを確実に知っていますが、常に最新の情報を提供できるわけではないため、それについて尋ねたり、何らかのレジストリを保持するように頼んだりすることはほとんど意味がありません。実際、これは機能しません。



ここでは、サービスがお互いを見つける方法の知識の助けになります：解決を使用しないが、CMDBへの直接呼び出しを介してパートナーを計算するコンポーネントは、この計算の結果を構成だけでなく一部のパブリックにも保存するように求めます合意された形式の場所。 また、解決を通じてCMDBを使用するサービスの場合、PowerDNSログを解析し、PowerDNSが要求に応答したことを確認します。 したがって、これらのコンポーネントまたはこれらのコンポーネントで使用できるIPの完全なリストを収集できます。

監視、テスト

通信を監視するタスクのために、コンテナ間の関連する接続の完全なリストを1か所にまとめています。この1か所が「サーバー」の役割を果たします。 すべての情報は、辞書の形式でサーバーに表示されます。

コンテナ	リンクリスト
be5.host58	192.168.5.1 192.168.5.2 10.1.2.3 10.2.3.4
be8.host1000	10.0.0.1 10.0.100.5

サーバーは、RESTインターフェースを介してこの情報を利用可能にします。



監視の後半は各コンテナにあります-この部分を「エージェント」と呼びます。 エージェントは、それが置かれているコンテナを知らず、現在の状態の名前以外は何も保存しません。 2分ごとに、エージェントはサーバーに接続のリストを問い合わせ、サーバーは上記の表の行で応答します。 通常、IPアドレスのリストは10を超えません。 エージェントはこれらのアドレスにpingを送信します。 問題のリスト（ある場合）を含む結果は、POSTを介してサーバーに報告されます。 サーバーがエージェントに対して実行するすべての操作は非常に単純であるため、多数のエージェントを簡単に処理できます。そのためには、GET、POSTリクエストを受け入れて辞書を検索するか、辞書にデータを1秒あたり数十回追加するだけです。



さらに、エージェントは数分ごとに起動するため、コンポーネントの他の現在のパフォーマンスインジケーターを収集してサーバーに転送することは理にかなっています。 muninを使用して多くのことを監視しますが、muninはデータの表示にかなり大きな遅延を与えますが、ここでは「リアルタイム」モードで何かを取得できます。 そのため、エージェントは、コンポーネント内のLA、nginxへの要求の割合（存在する場合）、およびコードごとのnginxエラーの数などのインジケータを同時に収集します。

結果の監視、プレゼンテーション、分析

前述のように、エージェントは接続テストの結果をサーバーに送信します（他のデータとともに、そのリストはエージェントによって異なる場合があります）。 ここに私たちが持っているいくつかの情報があります：

お名前	切断する	DC	役割	ロード	nginxErrRate	接続性	nginxAccessRate
be1.host123	0	TX	なる	0.21	15.55		31.38
be1.host122	0	TX	なる	0.11 |	18.28		34.61
fo1.host161	2	VA	fo	0.02	0.11	10.1.1.4,10.1.2.4	14.1
fo1.host160	0	VA	fo	0.0	0.00		0.0
fo1.host162	2	VA	fo	0.01	0.18	10.2.1.4,10.2.4.3	17.56

このテーブルの情報の一部はエージェントによって送信され（切断、ロード、nginx ...）、一部（DC、ロール）はCMDBから読み込まれます。 このテーブルのデータは非常に短命であり、その中の行数は数千のオーダーであるため、「：memory：」タイプのsqliteデータベースの一部として設計することは理にかなっています。



この庭園全体が設置された主な理由は、コミュニケーションの問題を監視することです。 したがって、そもそも切断と接続の列（壊れた接続の数と対応するコンテナーのリスト）にのみ関心がありますが、一般に、単純なSQLクエリを使用してこのようなテーブルからさまざまな興味深い事実を取得できます。 「SELECT BY FROMデータORDER BY切断DESC」-最初に解決する必要がある通信の問題があるサーバーのリストを提供します。 空でない場合、このクエリの結果は、問題のあるサーバーのリストが添付されたアラートとしてNagiosに送信されます。 問題に関する情報を受け取った当直のエンジニアは、さらに対策を講じます。問題のあるサーバーからトラフィックを削除し、ホスティングプロバイダーのシステムでチケットを作成します。



システムのエラーの全体的なレベルが増大し始める状況が時々あります。 これは、運用上の問題と外部の理由の両方に関連するさまざまな理由で発生する可能性があります。 抽象的な例-データセンター間のリクエストが時間制限に適合しなくなったため、データセンター間のルーティングが変更され、nginxで504エラーが増加しました。 クエリ「SELECT SUM（nginxAccessRate）、SUM（nginxErrorRate）、dataCenter FROM data GROUP by dataCenter ORDER BY SUM（nginxAccessRate）」は、データセンター別に分解されたエラーの一般的な状況を示しています。 この全体像は、504エラーなどでのみ機能するクエリを使用して詳細に表示できます。



別の例-サーバーの負荷とそれに発生するエラーの数との間に相関関係があるかどうかを調べたいとします。 クエリ "SELECT load、nginxErrorRate FROM data WHERE role =" be1 "ORDER by nginxErrorRate DESC"は、このような依存関係をプロットまたは分析的に検出する機会を提供します。



このような例のリストは継続できます。 ここで重要なのは、Muninのチャートとは異なり、この情報はすべて関連性が高いことです。データの表示の遅延は約2分であり、データ分析の方法は比較にならないほど大きく、実行が容易です。



これは、statsd +グラファイトのタイプのバンドルを置き換えるソリューションではありません。履歴がないためだけに、システムの動作のさまざまなセクションをすばやく取得する機能は、サービス間の接続を分析するためのボーナスにすぎません。

おわりに

現在説明されているシステムは、約1000のコンテナの通信を監視しています。 これまでにパフォーマンスの問題は発見されていません。 一方、感度は、通信の短期的な損失、チャネルの混雑、または時間の増加に対して高すぎることが判明しました。 これにより、Nagiosアラートの感度の調整に苦労しています。