クラウドネイティブのインストールと展開の詳細な分析と Prometheus の原理分析

1. プロメテウスの紹介

①プロメテウスの特徴

Prometheus は元々、SoundCloud によって開発されたオープンソースの監視および警報システムであり、Google の BorgMon 監視システムのオープンソースバージョンです。2016 年に Prometheus は CNCF に加わり、Kubernetes に次いで CNCF がホストする 2 番目のプロジェクトとなりました。コンテナ配置における Kubernetes の主導的地位の確立に伴い、Prometheus は Kubernetes コンテナ監視の標準構成にもなりました。
Prometheus の主な機能は次のとおりです。
- メトリック名とラベル (キーと値のペア) によって区別される多次元の時系列データモデル。
- 柔軟なクエリ構文 PromQL。
- サービスノードは、追加のストレージに依存せずに動作できます。
- http プロトコルを使用して、プルモードを通じて時系列データを収集します。
- プッシュモードを必要とするアプリケーションは、ミドルウェアゲートウェイを通じて実装できます。
- 監視ターゲットはサービス検出と静的構成をサポートします。
- さまざまなチャートとダッシュボードのコンポーネントをサポートします。

②Prometheusコアコンポーネント

Prometheus エコシステム全体には複数のコンポーネントが含まれており、Prometheus サーバーコンポーネントを除くすべてのコンポーネントはオプションです。
- Prometheus Server: 時系列データの収集と保存に使用される主要なコアコンポーネント。
- クライアントライブラリ: クライアントライブラリは、監視する必要があるサービスに対応するメトリックを生成し、それらを Prometheus サーバーに公開します。Prometheus サーバーがプルするようになると、リアルタイムメトリックを直接返します。
- プッシュゲートウェイ: 主に短期間のジョブに使用されます。このようなジョブは短期間存在するため、Prometheus がプルする前に消滅する可能性があります。このため、ジョブは自身のメトリクスを Prometheus サーバーに直接プッシュできます。主にこの方法が使用されますサービスレベルのメトリック、マシンレベルのメトリックの場合は、ノードエクスポーターを使用する必要があります。
- エクスポーター: 既存のサードパーティサービスのメトリクスを Prometheus に公開するために使用されます。
- アラートマネージャー: Prometheus サーバーからアラートを受信した後、重複データを削除し、それらをグループ化し、受信メソッドにルーティングして、アラームを送信します。一般的な受信メソッドには、電子メール、ポケットベルデューティ、OpsGenie、Webhook などが含まれます。
- 各種サポートツール。

③プロメテウスフレームワーク

取得は、公開されたターゲットページ上のサンプリングインジケータデータを定期的にキャプチャする責任があります。
ストレージは、サンプリングデータを指定された時系列データベースストレージに書き込む役割を果たします。
PromQL は Prometheus によって提供されるクエリ言語モジュールであり、grfana などの一部の Webui と統合できます。
ジョブ/エクスポーター: Prometheus はジョブまたはエクスポーターから監視データを取得でき、エクスポーターは Web API の形式でデータ収集インターフェイスを公開します。
Prometheus サーバー: Prometheus は、他の Prometheus サーバーからデータを取得することもできます。
Pushgateway: 一時ジョブとして実行される一部のコンポーネントについては、Prometheus がそれらから監視データをプルする時間がない場合があります。これらのジョブは終了しており、ジョブランタイムは実行時に監視データを Pushgateway にプッシュでき、Prometheus は監視データをプルします。 Pushgateway からデータをプルして、監視データの損失を防ぎます。
サービス検出: Prometheus は一部のサービスを動的に検出し、DNS、Kubernetes、Consul などから監視用のデータをプルできます。file_sd は静的に構成されたファイルです。
AlertManager: Prometheus から独立した外部コンポーネントであり、システムアラートの監視に使用されます。一部のアラートルールは構成ファイルを通じて構成でき、Prometheus はアラートを AlertManager にプッシュします。

ここに画像の説明を挿入

④ ワークフロー

Prometheus サーバーは、構成されたジョブまたはエクスポーターからメトリクスを定期的に取得するか、Pushgateway からメトリクスを受信するか、他の Prometheus サーバーからメトリクスを取得します。
Prometheus サーバーは、収集したメトリクスをローカルに保存し、定義されたalert.rules を実行して、新しい時系列を記録するか、アラートを Alertmanager にプッシュします。
Alertmanager は、受信したアラートを処理し、設定ファイルに従ってアラートを送信します。
グラフィカルインターフェイスで、収集されたデータを視覚化します。

