devkuma – Grafana

Grafana（グラファナ） - オープンソースのデータ監視ツール

kc@example.com (kc kim) — Mon, 05 Sep 2022 16:32:00 +0900

Grafanaとは？

Grafanaはオープンソースのデータ可視化・監視ツールである。Prometheusをはじめ、さまざまなデータを可視化できる。 Grafana Labsによって開発されている。

Kibanaとの違い

Kibanaは主にログメッセージの分析に使われる。
Grafanaは、CPU、メモリ、ディスクなどシステム観点のメトリクス指標の可視化に特化している。
KibanaはElasticsearchに結び付いているが、Grafanaではさまざまなデータベースを選択できる。
Grafanaはアラート機能を無料で利用できる。

Prometheus + Grafana + Docker Composeインストール

kc@example.com (kc kim) — Sun, 04 Dec 2022 06:49:14 +0900

概要

Prometheus、GrafanaをDocker Composeでインストールし、動作させてみる。

Docker設定

Prometheus

PrometheusをDockerにインストールするためのファイルとディレクトリを構成する。

まずインストールディレクトリを適当な場所に作成する。

mkdir prometheus-grafana
cd prometheus-grafana

Dockerを実行するためにdocker-compose.ymlファイルを作成する。 prometheus-grafana/docker-compose.yml

version: '3.7'  # ファイル規格バージョン
services:       # この項目の下に実行するコンテナを定義
  prometheus:
    image: prom/prometheus
    container_name: prometheus
    volumes:
      - ./prometheus/config:/etc/prometheus
      - ./prometheus/volume:/prometheus
    ports:
      - 9090:9090 # アクセスポート設定（コンテナ外部:コンテナ内部）
    command: # web.enable-lifecycleはAPI再起動なしで設定ファイルをreloadできるようにする
      - '--web.enable-lifecycle'
      - '--config.file=/etc/prometheus/prometheus.yml'
    restart: always
    networks:
      - promnet

networks:
  promnet:
    driver: bridge

Prometheus DockerHub image
- https://hub.docker.com/r/prom/prometheus
Prometheusの保存ディレクトリは./prometheus/volumeに指定した。
Prometheusの設定ディレクトリは./prometheus/configに指定した。

Prometheus関連設定ファイルを配置するディレクトリを作成する。

mkdir prometheus
mkdir prometheus/config

/prometheus/configディレクトリ内に設定ファイル（prometheus.yml、rule.yml）を作成する。

参照: Prometheus Configuration

prometheus-grafana/prometheus/config/prometheus.yml

global:
  scrape_interval: 15s     # scrape targetの基本intervalを15秒に変更 / default = 1m
  scrape_timeout: 15s      # scrape requestがtimeoutする長さ / default = 10s
  evaluation_interval: 2m  # ruleをどれくらい頻繁に検証するか / default = 1m

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'       # 基本的に付けるラベル
  query_log_file: query_log_file.log # prometheusのクエリログを記録。なければ記録しない

# ルールをロードし、evaluation_interval設定に従って定期的に評価する。
rule_files:
  - "rule.yml"  # ファイル位置はprometheus.ymlと同じ場所
  - "rule2.yml" # 複数指定可能

# メトリクスを収集するエンドポイント。ここではPrometheusサーバー自身を指す。
scrape_configs:
  # この設定で収集した時系列に`job=<job_name>`としてジョブ名を設定する。
  # metrics_pathの基本パスは'/metrics'で、schemeの基本値は`http`。
  - job_name: 'monitoring-item' # job_nameはすべてのscrape内で一意でなければならない
    scrape_interval: 10s      # globalでdefault値を定義しているため省略可能
    scrape_timeout: 10s       # globalでdefault値を定義しているため省略可能
    metrics_path: '/asdf'     # オプション - prometheusがmetrics取得時に参照するURIを変更できる | default = /metrics
    honor_labels: false       # オプション - ラベル衝突がある場合にラベルを変更するか設定 | default = false
    honor_timestamps: false   # オプション - honor_labelsがtrueの場合、metrics timestampが露出する | default = false
    scheme: 'http'            # オプション - request送信時のscheme設定 | default = http
    params:                   # オプション - request送信時のparam
      user-id: ['myemail@email.com']

    # その他authorization設定
    # service discovery設定（sd）

    # 実際にscrapeするターゲットに関する設定
    static_configs:
      - targets: ['localhost:9090', 'localhost:9100', 'localhost:80'] ## prometheus, node-exporter, cadvisor  
        labels: # オプション - scrapeして取得するmetricsすべてに付けるラベル
          service : 'monitor-1'
    
    # relabel_config - scrape前のlabelを修正
    # metric_relabel_configs - 取得対象のラベルを動的に書き換える設定（drop, replace, labeldrop）

