このセクションでは、Spring Integration のメトリクスをキャプチャーする方法について説明します。最近のバージョンでは、Micrometer（https://micrometer.io (英語) を参照）にさらに依存しており、将来のリリースでは Micrometer をさらに使用する予定です。

メッセージングアーキテクチャの主な利点は、参加しているコンポーネントが相互の認識を維持できないように、疎結合です。この事実だけで、アプリケーションは非常に柔軟になり、残りのフローに影響を与えずにコンポーネントを変更したり、メッセージングルートを変更したり、メッセージ消費スタイルを変更したりできます（ポーリングとイベントドリブン）。しかし、この控えめなスタイルのアーキテクチャは、物事がうまくいかない場合には難しいことがわかります。デバッグするときは、おそらくメッセージに関する情報（その発信元、通過したチャネル、その他の詳細）をできるだけ多く取得する必要があります。

メッセージ履歴は、デバッグまたは監査証跡を維持するために、メッセージパスの認識レベルを維持するオプションを提供することで役立つパターンの 1 つです。Spring 統合は、メッセージにヘッダーを追加し、メッセージが追跡対象コンポーネントを通過するたびにそのヘッダーを更新することにより、メッセージフローを設定してメッセージ履歴を維持する簡単な方法を提供します。

エンタープライズ統合パターン (英語) （EIP）ブックは、メッセージをバッファリングする機能を持ついくつかのパターンを識別します。例: アグリゲーターは、解放できるまでメッセージをバッファリングし、QueueChannel は、コンシューマーがそのチャネルからメッセージを明示的に受信するまでメッセージをバッファリングします。メッセージフロー内の任意の時点で発生する可能性がある障害のため、メッセージをバッファリングする EIP コンポーネントは、メッセージが失われる可能性のあるポイントも導入します。

メッセージを失うリスクを軽減するために、EIP はメッセージストア (英語) パターンを定義します。これにより、EIP コンポーネントは通常、ある種の永続ストア（RDBMS など）にメッセージを保存 (英語) できます。

Spring Integration は、以下によってメッセージストアパターンのサポートを提供します。

特定のメッセージストア実装の設定方法と特定のバッファリングコンポーネントへの MessageStore 実装の注入方法の詳細は、マニュアル全体で説明されています（QueueChannel、アグリゲーター、遅延器などの特定のコンポーネントを参照）。次の例のペアは、QueueChannel およびアグリゲーターのメッセージストアへの参照を追加する方法を示しています。

デフォルトでは、メッセージは MessageStore の実装である o.s.i.store.SimpleMessageStore を使用してメモリに保存されます。これは、非永続メッセージの潜在的な損失が懸念されない開発環境または単純な低ボリューム環境では問題ない場合があります。ただし、一般的な本番アプリケーションには、メッセージ損失のリスクを軽減するだけでなく、潜在的なメモリ不足エラーを回避するために、より堅牢なオプションが必要です。そのため、さまざまなデータストア用の MessageStore 実装も提供しています。以下は、サポートされている実装の完全なリストです。

Spring Integration 4.0 は 2 つの新しいインターフェースを導入しました:

実際の動作は実装によって異なります。このフレームワークは、QueueChannel および PriorityChannel の永続的な MessageStore として使用できる次の実装を提供します。

多くの外部システム、サービス、リソースはトランザクションではなく（Twitter、RSS、ファイルシステムなど）、データを既読としてマークする機能はありません。また、一部の統合ソリューションでは、エンタープライズ統合パターンべき等レシーバー (英語) を実装する必要がある場合があります。このゴールを達成し、外部システムとの次の対話の前にエンドポイントの以前の状態を保存するため、または次のメッセージを処理するために、Spring Integration は、一般的なキー値契約を備えた org.springframework.integration.metadata.MetadataStore インターフェースの実装としてメタデータストアコンポーネントを提供します。

メタデータストアは、さまざまな種類の汎用メタデータ（たとえば、処理された最後のフィードエントリの公開日）を格納して、フィードアダプターなどのコンポーネントが重複を処理できるように設計されています。コンポーネントに MetadataStore への参照が直接提供されない場合、メタデータストアを見つけるためのアルゴリズムは次のとおりです。最初に、アプリケーションコンテキストで metadataStore ID を持つ Bean を探します。見つかった場合は、それを使用します。そうでない場合は、SimpleMetadataStore の新しいインスタンスを作成します。これは、現在実行中のアプリケーションコンテキストのライフサイクル内でメタデータのみを永続化するメモリ内実装です。つまり、再起動すると、エントリが重複する可能性があります。

アプリケーションコンテキストの再起動間でメタデータを保持する必要がある場合、フレームワークは次の永続的な MetadataStores を提供します。

