Micrometerアダプタ¶

DefaultMeterBinderListProviderをコンポーネントとして宣言する¶

Micrometerには、 MeterBinder(外部サイト、英語) というインタフェースが存在する。

JVMのメモリ使用量やCPU使用率など、よく使用するメトリクスの収集は、このインタフェースを実装したクラスとしてあらかじめ用意されている。 （例：JVMのメモリ使用量は JvmMemoryMetrics(外部サイト、英語) 、CPU使用率は ProcessorMetrics(外部サイト、英語) ）

DefaultMeterBinderListProvider は、この MeterBinder(外部サイト、英語) のリストを提供するクラスで、本クラスを使用することでJVMのメモリ使用量やCPU使用率などのメトリクスを収集できるようになる。

まず src/main/resources/web-component-configuration.xml に、この DefaultMeterBinderListProvider の宣言を追加する。

<component name="meterBinderListProvider"
           class="nablarch.integration.micrometer.DefaultMeterBinderListProvider" />

収集されるメトリクスの具体的な説明については、 DefaultMeterBinderListProviderで収集されるメトリクス を参照。

DefaultMeterBinderListProviderを廃棄処理対象にする¶

DefaultMeterBinderListProvider は廃棄処理が必要なコンポーネントなので、下記のように廃棄処理対象として宣言する。

<component name="disposer"
    class="nablarch.core.repository.disposal.BasicApplicationDisposer">

  <property name="disposableList">
    <list>
      <component-ref name="meterBinderListProvider"/>
    </list>
  </property>

</component>

オブジェクトの廃棄処理については、 オブジェクトの廃棄処理を行う を参照

レジストリのファクトリクラスをコンポーネントとして宣言する¶

<component class="nablarch.integration.micrometer.logging.LoggingMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />
</component>

次に、使用するレジストリごとに用意されているファクトリクラスをコンポーネントとして宣言する。

このとき、 meterBinderListProvider と applicationDisposer の２つのプロパティを設定する。 それぞれのプロパティには、上で宣言した DefaultMeterBinderListProvider と BasicApplicationDisposer を設定する。

なお、本アダプタが提供しているファクトリクラスについては レジストリファクトリ に一覧を記載している。

設定ファイルを作成する¶

最後に、 src/main/resources の下に micrometer.properties という名前のテキストファイルを作成する。

ここでは、中身を次のように記述する。

# 確認を楽にするため、5秒ごとにメトリクスを出力する（デフォルトは1分）
nablarch.micrometer.logging.step=5s
# step で指定した時間よりも早くアプリケーションが終了した場合でも廃棄処理でログが出力されるよう設定
nablarch.micrometer.logging.logInactive=true

実行結果¶

以上で、 LoggingMeterRegistry を用いたメトリクスの収集ができるようになる。

アプリケーションを起動すると、以下のように収集されたメトリクスが標準出力に出力されていることを確認できる。

2020-09-04 15:33:40.689 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.gc.count{memory.manager.name=PS Scavenge} throughput=2.6/s
2020-09-04 15:33:40.690 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.gc.count{memory.manager.name=PS MarkSweep} throughput=0.4/s
2020-09-04 15:33:40.691 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.buffer.count{id=mapped} value=0 buffers
2020-09-04 15:33:40.691 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.buffer.count{id=direct} value=2 buffers
2020-09-04 15:33:40.692 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.buffer.memory.used{id=direct} value=124 KiB
2020-09-04 15:33:40.692 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.buffer.memory.used{id=mapped} value=0 B
2020-09-04 15:33:40.692 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.buffer.total.capacity{id=mapped} value=0 B
2020-09-04 15:33:40.692 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.buffer.total.capacity{id=direct} value=124 KiB
2020-09-04 15:33:40.693 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.classes.loaded{} value=9932 classes
2020-09-04 15:33:40.693 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.gc.live.data.size{} value=0 B
2020-09-04 15:33:40.693 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.gc.max.data.size{} value=2.65918 GiB
2020-09-04 15:33:40.694 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.committed{area=heap,id=PS Old Gen} value=182.5 MiB
2020-09-04 15:33:40.694 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.committed{area=heap,id=PS Survivor Space} value=44 MiB
2020-09-04 15:33:40.694 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.committed{area=heap,id=PS Eden Space} value=197 MiB
2020-09-04 15:33:40.694 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.committed{area=nonheap,id=Code Cache} value=29.125 MiB
2020-09-04 15:33:40.694 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.committed{area=nonheap,id=Compressed Class Space} value=6.796875 MiB
2020-09-04 15:33:40.695 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.committed{area=nonheap,id=Metaspace} value=55.789062 MiB
2020-09-04 15:33:40.695 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.max{area=heap,id=PS Old Gen} value=2.65918 GiB
2020-09-04 15:33:40.695 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.max{area=heap,id=PS Survivor Space} value=44 MiB
2020-09-04 15:33:40.696 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.max{area=nonheap,id=Code Cache} value=240 MiB
2020-09-04 15:33:40.696 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.max{area=nonheap,id=Metaspace} value=-1 B
2020-09-04 15:33:40.696 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.max{area=heap,id=PS Eden Space} value=1.243652 GiB
2020-09-04 15:33:40.696 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.max{area=nonheap,id=Compressed Class Space} value=1 GiB
2020-09-04 15:33:40.697 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.used{area=nonheap,id=Code Cache} value=28.618713 MiB
2020-09-04 15:33:40.697 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.used{area=nonheap,id=Compressed Class Space} value=6.270714 MiB
2020-09-04 15:33:40.697 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.used{area=nonheap,id=Metaspace} value=54.118324 MiB
2020-09-04 15:33:40.698 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.used{area=heap,id=PS Old Gen} value=69.320663 MiB
2020-09-04 15:33:40.698 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.used{area=heap,id=PS Survivor Space} value=7.926674 MiB
2020-09-04 15:33:40.698 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.memory.used{area=heap,id=PS Eden Space} value=171.750542 MiB
2020-09-04 15:33:40.698 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.daemon{} value=28 threads
2020-09-04 15:33:40.698 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.live{} value=29 threads
2020-09-04 15:33:40.699 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.peak{} value=31 threads
2020-09-04 15:33:40.702 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.states{state=blocked} value=0 threads
2020-09-04 15:33:40.703 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.states{state=runnable} value=9 threads
2020-09-04 15:33:40.703 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.states{state=new} value=0 threads
2020-09-04 15:33:40.703 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.states{state=timed-waiting} value=3 threads
2020-09-04 15:33:40.703 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.states{state=terminated} value=0 threads
2020-09-04 15:33:40.704 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: jvm.threads.states{state=waiting} value=17 threads
2020-09-04 15:33:41.199 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: process.cpu.usage{} value=0.111672
2020-09-04 15:33:41.199 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: process.start.time{} value=444222h 33m 14.544s
2020-09-04 15:33:41.199 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: process.uptime{} value=26.729s
2020-09-04 15:33:41.200 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: system.cpu.count{} value=8
2020-09-04 15:33:41.200 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: system.cpu.usage{} value=0.394545