prometheus-grafana/prometheus/config/rule.yml

groups:
- name: example # ファイル内でuniqueでなければならない
  rules:

  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

Dockerが修正できるように/prometheusディレクトリの権限を変更する。

sudo chmod -R 777 ./prometheus

最終的なファイルをすべて作成すると、次のような構造になる。

.
├── docker-compose.yml
└── prometheus
    └── config
        ├── prometheus.yml
        └── rule.yml

Grafana

Grafanaはデータ可視化、監視、分析のためのオープンソースプラットフォームである。

docker-compose.ymlでservices:の下にGrafana設定を追加する。

  grafana:
    image: grafana/grafana
    container_name: grafana
    # user: "$GRA_UID:$GRA_GID"
    ports:
      - 3000:3000 # アクセスポート設定（コンテナ外部:コンテナ内部）
    volumes:
      - ./grafana/volume:/var/lib/grafana
    restart: always
    networks:
      - promnet

Grafana DockerHub Image
- https://hub.docker.com/r/grafana/grafana
ここではGrafanaの保存ディレクトリを./grafana/volumeに指定した。

Docker実行

Dockerイメージを作成し、コンテナの起動をまとめて処理するコマンドを実行する。

docker compose up -d

コンテナを停止するには次のコマンドを実行する。

docker compose stop

コンテナを再起動するには次のコマンドを実行する。

docker compose start

実行後には、以下のようなvolumeディレクトリが作成されることを確認できる。

.
├── docker-compose.yml
├── grafana
│   └── volume
│       ├── grafana.db
│       ├── grafana.db-journal
│       └── plugins
└── prometheus
    ├── config
    │   ├── prometheus.yml
    │   ├── query_log_file.log
    │   └── rule.yml
    └── volume
        └── data
            ├── chunks_head
            ├── lock
            ├── queries.active
            └── wal
                └── 00000000

接続確認

Prometheus
- http://localhost:9090
Grafana
- http://localhost:3000
  - 基本アカウントID/PW: admin/admin

参考

設定ファイルはGitHubに置いてある。

Spring Boot default metrics

kc@example.com (kc kim) — Sat, 10 Dec 2022 04:41:00 +0900

https://tomgregory.com/spring-boot-default-metrics/

ここではSpring Bootで提供される最も重要な基本メトリクスと、それを使用してアプリケーション内の問題をより効果的に強調する方法を見ていく。

Spring Boot ActuatorとMicrometerの概要

Spring Boot ActuatorはHTTPおよびJMXを通じて、さまざまな監視・管理エンドポイントを提供する。Micrometerアプリケーション監視フレームワークと統合することで、非常に重要なメトリクス機能が含まれる。

Micrometerサイトのトップページには次のような内容がある。

Micrometer provides a simple facade over the instrumentation clients for the most popular monitoring systems, allowing you to instrument your JVM-based application code without vendor lock-in. Think SLF4J, but for metrics.

Micrometerはベンダーに依存しないmetrics facadeである。つまり、1つの共通方法でメトリクスを収集し、さまざまな監視システムが要求する形式で公開する。ロギング関連システムにSLF4Jがあるなら、監視（metric）システムにはMicrometerがある。

サポートされる人気の監視フレームワークにはGraphite、Prometheus、StatsDがある。ここでは、アプリケーションから周期的にメトリクスを取得する独立サービスであるPrometheusに焦点を当てる。

Spring BootアプリケーションにActuatorメトリクスを追加する

Prometheus形式でメトリクスを公開するようSpring Bootアプリケーションを構成するには、次の手順に従う。

追加依存関係を含める

Spring Boot Starter Actuator モジュールを含めるには、Gradle依存関係一覧に次を追加する。

implementation 'org.springframework.boot:spring-boot-starter-actuator'

Mavenでは次のようになる。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

そしてMicrometer Registry Prometheus モジュールを追加し、アプリケーションからPrometheus形式でメトリクスをスクレイプできるようにする。

Gradle:

implementation 'io.micrometer:micrometer-registry-prometheus:1.5.1'

Maven:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
    <version>1.5.1</version>
</dependency>

構成でメトリクス有効化を設定する

デフォルトでは、ほぼすべてのSpring Boot Actuator HTTPエンドポイントは無効化されているが、構成によって有効化できる。プロジェクトのsrc/main/resourcesフォルダにあるapplication.propertiesファイルへ次の設定を追加する。

management.endpoints.web.exposure.include=metrics,prometheus

Actuatorモジュールには有効化できるエンドポイントが多いが、この構成では次の2つだけを有効化した。

/actuator/metrics: メトリクスを探索し、その値を見るためのJSON APIを提供するエンドポイント。
/actuator/prometheus: Prometheusで収集するために必要なカスタム形式でメトリクスを返すエンドポイント。
- ここが今後説明していく内容である。