PropertiesPersistingMetadataStore は、プロパティファイルと PropertiesPersister (Javadoc) によってサポートされています。

デフォルトでは、アプリケーションコンテキストが正常に閉じられたときの状態のみを保持します。Flushable を実装しているため、flush() を呼び出すことで、状態を自由に維持できます。次の例は、XML で "PropertiesPersistingMetadataStore" を構成する方法を示しています。

または、MetadataStore インターフェースの独自の実装（たとえば JdbcMetadataStore）を提供し、それをアプリケーションコンテキストで Bean として構成できます。

バージョン 4.0 以降、SimpleMetadataStore、PropertiesPersistingMetadataStore、RedisMetadataStore は ConcurrentMetadataStore を実装します。これらはアトミックアップデートを提供し、複数のコンポーネントまたはアプリケーションインスタンスで使用できます。

エンタープライズ統合パターン (英語) （EIP）ブックに従って、コントロールバスの背景となる考え方は、「アプリケーションレベル」メッセージングに使用されるのと同じメッセージングシステムをフレームワーク内のコンポーネントの監視と管理に使用できるということです。Spring Integration では、公開された操作を呼び出す手段としてメッセージを送信できるように、上記のアダプターに基づいて構築しています。

次の例は、XML で制御バスを構成する方法を示しています。

制御バスには、アプリケーションコンテキストで Bean の操作を呼び出すためにアクセスできる入力チャネルがあります。また、エンドポイントをアクティブにするサービスのすべての共通プロパティもあります。例: 操作の結果に、ダウンストリームチャネルに送信する戻り値がある場合、出力チャネルを指定できます。

制御バスは、Spring Expression Language（SpEL）式として入力チャネルでメッセージを実行します。メッセージを受け取り、本文を式にコンパイルし、コンテキストを追加してから実行します。デフォルトのコンテキストは、@ManagedAttribute または @ManagedOperation でアノテーションが付けられたメソッドをサポートします。また、Spring の Lifecycle インターフェース（およびバージョン 5.2 以降の Pausable 拡張）のメソッドをサポートし、Spring の TaskExecutor および TaskScheduler 実装のいくつかを構成するために使用されるメソッドをサポートします。制御バスで独自のメソッドを使用できるようにする最も簡単な方法は、@ManagedAttribute または @ManagedOperation アノテーションを使用することです。これらのアノテーションは、メソッドを JMX MBean レジストリに公開するためにも使用されるため、便利な副産物を提供します。多くの場合、コントロールバスに公開するのと同じ型の操作は、JMX を介して公開するのに適しています。アプリケーションコンテキスト内の特定のインスタンスの解決は、一般的な SpEL 構文で実現されます。これを行うには、Bean の SpEL 接頭辞（@）を Bean 名に指定します。例: Spring Bean でメソッドを実行するために、クライアントは次のように操作チャネルにメッセージを送信できます。

式のコンテキストのルートは Message 自体であるため、式内の変数として payload および headers にもアクセスできます。これは、Spring Integration エンドポイントの他のすべての式サポートと一致しています。

Java アノテーションを使用すると、コントロールバスを次のように構成できます。

同様に、Java DSL フロー定義を次のように構成できます。

DirectChannel の自動作成でラムダを使用する場合は、次のように制御バスを作成できます。

この場合、チャネルの名前は controlBus.input です。

"MBean エクスポーター" に従って、MBean エクスポーターは stopActiveComponents と呼ばれる JMX 操作を提供します。これは、アプリケーションを正常に停止するために使用されます。操作には単一の Long パラメーターがあります。このパラメーターは、処理中のメッセージの補完を待機する時間（ミリ秒単位）を示します。操作は次のように機能します。

正常なシャットダウン管理操作で説明したように、この操作は JMX を使用して呼び出すことができます。プログラムでメソッドを呼び出す場合は、IntegrationMBeanExporter への参照を挿入するか、取得する必要があります。id 属性が <int-jmx:mbean-export/> 定義で指定されていない場合、Bean には名前が生成されます。この名前には、同じ JVM（MBeanServer）に複数の Spring Integration コンテキストが存在する場合に ObjectName の衝突を回避するためのランダムなコンポーネントが含まれています。

このため、プログラムでメソッドを呼び出す場合は、アプリケーションコンテキストで簡単にアクセスできるように、エクスポーターに id 属性を提供することをお勧めします。

最後に、<control-bus> 要素を使用して操作を呼び出すことができます。詳細については、モニタリング Spring Integration サンプルアプリケーション [GitHub] (英語) を参照してください。