配置場所¶

本アダプタの設定ファイルは、クラスパス直下に micrometer.properties という名前で配置されるように作成する。

フォーマット¶

このファイルに記載する設定は、以下のフォーマットで記述する。

nablarch.micrometer.<subPrefix>.<key>=設定する値

ここで、 <subPrefix> に設定する値は、使用するレジストリファクトリごとに異なる値を指定する。

レジストリファクトリごとに、 <subPrefix> で指定する値を下記表に記載する。

また、 <key> には Micrometer がレジストリごとに提供している 設定クラス(外部サイト、英語) で定義されたメソッドと同じ名前を指定する。

例えば、 DatadogMeterRegistry(外部サイト、英語) に対しては DatadogConfig(外部サイト、英語) という設定クラスが用意されている。 そして、この設定クラスには apyKey(外部サイト、英語) というメソッドが定義されている。

したがって、 micrometer.properties に次のように記述することで、 apiKey を設定できる。

nablarch.micrometer.datadog.apiKey=XXXXXXXXXXXXXXXXXXXX

OS環境変数・システムプロパティで上書きする¶

micrometer.properties に記述した設定の値は、OS環境変数およびシステムプロパティで上書きできる。

設定値は、優先度の高い順に次の順番で採用される。

1. システムプロパティで指定した値
2. OS環境変数で指定した値
3. micrometer.properties の設定値

例えば、次のような条件で設定したとする。

micrometer.properties

nablarch.micrometer.example.one=PROPERTIES
nablarch.micrometer.example.two=PROPERTIES
nablarch.micrometer.example.three=PROPERTIES

OS環境変数

$ export NABLARCH_MICROMETER_EXAMPLE_TWO=OS_ENV

$ export NABLARCH_MICROMETER_EXAMPLE_THREE=OS_ENV

システムプロパティ

-Dnablarch.micrometer.example.three=SYSTEM_PROP

この場合、それぞれの設定値は最終的に次の値が採用される。

OS環境変数で上書きするときの名前のルールについては、 OS環境変数の名前について を参照。

設定のプレフィックスを変更する¶

設定のプレフィックス (nablarch.micrometer.<subPrefix>) は、各レジストリファクトリごとに prefix プロパティを指定することで変更できる。

以下に、プレフィックスを変更する例を記載する。

<component name="meterRegistry" class="nablarch.integration.micrometer.logging.LoggingMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />

  <!-- prefix プロパティに任意のプレフィックスを設定する -->
  <property name="prefix" value="sample.prefix" />
</component>

この場合、 micrometer.properties は次のように設定できるようになる。

sample.prefix.step=10s

設定ファイルの場所を変更する¶

設定ファイル（micrometer.properties）の場所は、以下の方法で変更できる。

まず、レジストリファクトリの xmlConfigPath プロパティに、設定ファイルを読み込むXMLファイルのパスを指定する。

<component name="meterRegistry" class="nablarch.integration.micrometer.logging.LoggingMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />

  <!-- 設定ファイルを読み込むXMLファイルのパスを指定 -->
  <property name="xmlConfigPath" value="config/metrics.xml" />
</component>

そして、 xmlConfigPath プロパティで指定した場所に、設定ファイルを読み込むXMLファイルを配置する。 下記設定では、クラスパス内の config/metrics.properties が設定ファイルとして読み込まれるようになる。

<?xml version="1.0" encoding="UTF-8"?>
<component-configuration
        xmlns="http://tis.co.jp/nablarch/component-configuration"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://tis.co.jp/nablarch/component-configuration https://nablarch.github.io/schema/component-configuration.xsd">

  <!-- Micrometerアダプタの設定を読み込む -->
  <config-file file="config/metrics.properties" />

