使うよりも短いコードで書けます。PrometheusドキュメントPrometheusTweetこのページはPrometheus公式ドキュメント和訳+αの一部です。内部構造Prometheusサーバーは、Prometheus全体の機能を生み出すために協調して一緒に働く多くの内部コンポーネントから成る。このドキュメントは、それらがどのように組み合わさっているかを含む主要なコンポーネントの概要およびその実装の詳細へのリンクを示す。Prometheusの新米開発者でPrometheusの各部分の概要を知りたいのなら、ここからはじめよう。このダイアグラムで、Prometheusサーバー全体の構成が示されている。矢印は、リクエストやコネクションを開始する方向を示し、必ずしもデータの流れの方向ではない。以下のセクションで、図中の各コンポーネントについて説明する。2.3.1に基づいている。Prometheusの将来のバージョンでは異なる可能性がある。functionは、Prometheusサーバーの他の全てのコンポーネントを初期化し稼働させる。依存関係のあるコンポーネント同士を繋げる。第一歩として、main()は、サーバーのコマンドラインフラグを定義し、解析してローカルの設定の構造体に変換する。同時に、サニタイズやいくつかの値の初期化を行う。フラグに基づくこの設定の構造体は、あとで(--config.fileフラグで指定された)設定ファイルから読み込まれる設定からは独立していることに注意すること。Prometheusは、フラグに基づく設定とファイルに基づく設定を区別する。フラグは、サーバーの再起動なしに更新することができない単純な設定利用され流のに対し、設定ファイルで提供されている設定項目は、サーバーを再起動せずに再読み込みできなければならない。次に、main()は、Prometheusの実行時のコンポーネントを初期化し、channelや参照、後の協調動作やキャンセル処理のためのcontextの受け渡しを利用してそれらを接続する。これらのコンポーネントには、(このドキュメントの残りで説明されているように)サービスディスカバリー、監視対象のスクレイプ、ストレージなどが含まれる。最後にPrometheusサーバーは、起動とシャットダウンを調整するためにgithub.com/oklog/oklog/pkg/groupを利用して、actorモデルのように全てのコンポーネントを実行する。順序の制約を為に強制する(ストレージの準備が出来て最初の設定ファイル読み込みが起きるまではwebインターフェースを有効にしないなど)ために、複数のチャネルが利用される。設定のサブシステムは、--config.fileフラグで指定されたYAMLの設定ファイルで与えられる設定の読み込み、検証、適用を受け持つ。全ての設定項目の説明はドキュメントを参照すること。Prometheusには、設定ファイルの読み込みと適用のための機能があり、同じファイルからの設定の再読み込みのリクエストを待ち受けているgoroutineがある。どちらの仕組みもこの後で説明されている。structureに変換する。この構造体は、サーバーとその全てのコンポーネントの設定全体を表す。これは、設定ファイルの階層構造を反映した下層構造を含んでいる。各構造体には、デフォルトの設定およびYAMLから構造体へと変換しさらに有効性を検査したり初期化するUnmarshalYAML()メソッドがある。設定が完全に解析されて検証が終わると、その結果の設定の構造体が返される。設定再読み込みハンドラーは、main()の中で直接実装されているgoroutineであり、webインターフェースまたはシグナルHUP)からの設定再読み込みリクエストを待ち受けている。再読み込みリクエストを受け取ると、config.LoadFile()を使って上述のように設定ファイルをディスクから読み直し、再読み込みをサポートしている全てのコンポーネントに、ApplyConfig()メソッドを呼び出すか、独自の再読み込み関数を呼び出して、その結果の構造体config.Configを適用する。終了ハンドラーは、main()の中で直接実装されているgoroutineであり、webインターフェースまたはシグナルTERM)からの終了リクエストを待ち受けている。coordinationの機能を通じて、他のPrometheusコンポーネント全てを綺麗に終了させる。managerは、discovery.Managerであり、Prometheusのサービスディスカバリー機能を利用して、Prometheusのメトリクス取得元である対象のリストを継続的に更新する。groupの更新を流す。managerは、設定で定義されたサービスディスカバリーの仕組みのインスタンスをそれ自体のgoroutineで動作させる。managerは2つの別々のkubernetes.Discoveryのインスタンスを動作させる。managerに送信する。managerに転送する。managerは、動作中のディスカバリーの仕組みを全て停止し、新しい設定ファイルで定義されたものとして再起動する。さらなる詳細については、広範なサービスディスカバリーの内部についてのドキュメントを参照すること。managerは、scrape.Managerであり、検出された監視対象からメトリクスを取得し、得られたサンプルをストレージのサブシステムに転送する。managerはscrape_configそれぞれに対して対応するスクレイプのプールを動作させる。両者は、複数のリロードとこの2つのコンポーネントにまたがっているscrape_configを、設定項目job_nameを通して特定する(job_nameは1つの設定ファイルの中でユニークでなければならない)。managerに送信する。poolは、監視対象それぞれのスクレイプのループを実行する。全体の階層構造は以下のようになる。managerから受け取ると、そのスクレイプのプールは、デフォルトのターゲットラベル(job、instanceなど)を各ターゲットに適用し、最終的にスクレイプすべき監視対象のリストを生成するためにリラベルの設定を適用する。各監視対象は、ラベル集合と最終的なスクレイプURLでハッシュが取られる。このハッシュは、スクレイプ間隔内のオフセットを選ぶために利用される。監視対象のスクレイプ最後に、スクレイプのループは、定期的に、HTTPで監視対象をスクレイプし、受信したHTTPレスポンスをPrometheusのテキストベースのメトリクス出力フォーマットに従ってデコードする。個々のサンプルそれぞれにメトリックのリラベル設定を適用し、その結果のサンプルをストレージのサブシステムに送信する。複数のスクレイプの実行にまたがる時系列の失効を追跡し保存し、スクレイプの状態の情報(upやscrape_duration_secondsなどのメトリクス)を記録し、ストレージエンジンへの時系列の追加を最適化するためのデータの整理を行う。1回のスクレイプは、設定されたスクレイプ間隔より時間がかかってはいけないし、スクレイプのタイムアウトはそれが上限になっていることに注意。これによって、1回のスクレイプが別のスクレイプが始まる前に終わらされるのが確実になる。ストレージPrometheusは、時系列のサンプルをローカルの時系列データベース(TSDB)に保存し、オプションで、全サンプルのコピーを設定されたリモートのエンドポイントに転送する。同様に、Prometheusは、ローカルのTSDBおよびオプションでリモートのエンドポイントからデータを読み取る。ローカルとリモートのストレージのサブシステムについて以下で説明する。storageは、他のコンポーネントによる利用のために、背後にあるローカルおよびリモートのストレージの詳細をプロキシ、抽象化するstorage.Storageの実装である。読み込みのためにローカルとリモートの読み込み元からのクエリの結果をマージし、書き込みはローカルとリモートの全ての書き込み先に複製される。時系列の取り込みを最適化するための機能は様々なので、内部的には、第1の(ローカルの)ストレージとオプションの第2の(リモートの)ストレージを区別する。storageへ書き込みをしているが、しばらくすると、デフォルトでルールがローカルデータを読みこむだけになるように変更されるだろう。これで、ほとんどの場合で短期のデータしか必要のないアラートとレコーディングルールの信頼性が増す。ローカルストレージPrometheusのローカルディクス上の時系列データベースは、github.com/prometheus/tsdb.DBに対する軽量ラッパーである。このラッパーは、Prometheusサーバー環境でTSDBを利用するための若干のインターフェースの調整だけをし、storage.Storageインターフェースを実装する。ローカルストレージのドキュメントにTSDBのディスク上のレイアウトさらなる詳細がある。リモートストレージリモートストレージは、remote.Storageであり、storage.Storageインターフェースを実装し、リモートの読み込みと書き込みのエンドポイントとの連結を担っている。storageは1つのremote.QueueManagerを作成し、動作させる。次に、remote.QueueManagerは、サンプルをキューに入れ、リモートの書き込みエンドポイントに送信する。各キューマネージャーは、現在と過去の負荷の観察に基づいて動的に決まる数のシャードを動作させることで、リモートエンドポイントへの書き込みを並列化する。設定の再読み込みが適用されると、全てのリモートストレージのキューはシャットダウンされ、新しいキューが作成される。clientを作成し、各リモートソースからの結果はマージされる。queriesのPrometheusの時系列データベースに対して評価する役割を担っている。このエンジンはそれ自身アクターのgoroutineとして動作せず、webインターフェースとルールマネージャーからライブラリとして利用される。PromQLの評価は、複数の段階を経る。クエリが作成されると、その式は抽象的な構文木へとパースされ、実行可能なクエリとなる。後続の実行段階では、背後のストレージから得られる必要な時系列を検索し、そのためのイテレーターを作成する。時系列の大量データの実際の取得は、(少なくともローカルのTSDBの場合は)評価時に行われる。vector)を返す。managerは、rules.Managerであり、(設定ファイルのevaluation_intervalで設定されているように)定期的なレコーディングルールとアラートルールの評価をする役割を担っている。各繰り返しで、PromQLを利用して全てのルールを評価し、結果の時系列をストレージに書き込む。managerは、以下のように、各繰り返しでいくつかのことを行う。managerが生成したアラートをSend()メソッドで受け取り、キューに入れ、設定されたAlertmanagerインスタンス全てに送信する。notifierは、アラートの生成とアラートのAlertmanagerへの送信(失敗したり時間がかかったりする)を分離する役割を果たす。managerは、discovery.Managerであり、Prometheusのサービスディスカバリーの機能を利用して、notifierがアラートを送るAlertmanagerのインスタンスのリストを検索し継続的に更新する。managerに送信する。managerと同様な仕組みで動作する。UIとAPIを提供する。UIは/で利用可能であり、クエリを実行したり、activeなアラートを調査したり、その他のPrometheusサーバーの状態を理解するために人間が利用するインターフェースとして機能する。APIは、/api/v1で提供され、クエリ、メタデータ、サーバーの状態をプログラムで調べることを可能にしている。コンソールテンプレートは、TSDBデータにアクセスできるユーザー定義のHTMLテンプレートをPrometheusが提供出来るようにするものであり、設定されていれば/consolesで利用可能である。以下のようなアンカーリンクを[手順](#手順)[手順](#%E6%89%8B%E9%A0%86)書いたとしても、redcarpetはヘッダーのアンカーを作る際に非ASCII文字は取り除いてしまうのでうまく行かない。いうか、勝手なアンカーを作るので厄介である。これをなんとかしたい。アンカーに使いたいASCII文字列をHTMLタグで囲んで挿入すれば良い。その文字列は、CSSやJSで表示表は消しておく。PrometheusドキュメントTweetこのページはPrometheus公式ドキュメント和訳+αの一部です。ConsensusクラスタリングはPrometheusには最適ではない。見る和訳活動の支援Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。