2. Prometheusの展開

①gitをインストールする

$ yum install -y git

kube-プロメテウスをダウンロードします。

# 下载
$ git clone https://github.com/prometheus-operator/kube-prometheus.git
$ cd kube-prometheus/manifests
# yaml文件比较多，进行归档
$ mkdir -p serviceMonitor prometheus adapter node-exporter blackbox kube-state-metrics grafana alertmanager operator other/{
    
    nfs-storage,ingress}
$ mv alertmanager-* alertmanager/ && mv blackbox-exporter-* blackbox/ &&  mv grafana-* grafana/ && mv kube-state-metrics-* kube-state-metrics/ && mv node-exporter-*  node-exporter/ && mv prometheus-adapter-* adapter/ && mv prometheus-* prometheus/ && mv kubernetes-serviceMonitor* serviceMonitor/
$

②ミラーソースを変更する

外国のミラーソースからの一部のイメージはプルできません。ここで、prometheus-operator、prometheus、alertmanager、kube-state-metrics、node-exporter、および prometheus-adapter のミラーソースを国内のミラーソースに変更します。

# 查找
$ grep -rn 'quay.io' *
# 批量替换
$ sed -i 's/quay.io/quay.mirrors.ustc.edu.cn/g' `grep "quay.io" -rl *`
# 再查找
$ grep -rn 'quay.io' *
$ grep -rn 'image: ' *

ここに画像の説明を挿入

③タイプをNodePortに変更します。

prometheus、alertmanager、grafana に外部からアクセスするには、prometheus、alertmanager、grafana のサービスタイプを NodePort タイプに変更します。
プロメテウスのサービスを変更します。

# 设置对外访问端口：30080
$ cat prometheus-service.yaml

ここに画像の説明を挿入

grafana のサービスを変更します。

# 设置对外访问端口：30081
$ cat grafana-service.yaml

ここに画像の説明を挿入

アラートマネージャーのサービスを変更します。

# 设置对外访问端口：30082
$ cat alertmanager-service.yaml

ここに画像の説明を挿入

CRD と prometheus-operator をインストールします。

$ kubectl apply -f setup/

prometheus-operator イメージのダウンロードには数分かかります。prometheus-operator が実行されるまで待ちます。

$ kubectl get pod -n monitoring

ここに画像の説明を挿入

prometheus、alertmanager、grafana、kube-state-metrics、node-exporter およびその他のリソースをインストールします。

$ kubectl apply -f .

しばらく待ってから再度確認し、監視名前空間の下のすべてのポッドが実行ステータスに変わるまで、監視名前空間の下のポッドのステータスを確認して、完了します。

$ kubectl get pod -n monitoring

ここに画像の説明を挿入

ワークフロー: Prometheus Server は、設定されたエクスポータ/ジョブからメトリクス、プッシュゲートウェイによって送信されたメトリクス、またはその他のメトリクスを定期的に取得し、収集後に定義されたalert.rules を実行し、時系列を記録するか、アラートを Alertmanager にプッシュします。
コンポーネントの説明:
- node_exporter: 計算ノード上のホストのリソース情報を監視するために使用され、すべての計算ノードに展開する必要があります。
- kube-state-metric: prometheus が k8s リソースデータを収集するエクスポーターは、ポッド、デプロイ、サービスなど、ほとんどの k8s 組み込みリソースの関連データを収集できます。また、独自のデータ (主に数とデータ) も提供します。リソースのコレクション発生した例外の数に関する統計。
- blackbox_exporter: ビジネスコンテナの存続可能性を監視します。
- prometheus-adapter: prometheus 自体はサードパーティソリューションであるため、ネイティブの k8s システムは Prometheus のカスタムインジケーターを分析できません。そのため、k8s-prometheus-adapter を使用して、これらのインジケーターデータクエリインターフェイスを標準の Kubernetes 自動定義に変換する必要があります。指標;
確認：

$ kubectl get svc -n monitoring

ここに画像の説明を挿入

ブラウザアクセス:
- プロメテウス：http://192.168.0.113:30080/：

ここに画像の説明を挿入

- グラファナ: http://192.168.0.113:30081/login、デフォルトのアカウント/パスワード: admin/admin:

ここに画像の説明を挿入

- アラートマネージャー：http://192.168.0.113:30082/：

ここに画像の説明を挿入

Grafana はデータソースを追加し、プロメテウスアドレスを変更します。

ここに画像の説明を挿入

ダッシュボードをインポートする:
- ダッシュボードの公式 Web サイトからテンプレートをダウンロードしてインポートします。

