幸いなことに、モニタリングの問題には、有償と無料の両方の多くの解決策があります。 オープンソース監視システムPrometheusの実用化の経験を共有したいと思います。
プロメテウスの紹介
真剣に、最近マイクロサービスアーキテクチャに出会い、既存のサービスインフラストラクチャで作業を開始しました。 Zabbixは 、サーバーのステータスを監視し、メトリックを収集するために使用されました。 Zabbixは管理者によって設定され、スケジュールのすべての変更/追加はそれらを通過する必要がありました。 このアプローチにより、特に異なる開発チームが同じ監視システムを使用する場合に、責任範囲を分割できます。 ただし、同時に、管理者はタスクを設定したり、他のタスクで忙しい開発者に明らかな詳細に注意を払ったりできないため、新しいスケジュールを追加するときに遅延や不正確さが生じます。 問題は、さらなる開発がサービスメトリックによる履歴データへの迅速なアクセスを必要とする場合に特に深刻になります。 この問題を解決する手段として、既存のインフラストラクチャにうまく適合し、メトリックの分析作業を簡素化する、簡単で構成しやすい監視システムを探すことにしました。
Prometheus監視システムの最小構成は、Prometheusサーバーと監視対象アプリケーションで構成されています。メトリックを要求する必要があるアドレスを指定するだけです。 メトリックは、HTTPプロトコルを使用してプルモデルに従って収集されますが、短命のサービスを監視するためのプッシュゲートウェイコンポーネントもあります。 プルモデルを使用する場合、アプリケーションは監視システムを認識しません。つまり、監視のために複数のPrometheusサーバーを実行できるため、データ損失の可能性がなくなります。 さらに監視するためにアプリケーションを準備するには、さまざまな言語のメトリックを作成および表示するために必要なツールを実装するクライアントライブラリを使用することをお勧めします。 これらを使用することをお勧めしますが、 博覧会形式の仕様を満たす場合は実装を使用できます 。
Zabbixのメトリクスの収集は同様のスキームに従って実行されたため、このアプローチは私の要件を完全に満たしました。 Zabbixおよびすでに使用されているメトリックのライブラリとの互換性を維持するために、既存の形式をPrometheusに適した形式に変換するアダプタが作成されました。 このソリューションにより、Zabbixで監視を「ヒット」することなく、既存のサービスの安定性を維持しながら、Prometheusを簡単に試すことができました。
使用する
プロメテウスを使用する利点はすぐに明らかになりました。 Webインターフェイスのメインページを離れずに、メトリックの変化のダイナミクスを取得したり、他と比較したり、変換したり、テキスト形式またはグラフで表示したりする能力をいつでも過大評価することは困難です。
メトリックのフィルタリングと変換には、非常に便利なクエリ言語が使用されます。 残念ながら、生成されたリクエストをWebインターフェースから直接保存する方法はありません。 これを行うには、 Go-templatesを使用する機能を持つhtmlページであるコンソールを作成し、その中にすでにグラフ、表、要約などを作成する必要があります。
良い解決策は、汎用コンソールを作成することです。 たとえば、複数のHTTPサーバーを監視する必要があります。 それぞれにメトリックがあり、たとえば、「http_requests_total」は受信したHTTPリクエストの数を示します。 このようなサービスのリストを、より詳細な情報を含むコンソールへのリンクの形式で表示するコンソールを作成します。
{{ range query "sum(http_requests_total) by (instance)" | sortByLabel "instance" }} <a href="/consoles/job-overview.html?instance={{ .Labels.instance }}">{{ .Labels.job }}</a> {{ end }}
その結果、「instance」パラメーターが渡される「job-overview.html」コンソールへのリンクのリストを取得します。 これで、このパラメーターをグラフのフィルターとして使用できます。
new PromConsole.Graph({ node: document.querySelector("#successGraph"), expr: [ "sum(http_requests_success{instance='{{ .Params.instance }}' })" ], name: http_requests_success, })
追加の例のソースとして、コンソールの標準セットを使用できます。
性能
開発者によると 、1台のPrometheusサーバーで数百万の時系列を簡単に処理できます。 これは、10秒の間隔で数千のサーバーからデータを収集するのに十分です。 これで十分でない場合、 スケーリングの可能性が提供されます。
実際には、要求されたパフォーマンスが確認されます。 800個のサービス（それぞれ約80メトリック）を監視する場合、Prometheusは1コアの約6％と3 GBのRAMを使用し、15日間で収集されたメトリックはディスク上の17 GBのメモリを占有します。 Prometheusに別のサーバーを割り当てる必要はありません。リソースの消費量が非常に少ないため、他のサービスの隣に不都合なくインストールできます。
Prometheusは収集したメトリックをRAMに保存し、サイズ制限に達するか、一定の時間間隔が経過すると、それらをディスクに保存します。 大量のデータ（たとえば、10万時系列以上）を収集する必要がある場合、ディスクの負荷が増加する可能性があります。 プロメテウスのドキュメントは、このような場合に役立つ最適化のヒントを提供します。
重い計算を必要とするスケジュールを作成する必要がある場合、長い時間をキャプチャする場合、または出席率が高い場合があります。 プロメテウスの作業を促進し、各リクエストでそのようなデータを計算しないために、 予備計算の可能性があります 。 このオプションは、ダッシュボードを作成するときに特に役立ちます。
カスタマイズ
率直に言って、Webベースのインターフェイスは少し気が引けたように思えました。 グラフ、メトリック、および監視可能なサービスのセクション（/ターゲット）を操作する場合、追加機能が発生しました。 これには問題はありませんでしたが、すぐに、メトリックタグですばやく検索する機能を追加し、コンソールセクションのレイアウトを変更しました。 / targetsセクションが800個のサービスに拡張されたとき、ページ上のエンドポイントを非表示にし、それらをグループに結合する必要がありました（そうでなければ、スペースを使いすぎてしまいました）。 エンドポイントのいずれかが正常に機能しなくなると、エラーを通知するアイコンがグループに追加されます。 シートを展開すると、問題のあるエンドポイントを見つけて、エラーに関する詳細情報を見つけることができます。
WebインターフェースのシンプルさPrometheusは、標準インターフェースを変更したり、新しいセクションを追加したりするテーマを作成するための幅広い可能性を開きます。 上記の確認として、グラフィカル構成ジェネレーターを理解することを提案します 。
追加ソフトウェア
Prometheus開発チームは、統合のために可能な限りオープンなプロジェクトを作成します。これは他のテクノロジーと組み合わせて使用でき、コミュニティは最善を尽くして支援しています。 PrometheusのWebサイトで、サポートされているエクスポーターのリストを見つけることができます-他のサービスおよびテクノロジーからメトリックを取得するパッケージ。 node_exporter 、 postgres_exporterおよびgrok_exporterを使用します。 それらのために、一般化されたコンソールが構築され、そのグラフは表示されているサービスに関連して構築されます。 新しく追加または検出された（ サービス検出 ）サービスはすべて、以前に作成したコンソールで自動的に表示できます。 技術の「動物園」全体がある場合、それらを監視するために多くのエクスポーターをインストールする必要がありますが、このアプローチには論理的根拠があります。
セキュリティ状況は奇妙に見えるかもしれません。 当初、プロメテウスサービスと確立された輸出業者は「世界に開かれています」。 目的のアドレスとポートを知っている人は誰でも、メトリックスに従ってデータを受信できます。 ここでの開発者の立場はこれです-プロメテウスはセキュリティではなく監視システムです。 このようなタスクを長期間にわたって正常に実装してきたサードパーティのサードパーティ製品をユーザーが使用することは難しくなく、Prometheus開発者はタスクの監視に集中できます。 私の場合、Nginxはhttp基本認証でリバースプロキシとして正常に使用され、設定に非常に短い時間がかかりました。
睡眠と平和を奪いたい人のために、開発者はAlertManagerを使用する機能を提供します。 構成は非常に簡単で、既に説明したクエリ言語を使用できます。 AlertManagerはHipChat、Slack、PagerDutyと統合でき、必要に応じて、まだサポートされていないサービスとの統合が可能です。 音声アラートの統合に関する記事を読むことをお勧めします。
実際の例として、現在のAlertManager構成のルールを次に示します。
ALERT nodeexporter_available_disk_space IF (100 - node_filesystem_free{job=~".*nodeexporter"} / node_filesystem_size{job=~".*nodeexporter"} * 100) > 70 ANNOTATIONS {description="Used disk space: {{ $value }}%. Device: {{ $labels.device }}.", summary="Running out of disk space at instance {{ $labels.instance }}"}
このルールは、node_exporterを実行しているサーバーのいずれかでディスク容量が70％以上満たされている場合に機能し、その後、対応する電子メール通知が送信されます。
おわりに
プロメテウスをもっと身近に知ることをお勧めします。 私にとって、それは簡単でシンプルで理解しやすい監視システムになりました。ニーズに合わせて作業し、拡張し、変更するだけでいいです。 実用的なアプリケーションに関する質問がある場合は、コメントでお答えします。