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() メソッドをオーバーロードすることにより、メーターをさらにカスタマイズすることもできます。

これらのレガシーメトリクスは、将来のリリースで削除される予定です。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 個ごとです。

通知リスニングチャネルアダプターには、このリスナーを登録する通知を発行する MBean の JMX ObjectName が必要です。非常に単純な構成は、次のようになります。

アダプターは、NotificationFilter および「ハンドバック」オブジェクトへの参照を受け入れて、各通知で戻されるコンテキストを提供することもできます。これらの属性は両方ともオプションです。上記の例を拡張して、これらの属性と明示的な MBeanServer Bean 名を含めると、次の例が生成されます。

_Notification-listening チャネルアダプターはイベント駆動型であり、MBeanServer に直接登録されます。ポーラー構成は必要ありません。

通知発行チャネルアダプターは比較的単純です。次の例に示すように、構成に必要なのは JMX オブジェクト名のみです。

また、MBeanExporter がコンテキストに存在する必要があります。そのため、前の例で <context:mbean-export/> 要素も示されています。

このアダプターのチャネルにメッセージが送信されると、メッセージのコンテンツから通知が作成されます。ペイロードが String である場合、通知の message テキストとして渡されます。その他のペイロード型は、通知の userData として渡されます。

JMX 通知には type もあり、ドット区切りの String である必要があります。type を提供するには 2 つの方法があります。JmxHeaders.NOTIFICATION_TYPE キーに関連付けられたメッセージヘッダー値には常に優先順位が与えられます。または、次の例に示すように、構成でフォールバック default-notification-type 属性を提供できます。

属性ポーリングチャネルアダプターは、MBean を介して管理属性として使用可能な値を定期的に確認する必要がある場合に役立ちます。Spring Integration の他のポーリングアダプターと同じ方法でポーラーを構成できます（またはデフォルトのポーラーを使用できます）。object-name と attribute-name が必要です。MBeanServer の参照も必要です。ただし、デフォルトでは、それが自動的に mbeanServer という名前 Bean ためのチェックは、通知リスニングチャネルアダプターと同じでは先に述べました。次の例は、属性ポーリングチャネルアダプターを XML で構成する方法を示しています。

ツリーポーリングチャネルアダプターは、JMX MBean ツリーにクエリを実行し、クエリに一致するオブジェクトのグラフであるペイロードを含むメッセージを送信します。デフォルトでは、MBean はプリミティブと、Map、List、配列などの単純なオブジェクトにマップされます。そうすることで、（たとえば）JSON への単純な変換が可能になります。MBeanServer 参照も必要です。ただし、デフォルトでは、それが自動的に mbeanServer という名前 Bean ためのチェックは、通知リスニングチャネルアダプターと同じでは先に述べました。次の例は、XML を使用してツリーポーリングチャネルアダプターを設定する方法を示しています。

上記の例には、選択した MBean のすべての属性が含まれています。適切なフィルターが構成された MBeanObjectConverter を提供することにより、属性をフィルターに掛けることができます。converter 属性を使用して Bean 定義への参照としてコンバーターを提供するか、内部 <bean/> 定義を使用できます。Spring Integration は、コンストラクター引数で MBeanAttributeFilter を取ることができる DefaultMBeanObjectConverter を提供します。

Spring Integration は 2 つの標準フィルターを提供します。NamedFieldsMBeanAttributeFilter では、含める属性のリストを指定できます。NotNamedFieldsMBeanAttributeFilter では、除外する属性のリストを指定できます。独自のフィルターを実装することもできます。

操作呼び出しチャネルアダプターを使用すると、MBean によって公開されるすべての管理操作のメッセージ駆動型呼び出しが可能になります。各呼び出しには、呼び出される操作名とターゲット MBean のオブジェクト名が必要です。これらは両方とも、アダプター構成または JmxHeaders.OBJECT_NAME および JmxHeaders.OPERATION_NAME メッセージヘッダーを介してそれぞれ明示的に提供する必要があります。

その場合、アダプターは mbeanServer Bean を検出できる必要があるだけです。別の Bean 名が必要な場合は、mbean-server 属性に参照を提供します。