ここに画像の説明を挿入

- kubernetes テンプレートのインポート (k8s テンプレート):

ここに画像の説明を挿入

3. プロメテウス関連の概念

① 内部記憶機構

Prometheus には、非常に効率的な時系列データの保存方法があります。サンプリングされた各データは、約 3.5 バイトのスペースしか占有しません。数百万の時系列、30 秒間隔、60 日間の保持には、200 G 以上のコストがかかります。
Prometheus は主に 3 つの主要なブロックに分かれています。
- 取得は、公開されたターゲットページ上のサンプリングインジケータデータを定期的にキャプチャする責任があります。
- ストレージは、サンプリングされたデータをディスクに書き込む役割を果たします。
- PromQL は、Prometheus が提供するクエリ言語モジュールです。

ここに画像の説明を挿入

② データモデル

Prometheus によって保存されるすべてのデータは時系列データ (Time Serie Data、時系列データと呼ばれます) であり、時系列データはタイムスタンプを持つデータストリームであり、データストリームはメトリック (Metric) とメトリックの下の複数のタグに属します。（ラベル）：

ここに画像の説明を挿入

各メトリック名はインジケーターのタイプを表し、異なるラベルを付けることができます。各メトリック名とラベルを組み合わせて時系列データを表します。Prometheus では、すべての値が 64 ビットであり、各時系列に記録されるのは、実際には 64 ビットのタイムスタンプ (タイムスタンプ) + 64 ビットの値 (サンプリング値) です。
- メトリクス名 (インデックス名): 名前にはセマンティクスが必要で、通常はメトリクスの機能を表すために使用されます。たとえば、http_requests_total、http リクエストの総数を表します。メトリクス名は ASCII 文字、数字、アンダースコアとコロン、正規表現 [a-zA-Z_:][a-zA-Z0-9_:]*; を満たす必要があります。
- ラベル (ラベル): 同じ時系列に異なるディメンションを持たせて識別します。たとえば、 http_requests_total{method="Get"} は、すべての http リクエスト内の Get リクエストを意味します。Method="post" の場合、それは新しいメトリックです。ラベルのキーは ASCII 文字、数字、アンダースコアで構成され、正規表現 [a-zA-Z_:][a-zA-Z0-] を満たす必要があります。 9_:]*;
- タイムスタンプ (タイムスタンプ): データポイントの時刻。データの記録時刻を示します。
- サンプル値: 実際の時系列。各系列には float64 値とミリ秒レベルのタイムスタンプが含まれます。

http_requests_total{
    
    status="200",method="GET"}
http_requests_total{
    
    status="404",method="GET"}

上記の分析によると、時系列のストレージは (BigTable に基づいて) キーと値のストレージとして設計されているようです。

ここに画像の説明を挿入

さらに分割すると、次のようになります。

ここに画像の説明を挿入

上図の 2 番目のスタイルは Prometheus の現在の内部表現で、nameはメトリック名を表す特定のラベルタグです。
Prometheus の全体的なプロセスを確認してみましょう。

ここに画像の説明を挿入

KV ストレージについて言及していますが、もちろん、LevelDB エンジンを使用しています。このエンジンは、時系列ストレージと非常に一貫した、非常に高いシーケンシャル読み取りおよび書き込みパフォーマンスを特徴としています。

③メートル系

Prometheus では、Counter (カウンター)、Gauge (ダッシュボード)、Histogram (ヒストグラム)、summary (概要) の 4 つの異なるメトリックタイプが定義されています。
カウンター：
- 累積メトリクス。リクエストの数、完了したタスクの数、エラーの数などの一般的なアプリケーション。
- 例: query http_requests_total{method="get", job="Prometheus", handler="query"} は 8 を返し、10 秒後に再度クエリすると 14 が返されます。
ゲージ (ダッシュボード):
- データは瞬間値であり、現在のメモリ使用量の場合、時間の経過とともに変化します。
- 例: go_goroutines{instance="172.17.0.2", job="Prometheus"} は 147 を返し、10 秒後には 124 を返します。
ヒストグラム (ヒストグラム):
- ヒストグラムは、観測結果 (通常はリクエスト期間または応答サイズ) をサンプリングし、構成可能な分布間隔 (バケット) でこれらの結果を計算します。これにより、すべての観測値の合計も得られます。
- ヒストグラムには基本的なメトリクス名があり、1 回のキャプチャで複数の時系列を表示します。蓄積されたカウンターは、観測間隔: _bucket{le=""}、すべての観測の合計数: _sum、および観測されたイベントの数: _count を表します。
- 例: Prometheus サーバーの prometheus_local_storage_series_chunks_persisted は、Prometheus の時系列ごとに保存する必要があるチャンクの数を示します。これは、永続化するデータの分位数を計算するために使用できます。
まとめ：
- ヒストグラムと同様に、サマリーは観測結果 (通常はリクエスト期間または応答サイズ) をサンプリングしますが、観測値の数とすべての値の合計も提供し、スライディングタイムウィンドウにわたって構成可能な分位数を計算します。
- Summary には、1 回の取得で複数の時系列を表す基本的なメトリクス名があります。観測されたイベントのストリーミング φ 分位数 (0 ≤ φ ≤ 1): {quantile="φ"}、すべての観測値の合計 : _sum、観測されたイベントの数： _カウント;
- 例：Prometheus サーバー中の prometheus_target_interval_length_seconds。

