サービスとしてのモニタリング: マイクロサービス アーキテクチャのモジュラー システム

現在、モノリシック コードに加えて、私たちのプロジェクトには数十のマイクロサービスが含まれています。 それぞれを監視する必要があります。 DevOps エンジニアを使ってこのような規模でこれを行うには問題があります。 開発者向けのサービスとして機能する監視システムを開発しました。 彼らは独立して監視システムにメトリクスを書き込み、それを使用し、それに基づいてダッシュボードを構築し、しきい値に達したときにトリガーされるアラートをそれに添付することができます。 DevOps エンジニアの場合は、インフラストラクチャとドキュメントのみ。

この投稿は、私とのスピーチの書き起こしです。 セクション RIT++にて。 そこからテキスト版のレポートを作成してほしいという要望が多く寄せられました。 カンファレンスに参加していたり​​、ビデオを見ていたとしても、新しいことは何も見つかりません。 そして他の皆さんも、猫へようこそ。 このようなシステムをどのようにして構築したのか、それがどのように機能するのか、そしてどのように更新する予定なのかについて説明します。

過去: 計画と計画

どのようにして現在の監視システムに到達したのでしょうか? この質問に答えるには、2015 年に戻る必要があります。 そのときの様子は次のとおりです。

監視を担当するノードは約 24 ありました。 何らかの形で何かを監視し、メッセージを送信し、機能を実行する、さまざまなクラウン、スクリプト、デーモンのパック全体が存在します。 私たちは、先へ進めば進むほど、そのようなシステムは実行可能でなくなるだろうと考えました。 あまりにも面倒なので、開発する意味がありません。
私たちは、維持および開発する監視要素と放棄する監視要素を選択することにしました。 それらは 19 個あり、グラファイト、アグリゲーター、ダッシュボードとしての Grafana だけが残りました。 しかし、新しいシステムはどのようなものになるのでしょうか? このような：

メトリクス ストレージがあります。これらは高速 SSD ドライブをベースとするグラファイトであり、メトリクスの特定のアグリゲータです。 次 - ダッシュボードを表示するための Grafana とアラートを作成するための Moira。 また、異常を検索するシステムも開発したいと考えていました。

標準: モニタリング 2.0

これが 2015 年の計画の様子です。しかし、インフラストラクチャとサービス自体だけでなく、そのためのドキュメントも準備する必要がありました。 私たちは、モニタリング 2.0 と呼ぶ社内標準を独自に開発しました。 システムの要件は何でしたか?

• 常に利用可能。
• メトリクスの保存間隔 = 10 秒。
• メトリクスとダッシュボードの構造化されたストレージ。
• SLA > 99,99%
• UDP を介したイベント メトリクスの収集 (!)。

メトリクスを生成する大量のトラフィックとイベントがあるため、UDP が必要でした。 それらすべてを一度にグラファイトに書き込むと、ストレージが崩壊します。 また、すべてのメトリクスに対して第 XNUMX レベルのプレフィックスを選択しました。

各プレフィックスには何らかのプロパティがあります。 サーバー、ネットワーク、コンテナ、リソース、アプリケーションなどのメトリクスがあります。 明確で厳密な型付きフィルタリングが実装されており、第 2015 レベルのメトリクスを受け入れ、残りは単純に削除されます。 このようにして、XNUMX 年にこのシステムを計画しました。 現在には何が入っているのでしょうか？

現在: 監視コンポーネントの相互作用の図

まず第一に、私たちはアプリケーション、つまり PHP コード、アプリケーション、マイクロサービス、つまり開発者が作成したすべてのものを監視します。 すべてのアプリケーションは、UDP 経由で Brubeck アグリゲーター (statsd、C で書き直されたもの) にメトリクスを送信します。 総合テストでは最速であることが判明しました。 そして、既に集約されたメトリクスを TCP 経由で Graphite に送信します。

タイマーと呼ばれる一種のメトリクスがあります。 これはとても便利なことです。 たとえば、サービスへのユーザー接続ごとに、応答時間のメトリックを Brubeck に送信します。 10 万件の応答が返されましたが、アグリゲーターは 4 メトリクスのみを返しました。 訪問者数、最大、最小、平均応答時間、中央値、第 XNUMX パーセンタイルがわかります。 次に、データが Graphite に転送され、すべてがライブで表示されます。

