監視の仕組み

Prometheus Operatorは、ServiceMonitors、PodMonitors、およびPrometheusRulesの作成を監視します。Prometheusの設定リソースが作成されると、Prometheus Operatorは新しい設定をsyncするためにPrometheus APIを呼び出します。このセクションの最後にある図が示すように、Prometheus OperatorはPrometheusとKubernetesの間の仲介者として機能し、Prometheus APIを呼び出してPrometheusをKubernetes内の監視関連リソースとsyncさせます。

ServiceMonitorsとPodMonitorsは、監視が必要なターゲット（サービスやポッドなど）を宣言的に指定します。

PrometheusRulesは、ユーザーがアラートを発火させるべきメトリクスや時系列データベースクエリのルールを定義できるようにします。ルールは間隔で評価されます。

Prometheusがアラートを発火させる必要があると判断すると、アラートは*Alertmanager*に転送されます。

エクスポーターからメトリクスを収集した後、プロメテウスはローカルのディスク上の時系列データベースに時系列を保存します。プロメテウスはリモートシステムとオプションで統合できますが、`rancher-monitoring`は時系列データベースのためにローカルストレージを使用します。

保存された後、ユーザーはプロメテウスのクエリ言語であるPromQLを使用してこのTSDBをクエリできます。

PromQLクエリは、次の2つの方法のいずれかで視覚化できます：

ルールは、プロメテウスが特定のアクションを実行するために、定期的に`evaluationInterval`上で実行する必要があるクエリを定義します。例えば、アラートを発火させる（アラートルール）またはTSDBに存在する他のクエリに基づいてクエリを事前計算する（レコーディングルール）などです。これらのルールは、PrometheusRulesカスタムリソースにエンコードされています。PrometheusRuleカスタムリソースが作成または更新されると、プロメテウスオペレーターは変更を観察し、Prometheus APIを呼び出して、プロメテウスが現在定期的に評価しているルールのセットをsyncします。

PrometheusRuleは、1つ以上のRuleGroupを定義することを可能にします。各RuleGroupは、アラートルールまたはレコーディングルールを表すことができるRuleオブジェクトのセットで構成されています。以下のフィールドがあります：

ruleを評価すると、Prometheusは提供されたPromQLクエリを実行し、提供されたラベルを追加し、ルールに対して適切なアクションを実行します。ルールがアラートをトリガーすると、Prometheusは提供された注釈も追加します。例えば、提供されたPromQLクエリにラベルとして`team: front-end`を追加するアラートルールは、そのラベルを発火したアラートに追加し、Alertmanagerがアラートを正しい受信者に転送できるようにします。

Prometheusはアラートがアクティブであるかどうかの状態を維持しません。アラートは評価間隔ごとに繰り返し発火し、Alertmanagerにアラートをグループ化し、意味のある通知にフィルタリングさせます。

`evaluation_interval`定数は、Prometheusが時系列データベースに対してアラートルールを評価する頻度を定義します。`scrape_interval`と同様に、`evaluation_interval`もデフォルトで1分です。

ルールは一連のルールファイルに含まれています。ルールファイルにはアラートルールと記録ルールの両方が含まれていますが、アラートルールのみが評価後にアラートを発生させます。

記録ルールの場合、Prometheusはクエリを実行し、それを時系列として保存します。この合成時系列は、高価または時間のかかるクエリの結果を保存するのに役立ち、将来的により迅速にクエリできるようになります。

アラートルールはより一般的に使用されます。アラートルールが正の数に評価されるたびに、Prometheusはアラートを発生させます。

ルールファイルは、ユースケースに応じてアラートにラベルと注釈を追加します。

alertingDriversがインストールされると、alertingDriverの設定に基づき、TeamsやSMSの受信者URLとして利用できる`Service`が作成されます。ReceiverのURLはalertingDriversを指しているため、Alertmanagerは最初にalertingDriverにアラートを送信し、その後alertingDriverがアラートを適切な宛先に転送または送信します。

Alertmanagerはアラートが送信される場所を調整します。特定のラベルが一致するかどうかに基づいて、アラートをグループ化し、発火させることができます。1つのトップレベルのルートはすべてのアラートを受け入れます。そこから、Alertmanagerは次のルートの条件に一致するかどうかに基づいてアラートを受信者にルーティングし続けます。

Rancher UIのフォームは2レベル深いルーティングツリーの編集のみを許可しますが、Alertmanager Secretを編集することで、より深くネストされたルーティング構造を構成できます。

Rancher UIのフォームを編集することで、Alertmanagerが通知システムにアラートを送信するために必要なすべての情報を持つReceiverリソースを設定できます。

AlertmanagerまたはReceiverの設定でカスタムYAMLを編集することで、複数の通知システムにアラートを送信することもできます。詳細については、Receiverの設定に関するセクションを参照してください。

