🌍

【prometheus】 の理解を深める

に公開
Docker
Linux
Prometheus
Grafana
promql
tech

はじめに

以前、Prometheus と Grafana の環境構築を行いました。構築自体はできたものの、仕組みの理解が浅かったため、理解を深める目的で今回アウトプットすることにしました。
https://zenn.dev/eiken/articles/a5a61770531c70

1. prometheus とは

prometheus は、システムやアプリケーションから収集した メトリクス（時系列データ） をもとに、監視や可視化を行うオープンソースのソフトウェアです。

少し難しく書くとすれば、エクスポーターなどから HTTP 経由でメトリクスを収集し、内部の時系列データベースに格納、クエリ言語 PromQL により監視や可視化を実現するオープンソースのモニタリングツールです。

・メトリクスとは

一般的には、定量的に測定できる指標や値のことを指します。
prometheus においては、これらのメトリクスを時系列で収集・保存し、各メトリクスは「名前」「ラベル」「値」「タイムスタンプ」を持ちます。これらは PromQL（Prometheus Query Language） によって柔軟に検索・分析することができます。

・時系列データとは

時系列データとは、時間の経過に沿って連続的または定期的に観測されるデータのことです。
コンピューターリソースの使用状況を例に挙げると、「CPU やメモリ、ディスクの使用率」「ネットワークの通信量」「起動中のプロセス数」...... などが、時間ごとに変化するため時系列データに分類されます。
コンピューターに限らず、他にも「天気の変化」や「企業の月ごとの売上」、「国の GDP の推移」なども時系列データに該当します。

※当初は Prometheus をサーバー監視専用のソフトウェアだと考えていましたが、調査を進める中で、サーバー監視に限らず、さまざまな「時系列データ」を柔軟に扱えるツールであることを理解しました。

2. メトリクスの収集方法

prometheus はメトリクスを収集しないことには始まりません。メトリクスの収集方法は主に以下の3つがあります。

  1. Pull形式
    監視対象に exporter を導入し、prometheus サーバーが定期的に HTTP でメトリクスを取得する方式です。prometheus の標準的かつ一般的な収集方法です。

  2. Push形式
    監視対象が Prometheus Pushgateway にメトリクスを送信する方式です。主に一時的なジョブやバッチ処理の監視に使われます。Pushgateway は prometheus 本体ではなく別のコンポーネントです。

  3. その他
    APIやログファイルなどからメトリクスを抽出・収集する仕組みもあるようですね。

3. exporter とは

prometheus が監視対象のメトリクスを取得できるように、監視対象の内部情報を prometheus が理解できる形式（＝メトリクス形式）で公開するためのソフトウェアです。つまり、prometheus 用の「データ変換・公開ツール」といえます。
(exporter には公式のものと非公式のものが存在します。また、自作することも可能。)

【代表的な exporter 一覧】

Exporter 名称 監視対象・用途 備考
Node Exporter Linux/UNIX サーバーのハードウェア・OS情報 CPU、メモリ、ディスク、ネットワークなど基本情報を収集
Blackbox Exporter 外部サービスの可用性チェック（HTTP, TCP, ICMPなど） 死活監視に便利（pingやポート応答確認など）
Cadvisor コンテナ（Docker）のリソース使用状況 コンテナ単位のCPU・メモリなどを可視化可能
MySQL Exporter MySQL / MariaDB の各種統計情報 クエリ数、接続数、バッファ状況など
PostgreSQL Exporter PostgreSQL の統計情報 クエリ遅延、接続状況、テーブル情報など
NGINX Exporter NGINX のリクエスト・レスポンス統計情報 ステータスコード、転送量など
Apache Exporter Apache HTTP Server の統計情報 NGINXと同様、トラフィックや応答情報
MongoDB Exporter MongoDB のメトリクス コレクション統計、接続情報など

exporter のメトリクス収集タイミング

prometheus の動作を定義するメインの設定ファイルである prometheus.yml の scrape_interval 欄で収集タイミングを指定できます。

prometheus.ymlサンプル
global:
  scrape_interval: 15s  # 15秒ごとに全ターゲットをスクレイプ

scrape_configs:
  - job_name: "node_exporter"
    static_configs:
      - targets: ["localhost:9100"]

収集されたメトリクスについて

収集されたメトリクスは TSDB（時系列）データとして保存されます。どのように保存されているのか気になったので、確認してみます。
（※今回はdockerコンテナで prometheus を起動しているので、コンテナに接続して中身を確認してみます。）

% docker ps | grep prometheus         
8cb16b50f2cc   prom/prometheus   "/bin/prometheus --c…"   2 days ago   Up 2 days   0.0.0.0:9090->9090/tcp, [::]:9090->9090/tcp   prometheus

% docker exec -it prometheus sh  
/prometheus $
# コンテナ内に接続

/prometheus $ pwd
/prometheus
# prometheus の TSDB データは、通常 "/prometheus" 以下に保存されている

