監視システム-プロメテウス

[写真の一部は問題を示しています-影響の読み取りが監視システムの会場になる可能性があるなど-プロメテウス]

1はじめに

1.1公式紹介

Prometheusは2012年からSoundcloudの元Googleエンジニアであり、オープンソースソフトウェア開発システムの監視およびアラートツールキットの形をとっています。それ以来、多くの企業や組織がPrometheusをアラーム監視ツールとして採用しています。Prometheusの開発者およびユーザーコミュニティは非常に活発であり、現在、どの企業からも独立して維持できる独立したオープンソースプロジェクトです。これを証明するために、2016年5月にPrometheusがCNCF Foundationに参加し、2回目のCNCF管理プロジェクトの後にKubernetesになりました。

簡単な歴史

写真は比較的古く、バージョン2.25に更新されています。

1.2主な機能/利点

多次元データモデル（時系列はメトリック名とk / vラベルで構成されます）
強力なクエリステートメント（PromQL）

如以下案例：查询实例为10.224.192.\d{3}:9100的机器，用户近30s平均cpu使用率。
avg(rate(node_cpu_seconds_total{instance=~"10.224.192.\\d{3}:9100", mode="user"}[30s]))*100

依存関係ストレージはなく、ローカルとリモートのさまざまなモデルをサポートします。単一のサービスノードには自律性があります
httpプロトコルを使用し、プルモードを使用してデータをプルします。シンプルで理解しやすいです。中間ゲートウェイを使用してデータをプッシュすることもできます
ターゲットを監視し、サービス検出または静的構成を使用できます
グラフィカルに対応したさまざまな統計データモデルをサポート

1.3監視システムの比較

監視システム比較チャート

これは、ベテランの監視システムである4つの監視システムZabbixとNagiosの比較です。open
-falconはXiaomiのオープンソース監視システムです。

システムの成熟度の観点から、ZabbixとNagiosはどちらも、比較的安定したシステム機能と高い成熟度を備えたベテランの監視システムです。PrometheusとOpen-Falconはどちらもここ数年で誕生しましたが、機能はまだ繰り返し更新されています。
スケーラビリティ：Prometheusは、さまざまなエクスポータを介してシステム収集機能を拡張し、後で導入されるインターフェイスを介してストレージソリューションを拡張できます。
活動の観点から：Prometheusコミュニティは最も活発であり、CNCFによってもサポートされています。
パフォーマンスに関しては、主な違いはストレージにあります。Prometheusは高性能の時系列データベースを使用し、Zabbixはリレーショナルデータベースを使用し、NagiosとOpen-FalconはどちらもRRDデータストレージを使用します。
コンテナサポートに関して：ZabbixとNagiosは以前に登場し、コンテナはまだ生まれていないため、コンテナのサポートは比較的貧弱です。Open-Falconは、コンテナ監視のサポートが制限されています。Prometheusの動的検出メカニズムは、さまざまなコンテナクラスターの監視をサポートしており、現在、コンテナ監視に最適なソリューションです。

1.4まとめ

Prometheusは、依存関係がほとんどなく、完全な機能を備えたワンストップの監視およびアラームプラットフォームです。
Prometheusはクラウドまたはコンテナの監視をサポートし、他のシステムは主にホストを監視します。
Prometheusデータクエリステートメントは、より強力な組み込み統計関数を使用して、より表現力豊かです。
Prometheusは、データストレージのスケーラビリティと耐久性の点で、InfluxDB、OpenTSDB、Sensuほど優れていません。
該当シーン

Prometheusは、時系列をテキスト形式で記録するのに適しています。マシン中心の監視と非常に動的なサービス指向アーキテクチャの監視の両方に適しています。マイクロサービスの世界では、多次元データの収集とクエリのサポートに特別な利点があります。Prometheusは、システムの信頼性を向上させるように設計されており、停電時の問題を迅速に診断できます。各Prometheusサーバーは互いに独立しており、ネットワークストレージやその他のリモートサービスに依存していません。インフラストラクチャに障害が発生した場合、多くのインフラストラクチャリソースを消費することなく、Prometheusを介して障害のポイントをすばやく見つけることができます。
該当しないシナリオ