④ヒストグラムとサマリーの比較

シリアルナンバー	ヒストグラム	まとめ
構成	間隔設定	分位点とスライディングウィンドウ
クライアントのパフォーマンス	カウンターのコストを増やすだけで済みます。	ストリームコンピューティングに高額なコストが必要
サーバーのパフォーマンス	分位点の計算にはコストがかかり、時間がかかる場合があります	計算不要で低コスト
タイミング数量	_sum、_count、バケット	_sum、_count、分位数
分位誤差	バケットのサイズに関係するのは、	φ の構成は次のように関係します。
φと引き違い窓	プロメテウス式の設定	クライアント設定
重合	式による集計	一般に集計不可能

以下は、タイプのヒストグラムと概要のサンプル出力の例です。

# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{
    
    le="0.05"} 24054
http_request_duration_seconds_bucket{
    
    le="0.1"} 33444
http_request_duration_seconds_bucket{
    
    le="0.2"} 100392
http_request_duration_seconds_bucket{
    
    le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320
# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{
    
    quantile="0.01"} 3102
rpc_duration_seconds{
    
    quantile="0.05"} 3272
rpc_duration_seconds{
    
    quantile="0.5"} 4773
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693

⑤ タスク(JOBS)とインスタンス(INSTANCES)

Prometheus の用語では、取得できるエンドポイントはインスタンスと呼ばれ、通常は単一のプロセスに対応します。
同じ目的 (拡張性や信頼性を確保するためのレプリケーションのプロセスなど) を持つインスタンスの集合をジョブと呼びます。
4 つのレプリケートされたインスタンスを含む API サーバージョブ:
- ジョブ: APIサーバー：
- - インスタンス 1: 1.2.3.4:5670
- - インスタンス 2: 1.2.3.4:5671
- - インスタンス 3: 5.6.7.8:5670
- - インスタンス 4: 5.6.7.8:5671
- インスタンス: 単一のスクレイピングターゲット。通常はプロセスに対応します。
- ジョブ: 同じタイプのインスタンスのグループ (主にスケーラビリティと信頼性を確保するために使用されます)。

⑥ノードエクスポーター

ノードエクスポーターは主に、メトリクスを Prometheus に公開するために使用されます。メトリクスには、CPU 負荷、メモリ使用量、ネットワークなどが含まれます。

⑦ プッシュゲートウェイ

Pushgateway は Prometheus エコシステムの重要なツールであり、これを使用する主な理由は次のとおりです。
- Prometheus はプルモードを採用しているため、サブネットまたはファイアウォール内にないため、Prometheus が各ターゲットデータを直接プルできなくなる可能性があります。
- ビジネスデータを監視する場合、Prometheusでさまざまなデータを集約し、一元的に収集する必要があります。
上記の理由により、プッシュゲートウェイを使用する必要がありますが、使用する前に、その欠点のいくつかを理解する必要があります。
- 複数のノードのデータをプッシュゲートウェイに集約します。プッシュゲートウェイがダウンした場合、その影響は複数のターゲットの場合よりも大きくなります。
- Prometheus のプルステータスアップはプッシュゲートウェイのみに適用され、すべてのノードに有効であるわけではありません。
- Pushgateway はプッシュされたすべての監視データを永続化できるため、監視がオフラインであっても、prometheus は引き続き古い監視データをプルするため、pushgateway が必要としないデータを手動でクリーンアップする必要があります。

4. TSDB の概要

① 時系列データベースの特徴