</component-configuration>

Datadog と連携する¶

依存関係を追加する

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-datadog</artifactId>
  <version>1.5.4</version>
</dependency>

レジストリファクトリを宣言する

<component name="meterRegistry" class="nablarch.integration.micrometer.datadog.DatadogMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />
</component>

APIキーを設定する

nablarch.micrometer.datadog.apiKey=XXXXXXXXXXXXXXXX

API キーは nablarch.micrometer.datadog.apyKey で設定できる。

その他の設定については DatadogConfig(外部サイト、英語) を参照。

連携を無効にする

nablarch.micrometer.datadog.enabled=false
nablarch.micrometer.datadog.apiKey=XXXXXXXXXXXXXXXX

micrometer.properties で nablarch.micrometer.datadog.enabled に false を設定することで、メトリクスの連携を無効にできる。 この設定は環境変数で上書きできるので、本番環境のみ環境変数で true に上書きして連携を有効にできる。

重要

連携を無効にした場合も、 nablarch.micrometer.datadog.apiKey には何らかの値を設定しておく必要がある。 値はダミーで問題ない。

CloudWatch と連携する¶

依存関係を追加する

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-cloudwatch2</artifactId>
  <version>1.5.4</version>
</dependency>

レジストリファクトリを宣言する

<component name="meterRegistry" class="nablarch.integration.micrometer.cloudwatch.CloudWatchMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />
</component>

リージョンやアクセスキーを設定する

$ export AWS_REGION=ap-northeast-1

$ export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXXX

$ export AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYY

micrometer-registry-cloudwatch2 モジュールは AWS SDK を使用している。 したがって、リージョンやアクセスキーなどの設定は AWS SDK の方法に準拠する。

上記は、LinuxでOS環境変数を使って設定する場合の例を記載している。 より詳細な情報は、 AWSのドキュメント(外部サイト) を参照。

名前空間を設定する

nablarch.micrometer.cloudwatch.namespace=test

メトリクスのカスタム名前空間は nablarch.micrometer.cloudwatch.namespace で設定できる。

その他の設定については CloudWatchConfig(外部サイト、英語) を参照。

より詳細な設定

OS環境変数や設定ファイルでは指定できない、より詳細に設定したい場合は、 CloudWatchAsyncClientProvider を実装したカスタムプロバイダを作ることで対応できる。

package example.micrometer.cloudwatch;

import nablarch.integration.micrometer.cloudwatch.CloudWatchAsyncClientProvider;
import software.amazon.awssdk.services.cloudwatch.CloudWatchAsyncClient;

public class CustomCloudWatchAsyncClientProvider implements CloudWatchAsyncClientProvider {
    @Override
    public CloudWatchAsyncClient provide() {
        return CloudWatchAsyncClient
                .builder()
                .asyncConfiguration(...) // 任意の設定を行う
                .build();
    }
}

CloudWatchAsyncClientProvider は CloudWatchAsyncClient を提供する provide() メソッドを持つ。 カスタムプロバイダでは、任意の設定を行った CloudWatchAsyncClient を構築して返すように provide() メソッドを実装する。

<component name="meterRegistry" class="nablarch.integration.micrometer.cloudwatch.CloudWatchMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />

  <!-- cloudWatchAsyncClientProvider プロパティにカスタムプロバイダを設定する -->
  <property name="cloudWatchAsyncClientProvider">
    <component class="example.micrometer.cloudwatch.CustomCloudWatchAsyncClientProvider" />
  </property>
</component>

作成したカスタムプロバイダは、 CloudWatchMeterRegistryFactory の cloudWatchAsyncClientProvider プロパティに設定する。

これにより、カスタムプロバイダが生成した CloudWatchAsyncClient がメトリクスの連携で使用されるようになる。

補足

デフォルトでは、 CloudWatchAsyncClient.create() (外部サイト、英語) で作成されたインスタンスが使用される。

連携を無効にする

nablarch.micrometer.cloudwatch.enabled=false
nablarch.micrometer.cloudwatch.namespace=test

micrometer.properties で nablarch.micrometer.cloudwatch.enabled に false を設定することで、メトリクスの連携を無効にできる。 この設定は環境変数で上書きできるので、本番環境のみ環境変数で true に上書きして連携を有効にできる。

重要

連携を無効にした場合も、 nablarch.micrometer.cloudwatch.namespace には何らかの値を設定しておく必要がある。 また、環境変数 AWS_REGION を設定しておく必要がある。

いずれも、値はダミーで問題ない。

Azure と連携する¶

MicrometerでメトリクスをAzureに連携する方法

Azureは、JavaアプリケーションからAzureにメトリクスを連携するための仕組みとして、Javaエージェントを用いた方法(Java 3.0 エージェント)を提供している。

• Azure Monitor Application Insights を監視する Java のコード不要のアプリケーション(外部サイト)

このJava 3.0 エージェントは、Micrometerの グローバルレジストリ(外部サイト、英語) に出力したメトリクスを自動的に収集し、Azureに連携する仕組みを提供している。

• アプリケーションからカスタム テレメトリを送信する(外部サイト)

重要

Java 3.0 エージェントは、初期化処理中に大量のjarファイルをロードする。 これにより、Java 3.0 エージェントの初期化処理中はGCが頻発することがある。