Prometheusは信頼性を非常に重視しており、障害が発生した場合でも、システムに関する利用可能な統計情報をいつでも表示できます。リクエスト数に基づく請求など、100％の精度が必要な場合、Prometheusは収集するデータが詳細で完全でない可能性があるため、適切ではありません。この場合、他のシステムを使用して請求用のデータを収集および分析し、Prometheusを使用してシステムの残りの部分を監視することをお勧めします。

2.アーキテクチャ設計

2.1全体的なアーキテクチャ

アーキテクチャ図

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-QWpDeuaA-1617093666707）（https://raw.githubusercontent.com/1458428190/ prometheus-demo / main / images /prometheus.svg）]

Prometheusには、いくつかの主要なコンポーネントが含まれています。つまり、上の図の黄色の部分です。Prometheusサーバー、Pushgateway、Alertmanager、および関連するwebuiです。

Prometheusサーバーは、ターゲットノードにサービス検出または静的構成からデータをプルさせ、定期的にターゲットノードからデータをプルして保存します。ここでのターゲットノードは、httpインターフェイスを介してデータを直接公開するさまざまなエクスポーターです。、またはできます。プッシュデータの受信専用のプッシュゲートウェイです。

Prometheusはさまざまなルールを構成し、定期的にデータをクエリすることもできます。条件がトリガーされると、構成されたアラートマネージャーにアラートがプッシュされます。
最後に、alertmanagerは警告を受け取ります。Alertmanagerは、構成に応じて集約、重複排除、ノイズの低減を行い、最後に警告を送信できます。

Prometheusは、他のprometheusインスタンスからの情報の収集をサポートしています。複数のデータセンターがある場合は、フェデレーションクラスターを介して各データに個別のpromeheusインスタンスをデプロイし、中央のPrometheusサーバーを使用して複数のデータセンターの監視データを集約できます。

2.2メインモジュール

2.2.1プロメテウスサーバー

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止チェーンメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-mJfwjY0Q-1617093666708）（https://raw.githubusercontent.com/1458428190/ prometheus-demo / main / images /prometheus-server.svg）]

動作原理によれば、prometheus自体は最初にScrape Discovery Managerを介してターゲットノードを検出し、次にScrape Managerを使用してインジケーターをスクレイピングし、
次にストレージエージェントレイヤーFanoutストレージを介して対応するローカルストレージまたはリモートストレージにデータを保存します。

ローカルストレージ：カスタムストレージ形式を使用してサンプルデータをローカルディスクに保存しますが、ローカルストレージ自体の信頼性は低く、データの永続性要件が低いシナリオでの使用のみをお勧めします。

リモートストレージ：柔軟に拡張するために、Prometheusは2つの標準インターフェース（remote_write / remote_read）を定義し、ユーザーがこれら2つのインターフェースに基づいてサードパーティのストレージサービスにデータを保存できるようにします。

RuleManagerは、構成されたルールの定期的なクエリを担当します。条件がトリガーされると、結果がストレージに書き込まれ、トリガーする必要のあるアラート情報が通知機能を介してアラートマネージャーにプッシュされます。

2.2.2エクスポーター

エクスポーターをデプロイするだけでよく（公式およびサードパーティのライブラリが多数あるか、自分で実装できます）、データベースインジケーター、ハードウェアインジケーターなど、多くの一般的なインジケーターデータを収集できます...公式ウェブサイトを参照してください。詳細。

2.2.3 alertmanager

2.2.3.1はじめに

アラーム機能は、Prometheusアーキテクチャで2つの独立した部分に分割されています。PrometheusサーバーでAlertRuleを定義することにより、Prometheusは定期的にアラートルールを計算し、アラートトリガー条件が満たされると、アラート情報をAlertmanagerに送信します。

データフローチャート

アラートルールの構成：

アラーム名

ユーザーはアラームルールに名前を付ける必要があります。もちろん、名前を付けるには、アラームの主な内容を直接表現できる必要があります。
アラートルール

アラームルールは実際にはPromQLによって定義され、その実際の意味は、式（PromQL）のクエリ結果がアラームがトリガーされる時間（During）の間続く場合です。

