Loading

Log Aggregation Behavior in Clustered Environments (ClusterId vs ServerId) in Anypoint Monitoring

Date de publication: Jun 22, 2026
Description

The expected behavior in a clustered setup is that logs are aggregated under a single workerId representing the clusterId. This aligns with the current design of log forwarding configured in the Anypoint Monitoring (AM) agent OTEL pipeline.

However, an exception can occur during the initial setup phase:

  • If the Anypoint Monitoring agent is installed immediately after cluster creation, the cluster may not yet be fully formed.
  • During this period, the clusterId may not be properly propagated to all servers.
  • As a result, the clusterId value in the pipeline configuration may be set to null.
  • Due to non-null validation constraints, the system defaults to using the serverId instead.

This leads to logs being split and displayed under individual serverId values, resulting in multiple worker IDs in Anypoint Monitoring.

Once any server in the cluster is restarted:

  • The clusterId is correctly populated.
  • Logs are aggregated under a single workerId (cluster-level), which is the expected behavior.

This behavior is by design. Aggregating logs at the cluster level is the current standard implementation. The ability to persist log aggregation at individual server levels within a cluster is a feature request, and the Engineering team is actively working on it.

Résolution

If your use case requires logs to be consistently grouped by individual serverId, the following workaround can be applied.

Note: It is recommended to validate this workaround in lower environments before applying it to production.

Replication Steps:

  1. Create two Mule runtime servers (for example: nodeServer1 and nodeServer2).
  2. Form a unicast cluster with both servers.
  3. Install the Anypoint Monitoring agent on each server sequentially (refer to official documentation).
  4. Deploy a simple scheduler application that generates log messages.
  5. Observe that logs are initially grouped under individual serverId values.
  6. Restart both servers simultaneously from Runtime Manager.

Workaround Steps:

  1. Navigate to the file: /conf/mule-agent.yml

  2. Set the following value:

    id:
  clusterId: null
  3. Restart the server for the changes to take effect.

After restart:

  • The serverId will be reflected in:
    • am/config/pipelines/otel-config.yml
    • Individual app.yml files under the same directory (in the workerId field)

Important Consideration:

  • During subsequent restarts, the mule-agent.yml file may be overwritten, and the clusterId may be reset from Runtime Manager.
  • Therefore, this workaround must be reapplied before each restart to maintain log grouping by serverId.

This approach provides a temporary solution until native support for server-level log aggregation within clusters is made available. 

Numéro d’article de la base de connaissances

005387484

 
Chargement
Salesforce Help | Article