また、ハードウェア、ソフトウェア、システム メトリクス、および古い Munin 監視システム (2015 年まで機能していました) に関するメトリクスの集計も行っています。 これらすべてを C デーモンの CollectD を通じて収集します (これにはさまざまなプラグインが組み込まれており、インストールされているホスト システムのすべてのリソースをポーリングできます。構成でデータを書き込む場所を指定するだけです)。それを通じてデータをGraphiteに書き込みます。 Python プラグインとシェル スクリプトもサポートしているため、独自のカスタム ソリューションを作成できます。CollectD はローカルまたはリモート ホスト (Curl を想定) からこのデータを収集し、Graphite に送信します。

次に、収集したすべてのメトリクスを Carbon-c-relay に送信します。 これは、Graphite の Carbon Relay ソリューションを C で修正したものです。これは、アグリゲーターから送信されるすべてのメトリクスを収集し、それらをノードにルーティングするルーターです。 また、ルーティング段階でも、メトリクスの有効性がチェックされます。 第一に、それらは前に示したプレフィックス スキームに対応する必要があり、第二に、グラファイトに対して有効であるということです。 そうしないと落ちてしまいます。

次に、Carbon-c-relay はメトリクスを Graphite クラスターに送信します。 メトリクスのメインストレージとして、Go で書き直された Carbon-cache を使用します。 Go-carbon はマルチスレッド化により、Carbon-cache よりもはるかに優れたパフォーマンスを発揮します。 データを受信し、ウィスパー パッケージ (標準、Python で記述) を使用してディスクに書き込みます。 ストレージからデータを読み取るために、Graphite API を使用します。 標準の Graphite WEB よりもはるかに高速です。 次にデータはどうなりますか?

彼らはグラファナに行きます。 私たちはグラファイト クラスターを主なデータ ソースとして使用し、さらにメトリクスを表示し、ダッシュボードを構築するための Web インターフェイスとして Grafana を使用しています。 開発者はサービスごとに独自のダッシュボードを作成します。 次に、それらに基づいてグラフを作成し、アプリケーションから書き込んだメトリクスを表示します。 Grafana に加えて、SLAM もあります。 これは、グラファイトのデータに基づいて SLA を計算する Python デーモンです。 すでに述べたように、数十のマイクロサービスがあり、それぞれに独自の要件があります。 SLAM を使用してドキュメントにアクセスし、Graphite の内容と比較し、要件がサービスの可用性とどの程度一致しているかを比較します。

さらに進んで、警告を発します。 それは強力なシステム、モイラを使用して組織されています。 ボンネットの下に独自のグラファイトがあるため、独立しています。 SKB「Kontur」のメンバーによって開発され、Python と Go で書かれ、完全にオープンソースです。 モイラはグラファイトに入るのと同じ流れを受けます。 何らかの理由でストレージが停止した場合でも、アラートは引き続き機能します。

Moira を Kubernetes にデプロイし、Redis サーバーのクラスターをメイン データベースとして使用します。 その結果、フォールトトレラントなシステムが誕生しました。 メトリックのストリームとトリガーのリストを比較します。その中に言及がない場合、メトリックは削除されます。 そのため、XNUMX 分あたり数ギガバイトのメトリクスを処理できます。

また、企業 LDAP も接続しました。これを利用して、企業システムの各ユーザーは、既存の (または新しく作成された) トリガーに基づいて自分用の通知を作成できます。 Moira にはグラファイトが含まれているため、そのすべての機能がサポートされています。 したがって、まずその行を取得して Grafana にコピーします。 データがグラフにどのように表示されるかを確認します。 そして、同じ行を Moira にコピーします。 制限付きでハングアップすると、出力でアラートが表示されます。 これらすべてを行うのに、特別な知識は必要ありません。 Moira は、SMS、電子メール、Jira、Slack 経由でアラートを送信できます。また、カスタム スクリプトの実行もサポートしています。 トリガーが発生し、カスタム スクリプトまたはバイナリをサブスクライブすると、それを実行し、標準入力でこのバイナリに JSON を送信します。 したがって、プログラムはそれを解析する必要があります。 この JSON をどうするかはあなた次第です。 必要に応じて Telegram に送信したり、Jira でタスクを開いたり、何でもできます。