このため、アプリケーション起動後しばらくは、GCの影響により性能が一時的に劣化する可能性がある点に注意すること。

また、高負荷時は Java 3.0 エージェントの処理によるオーバーヘッドが性能に影響を与える可能性がある。 したがって、性能試験では本番同様に Java 3.0 エージェントを導入し、想定内の性能になることを確認すること。

Java 3.0 エージェントの設定方法は Azureにおける分散トレーシング 参照。

MicrometerアダプタでメトリクスをAzureに連携するための設定

MicrometerアダプタでメトリクスをAzureに連携するためには、以下のとおり設定する必要がある。

• アプリケーションの起動オプションに、Java 3.0 エージェントを追加する
• MeterRegistry にグローバルレジストリを使うようにコンポーネントを定義する

1つ目の起動オプションの設定方法については、 Azureのドキュメント を参照のこと。

2つ目のグローバルレジストリを使う方法について、本アダプタではグローバルレジストリのファクトリクラスとして GlobalMeterRegistryFactory を用意している。 以下に、このファクトリクラスのコンポーネント定義の例を示す。

<component name="meterRegistry" class="nablarch.integration.micrometer.GlobalMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />
</component>

この設定により、メトリクスの収集はグローバルレジストリによって行われるようになる。 そして、グローバルレジストリで収集されたメトリクスは、Java 3.0 エージェントによってAzureに連携されるようになる。

補足

Java 3.0 エージェントを使うこの方法では、Azure用の MeterRegistry は使用しない。 したがって、Azure用のモジュールを依存関係に追加しなくてもメトリクスを連携できる。

詳細設定について

メトリクスの連携は、Azureが提供するJava 3.0 エージェントによって行われる。 このため、メトリクスの連携に関する設定は全てJava 3.0 エージェントが提供する方法で行う必要がある。

Java 3.0 エージェントの設定の詳細については、 構成オプション(外部サイト) を参照のこと。

重要

本アダプタ用の設定ファイルである micrometer.properties は使用できないが、ファイルは配置しておく必要がある（内容は空で構わない）。

連携を無効にする

Java 3.0 エージェントを使用せずにアプリケーションを起動することで、メトリクスの連携を無効にできる。

StatsD で連携する¶

Datadog は DogStatsD(外部サイト) という StatsD(外部サイト、英語) プロトコルを使った連携をサポートしている。 したがって、 micrometer-registry-statsd モジュールを用いることで、 StatsD で Datadog と連携することもできる。

ここでは、 Datadog に StatsD プロトコルで連携する場合を例にして説明する。 なお、DogStatsD のインストール方法などについては Datadogのサイト(外部サイト) を参照。

依存関係を追加する

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-statsd</artifactId>
  <version>1.5.4</version>
</dependency>

レジストリファクトリを宣言する

<component name="meterRegistry" class="nablarch.integration.micrometer.statsd.StatsdMeterRegistryFactory">
  <property name="meterBinderListProvider" ref="meterBinderListProvider" />
  <property name="applicationDisposer" ref="disposer" />
</component>

必要に応じて設定ファイルを記述する

StatsD デーモンと連携するための設定は、デフォルト値が DogStatsD をデフォルト構成でインストールした場合と一致するように調整されている。

したがって、 DogStatsD をデフォルトの構成でインストールしている場合は、特に設定を明示しなくても DogStatsD による連携が動作する。

もしデフォルト構成以外でインストールしている場合は、 StatsdConfig(外部サイト、英語) を参照して、実際の環境に合わせた設定を行うこと。

# ポートを変更
nablarch.micrometer.statsd.port=9999

連携を無効にする

nablarch.micrometer.statsd.enabled=false

micrometer.properties で nablarch.micrometer.statsd.enabled に false を設定することで、メトリクスの連携を無効にできる。 この設定は環境変数で上書きできるので、本番環境のみ環境変数で true に上書きして連携を有効にできる。

ウェブアプリケーションで収集するメトリクスの例¶

HTTPリクエストの処理時間

HTTPリクエストごとの処理時間を計測することで、以下のようなことができるようになる。

• 各URLごとにどの程度アクセスがあるか確認する
• リクエストの処理にどれくらい時間がかかっているか確認する

また、パーセンタイルを計測することで、大部分のリクエストがどれくらいの時間で処理できているかを確認できるようにもなる。

これらのメトリクスを収集する方法については、以下のガイドを参照のこと。

• 処理時間を計測するハンドラ
• パーセンタイルを収集する

SQLの処理時間

SQLの処理時間を計測することで、以下のようなことができるようになる。

• それぞれのSQLがどの程度の時間で処理されているか確認する
• 想定よりも時間がかかっているSQLが無いか確認する

SQLの処理時間を計測する方法については、以下のガイドを参照のこと。

• SQLの処理時間を計測する

ログレベルごとの出力回数

ログレベルごとの出力回数を計測することで、以下のようなことができるようになる。

• 警告ログが異常な回数出力されていないか確認する（攻撃の検知）
• エラーログを検知する

ログレベルごとの出力回数については、以下のガイドを参照のこと。

• ログレベルごとの出力回数を計測する

アプリケーションサーバやライブラリが提供するリソースの情報

アプリケーションサーバやライブラリが提供するリソース（スレッドプールやDBのコネクションプールなど）の状態を メトリクスとして収集しておくことで、障害発生時に原因箇所を特定するための情報源として活用できるようになる。