Alertmanagerは、独立したコンポーネントとして、Prometheus Server（または他のクライアントプログラム）からのアラート情報の受信と処理を担当します。Alertmanagerは、重複排除、グループ化、ルーティングなど、これらのアラート情報に対してさらに処理を実行できます。現在、Prometheusには、電子メールやSlackなどの複数の通知方法のサポートが組み込まれています。popoやSMS通知などの他の通知方法は、Webhookを介して実装できます。

これが背景知識です。PrometheusエコシステムのアラートはPrometheusサーバーで計算および生成されます。いわゆるアラートルールは実際にはPromQLの期間中定期的に実行され、クエリの結果が記録されます。時系列アラームに使用されるアラート{alertname = ""、<alerttag>}は後続のアラームに使用されます。Prometheus Serverがいくつかのアラームを計算するとき、これらのアラームを通知する機能はありません。アラームをAlertmanagerにプッシュすることしかできず、Alertmanagerはそれらを送信します。このセグメンテーションは、一方では単一責任の考慮によるものであり、他方では、アラーム送信は実際には「単純な」ものではなく、それをうまく行うには特別なシステムが必要であるためです。Alertmanagerの目的は、単に「アラートを送信する」ことではなく、「高品質のアラートを送信する」ことであると言えます。

2.2.3.2機能

Alertmanagerは、基本的なアラート通知機能を提供するだけでなく、グループ化、抑制、無音などのアラート機能も提供します。

グループ化：グループ化メカニズムは、詳細なアラーム情報を1つの通知に組み合わせることができます

グループ化メカニズムは、詳細なアラーム情報を1つの通知に組み合わせることができます。たとえば、システムのダウンタイムが原因で、同時に多数のアラームがトリガーされる場合があります。この場合、グループ化メカニズムは、これらのトリガーされたアラームを1つのアラーム通知に結合して、で多数のアラーム通知を受信しないようにすることができます。一度。問題をすばやく特定します。

たとえば、クラスター内に数百の実行中のサービスインスタンスがあり、インスタンスごとにアラームルールが設定されている場合です。この時点でネットワーク障害が発生すると、多数のサービスインスタンスがデータベースに接続できなくなる可能性があり、その結果、何百ものアラームがAlertmanagerに送信されます。ユーザーとして、1つの通知で影響を受けるサービスインスタンスのみを確認したい場合があります。このとき、アラームはサービスクラスタまたはアラーム名に従ってグループ化でき、これらのアラームをグループ化して通知を形成できます。

アラームのグループ化、アラーム時間、およびアラームの受信方法は、Alertmanagerの構成ファイルを介して構成できます。
抑制：アラームが送信されると、アラームメカニズムによって引き起こされた他のアラームの繰り返し送信を停止できます

抑制とは、特定のアラームが送信された後、このアラームによって引き起こされた他のアラームの送信を繰り返し停止できるメカニズムを指します。

たとえば、クラスタにアクセスできないときにアラームがトリガーされた場合、Alertmanagerを設定することで、クラスタに関連する他のすべてのアラームを無視できます。これにより、実際の問題に関係のない多数のアラーム通知を受信することを回避できます。抑制メカニズムは、Alertmanagerの構成ファイルでも設定されます。
- Silence：タグに基づいてアラームをすばやくサイレントに処理するためのシンプルなメカニズムを提供します。受信したアラームがサイレント構成と一致する場合、Alertmanagerはアラーム通知を送信しません
  
  Silenceは、タグに基づいてアラームをすばやくサイレントに処理するためのシンプルなメカニズムを提供します。受信したアラームがサイレント構成と一致する場合、Alertmanagerはアラーム通知を送信しません。サイレント設定は、AlertmanagerのWerbページで設定する必要があります。

2.2.3.3アーキテクチャ