TSDB (Time Series Database) 時系列データベースは、時系列データを処理するために最適化されたソフトウェアとして簡単に理解でき、データ内の配列は時間によってインデックス付けされます。
TSDB の機能は次のとおりです。
- ほとんどの場合は書き込み操作。
- 書き込み操作はほぼ順番に追加され、ほとんどの場合、データは時間順にソートされて到着します。
- 書き込み操作では、かなり前にデータが書き込まれることはほとんどなく、データが更新されることもほとんどありません。ほとんどの場合、データは、データが収集されてから数秒または数分後にデータベースに書き込まれます。
- 削除操作は通常、ブロック削除であり、開始履歴時間を選択し、後続のブロックを指定します。特定の時間または別のランダムな時間にデータを削除することはほとんどありません。
- 基本データは大きく、一般にメモリサイズを超え、一般にその一部のみが選択され、不規則であり、キャッシュはほとんど効果がありません。
- 読み取り操作は、一般的な昇順または降順の順次読み取りです。
- 高度な同時読み取り操作は非常に一般的です。

②共通時系列データベース

TSDBプロジェクト	公式ウェブサイト
流入DB	https://influxdata.com/
RRDツール	http://oss.oetiker.ch/rrdtool/
黒鉛	http://グラファイトアプリ.org/
OpenTSDB	http://opentsdb.net/
kdb+	http://kx.com/
ドルイド僧	http://ドルイド.io/
カイロスDB	http://kairosdb.github.io/
プロメテウス	https://プロメテウス.io/

5、PromQL クエリ式

PromQL の 4 つのデータ型:
- インスタントベクトル: 同じタイムスタンプを共有する、各時系列の 1 つのサンプルを含む時系列のセット。
- 範囲ベクトル: 範囲内のデータポイントを含む時系列のセット。
- スカラー: 単純な浮動小数点数値。
- 文字列 (文字列): 現在使用されていない単純な文字列値。

①インスタントベクトルセレクター

インスタントベクトルセレクターを使用すると、一連の時系列、または特定のタイムスタンプでのサンプルデータを選択できます。以下に示すように、http_requests_total で時系列を選択します。

http_requests_total

これらの時系列は、次のように、{} で囲まれた一連のタグを追加することでさらにフィルタリングでき、http_requests_total という名前、prometheus ジョブタグ、および Canary グループタグを持つ時系列のみを選択します。

http_requests_total

さらに、タグ値を逆に一致させたり、正規表現に対してタグ値を一致させたりすることも可能です。一致演算子は以下のとおりです。
- =: 完全に等しい文字列タグを選択します。
- !=: 等しくない文字列タグを選択します。
- =~: 正規表現に一致するタグ (またはサブタグ) を選択します。
- !~: 正規表現に一致しないタグ (またはサブタグ) を選択します。
ステージング環境、テスト環境、開発環境での GET 以外の HTTP メソッドの http_requests_total の時系列を選択します。

http_requests_total

②レンジベクトルセレクター

範囲ベクトル式はインスタントベクトル式と同じように機能しますが、前者は現在の瞬間から始まる特定の時間範囲の時系列のセットを返します。構文は、ベクトル式の後に [] を追加して時間範囲を示します。期間は数値で表され、その後に次のいずれかの単位が続きます。
- s：秒
- m：分
- h：時間
- d：日
- w：週間
- y：年
以下に示す例では、過去 5 分間のレコード、メトリック名が http_requests_total、ジョブラベルが prometheus である時系列のすべての値を選択します。

http_requests_total{
    
    job="prometheus"}[5m]

③オフセットモディファイア

オフセットにより、クエリ内の個々の瞬間の時間および範囲ベクトルオフセットを変更できます。たとえば、次の式は、現在のクエリの評価時間を基準とした過去 5 分間の http_requests_total の値を返します。

http_requests_total offset 5m

範囲ベクトルについても同様で、これは http_requests_total に 1 週間前の 5 分間のレートを返します。

rate(http_requests_total[5m] offset 1w)

④ 集計演算を利用する

PromQL が提供する集計操作を使用して、これらの時系列を処理して新しい時系列を形成できます。

# 查询系统所有http请求的总量
sum(http_request_total)

# 按照mode计算主机CPU的平均使用时间
avg(node_cpu) by (mode)

# 按照主机查询各个主机的CPU使用率
sum(sum(irate(node_cpu{
    
    mode!='idle'}[5m]))  / sum(irate(node_cpu[5m]))) by (instance)

一般的な集計関数:
- 和
- min（最小値）
- max（最大値）
- avg（平均値）
- stddev (標準偏差)
- stdvar (標準分散)
- 数える（数える）
- count_values (カウント値)
- Bottomk (最後の n 時系列)
- topk (上位 n 時系列)
- quantile (分位数)