多くのアプリケーションサーバは、リソースの状態をJMXのMBeanを通じて公開している。 MBeanの情報を収集する方法については、以下のガイドを参照のこと。

• 任意のMBeanから取得した値をメトリクスとして計測する

バッチアプリケーションで収集するメトリクスの例¶

バッチの処理時間

普段からバッチの処理時間を計測しておくことで、平常時の処理時間を知ることができる。 これにより、処理時間が平常時とは異なる値になったときに、異常を迅速に検知できるようになる。

バッチの処理時間は、 DefaultMeterBinderListProviderで収集されるメトリクス で収集される process.uptime で計測できる。

トランザクション単位の処理時間

トランザクション単位の処理時間を計測することで、マルチスレッドのバッチが均等に処理を分散できているかなどを確認できるようになる。

また、バッチの処理時間と同様に、処理時間が平常時から逸脱したときにも異常を迅速に検知できる。

バッチのトランザクション単位の処理時間の計測については、以下のガイドを参照のこと。

• バッチのトランザクション単位の処理時間を計測する

バッチの処理件数

バッチの処理件数を計測することで、以下のようなことができるようになる。

• バッチの進捗状況を確認する
• 想定通りの速度で処理が進んでいるか確認する
• 想定通りの件数が処理できているか確認する

バッチの処理件数の計測については、以下のガイドを参照のこと。

• バッチの処理件数を計測する

SQLの処理時間

SQLの処理時間を計測することで、以下のようなことができるようになる。

• それぞれのSQLがどの程度の時間で処理されているか確認する
• 想定よりも時間がかかっているSQLが無いか確認する

SQLの処理時間を計測する方法については、以下のガイドを参照のこと。

• SQLの処理時間を計測する

ログレベルごとの出力回数

ログレベルごとの出力回数を計測することで、警告ログやエラーログの検知ができるようになる。

ログレベルごとの出力回数については、以下のガイドを参照のこと。

• ログレベルごとの出力回数を計測する

ライブラリが提供するリソースの情報

ライブラリが提供するリソース（DBのコネクションプールなど）の状態をメトリクスとして収集しておくことで、 障害発生時に原因箇所を特定するための情報源として活用できるようになる。

ライブラリによっては、リソースの状態をJMXのMBeanで公開していることがある。 MBeanの情報を収集する方法については、以下のガイドを参照のこと。

• 任意のMBeanから取得した値をメトリクスとして計測する

パーセンタイルを収集する¶

TimerMetricsHandler には、パーセンタイル値を監視サービスに連携するために以下のプロパティが用意されている。

これらのプロパティは、Micrometerが提供する Timer(外部サイト、英語) に設定する値として使用される。 より詳細な説明は、 Micrometerのドキュメント を参照のこと。

なお、これらのプロパティはデフォルトでは全て未設定のため、パーセンタイルの情報は収集されない。 パーセンタイルの情報を収集する必要がある場合は、これらのプロパティを明示的に設定すること。 以下に、設定例を示す。

<component class="nablarch.integration.micrometer.instrument.handler.TimerMetricsHandler">
  <property name="meterRegistry" ref="meterRegistry" />
  <property name="handlerMetricsMetaDataBuilder">
    <component class="nablarch.integration.micrometer.instrument.http.HttpRequestTimeMetricsMetaDataBuilder" />
  </property>

  <!-- 98, 90, 50 パーセンタイルを収集する -->
  <property name="percentiles">
    <list>
      <value>0.98</value>
      <value>0.90</value>
      <value>0.50</value>
    </list>
  </property>

  <!-- ヒストグラムバケットを監視サービスに連携する -->
  <property name="enablePercentileHistogram" value="true" />

  <!-- SLO として 1000ms, 1500ms を設定 -->
  <property name="serviceLevelObjectives">
    <list>
      <value>1000</value>
      <value>1500</value>
    </list>
  </property>

  <!-- バケットの最小値に 500 ms を設定 -->
  <property name="minimumExpectedValue" value="500" />
  <!-- バケットの最大値に 3000 ms を設定 -->
  <property name="maximumExpectedValue" value="3000" />
</component>

MeterRegistry として PrometheusMeterRegistry(外部サイト、英語) を使用した場合、上記設定により次のようなメトリクスが収集できるようになる。

http_server_requests_seconds{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",quantile="0.98",} 1.475346432
http_server_requests_seconds{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",quantile="0.9",} 1.408237568
http_server_requests_seconds{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",quantile="0.5",} 0.737148928
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.5",} 9.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.536870911",} 9.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.626349396",} 12.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.715827881",} 16.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.805306366",} 16.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.894784851",} 17.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="0.984263336",} 17.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="1.0",} 18.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="1.073741824",} 20.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="1.431655765",} 29.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="1.5",} 32.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="1.789569706",} 32.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="2.147483647",} 32.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="2.505397588",} 32.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="2.863311529",} 32.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="3.0",} 32.0
http_server_requests_seconds_bucket{class="com.nablarch.example.app.web.action.MetricsAction",exception="None",httpMethod="GET",method="index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext",outcome="SUCCESS",status="200",le="+Inf",} 32.0

package example.micrometer.prometheus;

