Prometheus を使ってみた

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください
【4/18開催】VSCode Dev Containersで楽々開発環境構築祭り〜Python/Reactなどなど〜
Visual Studio Codeの拡張機能であるDev Containersを使ってReactとかPythonとかSpring Bootとかの開発環境をラクチンで構築する方法を紹介するイベントです。
https://tech-lab.connpass.com/event/311864/

こんにちは。サイオステクノロジー OSS サポート担当 山本 です。

唐突ですが、今回はプロメテウスについてです。ギリシャ神話の神様で、人類に火をもたらしたという説のある…ではなく、今回扱うのはこちら。OSS の Prometheus™ です。

Prometheus って何?

Prometheus は、OSS の監視ソリューションの一種です。つまり、以前紹介した Zabbix と同じカテゴリのツールとなります。

機能の概要も Zabbix と似ており、設定した内容に従って自動でデータを収集し、設定した条件を満たすデータを検知したらメールなどで通知を行うことなどができる、といったツールになっています。

監視対象のデータの収集・保存を行う prometheus

収集されるデータの出力を行う exporter

の、主に 2つの要素から構成されています。
これらの他にも Prometheus に通知機能を提供する AlertManager などがあります。

監視データは Prometheus に組み込まれている TSDB (time series database) という仕組みで保存されます。デフォルトでは Prometheus を導入したサーバのローカルにデータが保存されます。
(参考:STORAGE )

■導入から起動まで

何はともあれ、動かしてみるのが一番実感が持てるはずです。実際に動かす手順を確認してみましょう。今回はお試し用の構成として、全ての要素を同じ一つの Linux サーバーで動かす場合を例として確認していきます。
このページなどを参考に、まずは Prometheus 本体を動かしてみましょう。、

最初に、公式サイトのダウンロードページから Prometheus をダウンロードします。ダウンロードページには他にもいろいろなものがありますが、最初は Prometheus だけで OK です。

1__prom_dl

ダウンロードを行なったら、解凍後に解凍ディレクトリに移動し、以下のコマンドを実行します。コマンドで指定している prometheus.yml は設定ファイルですが、今は特に編集せずに実行してみてください。

# ./prometheus --config.file=prometheus.yml

例えばダウンロード ~ 実行までの操作をコマンドで実行する場合、この記事の作成時点 (2019/03/28) の最新バージョン prometheus-2.8.0 を使用するならば以下の順にコマンドを実行します。

# wget https://github.com/prometheus/prometheus/releases/download/v2.8.0/prometheus-2.8.0.linux-amd64.tar.gz
# tar xvf prometheus-2.8.0.linux-amd64.tar.gz
# cd prometheus-2.8.0.linux-amd64
# ./prometheus --config.file=prometheus.yml

はい、これでローカルの監視データの収集や閲覧ができるようになりました (!!!)
ブラウザを開いて以下の URL を入力し、Prometheus のインターフェースにアクセスしてみましょう。以下のような画面が表示できれば、Prometheus は動作しており、既にデータ収集が始められています。

https://<サーバー名または IP アドレス>:9090/graph

2__prom_UI

■インターフェースからデータを取得してみる

Prometheus のインターフェースにアクセスできたら、取得したデータを確認してみましょう。
例えば、画面上部の「Execute」ボタンの上のテキストボックスに “prometheus_target_interval_length_seconds” と入力して、「Execute」ボタンを押下してみてください。

3__prom_UI_sample

はい、データが取れました。データが出力されているパーツの上部の「Graph」のタブをクリックすると、グラフ表示もできたりします。

3__2_prom_UI_sample

そんなわけで、何も準備していない状態からわずか 4コマンドで監視を始められてしまいました。めでたしめでたし。



ではないですね。監視ソリューションで大事なのは、「何を」監視しているのか、今見ているデータは「何を」監視したデータなのか、というところです。そもそも、細かい設定を何もした記憶がないのにデータが取れるのはどういう絡繰なのかも気になるところです。

Prometheus の取得するデータ

そんなわけで、Prometheus の監視の仕組みを確認してみましょう。

まず先ほどは無視していた設定ファイルを見てみましょう。先に入力した Prometheus の実行コマンドにも含まれていますが、Prometheus を解凍したディレクトリに存在している prometheus.yml がそれです。