メッセージのペイロードは、操作のパラメーター（存在する場合）にマップされます。String キーを持つ Map -typed ペイロードは名前 / 値のペアとして扱われますが、List または配列は単純な引数リストとして渡されます（明示的なパラメーター名はありません）。操作に単一のパラメーター値が必要な場合、ペイロードはその単一の値を表すことができます。また、操作にパラメーターが必要ない場合、ペイロードは無視されます。

ヘッダーを含む必要のないメッセージによって呼び出される単一の共通操作のチャネルを公開する場合、その最後のオプションはうまく機能します。

操作を呼び出すチャネルアダプターと同様に、Spring Integration は操作を呼び出す送信ゲートウェイも提供します。これは、戻り値が必要な場合に非 void 操作を処理するときに使用できます。戻り値は、メッセージペイロードとしてゲートウェイによって指定された reply-channel に送信されます。次の例は、XML を使用して操作呼び出し発信ゲートウェイを構成する方法を示しています。

reply-channel 属性を指定しない場合、応答メッセージは IntegrationMessageHeaderAccessor.REPLY_CHANNEL ヘッダーで識別されるチャネルに送信されます。通常、このヘッダーは、ゲートウェイコンポーネントなどのメッセージフローへのエントリポイントによって自動作成されます。ただし、Spring Integration メッセージを手動で作成してチャネルに直接送信することによってメッセージフローが開始された場合、メッセージヘッダーを明示的に指定するか、reply-channel 属性を使用する必要があります。

Spring Integration コンポーネントは、IntegrationMBeanExporter の構成時に MBean として公開される場合があります。IntegrationMBeanExporter のインスタンスを作成するには、Bean を定義し、MBeanServer への参照とドメイン名（必要な場合）を提供します。ドメインを除外できます。この場合、デフォルトのドメインは org.springframework.integration です。次の例は、IntegrationMBeanExporter および関連する MBeanServer インスタンスのインスタンスを宣言する方法を示しています。

Spring Integration 4.0 は、@Configuration クラスレベルでいくつかの便利なオプションを備えた型 IntegrationMBeanExporter のデフォルト integrationMbeanExporter Bean の便利な設定を可能にする @EnableIntegrationMBeanExport アノテーションを導入しました。次の例は、この Bean を構成する方法を示しています。

より多くのオプションを提供したり、複数の IntegrationMBeanExporter Bean が必要な場合（異なる MBean サーバー用、または @EnableMBeanExport などを介して標準 Spring MBeanExporter との競合を避けるため）、IntegrationMBeanExporter を汎用 Bean として構成できます。

メッセージ履歴を有効にするには、次の例に示すように、構成で message-history 要素のみを定義する必要があります。

これで、すべての名前付きコンポーネント（ "id" が定義されているコンポーネント）が追跡されます。フレームワークは、メッセージに "history" ヘッダーを設定します。その値は List<Properties> です。

次の構成例を検討してください。

上記の構成により、単純なメッセージ履歴構造が生成され、出力は次のようになります。

メッセージ履歴にアクセスするには、MessageHistory ヘッダーにアクセスするだけで済みます。次の例は、その方法を示しています。

すべてのコンポーネントを追跡したくない場合があります。名前に基づいて特定のコンポーネントに履歴を制限するには、tracked-components 属性を指定し、追跡するコンポーネントに一致するコンポーネント名とパターンのコンマ区切りリストを指定できます。次の例は、その方法を示しています。

前の例では、'Gateway' で終わる、'sample' で始まる、または名前 'aName' と完全に一致するコンポーネントに対してのみ、メッセージ履歴が保持されます。

バージョン 4.0 から、@Configuration クラスで @EnableMessageHistory アノテーションを使用することもできます。さらに、MessageHistoryConfigurer Bean は IntegrationMBeanExporter （MBean エクスポーターを参照）によって JMX MBean として公開され、実行時にパターンを変更できるようになりました。ただし、パターンを変更するには、Bean を停止する（メッセージ履歴をオフにする）必要があることに注意してください。この機能は、一時的に履歴をオンにしてシステムを分析するのに役立つ場合があります。MBean のオブジェクト名は <domain>:name=messageHistoryConfigurer,type=MessageHistoryConfigurer です。