import io.micrometer.prometheus.PrometheusConfig;
import io.micrometer.prometheus.PrometheusMeterRegistry;
import nablarch.core.repository.di.DiContainer;
import nablarch.integration.micrometer.MeterRegistryFactory;
import nablarch.integration.micrometer.MicrometerConfiguration;
import nablarch.integration.micrometer.NablarchMeterRegistryConfig;

public class PrometheusMeterRegistryFactory extends MeterRegistryFactory<PrometheusMeterRegistry> {

    @Override
    protected PrometheusMeterRegistry createMeterRegistry(MicrometerConfiguration micrometerConfiguration) {
        return new PrometheusMeterRegistry(new Config(prefix, micrometerConfiguration));
    }

    @Override
    public PrometheusMeterRegistry createObject() {
        return doCreateObject();
    }

    static class Config extends NablarchMeterRegistryConfig implements PrometheusConfig {

        public Config(String prefix, DiContainer diContainer) {
            super(prefix, diContainer);
        }

        @Override
        protected String subPrefix() {
            return "prometheus";
        }
    }
}

あらかじめ用意されているHandlerMetricsMetaDataBuilderの実装¶

ここでは、Nablarchによってあらかじめ用意されている HandlerMetricsMetaDataBuilder の実装クラスについて紹介する。

<!-- ハンドラキュー構成 -->
<component name="webFrontController"
           class="nablarch.fw.web.servlet.WebFrontController">
  <property name="handlerQueue">
    <list>
      <!-- HTTPリクエストの処理時間のメトリクス収集ハンドラ -->
      <component class="nablarch.integration.micrometer.instrument.handler.TimerMetricsHandler">
        <!-- レジストリファクトリが生成する MeterRegistry を meterRegistry プロパティに設定する -->
        <property name="meterRegistry" ref="meterRegistry" />

        <!-- HttpRequestTimeMetricsMetaDataBuilder を handlerMetricsMetaDataBuilder に設定する -->
        <property name="handlerMetricsMetaDataBuilder">
          <component class="nablarch.integration.micrometer.instrument.http.HttpRequestTimeMetricsMetaDataBuilder" />
        </property>
      </component>

      <component class="nablarch.fw.web.handler.HttpCharacterEncodingHandler"/>

      <!-- 省略 -->
   </list>
  </property>
</component>

2020-10-06 13:52:10.309 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: http.server.requests{class=com.nablarch.example.app.web.action.AuthenticationAction,exception=None,httpMethod=POST,method=login_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext,outcome=REDIRECTION,status=303} throughput=0.2/s mean=0.4617585s max=0.4617585s
2020-10-06 13:52:10.309 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: http.server.requests{class=com.nablarch.example.app.web.action.IndustryAction,exception=None,httpMethod=GET,method=find,outcome=SUCCESS,status=200} throughput=0.2/s mean=0.103277s max=0.103277s
2020-10-06 13:52:10.310 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: http.server.requests{class=com.nablarch.example.app.web.action.AuthenticationAction,exception=None,httpMethod=GET,method=index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext,outcome=SUCCESS,status=200} throughput=0.2/s mean=4.7409146s max=4.7409146s
2020-10-06 13:52:10.310 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: http.server.requests{class=com.nablarch.example.app.web.action.ProjectAction,exception=None,httpMethod=GET,method=index_nablarch.fw.web.HttpRequest_nablarch.fw.ExecutionContext,outcome=SUCCESS,status=200} throughput=0.2/s mean=0.5329547s max=0.5329547s

LogPublisher を設定する¶

LogCountMetrics は、ログ出力イベントを検知するために LogPublisher の仕組みを使用している。

したがって LogCountMetrics を使い始めるためには、まず LogPublisher の設定をする必要がある。 LogPublisher の設定については、 LogPublisherの使い方 を参照のこと。

カスタムのDefaultMeterBinderListProviderを作成する¶

LogCountMetrics は MeterBinder(外部サイト、英語) の実装クラスとして提供されている。 したがって、 DefaultMeterBinderListProvider を継承したクラスを作り、 LogCountMetrics を含んだ MeterBinder のリストを返すように実装する必要がある。

以下に、その実装例を示す。

package example.micrometer.log;

import io.micrometer.core.instrument.binder.MeterBinder;
import nablarch.integration.micrometer.DefaultMeterBinderListProvider;
import nablarch.integration.micrometer.instrument.binder.logging.LogCountMetrics;

import java.util.ArrayList;
import java.util.List;

public class CustomMeterBinderListProvider extends DefaultMeterBinderListProvider {

    @Override
    protected List<MeterBinder> createMeterBinderList() {
        // デフォルトの MeterBinder リストに LogCountMetrics を追加
        List<MeterBinder> meterBinderList = new ArrayList<>(super.createMeterBinderList());
        meterBinderList.add(new LogCountMetrics());
        return meterBinderList;
    }
}

最後に、 MeterRegistryFactory コンポーネントの meterBinderListProvider プロパティに、作成したカスタムの DefaultMeterBinderListProvider を設定する。 以上で、 LogCountMetrics が使用できるようになる。

LoggingMeterRegistry を使用した場合、以下のようにメトリクスが出力されることが確認できる。

2020-12-22 14:25:36.978 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: log.count{level=WARN,logger=com.nablarch.example.app.web.action.MetricsAction} throughput=0.4/s
2020-12-22 14:25:41.978 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: log.count{level=ERROR,logger=com.nablarch.example.app.web.action.MetricsAction} throughput=1.4/s