6. 輸出業者

エクスポーターはプロメテウス監視の重要な部分であり、データインジケーターの収集を担当します。大まかに言うと、モニタリングサンプルデータを Prometheus に提供できるすべてのプログラムをエクスポーターと呼び、エクスポーターのインスタンスをターゲットと呼びます。

ここに画像の説明を挿入

公式プラグインには、blackbox_exporter、node_exporter、mysqld_exporter、snmp_exporter などが含まれます。サードパーティのプラグインには、redis_exporter、cadvisor などが含まれ、公式エクスポーターのアドレスが含まれます。

① 共通輸出業者

ブロックボックスエクスポーター：
blackbox exporter は、prometheus コミュニティが提供するブラックボックス監視ソリューションで、ユーザーは HTTP、HTTPS、DNS、TCP、ICMP を通じてネットワークを検出し、ブラックボックスを通じてサイト情報を収集できます。
- GitHub アドレス。
ノードエクスポーター：
- node_exporter は主に、CPU、メモリ、ディスク、IO などの基本情報を含むマシンのパフォーマンスインデックスデータを収集するために使用されます。
- GitHub アドレス。
mysqld_exporter：
- mysql_exporter は MysQL または Mariadb データベース関連のインジケーターを収集するために使用されます。mysql_exporter はデータベースに接続し、関連する権限を持っている必要があります。
- GitHub アドレス。
snmp_exporter：
- SNMP Exporter は SNMP サービスから情報を収集し、Promethers 監視システムに提供します。
- GitHub アドレス。

②エクスポーターの仕組み

独立した動作: オペレーティングシステム自体は Prometheus を直接サポートしておらず、ユーザーはオペレーティングシステムレベルから直接 Prometheus のサポートを提供できないため、ユーザーはオペレーティングシステムが提供する関連インターフェイスを介してプログラムを独立して実行することのみが可能で、システムの動作を変換することができます。ステータスデータを Prometheus で読み取れる監視データに変換します。Node Exporter に加えて、MySQL Exporter、Redis Exporter などはすべてこの方法で実装されており、これらの Exporter プログラムは中間エージェント (データ変換) の役割を果たします。
アプリケーションへの統合 (推奨): システムの内部動作ステータスをより適切に監視するために、Kubernetes、ETCD などの一部のオープンソースプロジェクトはコード内で Prometheus クライアントライブラリを直接使用し、Prometheus を直接サポートします。監視の境界により、アプリケーションは内部の実行ステータスを Prometheus に直接公開できます。これは、よりカスタムの監視インジケーターを必要とする一部のプロジェクトに適しています。

③輸出業者の仕様

すべての Exporter プログラムは、Prometheus 仕様に従って監視されたサンプルデータを返す必要があります。Node Exporter を例に挙げると、/metrics アドレスにアクセスすると、次のコンテンツが返されます (directcurl はデータを取得できないため、承認する必要があります)。

# 取前面10行
$ curl -s -k --header "Authorization: Bearer $TOKEN" https://192.168.0.113:6443/metrics|head -10

ここに画像の説明を挿入

# HELP aggregator_openapi_v2_regeneration_count [ALPHA] Counter of OpenAPI v2 spec regeneration count broken down by causing APIService name and reason.
# TYPE aggregator_openapi_v2_regeneration_count counter
aggregator_openapi_v2_regeneration_count{
    
    apiservice="*",reason="startup"} 0
aggregator_openapi_v2_regeneration_count{
    
    apiservice="k8s_internal_local_delegation_chain_0000000002",reason="update"} 0
aggregator_openapi_v2_regeneration_count{
    
    apiservice="v1beta1.metrics.k8s.io",reason="add"} 0
aggregator_openapi_v2_regeneration_count{
    
    apiservice="v1beta1.metrics.k8s.io",reason="update"} 0
# HELP aggregator_openapi_v2_regeneration_duration [ALPHA] Gauge of OpenAPI v2 spec regeneration duration in seconds.
# TYPE aggregator_openapi_v2_regeneration_duration gauge
aggregator_openapi_v2_regeneration_duration{
    
    reason="add"} 0.929158077
aggregator_openapi_v2_regeneration_duration{
    
    reason="startup"} 0.509336209

Exporter が返すサンプルデータは主に、サンプルの一般アノテーション情報 (HELP)、サンプルの型アノテーション情報 (TYPE)、サンプルの 3 つの部分で構成されます。
Prometheus はエクスポーターの応答の内容を行ごとに解析します。
- 現在の行が # HELP で始まる場合、Prometheus は次のルールに従ってコンテンツを解析し、現在のインジケーター名と対応する説明情報を取得します。