バージョン 4.3 から、MessageGroupStore 実装の一部にカスタム MessageGroupFactory 戦略を注入して、MessageGroupStore が使用する MessageGroup インスタンスを作成およびカスタマイズできます。これはデフォルトで SimpleMessageGroupFactory になり、GroupType.HASH_SET （LinkedHashSet）内部コレクションに基づいて SimpleMessageGroup インスタンスを生成します。他の可能なオプションは SYNCHRONISED_SET および BLOCKING_QUEUE です。最後のオプションを使用して、以前の SimpleMessageGroup の動作を復元できます。PERSISTENT オプションも利用できます。詳細については、次のセクションを参照してください。バージョン 5.0.1 から、LIST オプションは、グループ内のメッセージの順序と一意性が重要でない場合にも使用できます。

バージョン 4.3 以降、すべての永続的な MessageGroupStore インスタンスは、遅延ロード方式でストアから MessageGroup インスタンスとその messages を取得します。ほとんどの場合、各相関操作でストアから MessageGroup 全体をロードするオーバーヘッドを追加する場合、相関 MessageHandler インスタンス（アグリゲーターおよびリシーケンサーを参照）に役立ちます。

AbstractMessageGroupStore.setLazyLoadMessageGroups(false) オプションを使用して、構成から遅延ロード動作をオフに切り替えることができます。

MongoDB MessageStore （MongoDB メッセージストア）および <aggregator> （アグリゲーター）での遅延ロードのパフォーマンステストでは、次のようなカスタム release-strategy を使用します。

1000 個の単純なメッセージに対して、次のような結果が生成されます。

メタデータストアは、受信メッセージがすでに処理されており、破棄するか、破棄時に他のロジックを実行できる場合、受信メッセージをフィルターする必要がある場合に、EIP べき等レシーバー (英語) パターンを実装できます。次の構成は、その方法の例を示しています。

べき等エントリの value は有効期限になる可能性があり、その後、そのエントリは何らかのスケジュールされたリーパーによってメタデータストアから削除される必要があります。

べき等レシーバーエンタープライズ統合パターンも参照してください。

次の例に示すように、一部のメタデータストア（現在は zookeeper のみ）は、アイテムの変更時にイベントを受信するリスナーの登録をサポートしています。

詳細については、Javadoc を参照してください。イベントのサブセットのみに関心がある場合は、MetadataStoreListenerAdapter をサブクラス化できます。

Spring Integration コンポーネントには、さまざまなレベルの複雑さがあります。例: ポーリングされた MessageSource には、ソースデータからメッセージを定期的に送信する SourcePollingChannelAdapter と MessageChannel もあります。他のコンポーネントは、メッセージ用の requestChannel （input）にサブスクライブ（またはポーリング）するための消費 AbstractEndpoint と、ダウンストリームに送信するための応答メッセージを生成する replyChannel （output）を備えたミドルウェアのリクエスト / 応答コンポーネント（JmsOutboundGateway など）です。一方、MessageProducerSupport 実装（ApplicationEventListeningMessageProducer など）は、一部のソースプロトコルリスニングロジックをラップし、outputChannel にメッセージを送信します。

グラフ内で、Spring Integration コンポーネントは、IntegrationNode クラス階層を使用して表されます。これは、o.s.i.support.management.graph パッケージに含まれています。例: AggregatingMessageHandler には ErrorCapableDiscardingMessageHandlerNode を使用でき（discardChannel オプションがあるため）、PollingConsumer を使用して PollableChannel からコンシュームするときにエラーを生成できます。もう 1 つの例は CompositeMessageHandlerNode です。EventDrivenConsumer を使用して SubscribableChannel にサブスクライブした場合の MessageHandlerChain 用です。

前述のゲートウェイは、次のようなノードを生成します。

この IntegrationNode 階層を使用して、クライアント側でグラフモデルを解析したり、一般的な Spring Integration ランタイムの動作を理解したりできます。詳細については、プログラミングのヒントとコツも参照してください。

バージョン 5.3 は、IntegrationPattern 抽象化と、エンタープライズ統合パターン（EIP）を表すすべての標準コンポーネントを導入し、この抽象化を実装し、IntegrationPatternType 列挙値を提供します。この情報は、ターゲットアプリケーションのいくつかの分類ロジックに役立ちます。または、グラフノードに公開されているため、UI がコンポーネントの描画方法を決定するために使用できます。