集計対象のログレベル¶

デフォルトでは、 WARN 以上のログ出力回数のみが集計の対象となる。

集計対象のログレベルのしきい値は、 LogCountMetrics のコンストラクタに LogLevel を渡すことで変更できる。 以下の実装例では、しきい値を INFO に変更している。

// （省略）
import nablarch.core.log.basic.LogLevel;

public class CustomMeterBinderListProvider extends DefaultMeterBinderListProvider {

    @Override
    protected List<MeterBinder> createMeterBinderList() {
        List<MeterBinder> meterBinderList = new ArrayList<>(super.createMeterBinderList());
        meterBinderList.add(new LogCountMetrics(LogLevel.INFO)); // LogLevel のしきい値を指定
        return meterBinderList;
    }
}

Tomcatのスレッドプールの状態を取得する¶

JmxGaugeMetrics は MeterBinder(外部サイト、英語) の実装クラスとして提供されている。 したがって、 DefaultMeterBinderListProvider を継承したクラスを作り、 JmxGaugeMetrics を含んだ MeterBinder のリストを返すように実装する必要がある。

以下に、実装例を示す。

package example.micrometer;

import io.micrometer.core.instrument.binder.MeterBinder;
import nablarch.integration.micrometer.DefaultMeterBinderListProvider;
import nablarch.integration.micrometer.instrument.binder.MetricsMetaData;
import nablarch.integration.micrometer.instrument.binder.jmx.JmxGaugeMetrics;
import nablarch.integration.micrometer.instrument.binder.jmx.MBeanAttributeCondition;

import java.util.ArrayList;
import java.util.List;

public class CustomMeterBinderListProvider extends DefaultMeterBinderListProvider {

    @Override
    protected List<MeterBinder> createMeterBinderList() {
        List<MeterBinder> meterBinderList = new ArrayList<>(super.createMeterBinderList());
        meterBinderList.add(new JmxGaugeMetrics(
            // メトリクスの名前と説明
            new MetricsMetaData("thread.count.current", "Current thread count."),
            // 収集する MBean の属性を特定する情報
            new MBeanAttributeCondition("Catalina:type=ThreadPool,name=\"http-nio-8080\"", "currentThreadCount")
        ));
        return meterBinderList;
    }
}

JmxGaugeMetrics のコンストラクタには、次の２つのクラスを渡す必要がある。

• MetricsMetaData

  • メトリクスの名前や説明、タグなどのメタ情報を指定する

• MBeanAttributeCondition

  • 収集するMbeanを特定するための、オブジェクト名と属性名を指定する

JmxGaugeMetrics は、 MBeanAttributeCondition で指定された情報に基づいてMBeanの情報を取得する。 そして、 MetricsMetaData で指定された情報でメトリクスを構築する。

以上の設定で LoggingMeterRegistry を使用した場合、以下のようにメトリクスが出力されることが確認できる。

24-Dec-2020 16:20:24.467 情報 [logging-metrics-publisher] io.micrometer.core.instrument.logging.LoggingMeterRegistry.lambda$publish$3 thread.count.current{} value=10

HikariCPのコネクションプールの状態を取得する¶

HikariCP(外部サイト、英語) には、コネクションプールの情報をMBeanで参照できるようにする機能が用意されている。

• MBean (JMX) Monitoring and Management(外部サイト、英語)

この機能を使用することで、 JmxGaugeMetrics でコネクションプールの情報を収集できるようになる。

まず、HikariCPのMBeanで情報を公開する機能を有効にする。 MBeanによる情報公開を有効にするには、 com.zaxxer.hikari.HikariDataSource の registerMbeans プロパティに true を設定する。

<?xml version="1.0" encoding="UTF-8"?>
<component-configuration
        xmlns="http://tis.co.jp/nablarch/component-configuration"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://tis.co.jp/nablarch/component-configuration https://nablarch.github.io/schema/component-configuration.xsd">
  <!-- 省略 -->

  <!-- データソース設定 -->
  <component name="dataSource"
            class="com.zaxxer.hikari.HikariDataSource" autowireType="None">
    <property name="driverClassName" value="${nablarch.db.jdbcDriver}"/>
    <property name="jdbcUrl"         value="${nablarch.db.url}"/>
    <property name="username"        value="${nablarch.db.user}"/>
    <property name="password"        value="${nablarch.db.password}"/>
    <property name="maximumPoolSize" value="${nablarch.db.maxPoolSize}"/>
    <!-- MBeanによる情報公開を有効にする -->
    <property name="registerMbeans"  value="true"/>
  </component>

</component-configuration>

上記設定では、 HikariDataSource のコンポーネント定義で registerMbeans プロパティに true を設定している。

次に、HikariCPが公開するMBeanのオブジェクト名と、計測したい属性名を指定した形で JmxGaugeMetrics を設定する。 なお、オブジェクト名や属性名の仕様は、 前述のHikariCPのドキュメント(外部サイト、英語) に記載されている。

以下は、コネクションプールの最大数とアクティブ数を計測する場合の JmxGaugeMetrics の実装例になる。

package com.nablarch.example.app.metrics;