また、アラートのために独自に開発した Imagotag も使用しています。 店頭の電子値札によく使われているパネルをニーズに合わせてアレンジしました。 モイラからトリガーを導入しました。 それらがどのような状態にあるのか、いつ発生したのかを示します。 開発担当者の中には、Slack や電子メールでの通知を放棄して、このパネルを支持した人もいます。

当社は先進的な企業なので、このシステムで Kubernetes も監視しました。 クラスターにインストールした Heapster を使用してシステムに組み込み、データを収集して Graphite に送信します。 その結果、図は次のようになります。

コンポーネントの監視

このタスクに使用したコンポーネントへのリンクのリストを次に示します。 それらはすべてオープンソースです。

黒鉛：

• ゴーカーボン: github.com/lomik/go-carbon
• ささやき： github.com/graphite-project/whisper
• グラファイト API: github.com/brutasse/graphite-api

カーボンCリレー:

github.com/grobian/carbon-c-relay

ブルーベック:

github.com/github/brubeck

収集:

コレクトド.org

モイラ：

github.com/moira-alert

グラファナ:

グラファナ.com

ヒープスター:

github.com/kubernetes/heapster

統計

そして、システムが私たちにとってどのように機能するかを示すいくつかの数字があります。

アグリゲーター (ブルーベック)

メトリクスの数: ~300/秒
メトリクスをGraphiteに送信する間隔: 30秒
サーバーリソース使用量: ~ 6% CPU (本格的なサーバーについて話しています)。 ~ 1Gb RAM; ~3 Mbps LAN

グラファイト（ゴーカーボン）

メトリクスの数: ~ 1/分
メトリクスの更新間隔: 30 秒
メトリクスの保存スキーム: 30 秒 35 日、5 分 90 日、10 分 365 日 (長期間にわたってサービスに何が起こっているかを把握できます)
サーバーリソース使用量: CPU 最大 10%。 ~ 20GB RAM; ~30Mbps LAN

柔軟性

Avito では、モニタリング サービスの柔軟性を非常に重視しています。 なぜ彼は実際にこのような結果になったのでしょうか？ まず、そのコンポーネントは、コンポーネント自体とそのバージョンの両方で交換可能です。 XNUMXつ目はサポート性です。 プロジェクト全体がオープンソースであるため、コードを自分で編集し、変更を加え、そのままでは利用できない機能を実装することができます。 主に Go と Python などの非常に一般的なスタックが使用されるため、これは非常に簡単に実行されます。

実際の問題の例を次に示します。 Graphite のメトリクスはファイルです。 名前があります。 ファイル名 = メトリック名。 そしてそこに到達する方法があります。 Linux のファイル名は 255 文字に制限されています。 そして、データベース部門からも (「内部顧客」として) スタッフがいます。 彼らは私たちにこう言います。「SQL クエリを監視したいのです。 そして、それらは 255 文字ではなく、それぞれ 8 MB です。 これらを Grafana で表示し、このリクエストのパラメータを確認したいと考えています。さらに、そのようなリクエストの先頭も確認したいと考えています。 リアルタイムで表示されたら最高ですね。 彼らを警戒態勢に置けたら本当に素晴らしいだろう。」

SQL クエリの例は、次の例から引用されています。 サイトpostgrespro.ru

Redis サーバーをセットアップし、Collectd プラグインを使用します。これは Postgres に移動し、そこからすべてのデータを取得し、メトリクスを Graphite に送信します。 ただし、メトリック名をハッシュに置き換えます。 同じハッシュをキーとして Redis に送信し、SQL クエリ全体を値として同時に送信します。 私たちがしなければならないのは、Grafana が Redis にアクセスしてこの情報を取得できることを確認することだけです。 Graphite API を公開している理由は... これは、すべての監視コンポーネントとグラファイトとの対話のためのメイン インターフェイスであり、そこに aliasByHash() という新しい関数を入力します。Grafana からメトリクスの名前を取得し、それを Redis へのリクエストでキーとして使用します。応答としてキーの値を取得します。これが「SQL クエリ」です。 そこで、理論上表示することが不可能だった SQL クエリの表示を、その統計情報 (呼び出し数、行数、total_time など) とともに Grafana で表示しました。

