MessageSource、MessageChannel、MessageHandler メトリクスを有効にするには、<int:management/> Bean をアプリケーションコンテキスト（XML）に追加するか、@Configuration クラスの 1 つに @EnableIntegrationManagement （Java）でアノテーションを付けます。MessageSource インスタンスはカウントのみを維持し、MessageChannel インスタンスと MessageHandler インスタンスはカウントに加えて期間統計を維持します。この章で後述する MessageChannel メトリクス機能および MessageHandler メトリクス機能を参照してください。

これにより、アプリケーションコンテキストで IntegrationManagementConfigurer Bean が自動的に登録されます。このような Bean はコンテキストに 1 つだけ存在でき、<bean/> 定義を介して手動で登録する場合は、Bean 名を integrationManagementConfigurer に設定する必要があります。この Bean は、コンテキスト内のすべての Bean がインスタンス化された後、その構成を Bean に適用します。

メトリクスに加えて、メインメッセージフローでデバッグロギングを制御できます。非常に大量のアプリケーションでは、isDebugEnabled() の呼び出しでさえ、一部のロギングサブシステムでは非常に高負荷になる可能性があります。このオーバーヘッドを回避するために、このようなロギングをすべて無効にすることができます。例外ロギング（デバッグまたはその他）は、この設定の影響を受けません。

次のリストは、ロギングを制御するために使用可能なオプションを示しています。

実行時に、カウントと統計は、それぞれ MessageChannelMetrics、MessageHandlerMetrics、MessageSourceMetrics を返す getChannelMetrics、getHandlerMetrics、getSourceMetrics （すべて IntegrationManagementConfigurer クラスから）を呼び出すことによって取得できます。

これらのクラスの詳細については、Javadoc を参照してください。

JMX が有効な場合（JMX サポートを参照）、IntegrationMBeanExporter はこれらのメトリクスも公開します。

IMPORTANT: defaultLoggingEnabled、defaultCountsEnabled、defaultStatsEnabled は、Bean 定義で対応する設定を明示的に構成していない場合にのみ適用されます。

バージョン 5.0.2 以降、フレームワークは、アプリケーションコンテキストに単一の MetricsFactory Bean が存在するかどうかを自動的に検出し、存在する場合はデフォルトのメトリクスファクトリの代わりにそれを使用します。

バージョン 5.0.3 以降、アプリケーションコンテキストに Micrometer (英語)  MeterRegistry が存在すると、組み込みメトリクスに加えて Micrometer メトリクスのサポートがトリガーされます（従来の組み込みメトリクスは将来のリリースで削除されることに注意してください）。

Micrometer を使用するには、MeterRegistry Bean の 1 つをアプリケーションコンテキストに追加します。IntegrationManagementConfigurer は、MeterRegistry Bean を 1 つだけ検出した場合、integrationMicrometerMetricsCaptor という名前で MicrometerMetricsCaptor Bean を構成します。

MessageHandler および MessageChannel ごとに、タイマーが登録されます。MessageSource ごとに、カウンターが登録されます。

これは、AbstractMessageHandler、AbstractMessageChannel、AbstractMessageSource を継承するオブジェクトにのみ適用されます（ほとんどのフレームワークコンポーネントに当てはまります）。

Micrometer メトリクスでは、統計のキャプチャーは Micrometer に委譲されるため、statsEnabled フラグは効果がありません。countsEnabled フラグは、各メッセージを処理するときに Micrometer Meter インスタンスを更新するかどうかを制御します。

メッセージチャネルの送信操作用の Timer メーターには、次の名前またはタグがあります。

（none 例外を含む failure 結果は、チャネルの send() 操作が false を返したことを意味します）

ポーリング可能なメッセージチャネルでの受信操作用の Counter メーターには、次の名前またはタグがあります。

メッセージハンドラーの操作用の Timer メーターには、次の名前またはタグがあります。

メッセージソースの Counter メーターには、次の名前 / タグがあります。

さらに、3 つの Gauge メーターがあります。

MicrometerMetricsCaptor のサブクラスを提供することにより、統合コンポーネントによって作成された Meters の名前とタグをカスタマイズできます。MicrometerCustomMetricsTests [GitHub] (英語) テストケースは、その方法の簡単な例を示しています。ビルダーサブクラスの build() メソッドをオーバーロードすることにより、メーターをさらにカスタマイズすることもできます。