import io.micrometer.core.instrument.binder.MeterBinder;
import nablarch.integration.micrometer.DefaultMeterBinderListProvider;
import nablarch.integration.micrometer.instrument.binder.MetricsMetaData;
import nablarch.integration.micrometer.instrument.binder.jmx.JmxGaugeMetrics;
import nablarch.integration.micrometer.instrument.binder.jmx.MBeanAttributeCondition;

import java.util.ArrayList;
import java.util.List;

public class CustomMeterBinderListProvider extends DefaultMeterBinderListProvider {

    @Override
    protected List<MeterBinder> createMeterBinderList() {
        List<MeterBinder> meterBinderList = new ArrayList<>(super.createMeterBinderList());
        // 最大数
        meterBinderList.add(new JmxGaugeMetrics(
            new MetricsMetaData("db.pool.total", "Total DB pool count."),
            new MBeanAttributeCondition("com.zaxxer.hikari:type=Pool (HikariPool-1)", "TotalConnections")
        ));
        // アクティブ数
        meterBinderList.add(new JmxGaugeMetrics(
            new MetricsMetaData("db.pool.active", "Active DB pool count."),
            new MBeanAttributeCondition("com.zaxxer.hikari:type=Pool (HikariPool-1)", "ActiveConnections")
        ));
        return meterBinderList;
    }
}

以上の設定で LoggingMeterRegistry を使用した場合、以下のようにメトリクスが出力されることが確認できる。

2020-12-24 16:37:57.143 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: db.pool.active{} value=0
2020-12-24 16:37:57.143 [INFO ]      i.m.c.i.l.LoggingMeterRegistry: db.pool.total{} value=5

24-Dec-2020 16:57:16.729 警告 [logging-metrics-publisher] io.micrometer.core.util.internal.logging.WarnThenDebugLogger.log Failed to apply the value function for the gauge 'db.pool.active'. Note that subsequent logs will be logged at debug level.
        java.lang.RuntimeException: javax.management.InstanceNotFoundException: com.zaxxer.hikari:type=Pool (HikariPool-1)
                at nablarch.integration.micrometer.instrument.binder.jmx.JmxGaugeMetrics.obtainGaugeValue(JmxGaugeMetrics.java:59)
                at io.micrometer.core.instrument.Gauge.lambda$builder$0(Gauge.java:58)
                at io.micrometer.core.instrument.StrongReferenceGaugeFunction.applyAsDouble(StrongReferenceGaugeFunction.java:47)
                at io.micrometer.core.instrument.internal.DefaultGauge.value(DefaultGauge.java:54)
                at io.micrometer.core.instrument.logging.LoggingMeterRegistry.lambda$publish$3(LoggingMeterRegistry.java:98)
                at io.micrometer.core.instrument.Meter.use(Meter.java:158)
                at io.micrometer.core.instrument.logging.LoggingMeterRegistry.lambda$publish$12(LoggingMeterRegistry.java:97)
                at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
                at java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:357)
                at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
                at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
                at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
                at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
                at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
                at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
                at io.micrometer.core.instrument.logging.LoggingMeterRegistry.publish(LoggingMeterRegistry.java:95)
                at io.micrometer.core.instrument.push.PushMeterRegistry.publishSafely(PushMeterRegistry.java:52)
                at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
                at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
                at java.lang.Thread.run(Thread.java:748)
        Caused by: javax.management.InstanceNotFoundException: com.zaxxer.hikari:type=Pool (HikariPool-1)
                at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
                at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
                at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
                at nablarch.integration.micrometer.instrument.binder.jmx.JmxGaugeMetrics.obtainGaugeValue(JmxGaugeMetrics.java:52)
                ... 23 more

24-Dec-2020 17:01:31.443 情報 [logging-metrics-publisher] io.micrometer.core.instrument.logging.LoggingMeterRegistry.lambda$publish$3 db.pool.active{} value=NaN
24-Dec-2020 17:01:31.443 情報 [logging-metrics-publisher] io.micrometer.core.instrument.logging.LoggingMeterRegistry.lambda$publish$3 db.pool.total{} value=NaN

package example.micrometer;

// 省略
import nablarch.core.log.Logger;
import nablarch.core.log.LoggerManager;
import nablarch.core.repository.initialization.Initializable;
import java.sql.SQLException;
import javax.sql.DataSource;
import java.sql.Connection;

public class CustomMeterBinderListProvider extends DefaultMeterBinderListProvider implements Initializable {
    private static final Logger LOGGER = LoggerManager.get(CustomMeterBinderListProvider.class);

    private DataSource dataSource;

    @Override
    protected List<MeterBinder> createMeterBinderList() {
        // 省略
    }

    public void setDataSource(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public void initialize() {
        try (Connection con = dataSource.getConnection()) {
            // 初期化時にコネクションを確立することで、MBeanが取れないことによる警告ログの出力を抑制する
        } catch (SQLException e) {
            LOGGER.logWarn("Failed initial connection.", e);
        }
    }
}

<component name="meterBinderListProvider"
           class="example.micrometer.CustomMeterBinderListProvider">
  <!-- DataSource を設定する -->
  <property name="dataSource" ref="dataSource" />
</component>

<!-- 初期化が必要なコンポーネント -->
<component name="initializer"
           class="nablarch.core.repository.initialization.BasicApplicationInitializer">
  <property name="initializeList">
    <list>
      <!-- 省略 -->

      <!-- 初期化対象のコンポーネントとして追加 -->
      <component-ref name="meterBinderListProvider" />
    </list>
  </property>
</component>