目次
1.2.2 柔軟で強力なクエリステートメント (PromQL)
1.2.6 プッシュゲートウェイを使用して、時系列データを Prometheus サーバーにプッシュできます
1.2.7 サービスディスカバリや静的設定で監視対象を取得できる
1.2.8 さまざまな視覚的グラフィカル インターフェイスがあり、一般に grafana と組み合わせて使用されます
6.3 基本的な HA + リモート ストレージ + フェデレーション クラスター ソリューション
1: プロメテウスの概要
1.1 プロメテウスとは？
Prometheus は、SoundCloud によって開発されたオープン ソースの監視および警報システムおよび時系列データベース (TSDB) です。Prometheus は Go 言語で開発されており、Google の BorgMon 監視システムのオープン ソース バージョンです。
Prometheus は、オープン ソース システムの監視およびアラーム システムです. 2016 年に、Google は Linux Foundation の下で Cloud Native Computing Foundation を開始し、Prometheus を含めました. 現在、k8s に次ぐ 2 番目に大きな CNCF ホスティング プラットフォームになりました. kubernetes コンテナ管理システムでは、 prometheus は通常、監視に使用されます.また、データを収集するための複数のエクスポーターをサポートし、データ レポート用のプッシュゲートウェイもサポートします.Prometheus のパフォーマンスは、数万のクラスターをサポートするのに十分です.
1.2 プロメテウスの特徴
新世代の監視フレームワークとして、Prometheus には次の特徴があります。
1.2.1 強力な多次元データ モデル:
- 時系列データは、メトリック (メトリック名) とラベルのキーと値のペア
labelsによって区別されます。 - すべてのメトリックは、任意の多次元ラベルで設定できます。
- データ モデルはよりカジュアルで、意図的にドット区切りの文字列として設定する必要はありません。
- 集計、切り取り、およびスライス操作は、データ モデルに対して実行できます。
- 倍精度浮動小数点型がサポートされ、ラベルは完全な Unicode に設定できます。
各時系列データは、メトリクス名とそのラベル ラベルのキーと値のペアのコレクションによって一意に識別されます。
メトリック名は、監視対象システムの測定特性を指定します (例: http_requests_total - 受信した http 要求の総数)。
labels は、Prometheus の多次元データ モデルを開きます。同じ測定名に対して、異なるラベル リストの組み合わせにより、特定の測定次元インスタンスが形成されます。(例: メトリック名 /api/tracks を含むすべての http リクエストは、特定の http リクエストを形成するために method=POST でタグ付けされます)。
クエリ言語は、これらのメトリックとタグ リストに基づいてフィルター処理と集計を行います。メトリックのラベル値を変更すると、新しい時系列プロットが作成されます。
1.2.2 柔軟で強力なクエリステートメント (PromQL)
1.2.3 管理が容易
- Prometheus サーバーは、分散ストレージに依存せずにローカルで直接動作できる単一のバイナリ ファイルです。
1.2.4 効率的なストレージ
- 平均して、各サンプリング ポイントは 3.5 バイトしか占有せず、Prometheus サーバーは数百万のメトリックを処理できます。
1.2.5 プル モードを使用して時系列データを収集する
- これは、ローカル テストに適しているだけでなく、問題のあるサーバーが不適切なメトリックをプッシュするのを防ぎます。
1.2.6 時系列データは、プッシュ ゲートウェイを使用して Prometheus サーバーにプッシュできます
1.2.7 サービスディスカバリや静的設定で監視対象を取得できる
1.2.8 さまざまな視覚的グラフィカル インターフェイスがあり、一般に grafana と組み合わせて使用されます
1.2.9 スケーリングが容易
1.3 サンプルとは
サンプル:時系列の各ポイントはサンプルと呼ばれ、サンプルは次の 3 つの部分で構成されます。
- インジケーター (メトリック): 現在のサンプルの特性を説明するインジケーター名とラベルセット。
- Timestamp (timestamp): ミリ秒単位の正確なタイムスタンプ。
- サンプル値 (値): folat64 浮動小数点データは、現在のサンプルの値を表します。
表現方法：指定したメトリック名と指定したラベルセットの時系列を次の式で表現：<メトリック名>{<ラベル名>=<ラベル値>, ...}
たとえば、メトリクス名が api_http_requests_total でラベルが method="POST" および handler="/messages" の時系列は、次のように表現できます。
1.4 プロメテウスの制限
- そのデータはメモリに保存され、再起動の前後の統計はすべてクリアされます。
- 各プログラムは独自のリクエスト数のみをカウントします.複数のポイントが展開されている場合、リクエストから取得された統計データは要約されていない単一のポイントのデータのみであり、データは不正確です;
- Prometheus はメトリクス (Metric) モニタリングに基づいており、ログ (Logs)、イベント (Event)、コール チェーン (Tracing) には適していません。正確なデータよりも多くのトレンド モニタリングを示します。
- Prometheus は、最新の監視データのみを照会する必要があると考えています. ローカル ストレージの本来の設計は、短期 (たとえば 1 か月) のデータを保存することであるため、大量の履歴データの保存はサポートされていません。 . 長期の履歴データを保存する必要がある場合は、リモート ストレージ メカニズムに基づいて InfluxDB や OpenTSDB などのシステムにデータを保存することをお勧めします
- Prometheus クラスタ メカニズムの成熟度は高くない
1.5 基本原則
Prometheus の基本原則は、HTTP プロトコルを介して監視対象コンポーネントのステータスを定期的に取得することであり、対応する HTTP インターフェースを提供する限り、どのコンポーネントも監視にアクセスできます。SDK やその他の統合プロセスは必要ありません。これは、VM、Docker、Kubernetes などの仮想化環境でシステムを監視するのに非常に適しています。監視対象コンポーネントの情報を出力するHTTPインターフェースをエクスポーターと呼びます。現在、インターネット企業が一般的に使用するほとんどのコンポーネントには、Varnish、Haproxy、Nginx、MySQL、および Linux システム情報 (ディスク、メモリ、CPU、ネットワークなどを含む) など、直接使用できるエクスポーターがあります。
1.6 Prometheus の使用シナリオ
- コンテナの監視、サービスはクラウド サーバーに展開されます。
- k8s アーキテクチャの監視システム。
- 監視システムの緊急の必要性がありますが、それを開発するための特別なエネルギーとコストはありません。
Prometheus は、純粋に数値の時系列を記録するのに最適です。マシン中心の監視と非常に動的なサービス指向アーキテクチャの監視の両方に適しています。多次元データの収集とクエリのサポートは、マイクロサービスの世界では特に有利です。
Prometheus は信頼性を重視して設計されているため、障害時に使用して問題を迅速に診断できるシステムになっています。
各 Prometheus サーバーは独立しており、ネットワーク ストレージやその他のリモート サービスに依存しません。インフラストラクチャの他の部分が壊れたときに頼ることができ、大規模なインフラストラクチャを設定することなく使用できます。
2: Prometheus コンポーネントの紹介
Prometheus エコシステムはいくつかのコンポーネントで構成されており、その多くはオプションです。
(1) Prometheus サーバー:時系列データの収集と保存に使用されます。
(2)クライアント ライブラリ:クライアント ライブラリは、アプリケーション コードを検出します. Prometheus がインスタンスの HTTP エンドポイントを取得すると、クライアント ライブラリは、追跡されたすべてのメトリックの現在のステータスを Prometheus サーバーに送信します.
(3)エクスポーター: プロメテウスはさまざまなエクスポーターをサポートしており, メトリック データを収集してプロメテウス サーバーに送信することができます. プロメテウス サーバーに監視データを提供するすべてのプログラムはエクスポーターと呼ばれます.
(4) Alertmanager: Prometheus サーバーからアラートを受信した後、重複排除、グループ化、および対応する受信者へのルーティングを行い、アラームを送信します. 一般的な受信方法は、電子メール、WeChat、DingTalk、slack などです.
(5) Grafana:監視ダッシュボード、ビジュアル監視データ
(6)プッシュ ゲートウェイ:各ターゲット ホストはデータをプッシュゲートウェイに報告でき、プロメテウス サーバーはプッシュゲートウェイからデータを一様にプルします。
(7)サービス検出:監視対象のターゲットを動的に検出し、監視構成の重要なコンポーネントを完成させます. これは、コンテナ化された環境で特に役立ちます. このコンポーネントは現在、Prometheus サーバーでサポートされています. ユーザー提供の静的リソース リスト、ファイルベースの検出、たとえば構成管理ツールを使用して Prometheus で自動的に更新されるリソース リストを生成、自動検出。
3:プロメテウスのアーキテクチャ図
上の図からわかるように、Prometheus のエコシステム全体には、主に Prometheus サーバー、Exporter、pushgateway、alertmanager、grafana、Web UI インターフェイスが含まれ、Prometheus サーバーは、Retrieval、Storage、PromQL の 3 つの部分で構成されています。
Retrievalアクティブなターゲット ホストで監視インジケータ データをキャプチャする責任があります。Storageストレージは主に収集したデータをディスクに保存するためのものですPromQLPrometheus が提供するクエリ言語モジュールです。
4: Prometheus ワークフロー
- Prometheus サーバーは、アクティブな (稼働中の) ターゲット ホスト (ターゲット) から監視インジケータ データを定期的にプルできます. ターゲット ホストの監視データは、静的ジョブまたはサービス ディスカバリを構成することにより、プロメテウス サーバーによって収集できます. この方法はデフォルトのプルです.メソッドプル インジケーター; 収集されたデータは、pushgateway を介してプロメテウス サーバーに報告することもできます; 対応するコンポーネントのデータは、一部のコンポーネントに付属するエクスポーターを介して収集することもできます。
- Prometheus サーバーは、収集した監視インジケーター データをローカル ディスクまたはデータベースに保存します。
- Prometheus が収集した監視指標データは時系列で保存され、トリガーされたアラームはアラームルールを設定することで alertmanager に送信されます
- Alertmanager は、アラーム レシーバーを構成することにより、電子メール、WeChat、または DingTalk にアラームを送信します。
- Prometheus に付属の Web UI インターフェイスは、監視データをクエリできる PromQL クエリ言語を提供します。
- Grafana は、prometheus データ ソースにアクセスし、モニタリング データをグラフィカルな形式で表示できます。
注：簡単に言えば、データを収集し、データを加工し、視覚化して表示し、アラーム処理のためのデータ分析を行うことです。
簡単な紹介：
ステップ 1: Prometheus サーバーは、構成されたジョブまたはエクスポーター、 Pushgateway、または他の Prometheus サーバーからメトリックを定期的にプルします。
- デフォルトの pull メソッドは pull であり、pushgateway が提供する push メソッドを使用して、各監視ノードのデータを取得することもできます。
ステップ 2: Prometheus サーバーは、収集されたメトリクスをローカルに保存し、定義された alert.rules を実行し、特定のルールに従ってデータを整理して整理し、取得した結果を新しい時系列に保存します。新しい時系列を記録するか、Alertmanager にアラートをプッシュします。
- 取得したデータは時系列データベースであるTSDBに格納されます。
ステップ 3: Prometheus は、PromQL およびその他の API を介して収集されたデータを視覚化します。Prometheus は、さまざまな方法でグラフを視覚化できます。
- たとえば、Grafana、組み込みの Promdash、およびそれ自体が提供するテンプレート エンジンなどです。
- Prometheus は、必要な出力をカスタマイズするための HTTP API クエリ メソッドも提供します。
5：Prometheusとzabbixの比較分析
| ザビックス | プロメテウス |
| バックエンドはCで、インターフェースはPHPで開発されており、カスタマイズが非常に難しいです。 | バックエンドはgolang、フロントエンドはGrafanaで、JSON編集で解決できます。カスタマイズの難易度が低い。 |
| クラスタの最大サイズは 10000 ノードです。 | より大きなクラスター サイズをサポートし、より高速です。 |
| 物理マシン環境の監視に適しています。 | クラウド環境の監視により適しており、OpenStack および Kubernetes との統合が向上しています。 |
| 監視データは MySQL などのリレーショナル データベースに格納され、既存のデータからディメンションを拡張することは困難です。 | 監視データは時系列ベースのデータベースに保存されるため、既存のデータの新しい集計が容易になります。 |
| インストールは簡単で、zabbix-server にはすべてのサーバー側機能が 1 つのパッケージに含まれています。 | インストールは比較的複雑で、監視、アラーム、およびインターフェイスはすべて異なるコンポーネントに属しています。 |
| グラフィカル インターフェイスは比較的成熟しており、基本的にすべての構成操作をインターフェイス上で完了することができます。 | インターフェイスは比較的弱く、多くの構成では構成ファイルを変更する必要があります。 |
| 開発時間は長くなりますが、多くの監視シナリオに対応する既成のソリューションがあります。 | 2015年以降急速に発展し始めましたが、開発期間は比較的短く、成熟度はZabbixほどではありません。 |
要約:
物理マシンを監視している場合は、Zabbix に問題はありません.Zabbix は、従来の監視システム、特にサーバー関連の監視において絶対的な利点があります. 環境があまり頻繁に変化しない場合でも、Zabbix は Prometheus よりも優れています。
でもクラウド環境なら、Zabbixがよっぽどスベスベで色々カスタマイズできるのでない限り、Prometheusの方がいいですよね、やっぱりそういうところですよね。Prometheus は、コンテナー監視の主要かつ標準的な構成になり始めており、kubernetes との互換性が高く、近い将来広く使用される予定です。監視システムを使いたいだけなら、躊躇しないでください。プロメテウスは正しいです。
6: Prometheus のいくつかの展開モード
6.1 基本高可用性モード
基本的な HA モードは、Promthues サービスの可用性を保証することしかできませんが、Prometheus サーバー間のデータの一貫性と永続性の問題を解決することはできず (データが失われた後に回復することはできません)、動的に拡張することもできません。したがって、この展開方法は、監視規模が大きくなく、Promthues サーバーが頻繁に移行されず、短期間の監視データのみを保存する必要があるシナリオに適しています。
6.2 基本的な高可用性 + リモート ストレージ
Promthues サービスの可用性を解決することに基づいて、データの永続性も保証します. Promthues サーバーがダウンしたり、データが失われたりした場合でも、迅速に復元できます. 同時に、Promthues サーバーは適切に移行される可能性があります。したがって、このソリューションは、ユーザー監視の規模が大きくないシナリオに適していますが、監視データを永続化できると同時に、Promthues サーバーの移植性を確保できることが期待されます。
6.3 基本的な HA + リモート ストレージ + フェデレーション クラスター ソリューション
Promthues のパフォーマンスのボトルネックは主に多数の収集タスクにあるため、ユーザーはPrometheus フェデレーテッド クラスターの特性を利用して、さまざまな種類の収集タスクをさまざまな Promthues サブサービスに分割し、機能的なパーティショニングを実現する必要があります。たとえば、Promthues サーバーはインフラストラクチャ関連の監視インジケーターの収集を担当し、別の Prometheus サーバーはアプリケーション監視インジケーターの収集を担当します。次に、データの集約を実現する上層の Prometheus Server があります。
Seven: Prometheus の 4 つのデータ型
7.1カウンター
カウンターはカウンタータイプです：
- カウンタは、リクエスト数、タスクの完了、エラーの記録など、値を蓄積するために使用されます。
- 常に増加し、減少することはありません。
- プロセスを再起動すると、リセットされます。
# Counter类型示例
http_response_total{method="GET",endpoint="/api/tracks"} 100
http_response_total{method="GET",endpoint="/api/tracks"} 160カウンタータイプのデータにより、ユーザーはイベント生成率の変化を簡単に理解できます.PromQLに組み込まれている関連する操作関数は、HTTPアプリケーションのリクエスト量などの対応する分析を提供して、説明することができます.
1) rate() 関数を使用して HTTP リクエストの増加率を取得します: rate(http_requests_total[5m])
2) 現在のシステムの上位 10 個の HTTP アドレスを照会します: topk(10, http_requests_total)
7.2 ゲージ
ゲージはゲージタイプです:
- ゲージは、温度変化、メモリ使用量の変化などの一般的な値です。
- 大きくても小さくてもいい。
- プロセスを再起動すると、リセットされます
# Gauge类型示例
memory_usage_bytes{host="master-01"} 100
memory_usage_bytes{host="master-01"} 30
memory_usage_bytes{host="master-01"} 50
memory_usage_bytes{host="master-01"} 80 Gauge タイプのモニタリング指標の場合、 PromQL 組み込み関数を使用して 、delta() 一定期間にわたるサンプルの変化を取得できます。たとえば、2 時間以内の CPU 温度の差を計算できます。dalta(cpu_temp_celsius{host="zeus"}[2h])
また、PromQL 組み込み関数 predict_linear() を使用して、単純な線形回帰に基づいてサンプル データの変化傾向を予測することもできます。たとえば、2 時間のサンプル データに基づいて、4 時間後のホストの残りの空きディスク容量を予測するには: predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0
7.3ヒストグラム
ヒストグラムの機能と特徴
Histogram is a histogram . Prometheus システムのクエリ言語では、次の 3 つの機能があります。
1) 一定期間 (通常は要求期間または応答サイズなど) にわたってデータをサンプリングし、それを構成可能なバケットにカウントします ( ). 後続のサンプルは、指定された間隔でフィルタリングするか、サンプルの総数をカウントできますbucket,最後に、データをヒストグラムとして表示します。
2) 各サンプリングポイントの値を累積する ( sum)
3) サンプリング点数の累計 ( count)
メトリック名: [basename]上記 3 種類のロール メトリックの名前
1）[basename]bucket{le="上边界"}, 这个值为小于等于上边界的所有采样点数量
2）[basename]_sum_
3）[basename]_count注: メトリック タイプをヒストグラムとして定義すると、Prometheus は対応する 3 つのメトリックを自動的に生成します。
ヒストグラム ヒストグラムを使用する必要があるのはなぜですか?
ほとんどの場合、平均 CPU 使用率やページの平均応答時間など、特定の定量的指標の平均値を使用する傾向があります。この方法の問題点は明らかで、システム API 呼び出しの平均応答時間を例に取ると、ほとんどの API 要求が 100 ミリ秒の応答時間範囲内に維持され、個々の要求の応答時間が 5 秒かかる場合、WEB の一部が発生します。ページの応答時間が中央値まで低下し、この現象はロングテール問題と呼ばれます。
平均的な遅さとロングテールの遅さを区別する最も簡単な方法は、リクエストの遅延の範囲に従ってリクエストをグループ化することです。たとえば、遅延が 0 ～ 10 ミリ秒のリクエストの数と、遅延が 10 ～ 20 ミリ秒のリクエストの数をカウントします。このようにして、システムの速度低下の原因を迅速に分析できます。ヒストグラムとサマリーはどちらもこのような問題を解決するように設計されており、ヒストグラムとサマリー タイプの監視指標により、監視サンプルの分布をすばやく把握できます。
ヒストグラム タイプのサンプルは、3 つのインジケーターを提供します (インジケーター名が であると仮定します <basename>)。
1) サンプルの値は、 という名前のバケットの数に分配されます <basename>_bucket{le="<上边界>"}。簡単に説明すると、この値は、インデックス値が上限以下であるすべてのサンプルの数を示します。
# 1、在总共2次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0
# 2、在总共2次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0
# 3、在总共2次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0
# 4、在总共2次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.02) すべてのサンプル値のサイズの合計。 <basename>_sum
# 实际含义： 发生的2次 http 请求总的响应时间为 13.107670803000001 秒
io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001<basename>_count3) 、値、および 同じ名前のサンプルの総数 <basename>_bucket{le="+Inf"}
# 实际含义： 当前一共发生了 2 次 http 请求
io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0注:
1) バケットは、データ指標の値の範囲の分割として理解でき、分割の基準はデータ値の分布に基づく必要があります。次のサンプリング ポイントには、前のサンプリング ポイントが含まれることに注意してください. xxx_bucket{...,le="0.01"} の値が 10 で、xxx_bucket{...,le="0.05"} の値が 30 であるとします。 30 個のサンプリング ポイントのうち、10 個が 0.01 秒未満であり、残りの 20 個のサンプリング ポイントの応答時間が 0.01 秒から 0.05 秒の間であることを意味します。
2) ヒストグラム タイプのサンプルの変位値は、histogram_quantile() 関数で計算できます。分位数はわかりにくいかもしれませんが、データを分割するポイントとして理解できます。サンプルの 9 番目の分位数 ( quantile=0.9) の値をx とすると、x より小さいサンプル値の数がサンプル値全体の 90% を占めることを意味します。ヒストグラムは、アプリケーションのパフォーマンス指標値 (Apdex スコア) の計算にも使用できます。
7.4まとめ
ヒストグラム タイプと同様に、一定期間のデータ サンプリング結果を表すために使用されます (通常は、要求期間または応答サイズなど)。ただし、間隔ではなく、分位数 (クライアントによって計算されてから表示される) を直接格納します。計算する。また、次の 3 つの機能があります。
1) 各サンプリング ポイントの統計を作成し、分位点マップを作成します。（例：正規分布と同様に、60点未満の生徒の割合を数え、80点未満の生徒の割合を数え、95点未満の生徒の割合を数えます）
2) クラス内のすべての生徒の合計成績を数える (合計)
3) 試験を受けるクラスの生徒の総数を数える (count)
[basename] のメトリクス付きの概要は、時系列データを取得するときの名前のようなものです。
1. 観測時間は次φ-quantiles (0 ≤ φ ≤ 1)のように表示されます[basename]{分位数="[φ]"}
2, [basename]_sum, は、すべての観測値の合計を指します_
3、[basename]_count、観測されたイベントカウント値を指します
という名前のサンプル値の分位分布 <basename>{quantile="<φ>"}。
# 1、含义：这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983s
io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983
# 2、含义：这 12 次 http 请求中有 90% 的请求响应时间是 8.003261666s
io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666という名前のすべてのサンプル値のサイズの合計 <basename>_sum。
# 1、含义：这12次 http 请求的总响应时间为 51.029495508s
io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508という名前のサンプルの総数 <basename>_count。
# 1、含义：当前一共发生了 12 次 http 请求
io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0Histogram と Summary の類似点と相違点:
それらはすべてインジケーターを含み <basename>_sum 、 分位を計算する<basename>_count にはヒストグラムを使用する必要があり <basename>_bucket 、サマリーは分位の値を直接保存します。
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216
# 从上面的样本中可以得知当前Promtheus Server进行wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s。8: プロメテウス ストレージ
8.1 保管原則
1. Prometheus は、ローカル ストレージ (TSDB) 時系列データベース ストレージ メソッドを提供します. バージョン 2.0 以降、データを圧縮する機能が大幅に改善されました. 単一ノードの場合、ほとんどのユーザーのニーズを満たすことができますが、ローカルストレージはプロメテウスを妨げます。クラスタリングの実装であるため、代わりに influxdb などの他の時系列データをクラスタで使用する必要があります。
2. Prometheus はデータをブロックの形で保存します. 2 時間ごとが時間単位です. 最初にメモリに保存され、2 時間になると自動的にディスクに書き込まれます.
3. プログラムの例外によるデータ損失を防ぐために、WAL メカニズムが採用されています。つまり、2 時間以内に記録されたデータがメモリに保存される一方で、ログも記録され、ブロックの下の wal ディレクトリに保存されます。 . プログラムが再起動すると、wal ディレクトリ内のデータが対応するブロックに書き込まれ、データ回復の効果が得られます。
8.2 ローカルストレージ
ローカル ディスクに直接保存されますが、パフォーマンスの観点から、SSD を使用し、1 か月以上データを保存しないことをお勧めします。NFS はどのバージョンの Prometheus でもサポートされていないことに注意してください。Prometheus が NFS を使用してファイルを保存すると、履歴データが破損したり失われたりする可能性があることが、実際の運用ケースで示されています。
8.3 リモートストレージ
大量の監視データを保存するのに適しています。Prometheus がサポートするリモート ストレージには、OpenTSDB、InfluxDB、Elasticsearch、Kakfa、PostgreSQL などが含まれます。リモート ストレージは、主に Prometheus の remote_write および remote_read インターフェイスを含む、中間層のアダプターで変換する必要があります。実際の運用では、リモート ストレージでさまざまな問題が発生します。これには、継続的な最適化、ストレス テスト、アーキテクチャの変換、さらにはデータ ロジックをアップロードするためのモジュールの書き換えが必要です。