# HELP <metrics_name> <doc_string>

- 現在の行が # TYPE で始まる場合、Prometheus は次のルールに従って内容を解析し、現在のインジケーター名とインジケーターのタイプを取得します。

# TYPE <metrics_name> <metrics_type>

- TYPE コメント行は、インジケーターの最初のサンプルの前に表示する必要があります。型なしとして返す必要がある明確なインジケータータイプがない場合は、先頭の # を除くすべての行がモニタリングサンプルデータとみなされます。サンプルの各行は、次の形式仕様を満たしています。

metric_name [
"{" label_name "=" " label_value " {
    
     "," label_name "=" " label_value " } [ "," ] "}"
] value [ timestamp ]

④ノードエクスポーター

エクスポーターは Prometheus の指標データ収集コンポーネントであり、ターゲットジョブからデータを収集し、収集したデータを Prometheus がサポートする時系列データ形式に変換する役割を果たします。従来のインジケーターデータ収集コンポーネントとは異なり、収集のみを担当し、サーバーにデータを送信せず、Prometheus Server がアクティブにデータを取得するのを待ちます。
node-exporter は、ノードの CPU、負荷、ファイルシステム、meminfo、ネットワークなどの基本的な監視インジケーターを含む、ノードの実行インジケーターを収集するために使用されます。zabbix 監視システムの zabbix-agent と同様、概略図は次のとおりです。

ここに画像の説明を挿入

ノードエクスポーターサービスを確認します。

$ kubectl get pods -n monitoring -o wide|grep node-exporter
# 查看pod内的node_exporter进程
$ kubectl exec -it node-exporter-dc65j -n monitoring -- ps -ef|grep node_exporter
# 获取容器ID
$ docker ps |grep node_exporter
# 查看docker 容器的pid
$ docker inspect -f {
    
    {
    
    .State.Pid}} 8b3f0c3ea055
# 再通过pid进入命名空间
$ nsenter -n -t8303
# 再查看进程
$ ps -ef|grep node_exporter
# 退出当前命名空间
$ exit

ここに画像の説明を挿入

yaml ファイルに設計:

node-exporter-clusterRoleBinding.yaml # 角色绑定
node-exporter-clusterRole.yaml # 角色
node-exporter-daemonset.yaml # daemonset，容器配置，node-exporter配置
node-exporter-prometheusRule.yaml # 采集规则
node-exporter-serviceAccount.yaml # 服务账号
# K8s集群内的Prometheus抓取监测数据是通过servicemonitor这个crd来完成的。
# 每个servicemonitor对应Prometheus中的一个target。
# 每个servicemonitor对应一个或多个service，负责获取这些service上指定端口暴露的监测数据，并向Prometheus上报。
node-exporter-serviceMonitor.yaml 
node-exporter-service.yaml # 服务

ここに画像の説明を挿入

サービスの自動検出:
- 時系列データの収集、保存、警報、表示を行うには、監視対象を事前に監視システムに組み込む必要があり、監視対象は構成情報を通じて静的に指定することも、Prometheus によって動的に管理することもできます。サービス検出メカニズム。
- まず従来の構成方法を見てみましょう。
- - まず、node-exporter をインストールし、ノードメトリックを取得し、ポートを公開する必要があります。
- - 次に、Prometheus Server の prometheus.yaml ファイルに移動して、scarpe_config にノードエクスポータージョブを追加し、ノードエクスポーターのアドレスとポート情報を構成します。
- - 次に、Prometheus サービスを再起動する必要があります。
- - 最後に、prometheus サービスが監視情報を取得するのを待ち、ノードエクスポーター監視を追加するタスクを完了します。
- サンプル構成は次のとおりです (prometheus.yml)。

- job_name: 'node-exporter'
    static_configs:
    - targets: ['192.168.0.113:9090']   #这里我修改了端口为9090

- サービスを再起動する

$ systemctl restart prometheus