結果

可用性。 当社の監視サービスは、あらゆるアプリケーションおよびあらゆるコードから 24 時間 7 日利用できます。 ストレージ設備にアクセスできる場合は、サービスにデータを書き込むことができます。 言語は重要ではありません、決定も重要ではありません。 ソケットを開き、そこにメトリクスを配置し、ソケットを閉じる方法を知る必要があるだけです。

信頼性。 すべてのコンポーネントはフォールトトレラントであり、負荷を適切に処理します。

参入閾値が低い。 このシステムを使用するために、Grafana でプログラミング言語やクエリを学ぶ必要はありません。 アプリケーションを開き、メトリクスを Graphite に送信するソケットを入力し、アプリケーションを閉じて Grafana を開き、そこにダッシュボードを作成してメトリクスの動作を確認し、Moira 経由で通知を受信します。

独立。 DevOps エンジニアの助けを借りずに、これらすべてを自分で行うことができます。 これは利点です。プロジェクトを今すぐ監視できるため、作業を開始するか変更を加えるかを誰にも尋ねる必要がありません。

私たちは何のために努力しているのでしょうか？

以下にリストされているものはすべて、単なる抽象的な考えではなく、少なくとも最初の一歩が踏み出されたものです。

1. 異常検出器。 Graphite ストレージにアクセスし、さまざまなアルゴリズムを使用して各メトリクスをチェックするサービスを作成したいと考えています。 表示したいアルゴリズムがすでに存在し、データがあり、それを操作する方法を知っています。
2. メタデータ。 私たちには多くのサービスがあり、それらは、サービスで働く人々と同じように、時間の経過とともに変化します。 ドキュメントを手動で継続的に保守することはオプションではありません。 そのため、私たちは現在メタデータをマイクロサービスに埋め込んでいます。 開発者、やり取りする言語、SLA 要件、通知の送信先と送信先が記載されています。 サービスをデプロイするとき、すべてのエンティティ データは個別に作成されます。 その結果、XNUMX つのリンクが取得されます。XNUMX つはトリガーへ、もう XNUMX つは Grafana のダッシュボードへです。
3. 各家庭でのモニタリング。 私たちは、すべての開発者がそのようなシステムを使用すべきであると信じています。 この場合、トラフィックがどこにあるのか、トラフィックに何が起こっているのか、どこに落ちているのか、どこに弱点があるのか​​を常に把握できます。 たとえば、何かが発生してサービスがクラッシュした場合、マネージャーからの電話ではなくアラートによってそれを知り、すぐに最新のログを開いてそこで何が起こったのかを確認できます。
4. ハイパフォーマンス。 私たちのプロジェクトは成長を続けており、現在では 2 分あたり約 000 のメトリック値を処理しています。 000 年前、この数字は 500 でしたが、増加は続いており、これは、しばらくすると、Graphite (ささやき) がディスク サブシステムに大きな負荷を与え始めることを意味します。 すでに述べたように、この監視システムはコンポーネントの互換性があるため、非常に汎用的です。 誰かが Graphite 専用のインフラストラクチャを維持し、継続的に拡張していますが、私たちは別の道を進むことにしました。 クリックハウス メトリクスのリポジトリとして。 この移行はほぼ完了しています。間もなく、これがどのように行われたか、どのような困難があり、どのように克服されたか、移行プロセスがどのように行われたか、バインディングとして選択されたコンポーネントとその構成について詳しく説明する予定です。

ご清聴ありがとうございました！ このトピックに関するご質問がございましたら、ここまたは次の投稿でお答えいたします。 おそらく誰かが同様の監視システムを構築したり、同様の状況でクリックハウスに切り替えたりした経験があるので、コメントで共有してください。

出所： habr.com