バージョン 5.1.13 以降、QueueChannel は、キューサイズと残り容量の Micrometer ゲージを公開します。

および

これらのレガシーメトリクスは、将来のリリースで削除される予定です。Micrometer 統合を参照してください。

メッセージチャネルは、具象型に従ってメトリクスをレポートします。DirectChannel を見ている場合、送信操作の統計が表示されます。QueueChannel の場合、受信操作の統計と、この QueueChannel によって現在バッファリングされているメッセージの数も表示されます。どちらの場合も、一部のメトリクスは単純なカウンター（メッセージカウントとエラーカウント）であり、一部は興味深い量の平均の推定値です。これらの推定値の計算に使用されるアルゴリズムについて、次の表で簡単に説明します。

これらのレガシーメトリクスは、将来のリリースで削除される予定です。Micrometer 統合を参照してください。

次の表は、メッセージハンドラーについて維持される統計を示しています。一部のメトリクスは単純なカウンター（メッセージカウントとエラーカウント）であり、1 つは送信期間の平均の推定値です。これらの推定値の計算に使用されるアルゴリズムについて、次の表で簡単に説明します。

時間ベースの平均推定値の特徴は、新しい測定値が到着しなければ時間とともに減衰することです。経時的な動作の解釈に役立つように、最後の測定からの時間（秒単位）もメトリクスとして公開されます。

2 つの基本的な指数モデルがあります: 測定ごとの減衰（期間と測定回数がメトリクスの一部である場合に適切）および時間単位ごとの減衰（測定間の時間がメトリクスの一部であるレート測定により適しています）。両方のモデルは、w(i) = r^i が r=constant: S(n) = x(n) + r S(n-1) の場合、S(n) = sum(i=0,i=n) w(i) x(i) が特別な形式を持っているという事実に依存します（したがって、S(n-1) （シリーズ x(i) 全体ではなく）のみを保存して、最後の測定から新しいメトリクス推定値を生成します）。期間メトリクスで使用されるアルゴリズムは、r=exp(-1/M) と M=10 を使用します。最終的な影響は、推定値 S(n) が最近の測定値により大きく重み付けされ、おおよそ最後の M 測定値で構成されることです。M は推定の「ウィンドウ」または失効率です。バニラ移動平均の場合、i は測定回数のカウンターです。レートについては、i を経過時間または経過時間とカウンターの組み合わせとして解釈します（したがって、メトリクス推定値には、最後の M 測定値と最後の T 秒からのおおよそのコントリビュートが含まれます）。

MessageChannel インスタンスおよび MessageHandler インスタンスにカスタムチャネルメトリクスを提供できるように、戦略インターフェース MetricsFactory が導入されました。デフォルトでは、DefaultMetricsFactory は MessageChannelMetrics と MessageHandlerMetrics のデフォルト実装を提供し、先に説明しました。デフォルトの MetricsFactory をオーバーライドするには、MetricsFactory Bean インスタンスへの参照を提供して、前述のように構成します。次のセクションで説明するように、デフォルトの実装をカスタマイズするか、AbstractMessageChannelMetrics または AbstractMessageHandlerMetrics を継承してまったく異なる実装を提供できます。

Micrometer 統合も参照してください。

前述のデフォルトのメトリクスファクトリに加えて、フレームワークは AggregatingMetricsFactory を提供します。このファクトリは、AggregatingMessageChannelMetrics および AggregatingMessageHandlerMetrics インスタンスを作成します。非常に大容量のシナリオでは、統計をキャプチャーするコストが非常に高くなる可能性があります（システムに 2 回呼び出して、各メッセージのデータを保存する時間）。集約メトリクスは、メッセージのサンプル全体のレスポンス時間を集約します。これにより、CPU 時間を大幅に節約できます。

次の例は、集約メトリクスファクトリを定義する方法を示しています。

上記の構成では、1000 メッセージを超える期間が集約されます。カウント（送信およびエラー）はメッセージごとに維持されますが、統計はメッセージ 1000 個ごとです。