prometheus.yml

      1 # my global config
      2 global:
      3   scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
      4   evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
      5   # scrape_timeout is set to the global default (10s).
      6
      7 # Alertmanager configuration
      8 alerting:
      9   alertmanagers:
     10   - static_configs:
     11     - targets:
     12       # - alertmanager:9093
     13
     14 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
     15 rule_files:
     16   # - "first_rules.yml"
     17   # - "second_rules.yml"
     18
     19 # A scrape configuration containing exactly one endpoint to scrape:
     20 # Here it's Prometheus itself.
     21 scrape_configs:
     22   # The job name is added as a label `job=` to any timeseries scraped from this config.
     23   - job_name: 'prometheus'
     24
     25     # metrics_path defaults to '/metrics'
     26     # scheme defaults to 'https'.
     27
     28     static_configs:
     29     - targets: ['localhost:9090']

見ての通り、Prometheus のデフォルトの設定ファイルはわずか 30行足らずです。”#” から行末までは設定としては読み込まれないコメントとして扱われるため、実際に設定として使用されているのは…ものすごく少ないですね。
(勿論、これだけしか設定項目がないというわけではなく、マニュアルにあるとおり多数の設定項目が存在しています。)

このデフォルトの設定ファイルから、Prometheus がデフォルト設定でどのようなデータを取得していたのかを確認してみましょう。
Prometheus では監視データを取得することを “scrape” と呼んでいます。
設定ファイルを確認してみると、19・20行目のコメントで説明されている “scrape_configs” が scrape に関する設定項目となっていることが読み取れます。

さて、デフォルトの “scrape_configs” の中身ですが…”job_name” と “static_configs:targets” しか設定されていません。“static_configs:targets” のアドレスがデータの取得先であることは見当がつきますが、取得しているデータの内容に関しての設定はないように見えます。

