OpenTelemetry considerations and limitations
You can configure OpenTelemetry trace for IBM® App Connect Enterprise integration servers on the Linux® x86-64, Linux zSeries, Linux on POWER® Systems - Little Endian, AIX®, and Windows platforms.
When OpenTelemetry is enabled, trace parent identifiers become part of the transport headers. The input nodes check the input headers for an existing trace parent identifier, and if one is found, the spans created in these nodes become child spans using the trace parent identifier. The synchronous and asynchronous HTTP, SOAP, and REST request nodes include the current trace parent identifier in the HTTP headers of the request message. The MQOutput node includes the current trace parent identifier in the MQRFH2 usr folder.
No telemetry information is generated for input and reply nodes when messages are injected into the runtime. Injection does not use the transport, which means that no transport-related information can be used. If a request, get, or output node that supports telemetry is invoked in a flow from an injected message, a sparse span (which contains no transport-related information) is started for the message flow, and the normal child span is created for these request, get, and output nodes.
If a message flow starts with an input node that does not support OpenTelemetry, but a request, get, or output node is used that does support it, a sparse span is started for the message flow, which is the parent of the child spans created by the request, get, or output nodes.
MQ Telemetry considerations
If an MQGet node does not get a message, a child span is
created and marked as an error containing MQCC=2, MQRC=2033. If an MQInput node does not get a message, no telemetry information is
created. No return codes or completion codes are published for the MQInput node; MQ Telemetry is created when a message is
successfully returned from the queue, so these would always be zero.
MQOutput, MQGet, and MQPublication nodes start a child span just before the interaction with MQ. If these nodes throw an exception beforehand (such as rejecting an LE override), no child span is created. The child span ends after the MQ call, irrespective of whether the message was got or put in syncpoint. If the message is rolled back, the child span stills show success, but the parent span shows an error. If MQ has OpenTelemetry enabled, it shows how long the message was held in syncpoint.
MQPublication nodes can create multiple child spans - one for each topic that it has been asked to publish on. If the MQMD settings are such that a reply is needed, that reply is sent in a separate child span to be published.
MQOutput nodes can create multiple child spans when a destination list is used - one child span for each destination.
If an MQGet node retrieves a message that has an existing trace parent identifier in the MQRFH2 header, this is currently ignored.
No telemetry is captured for MQ processing that is used internally for the following resources:
- Integration node listener queues
- Collector nodes
- Aggregation nodes
- Sequence and Resequence nodes
- Timer nodes
No telemetry is captured when publishing to MQ topics for monitoring, message flow statistics, and resource statistics.
Limitations
- Tracing for SOAP WS-RM and WS-Addressing is not supported.
- SOAP nodes using the JMS transport are not supported.
- Full support is provided for HTTP transport nodes using both the embedded and integration node HTTP listener. However, the integration node listener does not support decompression on input and does not produce any telemetry information about compressed payloads.
- When the processing of a message by a message flow exceeds the timeout defined on an HTTPInput or SOAPInput node, no telemetry is collected for the propagation to the timeout terminal of the input node.