バージョン 4.3 から、Spring Integration はアプリケーションのランタイムオブジェクトモデルへのアクセスを提供します。これには、オプションでコンポーネントメトリクスを含めることができます。グラフとして公開され、統合アプリケーションの現在の状態を視覚化するために使用できます。o.s.i.support.management.graph パッケージには、Spring Integration コンポーネントのランタイム状態を単一のツリーのような Graph オブジェクトとして収集、構築、レンダリングするために必要なすべてのクラスが含まれています。IntegrationGraphServer は、Graph オブジェクトを作成、取得、リフレッシュするために Bean として宣言する必要があります。結果の Graph オブジェクトは任意の形式に直列化できますが、JSON はクライアント側で解析および表現するのに柔軟で便利です。デフォルトのコンポーネントのみを持つ Spring Integration アプリケーションは、次のようなグラフを公開します。

前の例では、グラフは 3 つの最上位要素で構成されています。

contentDescriptor グラフ要素には、データを提供するアプリケーションに関する一般情報が含まれています。name は、IntegrationGraphServer Bean または spring.application.name アプリケーションコンテキスト環境プロパティでカスタマイズできます。他のプロパティはフレームワークによって提供され、同様のモデルを他のソースと区別できます。

links グラフ要素は、nodes グラフ要素のノード間の接続を表します。ソース Spring Integration アプリケーションの統合コンポーネント間の接続を表します。例: MessageChannel から MessageHandler を含む EventDrivenConsumer へ、または AbstractReplyProducingMessageHandler から MessageChannel へ。便宜上、リンクの目的を判断できるように、モデルには type 属性が含まれています。可能な型は次のとおりです。

この要素からの情報を視覚化ツールで使用して、nodes グラフ要素のノード間の接続をレンダリングできます。from および to 番号は、リンクされたノードの nodeId プロパティの値を表します。例: link 要素を使用して、ターゲットノードで適切な port を決定できます。

次の「テキストイメージ」は、型間の関連を示しています。

nodes グラフ要素は、おそらく最も興味深いものです。その要素には、componentType インスタンスと name 値を持つランタイムコンポーネントが含まれるだけでなく、オプションでコンポーネントによって公開されるメトリクスも含まれる可能性があるためです。ノード要素には、一般的に一目でわかるさまざまなプロパティが含まれています。例: 式ベースのコンポーネントには、コンポーネントの 1 次式文字列を含む expression プロパティが含まれます。メトリクスを有効にするには、@EnableIntegrationManagement を @Configuration クラスに追加するか、<int:management/> 要素を XML 構成に追加します。詳細については、指標と管理を参照してください。

nodeId は、あるコンポーネントと別のコンポーネントを区別できるようにする一意の増分識別子を表します。links 要素でも使用され、このコンポーネントと他のコンポーネント（ある場合）との関連（接続）を表します。input および output 属性は、AbstractEndpoint、MessageHandler、SourcePollingChannelAdapter または MessageProducerSupport の inputChannel および outputChannel プロパティ用です。詳細については、次のセクションを参照してください。

バージョン 5.1 以降、IntegrationGraphServer は、特定の NamedComponent の IntegrationNode 上の追加プロパティの作成に Function<NamedComponent, Map<String, Object>> additionalPropertiesCallback を受け入れます。たとえば、SmartLifecycleautoStartup、running プロパティをターゲットグラフに公開できます。

アプリケーションが Web ベース（または Web コンテナーが埋め込まれた Spring Boot 上に構築されている）であり、Spring Integration HTTP または WebFlux モジュール（それぞれ HTTP サポートおよび WebFlux サポートを参照）がクラスパスに存在する場合、IntegrationGraphController を使用して IntegrationGraphServer を公開できます。REST サービスとしての機能。この目的のために、@EnableIntegrationGraphController および @Configuration クラスのアノテーションと <int-http:graph-controller/> XML 要素が HTTP モジュールで使用可能です。この構成は、@EnableWebMvc アノテーション（または XML 定義の場合は <mvc:annotation-driven/>）とともに、IntegrationGraphController@RestController を登録します。この構成では、@RequestMapping.path を @EnableIntegrationGraphController アノテーションまたは <int-http:graph-controller/> 要素で構成できます。デフォルトのパスは /integration です。

IntegrationGraphController@RestController は、次のサービスを提供します。

Spring Security および Spring MVC プロジェクトによって提供される標準の構成オプションとコンポーネントを使用して、IntegrationGraphController のセキュリティとクロスオリジンの制限を設定できます。次の例は、これらのゴールを達成します。

次の例は、Java 構成で同じことを行う方法を示しています。

便宜上、@EnableIntegrationGraphController アノテーションは allowedOrigins 属性を提供することに注意してください。これにより、path への GET アクセスが提供されます。より高度にするために、標準の Spring MVC メカニズムを使用して CORS マッピングを構成できます。