- kube-prometheus サービスの自動検出:
- - まず、最初のステップは従来の方法と同じで、ノードエクスポーターをデプロイして監視項目を取得します。
- - 次に、labelSelector を介してデプロイされたばかりのノードエクスポーターを選択する ServiceMonitor を作成します。デフォルトで Prometheus をデプロイするときに Operator が Prometheus を指定するため、ラベルは prometheus: kube-prometheus ServiceMonitor となるため、prometheus: kube-prometheus にラベルを付けるだけで済みます。 ServiceMonitor Prometheus によって選択できます。
- - 上記の 2 つの手順を完了すると、ホストリソースの監視が完了します。Prometheus 設定ファイルを変更したり、Prometheus サービスを再起動したりする必要はありません。非常に便利です。Operator は、ホストの変更を監視すると、Prometheus 設定ファイルを動的に生成します。 ServiceMonitor を実行し、構成ファイルがすぐに有効になることを確認します。

7. k8s 外部モニタリングを追加する

① 設定プロセス

プロジェクトの開始時に、データベースや CDH クラスターなどのコンテナーをすべて実装するのは難しいかもしれませんが、それでも監視する必要があります。これらの監視は kube-prometheus に対して均一に行われます。
AdditionalScrapeConfigs プロパティの具体的な概要については、kubectl Explain コマンドを使用して詳細を確認できます。

$ kubectl explain prometheus.spec.additionalScrapeConfigs

ここに画像の説明を挿入

次に、新しい prometheus-Additional.yaml ファイルを作成し、追加の監視コンポーネントを追加して、scrape_configs を構成します。

$ cat << EOF > prometheus-additional.yaml
- job_name: 'node-exporter-others'
  static_configs:
    - targets:
      - *.*.*.113:31190
      - *.*.*.114:31190
      - *.*.*.115:31190

- job_name: 'mysql-exporter'
  static_configs:
    - targets:
      - *.*.*.104:9592
      - *.*.*.125:9592
      - *.*.*.128:9592

- job_name: 'nacos-exporter'
  metrics_path: '/nacos/actuator/prometheus'
  static_configs:
    - targets:
      - *.*.*.113:8848
      - *.*.*.114:8848
      - *.*.*.115:8848

- job_name: 'elasticsearch-exporter'
  static_configs:
  - targets:
    - *.*.*.113:9597
    - *.*.*.114:9597
    - *.*.*.115:9597

- job_name: 'zookeeper-exporter'
  static_configs:
  - targets:
    - *.*.*.113:9595
    - *.*.*.114:9595
    - *.*.*.115:9595

- job_name: 'nginx-exporter'
  static_configs:
  - targets:
    - *.*.*.113:9593
    - *.*.*.114:9593
    - *.*.*.115:9593

- job_name: 'redis-exporter'
  static_configs:
  - targets:
    - *.*.*.113:9594

- job_name: 'redis-exporter-targets'
  static_configs:
    - targets:
      - redis://*.*.*.113:7090
      - redis://*.*.*.114:7090
      - redis://*.*.*.115:7091
  metrics_path: /scrape
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: *.*.*.113:9594
EOF

次に、これらの監視設定を k8s クラスターにシークレットリソースタイプとして保存する必要があります。

$ kubectl create secret generic additional-scrape-configs --from-file=prometheus-additional.yaml -n monitoring

②プロメテウスファイルを修正する

AdditionalScrapeConfigs:追加の監視項目構成を追加します。

$ vi prometheus-prometheus.yaml

以下を追加します。

additionalScrapeConfigs:
    name: additional-scrape-configs
    key: prometheus-additional.yaml

診る：

$ grep -n -C5 'additionalScrapeConfigs' prometheus-prometheus.yaml

ここに画像の説明を挿入

設定は次のように有効になります。

$ kubectl apply -f prometheus-prometheus.yaml

クラウドネイティブのインストールと展開の詳細な分析と Prometheus の原理分析

1. プロメテウスの紹介

①プロメテウスの特徴

②Prometheusコアコンポーネント

③プロメテウスフレームワーク

④ ワークフロー

2. Prometheusの展開

①gitをインストールする

②ミラーソースを変更する

③タイプをNodePortに変更します。

3. プロメテウス関連の概念

① 内部記憶機構

② データモデル

③メートル系

④ヒストグラムとサマリーの比較

⑤ タスク(JOBS)とインスタンス(INSTANCES)

⑥ノードエクスポーター

⑦ プッシュゲートウェイ

4. TSDB の概要

① 時系列データベースの特徴

②共通時系列データベース

5、PromQL クエリ式

①インスタントベクトルセレクター

②レンジベクトルセレクター

③オフセットモディファイア

④ 集計演算を利用する

6. 輸出業者

① 共通輸出業者

②エクスポーターの仕組み

③輸出業者の仕様

④ノードエクスポーター

7. k8s 外部モニタリングを追加する

① 設定プロセス

②プロメテウスファイルを修正する

おすすめ