では、何を基準にデータの収集が行われているのか…それは、一度 scrape の対象を確認してみるとわかると思います。”scrape_configs” の中の 25・26行目のコメントを見ると、デフォルトではスキーマは https で metric_path は “/metrics” であるとあります。これと “static_configs:targets” の “localhost:9090” を組み合わせると [https://localhost:9090/metrics] となりそうです。このアドレスの “localhost” の部分をサーバーの IP アドレスなどに直して、ブラウザでアクセスしてみましょう。

https://<サーバー名または IP アドレス>:9090/metrics

4__prom_metric_sample

コンソール上で以下のコマンドを実行しても同じ内容を確認することができます。

# curl https://localhost:9090/metrics
 または
# curl https://<サーバー名または IP アドレス>:9090/metrics

色々とデータらしきものが出てきました。これがまさに、Prometheus の収集している一連のデータである「metrics」です。
この一連の出力は、”#” で開始するコメント行と、左側の “キーワード” と右側の “値” のセットのデータ行が多数含まれています。Prometheus のインターフェースでキーワードを入力すると、「値」が返ってくる、という仕組みですね。上記アドレスの出力の中身を探してみると、先にインターフェースでの監視データの確認で使った “prometheus_target_interval_length_seconds” という項目も含まれているはずです。

Prometheus はこのように、指定したアドレスから取得できる一連のデータを対象に監視を行う、監視ソリューションなのです。

■metrics を出力するもの Exporter

Prometheus が特定のアドレスに出力されている一連のデータ「metrics」を取得しているということはわかりました。ではこの一連のデータを出力しているのは一体何者なのか、というのは、次に当然浮かぶ疑問だと思います。

当然、何もせずに特定のアドレスにデータが出力されるなんてことはありません。
先ほど確認した [https://<サーバー名または IP アドレス>:9090/metrics] で出力されている「metrics」は、Prometheus のプロセスが出力しているものです。

さて、Prometheus が監視しているのは「metrics」であるため、監視対象でも「metrics」が出力されていなければ監視を行うことができません
これを満たすため、導入したサーバーで「metrics」を出力してくれるツールexporter です。exporter は Prometheus をダウンロードしたページと同じページなどから入手することができます。早速導入してみましょう。

exporter にはいくつか種類がありますが、今回は公式のページから入手できる node_exporter を使用してみます。node_exporter には設定ファイルなどもないので、ダウンロードして解凍したらそのまま実行ファイルを実行すれば OK です。
例えば、この記事の作成時点 (2019/03/28) で最新の node_exporter-0.17.0 であれば、以下の4つのコマンドでダウンロード ~ 実行まで行うことができます。

# wget https://github.com/prometheus/node_exporter/releases/download/v0.17.0/node_exporter-0.17.0.linux-amd64.tar.gz
# tar xvf node_exporter-0.17.0.linux-amd64.tar.gz
# cd node_exporter-0.17.0.linux-amd64
# nohup ./node_exporter &

(4行目は # ./node_exporter でも可)

特に難しい点はありませんね。バックグラウンドで実行させるために nohup で実行したので、コンソールへの出力は代わりに ./nohup.out に記録されます。このファイルの末尾を見ると、node_exporter は 9100 番ポートで待ち受けていることが確認できます。

time="yyyy-MM-ddTHH:mm:ss+09:00" level=info msg="Listening on :9100>" source="node_exporter.go:111"

では本当に 9100 番ポートに「metrics」が出力されているかを確認してみましょう。ブラウザから [https://<サーバー名または IP アドレス>:9100/metrics] にアクセスしてみます。

5__node_metric_sample

コンソール上で以下のコマンドを実行しても同じ内容を確認することができます。

# curl https://localhost:9100/metrics
 または
# curl https://<サーバー名または IP アドレス>:9100/metrics

無事に上記のアドレスから「metrics」が取得できることを確認できたら、今度は Prometheus がこの「metrics」を取得するように設定します。Prometheus の設定ファイル prometheus.yml の末尾に設定を書き加えましょう。
今回追加する設定は、追加する Exporter を識別するための名前を設定する “job_name” と、追加する Exporter の「metrics」の出力先のアドレスを設定する “static_configs:targets” です。

<Prometheus の解凍ディレクトリ>/prometheus.yml

      :
     19 # A scrape configuration containing exactly one endpoint to scrape:
     20 # Here it's Prometheus itself.
     21 scrape_configs:
     22   # The job name is added as a label `job=` to any timeseries scraped from this config.
     23   - job_name: 'prometheus'
     24
     25     # metrics_path defaults to '/metrics'
     26     # scheme defaults to 'https'.
     27
     28     static_configs:
     29     - targets: ['localhost:9090']
     30 # ここから追加分
     31   - job_name: 'local_node'
     32     static_configs:
     33     - targets: ['localhost:9100']

設定できたら、以下のコマンドで Prometheus の設定をリロードします。
(一見変わった手法ですが、ここここなどで紹介されている手法です)

# killall -HUP prometheus

コマンドを実行したら、[https://<サーバー名または IP アドレス>:9090/targets] にアクセスしてみましょう。または、インターフェースの上部から [Status > Targets] と選択しても同じページを表示できます。
このページは Prometheus に設定している監視対象の状態を確認できるページですが、”local_node” (job_name で設定した名前) の項目が追加されているはずです。

6__prom_UI_target_1
7__prom_UI_target_2

これで、Prometheus で node_exporter で出力されている監視情報を取得・参照できるようになりました。試しに [https://<サーバー名または IP アドレス>:9090/graph] にアクセスし、node_exporter で出力されている「metric」のうちの一つ “node_filesystem_avail_bytes” が取得できるかを確認してみてください。

8__prom_UI_sample_2

Prometheus で監視できる内容について

ここまで確認してきた内容から既にお気づきかと思いますが、Prometheus の監視項目は exporter などで出力される「metrics」の項目がそのまま監視項目となっています。また、その内容は Prometheus での設定ではなく exporter 側の実装に依存します。

そのため、Prometheus でどのような項目が監視できるのかは、導入した exporter によって決まります。多くの種類の exporter が存在しているのはそれぞれ出力する「metrics」の内容が異なるからで、要件に合致する exporter が用意できるかが Prometheus での監視を行う際の非常に重要なポイントとなります。

Prometheus のダウンロードページで直接ダウンロードできるもの以外にも、サードパーティ製を含む Exporter のリストが公式ドキュメント上に存在していますが、リストアップされているだけでも非常に多岐に渡る Exporter が存在しています。勿論、このページに挙げられていないものも多く存在していることでしょう。
https://prometheus.io/docs/instrumenting/exporters/

なお、どの Exporter でどんな名前の項目でどんな内容を出力しているかの情報は…ドキュメントとして纏められているものは見つけることはできませんでした。多くの Exporter では「metrics」の出力に「どんな内容のデータを取得しているか」のコメントが含まれているはずなので、それらを確認するしかないようです。
例えば、今回確認で使っていた “prometheus_target_interval_length_seconds” と “node_filesystem_avail_bytes” は、「metrics」の出力内容に以下のような説明が含まれています。

# HELP prometheus_target_interval_length_seconds Actual intervals between scrapes.
# TYPE prometheus_target_interval_length_seconds summary
# HELP node_filesystem_avail_bytes Filesystem space available to non-root users in bytes.
# TYPE node_filesystem_avail_bytes gauge

なお、マニュアルには exporter を作成するためのガイドが存在しています。他の監視ソリューションや公開されている exporter でも監視できない内容を監視したい、という場合には exporter を作成することで対応することができるかもしれません。

Prometheus のクエリ

Prometheus で指定したデータを取得するための “クエリ” は、promQL (Prometheus Query Language) という独自の言語を使用しています。そのため、Prometheus を使いこなすにはこの promQL を理解する必要があります。

ここでは基本的な例をいくつか紹介します。

<項目名>
最新の取得データから <項目名> を持つ全ての要素を取得します。

例:node_filesystem_avail_bytes
“node_filesystem_avail_bytes” の最新値を取得。

9__prom_query_sample_1

<項目名>{<条件>}
最新の取得データから <項目名> を持つ要素のうち、<条件> を満たすものを取得します。

例:node_filesystem_avail_bytes{fstype=”tmpfs”}
“node_filesystem_avail_bytes” の最新値のうち、fstype の項目が “tmpfs” のものを取得。

10__prom_query_sample_2

<項目名>{<条件>}[<時間>]
<時間> 前から現在までの間に取得した全てのデータから <項目名> を持つ要素のうち、<条件> を満たすものを取得します。

例:node_filesystem_avail_bytes{fstype=”tmpfs”}[1m]
直近 1分以内に取得された “node_filesystem_avail_bytes” のうち、fstype の項目が “tmpfs” のものを取得。
(※1m = 1minutes、デフォルトの設定ファイル使用時の 15秒で 1つデータが取得されている場合の例)

11__prom_query_sample_3

この他、関数など様々な取得方法がありますので、詳細は以下のページなどをご確認ください。
QUERYING PROMETHEUS (basic)
OPERATORS
FUNCTIONS
QUERY EXAMPLES

■UI の編集について

Prometheus のインターフェースには、表示をカスタマイズしたり、監視に便利なデータセットのページを作成したり、といった表示をカスタマイズする機能はありません。

Prometheus のデータを用いて、複数の監視データをグラフなどにして一つのページで配置・表示できるようなダッシュボード機能を使用したい場合、別ツールである Grafana を使用するのが一般的です。
(マニュアルでも Grafana が紹介されています。)

また、GO 言語で作成されているコンソールテンプレートという表示用のテンプレートのサンプルが <Prometheus の解凍ディレクトリ>/console/ 配下にいくつか用意されています。GO 言語の扱いに慣れているならば、これらのファイルを参考に新しいテンプレートを作成することもできます。

■最後に

今回は Prometheus について見てきました。

独自のクエリ言語や取得できている内容の把握など難しいところもありますが、動作させるまでに必要な手順の少なさや少ない設定で多くのデータを取得できる仕組み、独自にカスタマイズするためのガイドなど、上手く要件に合致した時には強力な監視ソリューションになるのではないか、と思います。
UI 等グラフィカルな表示に関してはやや弱い印象を受けますが、別ツールである Grafana を活用することで比較的簡単に非常に柔軟な表示を実現することができます。(Grafana についてはまた別の機会に紹介します)

アバター画像
About 山本 53 Articles
元サーバサイドエンジニアのサポートエンジニア。「物事は理解できれば活路が見出せる可能性がある」という信条のもと、今日も石橋を叩く。
ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

2人がこの投稿は役に立ったと言っています。


ご覧いただきありがとうございます。
ブログの最新情報はSNSでも発信しております。
ぜひTwitterのフォロー&Facebookページにいいねをお願い致します!



>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

Be the first to comment

Leave a Reply

Your email address will not be published.


*


質問はこちら 閉じる