デフォルトでは、 kube-prometheusプロジェクトによってキュレーションされた一連のリソースが、基本的なモニタリング/アラートスタックを設定するためにRancher Monitoringアプリケーションをインストールする際に、クラスターにデプロイされます。

このソリューションをサポートするためにクラスターにデプロイされるリソースは、 rancher-monitoring Helmチャートに見つけることができ、これはPrometheusコミュニティによって維持されている上流の kube-prometheus-stack Helmチャートを密接に追跡し、 CHANGELOG.mdで追跡される特定の変更があります。

Monitoring V2は、Prometheusが保存するための追加のメトリクスを提供する3つのデフォルトエクスポーターをデプロイします：

ServiceMonitorsとPodMonitorsは、ここで定義されたように、これらのエクスポーターをスクレイプします。Prometheusはこれらのメトリクスを保存し、PrometheusのUIまたはGrafanaを介して結果をクエリできます。

記録ルール、アラートルール、およびAlertmanagerに関する詳細情報は、アーキテクチャセクションを参照してください。

モニタリングアプリケーションがインストールされると、Rancher UIで以下のコンポーネントを編集できるようになります：

PushProxは、Prometheusがネットワーク境界を越えてメトリクスをスクレイプできるようにし、Kubernetesクラスター内の各ノードで内部Kubernetesコンポーネントのメトリクス用ポートを公開する必要がなくなります。

Kubernetesコンポーネントのメトリクスは一般的にクラスター内のノードのホストネットワークで公開されるため、PushProxは各ノードのhostNetwork上にクライアントのDaemonSetをデプロイし、Kubernetes API上にある単一のプロキシに対して外向きの接続を行います。その後、Prometheusはプロキシを介して各クライアントへのスクレイプリクエストをプロキシするように構成でき、これにより内部Kubernetesコンポーネントからメトリクスをスクレイプする際に、受信ノードポートを開く必要がなくなります。

詳細については、PushProxによるメトリクスのスクレイピングを参照してください。

ServiceMonitorsとPodMonitorsは、Prometheusがスクレイプすることを意図したターゲットを定義します。 Prometheusカスタムリソースは、Prometheusがメトリクスをスクレイプする場所を見つけるために使用すべきServiceMonitorsまたはPodMonitorsを指示します。

Prometheusオペレーターは、ServiceMonitorsとPodMonitorsを監視します。それらが作成または更新されたことを観察すると、Prometheus APIを呼び出してPrometheusカスタムリソース内のスクレイプ設定を更新し、ServiceMonitorsまたはPodMonitors内のスクレイプ設定とsyncを保ちます。このスクレイプ設定は、Prometheusにどのエンドポイントからメトリクスをスクレイプするか、そしてそれらのエンドポイントからのメトリクスにどのようにラベルを付けるかを指示します。

Prometheusは、デフォルトで1分ごとに`scrape_interval`スクレイプ設定で定義されたすべてのメトリクスをスクレイプします。

スクレイプ設定は、Rancher UIで公開されているPrometheusカスタムリソースの一部として表示できます。

Prometheusのデプロイメントまたはステートフルセットがメトリクスをスクレイピングし、Prometheusの設定はPrometheusカスタムリソースによって制御されます。PrometheusオペレーターはPrometheusおよびAlertmanagerリソースを監視し、それらが作成されると、ユーザー定義の設定でPrometheusまたはAlertmanagerのデプロイメントまたはステートフルセットを作成します。

PrometheusオペレーターがServiceMonitors、PodMonitors、およびPrometheusRulesが作成されるのを観察すると、Prometheusのスクレイプ設定を更新する必要があることを知ります。最初にPrometheusのデプロイメントまたはステートフルセットのボリューム内の設定およびルールファイルを更新することによって、Prometheusを更新します。次に、Prometheus APIを呼び出して新しい設定をsyncさせ、その結果、Prometheusのデプロイメントまたはステートフルセットがその場で修正されます。

Prometheusは、Prometheusが取り込むことができる形式で時系列データをエクスポートする エクスポータ,として知られるデプロイメントからメトリクスをスクレイピングします。Prometheusにおいて、時系列は同じメトリクスおよび同じラベル付き次元のストリームのタイムスタンプ付き値の集合で構成されます。

特定の内部Kubernetesコンポーネントは、PushProxと呼ばれるMonitoring V2の一部としてデプロイされたプロキシを介してスクレイピングされます。PushProxに関する詳細情報は、こちらおよび上記のアーキテクチャセクションを参照してください。

以下のKubernetesコンポーネントは、Prometheusによって直接スクレイピングされます：

メトリクスはKubernetesディストリビューションに基づいて異なる方法でスクレイピングされます。用語に関するヘルプについては、こちらを参照してください。詳細については、以下の表をご覧ください：