[外部リンク画像の転送に失敗しました。ソースサイトにヒル防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img-Ee2TYGsR-1617093666711）（https://raw.githubusercontent.com/1458428190/ prometheus-demo / main / images /alertmanager.svg）]

左上から、プロメテウスサーバーでアラームルールが設定されます。デフォルトでは、これらのアラームルールは毎分計算されます。トリガー条件が満たされると、アラームレコードが生成され、APIを介してアラートマネージャにプッシュされます。
Alertmanagerは、APIを介してアラートレコードを受信し、アラート情報を検証、変換して、最後にAlertProviderに格納します。ここでの現在の実装はメモリに格納され、他のストレージメソッドはインターフェイスを介して単独で実装できます。
ディスパッチャは常に新しいアラームをリッスンして受信し、ルーティングツリーの構成に従って対応するグループにアラームをルーティングします。これにより、同じ属性情報を持つアラームの統合管理が容易になります[group_by **を介してグループ化ルール。アラームに含まれるラベルに基づく]。これにより、アラームストームを大幅に減らすことができます。
各グループは、構成されたサイクルタイムで通知パイプラインプロセス処理を定期的に実行します。
この通知パイプラインプロセスは、実際に抑制ロジック、サイレントロジック、データ収集の待機、重複排除、送信および再試行ロジックを実行し、最終的にアラームを実現します。アラームが完了すると、通知レコードはクラスターに同期され、その後、次の目的で使用されます。クラスター間の沈黙と重複排除

アラーム抑制

特定の問題アラームが生成された後、ユーザーが問題によって引き起こされた他の多数のアラーム通知を受信するのを回避できます。たとえば、クラスターが使用できない場合、ユーザーは、クラスター内の異常なアプリケーションや異常なミドルウェアなどの多数のアラーム通知ではなく、現時点でクラスターに問題があることを通知するアラームのみを受信したい場合があります。サービス。
```
inhibit_rules:
- source_match:
    alertname: NodeDown
    severity: critical
  target_match:
    severity: warning
  equal:
  - node
```
たとえば、クラスタ内の特定のホストノードが異常にダウンすると、アラームNodeDownがトリガーされ、アラームレベルseverity = criticalがアラームルールで定義されます。ホストの異常なダウンタイムが原因で、ホストにデプロイされているすべてのサービスとミドルウェアが使用できなくなり、アラームがトリガーされます。抑制ルールの定義によれば、重大度=クリティカルの新しいアラームレベルがあり、アラームのラベルノードの値がNodeDownアラームの値と同じである場合、新しいアラームはNodeDownによって発生していることを意味します。、および抑制メカニズムが開始され、受信者への送信が停止します。通知。
アラートの沈黙

ユーザーは、バックグラウンドまたはAPI構成を介して特定のアラーム通知を一時的にブロックします。ラベルの一致ルール（文字列または正規表現）を定義することにより、新しいアラーム通知がサイレントルールの設定を満たしている場合、受信者への通知の送信を停止します。

2.2.4プッシュゲートウェイ

その存在により、短期間のバッチジョブでそのメトリックをPrometheusに公開できます。これらのジョブのライフサイクルは十分に長くない可能性があるため、Prometheusがメトリックをクロールするのに十分な時間はありません。Pushgatewayを使用すると、メトリックをPushgatewayにプッシュでき、PushgatewayはこれらのメトリックをPrometheusに公開してクロールします。

それを使用する主な理由は次のとおりです。

Prometheusはプルモードを使用します。Prometheusは、同じサブネットまたはファイアウォールにないため、ターゲットデータを直接プルできない場合があります。
ビジネスデータを監視する場合、Prometheusがさまざまなデータを集約および収集する必要があります。
一時的なタスクのデータ収集

短所：

複数のノードからプッシュゲートウェイにデータを集約します。プッシュゲートウェイに障害が発生した場合、影響は複数のターゲットよりも大きくなります。
プッシュupゲートウェイのみのプロメテウスプル状態は、各ノードで有効にすることはできません。
Pushgatewayは、プッシュされたすべての監視データを保持できます。

したがって、モニタリングがオフラインの場合でも、prometheusは古いモニタリングデータをプルし、プッシュゲートウェイで必要とされないデータを手動でクリーンアップする必要があります。

3.統合する方法

詳細については別の記事を参照してください〜https：//juejin.cn/post/6943406808513904654