/prometheus $ ls -l
total 52
drwxr-xr-x    3 nobody   nobody        4096 Jul 26 23:20 01K14GKYBCE48FMG9T77HWT3PR
drwxr-xr-x    3 nobody   nobody        4096 Jul 27 19:28 01K16NQMTC66M8KZYPEEZXKEKC
drwxr-xr-x    3 nobody   nobody        4096 Jul 28 11:57 01K18EAS6N5FY40PEHMTRESAT5
drwxr-xr-x    3 nobody   nobody        4096 Jul 29 03:58 01K1A59F55VN5XYF4XF356WZY1
drwxr-xr-x    3 nobody   nobody        4096 Jul 29 05:47 01K1ABGSC3NF422GPBHP3GX8XT
drwxr-xr-x    3 nobody   nobody        4096 Jul 29 05:47 01K1ABGSF1DBYD2FCCP0MP24JQ
drwxr-xr-x    2 nobody   nobody        4096 Jul 29 05:48 chunks_head
-rw-r--r--    1 nobody   nobody           0 Jul 26 07:50 lock
-rw-r--r--    1 nobody   nobody       20001 Jul 29 04:54 queries.active
drwxr-xr-x    3 nobody   nobody        4096 Jul 29 05:47 wal
# 「01K14GKYBCE48FMG9T77HWT3PR」 などが TSDB の「ブロック」という単位で保存されている

/prometheus $ ls 01K14GKYBCE48FMG9T77HWT3PR
chunks      index       meta.json   tombstones
# chunks : 実際の時系列データが圧縮された形で保存されているファイル群（データ本体）
# index : メトリクスのラベルや時系列データの検索を効率化するためのインデックス情報
# meta.json : このブロックの開始時刻や終了時刻、バージョン情報などのメタデータ（設定情報）
# tombstones : 削除された時系列データ（メトリクス）に関する情報（論理削除の記録）

Prometheus は収集したメトリクスを上記の様に内部のTSDB（時系列データベース）にファイル形式で保存しています。このファイル群（例：01K14GKYBCE48FMG9T77HWT3PR）がそのデータの塊です。
後述する PromQL を使ってクエリを投げると、そのクエリに該当する時系列データをこのTSDBファイル群から効率的に読み出し、計算や集計を行っているようです。

※これらのデータは一定のルールに基づいて自動的に管理されており、古くて不要になったファイルはPrometheusが自動で消去してくれるとのこと。

4. PromQL とは

PromQL（Prometheus Query Language） は、prometheus に蓄積された 時系列データ（メトリクス）を検索・抽出・集約・演算するための専用クエリ言語です。ざっくり言えば、「CPU使用率が高いサーバーは？」「メモリ使用量の平均は？」といった問いに答えるための文法です。
prometheus でメトリクスを可視化したり、アラート条件を定義したりする際に中心となる仕組みです。

【基本構文と概念】

インスタントクエリ

単一時点のデータを取得します。

サンプル
node_cpu_seconds_total
レンジクエリ

一定期間のデータを取得します。[時間] をつけると範囲指定になります。

サンプル
node_cpu_seconds_total[5m]
ラベルセレクタ

データをフィルタできます。

サンプル
node_cpu_seconds_total{mode="idle", instance="192.168.1.1:9100"}
関数（例：rate）

メトリクスを集計・加工できます。

サンプル
rate(node_cpu_seconds_total{mode="idle"}[1m])

【理解したこと】

サンプルであげた 「node_cpu_seconds_total」 は node_exporter が提供しているメトリクス名です。まとめると以下の通りです。

  • prometheus 本体は、データ収集（scrape）と保存、クエリ言語（PromQL）を提供するだけ。
  • 実際の「データの中身（＝メトリクス名と値）」は exporter が作成している

つまり、監視対象に設定した exporter によって Prometheus が取得・表示できるメトリクス名は変わるという事です。

したがって、PromQL を使う上では 使用する exporter が提供するメトリクスの仕様を理解することが重要です。prometheus環境構築の前にここを先に理解すべきでした。

5. prometheus の活用例

その他、prometheus で実現できる事例をまとめました。もう少し理解が進んだら何かしらトライしてみようと思います。

1. IoTデバイスのモニタリング
温度センサー、湿度センサー、照度など、時間と共に変化する値を収集。

2. ビジネス指標のトラッキング
ECサイトの注文数、在庫推移、キャンペーンの反応数など、ビジネス上のKPIを時系列管理。

3. アプリケーションパフォーマンスの可視化
レスポンスタイム、リクエスト数、エラー率などを時系列で収集。特定の時間帯のパフォーマンス劣化を分析可能。

4. ネットワークトラフィック分析
帯域使用量、パケット数、エラーパケットの推移などをモニタリング。異常検知にも活用できる。

さいごに

以上で今回の記事については一旦終了となります。今後は grafana を用いて自分用のテンプレートを作成したり、閾値を設定しアラートを送信するなど、実践的な内容にも取り組んでいこうと思います。

Discussion