1. Spring MVCメトリクス

すべてのWebアプリケーションにおいて、基本Spring MVCメトリクスはインバウンドHTTPトラフィックを監視するための優れた開始点を提供する。エラー、トラフィック量、リクエスト遅延時間のいずれを追跡する必要がある場合でも、これらのメトリクスで確認できる。

インバウンドHTTPリクエスト期間

Spring Bootアプリケーションで公開される各エンドポイントについて、リクエスト数とリクエスト期間に関する情報を提供するhttp_server_requests_seconds summaryメトリクスを得られる。これは/actuator/prometheusエンドポイントに公開される2つのメトリクスで構成される。

# HELP http_server_requests_seconds  
# TYPE http_server_requests_seconds summary
http_server_requests_seconds_count{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/hello",} 12.0
http_server_requests_seconds_sum{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/hello",} 0.083579374

http_server_requests_seconds_countは、アプリケーションがそのエンドポイントで受け取った総リクエスト数である。
http_server_requests_seconds_sumは、アプリケーションがそのエンドポイントで受け取った全リクエスト期間の合計である。

これらのメトリクスには次のタグが含まれる。

Tag	説明	例
`exception`	発生した例外のクラス名	None, NullPointerException
`method`	HTTPリクエスト方法	GET, POST, PUT, PATCHなど
`outcome`	HTTPレスポンス状態の文字列表現	SUCCESS, SERVER_ERROR
`status`	HTTPレスポンスステータスコード	200, 500など
`uri`	リクエストURI	`/hello`

タグとは

タグ（Tag）はメトリクスの変化を測定するのに有用である。たとえば`http_server_requests_seconds_count`を使うと、特定URIに対するリクエスト数を測定できる。アプリケーションが別のエラーレスポンス状態を返し始めると、別のstatusタグを持つメトリクスとして分離される。そのようなメトリクスを一緒に、または個別にクエリできる。

Prometheusでは、すべてのタグに対する平均インバウンドリクエスト期間を提供する簡単なクエリを作成できる。

rate(http_server_requests_seconds_sum[1m]) / rate(http_server_requests_seconds_count[1m])

なぜrate関数を使うのか

上のPrometheusクエリにrate関数が含まれている理由が気になるかもしれない。リクエスト回数を全リクエスト期間で割ればよいのではないか。[Micrometer Webサイト](https://micrometer.io/docs/registry/prometheus#_timers)には次の説明がある。 "Representing a counter without rate normalization over some time window is rarely useful, as the representation is a function of both the rapidity with which the counter is incremented and the longevity of the service." つまり、表現はカウンターが増加する速度とサービスの寿命の両方の関数であるため、一定時間のrate正規化なしにカウンターを表現してもほとんど有用ではない。

インバウンドHTTPリクエストの分位数とパーセンタイル

Spring MVCメトリクスは分位数とパーセンタイルも計算できる。これは最も遅いリクエストを無視しながら、APIのリクエスト期間がどれほど遅いか評価したい場合に有用である。

たとえば95パーセンタイルは、観測値の95%が下にあり、5%が上にある値である。つまり、リクエストの95%で見られる最も遅いリクエスト期間を提供する。

分位数を有効にするには、関心のある分位数を指定した追加設定プロパティをapplication.propertiesに追加する。

management.metrics.web.server.request.autotime.percentiles=<comma-separated list of quantiles>

プロパティを0.95に構成すると、/actuator/prometheusで次のようなメトリクスが生成される。

http_server_requests_seconds{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/hello",quantile="0.95",} 0.023068672

このメトリクスで使用されるタグは上と同じだが、メトリクスをクエリするために使えるquantileタグも追加される。

http_server_requests_seconds{quantile="0.95"}クエリでPrometheusにグラフが生成される。

インバウンドHTTPリクエスト最大期間

Spring Bootアプリケーションが公開する各エンドポイントについて、各インバウンドHTTPリクエストタイプの最大持続時間を提供するhttp_server_requests_seconds_max gaugeメトリクスを得られる。

# HELP http_server_requests_seconds_max Duration of HTTP server request handling
# TYPE http_server_requests_seconds_max gauge
http_server_requests_seconds_max{exception="None",method="GET",outcome="SUCCESS",status="200",uri="/hello",} 0.005831

http_server_requests_seconds_maxは期間中の最大リクエスト期間である。新しい時間ウィンドウが始まると値は0にリセットされる。デフォルト時間ウィンドウは2分である。

このメトリクスで使用されるタグは上と同じである。

このグラフは通常のhttp_server_requests_seconds_maxクエリからPrometheusで生成される。

2. HTTPクライアントRestTemplateおよびWebClientアウトバウンドリクエストメトリクス

RestTemplateまたはWebClientクラスを使用してアウトバウンドHTTPリクエストを実行する場合、インバウンドHTTPリクエストと同様のリクエストメトリクスを使用できる。これらのメトリクスが動作するには、注入されたRestTemplateBuilderまたはWebClient.Builderクラスを使用してHTTPクライアントを作成する必要がある。

アウトバウンドHTTPリクエスト期間

各アウトバウンドエンドポイントはhttp_client_requests_secondsメトリクスを取得する。これは/actuator/prometheusエンドポイントによって公開される2つのメトリクスで構成される。

# HELP http_client_requests_seconds Timer of RestTemplate operation
# TYPE http_client_requests_seconds summary
http_client_requests_seconds_count{clientName="google.com",method="GET",outcome="SUCCESS",status="200",uri="/https://google.com",} 3.0
http_client_requests_seconds_sum{clientName="google.com",method="GET",outcome="SUCCESS",status="200",uri="/https://google.com",} 0.465022459

http_client_requests_seconds_countは、アプリケーションがこのエンドポイントに対して実行した総リクエスト数である。
http_client_requests_seconds_sumは、アプリケーションがこのエンドポイントに対して実行した全リクエスト期間の合計である。

これらのメトリクスには次のタグも含まれる。

タグ	説明
`clientName`	URIのホストを使用して呼び出すエンドポイント名
`exception`	発生した例外のクラス名
`method`	HTTPリクエスト方法
`outcome`	HTTPレスポンス状態の文字列表現
`status`	HTTPレスポンスステータスコード
`uri`	リクエストURI

Prometheusでは、時間経過に伴う平均アウトバウンドリクエスト期間を提供する簡単なクエリを作成できる。

rate(http_client_requests_seconds_sum[1m]) / rate(http_client_requests_seconds_count[1m])

アウトバウンドHTTPリクエスト最大期間

各アウトバウンドエンドポイントはhttp_client_requests_seconds_max gauge指標を取得し、各アウトバウンドHTTPリクエストタイプの最大持続時間を提供する。

# HELP http_client_requests_seconds_max Timer of RestTemplate operation
# TYPE http_client_requests_seconds_max gauge
http_client_requests_seconds_max{clientName="google.com",method="GET",outcome="SUCCESS",status="200",uri="/https://google.com",} 0.205564498

http_client_requests_seconds_maxは期間中の最大リクエスト期間である。新しい時間ウィンドウが始まると値は0にリセットされる。デフォルト時間ウィンドウは2分である。

このメトリクスで使用されるタグは上の「アウトバウンドHTTPリクエスト期間」と同じである。

3. JVMメトリクス

Micrometerには、JVM（Java Virtual Machine）で発生している状況の監視に役立つ3種類のメトリクスが含まれている。

JVMメモリメトリクス

各メモリ領域について、jvm_memory_used_bytesで使用済みメモリ量を、jvm_memory_max_bytesで使用可能メモリ量を確認できる。

# HELP jvm_memory_used_bytes The amount of used memory
# TYPE jvm_memory_used_bytes gauge
jvm_memory_used_bytes{area="heap",id="G1 Survivor Space",} 8388608.0
jvm_memory_used_bytes{area="heap",id="G1 Old Gen",} 3938936.0
jvm_memory_used_bytes{area="nonheap",id="Metaspace",} 4.2306152E7

...

# HELP jvm_memory_max_bytes The maximum amount of memory in bytes that can be used for memory management
# TYPE jvm_memory_max_bytes gauge
jvm_memory_max_bytes{area="heap",id="G1 Survivor Space",} -1.0
jvm_memory_max_bytes{area="heap",id="G1 Old Gen",} 8.589934592E9

ここには多くのデータがあるが、たとえばPrometheusで次のクエリを使用し、使用されたheap type memoryの総量を表示できる。

sum(jvm_memory_used_bytes{area="heap"})

これはPrometheusのsum関数を使用し、上のidタグで見られるすべてのヒープメモリ領域（G1 Survivor Space、G1 Old Gen、G1 Eden Space）で使用されたメモリを合算する。

JVMガベージコレクション指標

JVMがメモリを管理する方法について深い洞察を得るために使えるガベージコレクション指標が多数ある。大きく次の領域に分けられる。

一時停止時間

jvm_gc_pause_secondsとjvm_gc_pause_seconds_maxメトリクスは、ガベージコレクションに費やされた時間に関する情報を提供する。

# HELP jvm_gc_pause_seconds Time spent in GC pause
# TYPE jvm_gc_pause_seconds summary
jvm_gc_pause_seconds_count{action="end of minor GC",cause="Metadata GC Threshold",} 1.0
jvm_gc_pause_seconds_sum{action="end of minor GC",cause="Metadata GC Threshold",} 0.005
# HELP jvm_gc_pause_seconds_max Time spent in GC pause
# TYPE jvm_gc_pause_seconds_max gauge
jvm_gc_pause_seconds_max{action="end of minor GC",cause="Metadata GC Threshold",} 0.0

メモリプールサイズ増加

jvm_gc_memory_allocated_bytes_total指標はyoung generation memory poolのサイズ増加を知らせ、jvm_gc_memory_promoted_bytes_totalメトリクスはold generationに関するものである。

ライブold generation poolサイズ

jvm_gc_live_data_size_bytesメトリクスはold generation poolサイズを知らせる。jvm_gc_max_data_size_bytesはold generation poolに割り当て可能な最大サイズを知らせる。

JVMスレッドメトリクス

これらの指標により、JVM内のスレッドを確認できる。

# HELP jvm_threads_states_threads The current number of threads having NEW state
# TYPE jvm_threads_states_threads gauge
jvm_threads_states_threads{state="runnable",} 7.0
jvm_threads_states_threads{state="blocked",} 0.0
jvm_threads_states_threads{state="waiting",} 11.0
jvm_threads_states_threads{state="timed-waiting",} 3.0
jvm_threads_states_threads{state="new",} 0.0
jvm_threads_states_threads{state="terminated",} 0.0

jvm_threads_states_threadsは各スレッド状態にあるスレッド数を示す。
jvm_threads_live_threadsはデーモンおよび非デーモンスレッドを含む総ライブスレッド数を示す。
jvm_threads_daemon_threadsは総デーモンスレッド数を示す。
jvm_threads_peak_threadsはJVM起動後の最大総スレッド数を示す。

デーモンスレッド

デーモンスレッドは、ガベージコレクションのようなバックグラウンド作業を行う優先順位の低いスレッドである。

Prometheusでjvm_threads_states_threadsを実行すると、グラフですべてのスレッド状態を確認できる。

Spring Boot + Prometheus + Grafana + Dockerでアプリケーション監視を連携するクイックガイド

kc@example.com (kc kim) — Sat, 10 Dec 2022 04:41:00 +0900

概要

Spring BootのActuatorを利用してMetricsの測定情報をPrometheusへ渡し、それをGrafanaで可視化する構成を作成する。

Spring Bootプロジェクトの作成

まず、Prometheusへ渡すメトリクスを公開するSpring Bootプロジェクトを作成する。

新規プロジェクト作成コマンド

次のようにcurlコマンドを使用してSpring Bootの新規プロジェクトを作成する。

curl https://start.spring.io/starter.tgz \
-d bootVersion=2.7.6 \
-d dependencies=web,actuator,prometheus \
-d baseDir=spring-actuator-prometheus \
-d groupId=com.devkuma \
-d artifactId=spring-actuator-prometheus \
-d packageName=com.devkuma.prometheus \
-d applicationName=ActuatorPrometheusApplication \
-d javaVersion=11 \
-d packaging=jar \
-d type=gradle-project | tar -xzvf -

このコマンドではJava 11、Spring Boot 2.7.6を使用し、依存関係としてweb、actuator、prometheusを追加している。

ビルドファイルの依存関係を確認

build.gradle

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	runtimeOnly 'io.micrometer:micrometer-registry-prometheus'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

spring-boot-starter-actuatorはSpring Bootアプリケーションの情報を扱えるようにする。
- Spring Boot 2.0以降のActuatorには、アプリケーションのメトリクスを測定できるMicrometerの機能が含まれている。
micrometer-registry-prometheusはPrometheusが読み取れるメトリクスを提供する役割を持つ。
- このライブラリは、Micrometerが生成するメトリクスをPrometheusサーバーで利用できるメトリクス形式へ変換する。

Actuator Endpointの設定

Spring WebでActuatorを使うと、Micrometerを通じて生成されたアプリケーションのメトリクス情報をPrometheusサーバーが取得（Pull）できるように、追加のendpointを提供できる。

Actuatorでは、application.ymlのオプション（management.endpoints.web.exposure.include）で/actuatorページに公開するendpointの一覧を設定できる。

/src/main/resources/application.yml

management:
  endpoints:
    web:
      exposure:
        include: health, prometheus

ここではデフォルトで含まれるhealthとPrometheus endpointを追加している。

アプリケーションが提供するendpoint一覧を確認

アプリケーションを起動し、http://localhost:8080/actuatorへアクセスすると、Actuatorが提供するendpoint一覧を確認できる。

{
    "_links": {
        "self": {
            "href": "http://localhost:8080/actuator",
            "templated": false
        },
        "health-path": {
            "href": "http://localhost:8080/actuator/health/{*path}",
            "templated": true
        },
        "health": {
            "href": "http://localhost:8080/actuator/health",
            "templated": false
        },
        "prometheus": {
            "href": "http://localhost:8080/actuator/prometheus",
            "templated": false
        }
    }
}

ここでhttp://localhost:8080/actuator/prometheusでは、Micrometerを通じて収集されたメトリクスを確認できる。

# HELP tomcat_sessions_active_current_sessions  
# TYPE tomcat_sessions_active_current_sessions gauge
tomcat_sessions_active_current_sessions 0.0
# HELP jvm_gc_pause_seconds Time spent in GC pause
# TYPE jvm_gc_pause_seconds summary
jvm_gc_pause_seconds_count{action="end of minor GC",cause="Metadata GC Threshold",} 1.0
jvm_gc_pause_seconds_sum{action="end of minor GC",cause="Metadata GC Threshold",} 0.006
# HELP jvm_gc_pause_seconds_max Time spent in GC pause
# TYPE jvm_gc_pause_seconds_max gauge
jvm_gc_pause_seconds_max{action="end of minor GC",cause="Metadata GC Threshold",} 0.006

... 以下省略 ...

ここでは、それぞれがPrometheusで認識できるメトリクス（tomcat_sessions_active_current_sessions、jvm_gc_pause_seconds_countなど）として表示されており、各メトリクスの上にHELPとTYPEも確認できる。

Prometheusサーバー

これでアプリケーション側の準備はできたので、アプリケーションが生成するメトリクスを収集するPrometheus Serverを用意する。

ここではDockerにインストールしたPrometheusを利用する。PrometheusのDockerインストールについてはこちらを参照してほしい。

Prometheusサーバーの設定

Prometheusサーバー起動時の設定ファイル（prometheus.yml）を次のように設定する。

/etc/prometheus/prometheus.yml

global:
  scrape_interval: 10s # 10秒ごとにMetricをPulling
  evaluation_interval: 10s # ruleをどれくらいの頻度で検証するかを設定
scrape_configs:
  - job_name: 'spring-actuator-prometheus'
    metrics_path: '/actuator/prometheus' # Application prometheus endpoint
    static_configs:
      - targets: ['host.docker.internal:8080'] # Application host:port

Warn: Application Host

この設定ファイルではApplication Hostを`host.docker.internal`に指定している。このHostはMacまたはWindowsのDocker環境で使用できる。Linuxの場合は`localhost`と入力する必要がある。 **参考**: [Collect Docker metrics with Prometheus](https://docs.docker.com/config/daemon/prometheus/)

Prometheusサーバーの確認

ではPrometheusのDockerを起動し、Prometheusへアクセスしてみよう。

上記に問題がなければ、Prometheus（http://localhost:9090）にアクセスすると、次のようにPrometheusのメイン画面を確認できる。

Status > Configurationメニューでは、Prometheusに設定したファイルが適用されているか確認できる。

Status > Targetsメニューでは、接続されたApplicationの状態を確認できる。

最後にメイン画面に戻り、Expressionにjvm_memory_used_bytesを入力して実行し、Graphを選択すると次のようなグラフチャートを確認できる。

Grafanaサーバー

次に、Prometheusで収集したメトリクスをGrafanaで可視化する方法を見ていく。

PrometheusのWebページでクエリを実行すれば、任意のメトリクスをグラフとして可視化できる。しかし、監視のたびに手動でクエリを実行するのは非効率であり、標準で提供されるダッシュボードも簡単なグラフを確認できる程度である。
Prometheusだけでは可視化に限界があるため、通常は別の可視化ツールを利用してメトリクスを監視する。

こちらを参考にしていれば、GrafanaもPrometheusと一緒にインストールされているはずである。

Grafanaログイン

まずGrafana（http://localhost:9090）へアクセスすると、次のようにGrafanaのログイン画面を確認できる。
デフォルトで設定されているアカウント情報（ID/PW）であるadmin/adminでログインできる。

Grafanaデータソースの追加

ログインすると次のような初期画面が表示されるので、DATA SOURCESのアイコンをクリックする。

追加するData SourceからPrometheusをクリックする。

PrometheusのData Source追加画面が表示されたら、NameとURLを入力する。
Nameには任意の名前を入力し、URLにはhttp://host.docker.internal:9090を入力すればよい。

下へスクロールしてSave & testボタンをクリックすると、成功メッセージ（Data source is working）が表示される。

Configurationアイコンを押すと、先ほど登録したData sourceを確認できる。

Grafana Metricグラフチャートの追加

次に、Exploreアイコンを押して、Metricにjvm_memory_max_bytesを選択し、Run queryボタンを押す。すると、次のようなグラフチャートを確認できる。

Add to dashboardボタンを押すと、Add panel to dashboard画面が表示される。
ここでNew dashboardを選択し、Open dashboardボタンを押す。

Save dashboard画面でDashboard nameを入力し、Saveボタンを押して保存する。

次に左側のDashboardアイコンをクリックし、先ほど入力した名前のJVM Memory used項目を選択する。

すると、次のようなチャートを確認できる。

このチャートはマウスで横に広げることができ、保存もできる。

参考

上記で完成したプロジェクトコードはこちらに置いてある。
Micrometer Application Monitoring | concepts
SpringBoot Applicationのmonitoringシステム構築

Spring Batch + Prometheus + Pushgateway + Grafana + Dockerでアプリケーション監視

kc@example.com (kc kim) — Tue, 27 Dec 2022 13:53:49 +0900

概要

Prometheusは基本的に、メトリクス指標を提供するサーバーへ周期的にリクエスト（pull）してメトリクスを収集する。

しかし、Spring BatchのようにCLI形式で周期的に実行されるだけの場合がある。このような場合は個別のIPがないため、周期的なPolling方式ではなく、Prometheusへメトリクスを逆にPushできるようにする必要がある。メトリクスのPushを支援するのがPushgatewayである。

Pushgateway

Prometheusが提供するPushgatewayは、メトリクスをPushできるようにし、PushされたメトリクスをPrometheusがPullingして取得できるようにする仲介者の役割を果たす。この構造により、PushgatewayへPushされたメトリクスをPrometheusが取得できる。

Spring Batchプロジェクト作成

新規プロジェクト作成コマンド

次のようにcurlコマンドを使用してSpring Bootの新規プロジェクトを作成する。

curl https://start.spring.io/starter.tgz \
-d bootVersion=2.7.6 \
-d dependencies=batch,h2 \
-d baseDir=spring-batch-prometheus \
-d groupId=com.devkuma \
-d artifactId=spring-batch-prometheus \
-d packageName=com.devkuma.batch.prometheus \
-d applicationName=BatchPrometheusApplication \
-d javaVersion=11 \
-d packaging=jar \
-d type=gradle-project | tar -xzvf -

上記コマンドを実行するとSpring Batch、H2 Databaseが追加される。

Spring Batch設定

/src/main/java/com/devkuma/batch/prometheus/BatchPrometheusApplication.java

package com.devkuma.batch.prometheus;

import org.springframework.batch.core.configuration.annotation.EnableBatchProcessing;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;

@EnableScheduling
@SpringBootApplication
@EnableBatchProcessing
public class BatchPrometheusApplication {

	public static void main(String[] args) {
		SpringApplication.run(BatchPrometheusApplication.class, args);
	}
}

@EnableBatchProcessingアノテーションを追加してバッチ機能を有効化し、@EnableSchedulingアノテーションも追加してスケジューラ機能を有効化した。

Prometheus関連ライブラリ追加

/build.gradle

// ... 省略 ...

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-batch'
	runtimeOnly 'com.h2database:h2'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.springframework.batch:spring-batch-test'

    // Prometheus関連ライブラリ追加
	implementation 'io.micrometer:micrometer-registry-prometheus'
	implementation 'io.prometheus:simpleclient_pushgateway'
}

// ... 省略 ...

ファイル内の依存ライブラリを見ると、Spring Batch関連ライブラリとPrometheusおよびPushgatewayライブラリが追加されていることが分かる。

Tasklet処理方式のJob構成を実装

簡単なTasklet処理方式のJob構成ファイルを追加する。

/src/main/java/com/devkuma/batch/prometheus/batch/TaskletStepJobConfiguration.java

package com.devkuma.batch.prometheus.batch;

import java.util.Random;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.configuration.annotation.JobBuilderFactory;
import org.springframework.batch.core.configuration.annotation.StepBuilderFactory;
import org.springframework.batch.repeat.RepeatStatus;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class TaskletStepJobConfiguration {

    private static final Logger LOGGER = LoggerFactory.getLogger(TaskletStepJobConfiguration.class);

    private Random random;

    public TaskletStepJobConfiguration() {
        this.random = new Random();
    }

    @Bean
    public Job taskletStepJob(JobBuilderFactory jobBuilderFactory, Step taskletStep1, Step taskletStep2) {
        return jobBuilderFactory.get("taskletStepJob")
                                .start(taskletStep1)
                                .next(taskletStep2)
                                .build();
    }
}

itemReader、itemWriter処理方式のJob構成を実装

簡単なitemReader、itemWriter処理方式のJob構成ファイルを作成する。

/src/main/java/com/devkuma/batch/prometheus/batch/ItemStepJobConfiguration.java

package com.devkuma.batch.prometheus.batch;

import java.util.LinkedList;
import java.util.List;
import java.util.Random;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.configuration.annotation.JobBuilderFactory;
import org.springframework.batch.core.configuration.annotation.StepBuilderFactory;
import org.springframework.batch.core.configuration.annotation.StepScope;
import org.springframework.batch.item.ItemWriter;
import org.springframework.batch.item.support.ListItemReader;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ItemStepJobConfiguration {
    // itemReader and itemWriter configuration
}

Jobスケジューラ作成

ここでは必ずしもスケジューラは必要ないが、グラフをより見やすくするため、周期的にデータを送るJobスケジューラを作成する。

/src/main/java/com/devkuma/batch/prometheus/batch/JobScheduler.java

package com.devkuma.batch.prometheus.batch;

import org.springframework.batch.core.Job;
import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.JobParametersBuilder;
import org.springframework.batch.core.launch.JobLauncher;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
public class JobScheduler {
    // Run taskletStepJob every 10 seconds and itemStepJob every 15 seconds
}

続いて、thread.pool.sizeも設定ファイルへ入れる。
/src/main/resources/application.properties

thread.pool.size=3

前で入れたthread.pool.sizeを使用してThreadPoolTaskScheduler設定ファイルを作成する。

Prometheus設定

次にPrometheus設定を行う。
/src/main/resources/application.properties

prometheus.push.rate=5000
prometheus.job.name=springbatch
prometheus.grouping.key=appname
prometheus.pushgateway.url=localhost:9091

Prometheusのpush周期、Job名、グループキーを入れる。そしてPushgateway URLを設定する。

設定したPrometheus設定値を設定オブジェクトへ反映する。
/src/main/java/com/devkuma/batch/prometheus/config/PrometheusConfiguration.java

package com.devkuma.batch.prometheus.config;

import java.util.HashMap;
import java.util.Map;

import javax.annotation.PostConstruct;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.annotation.Scheduled;

import io.micrometer.core.instrument.Metrics;
import io.micrometer.prometheus.PrometheusConfig;
import io.micrometer.prometheus.PrometheusMeterRegistry;
import io.prometheus.client.CollectorRegistry;
import io.prometheus.client.exporter.PushGateway;

@Configuration
public class PrometheusConfiguration {
    // Configure PushGateway and periodically push metrics
}

Prometheus + Pushgateway + GrafanaサーバーをDockerで起動

次にDockerでPrometheus + Pushgateway + Grafanaサーバーを起動するため、docker-compose.ymlを作成し、Prometheus設定を行う。

docker-compose.yml設定ファイル

/src/prometheus/docker-compose.yml

version: '3.7'
services:

  prometheus:
    image: prom/prometheus
    container_name: 'prometheus'
    ports:
      - '9090:9090'
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml

  pushgateway:
    image: prom/pushgateway
    container_name: 'pushgateway'
    ports:
      - '9091:9091'

  grafana:
    image: grafana/grafana
    container_name: 'grafana'
    ports:
      - '3000:3000'

prometheus.yml設定ファイル

/src/docker/prometheus/prometheus.yml

global:
  scrape_interval:     5s
  evaluation_interval: 5s

scrape_configs:
  - job_name: 'springbatch'
    honor_labels: true
    static_configs:
      - targets: ['host.docker.internal:9091'] # pushgateway

テスト環境がmacOSのためPushgatewayのURLをhost.docker.internal:9091としているが、Linuxなどでは異なる場合がある。テスト環境に合わせてURLを入力する。

Docker起動

% cd src/prometheus
% docker-compose up -d

接続実行

Pushgateway
- http://localhost:9091
Prometheus
- http://localhost:9090
Grafana
- http://localhost:3000
  - 基本アカウントID/PW: admin/admin

Pushgateway収集情報確認

Pushgateway（http://localhost:9091）にアクセスすると、spring-batchで収集された情報を確認できる。

Prometheus収集情報確認

Prometheus（http://localhost:9090）にアクセスすると、Pushgatewayを通じて受け取ったspring-batchで収集された情報を確認できる。

Grafana設定

では、spring-batchで収集された情報をGrafanaを通じてより視覚的に表示してみる。

Grafanaデータソース設定

まずデータソースを追加する。

データソースとしてPrometheusを選択する。

PrometheusのData Source追加画面が表示されたら、NameとURLを入力する。
ここでは実装環境がmacOSなのでURLにはhttp://host.docker.internal:9090を入力したが、Linux環境などでは異なる場合があるので注意してほしい。

Grafanaダッシュボード設定および確認

続いてダッシュボード設定をImportで追加する。

用意されたImport JSONファイル（spring-batch-dashboard.json）を選択する。

内容を確認し、Importをクリックする。

ダッシュボード画面へ移動すると、spring-batchメトリクス情報がグラフで見えることを確認できる。

参考

上記のサンプルコードはGitHubで確認できる。