iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can send OpenTelemetry traces, metrics, and logs to IBM Instana through an OpenTelemetry Collector, an Instana agent, or—in supported setups—directly to the Instana backend. The Collector is optional: use it when you need to gather multiple sources, process or route telemetry in the middle, or centralize configuration. For reliable cross-service traces and useful host-level analysis, plan for W3C trace context, stable resource identity, and consistent attributes before you choose a route.
What OpenTelemetry and Instana do together
OpenTelemetry instruments applications and transports telemetry using OTLP; Instana ingests and analyzes that data alongside telemetry it collects itself. IBM documents traces, metrics, and logs as generally available. It also supports mixed traces made from OpenTelemetry spans and spans produced by Instana AutoTrace, allowing a request path to remain visible across differently instrumented services. IBM’s OpenTelemetry overview describes this as “continuous mixed tracing.”
This does not mean every OpenTelemetry signal or emerging convention has identical support, mapping, or licensing. The practical integration described here focuses on traces, metrics, and logs, for which IBM provides ingestion guidance. Check current IBM documentation for the versions and deployment type you run; the exact cross-language SDK and Collector compatibility matrix is not established by the pages cited here.
Choose where OTLP should go
The main decision is whether a middle-stage Collector is useful and whether telemetry should pass through an Instana agent or go directly to the backend. A Collector is an optional component, not a prerequisite when an application already emits OTLP and no further intermediate processing is required. IBM documents the supported sending methods.
#1 Best Overall
| Route | When it fits | Deployment and routing | Operational ownership |
|---|---|---|---|
| Application to Instana agent | The application emits OTLP and a reachable local or nearby agent can receive it. | Send to the agent’s OTLP receiver; the agent forwards data to Instana. | Operate the agent and confirm OTLP ingestion is enabled on the target host. |
| Application or receivers to Collector, then agent | You need to gather multiple sources, apply processors, or centralize routing before data reaches Instana. | Run the Collector where it can reach its sources and the selected agent; configure its OTLP exporter for that agent. | Own Collector configuration, processing, availability, and the agent receiving the forwarded data. |
| Collector or application directly to backend | You need direct OTLP delivery and can configure backend authentication, transport, region, and resource identity. | Send to the deployment-specific OTLP acceptor endpoint with TLS and the required credentials and identity. | Protect and rotate the agent key; maintain the regional endpoint, TLS, and identity configuration. |
| Instana Distribution of OpenTelemetry Collector (IDOT) | You want IBM’s distribution to handle Instana-oriented service mapping and infrastructure correlation by default. | Use its configured endpoints and settings for the target Instana backend. | Maintain the IDOT deployment and check its current configuration against your environment. |
Use an agent when it suits the deployment
An Instana agent can receive OTLP traces, metrics, and logs and forward them to the backend. IBM documents default OTLP/gRPC on port 4317 and OTLP/HTTP or HTTPS on port 4318. In the agent ingestion documentation, OTLP ingestion is described as activated by default for host-agent version 1.1.726 or higher; older behavior had it deactivated by default. Treat this as version-sensitive and verify the setting on the agent you deploy.
This route can keep backend credentials and regional endpoint configuration out of each application, but it makes the agent’s reachability and configuration part of the path. If you use a Collector, IBM’s examples send OTLP/gRPC to localhost:4317 with an otlp exporter, or OTLP/HTTP to http://localhost:4318 with otlphttp. The HTTP example is plaintext; do not copy it into production unless the transport is appropriately protected. IBM recommends TLS.
Use a Collector when you need an intermediate stage
A Collector is useful when one process must receive telemetry from multiple applications or receivers, apply processors, or route data to an agent or backend. Put it where it can reach its sources and destination, and decide which component owns filtering, batching, and other processing. An extra hop also creates configuration and availability to operate; it is not inherently required just because Instana is the destination.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use direct backend delivery only with its required settings
Direct OTLP delivery targets the Instana backend’s otlp-acceptor. IBM’s backend ingestion instructions require an x-instana-key agent key and a host identity resource attribute—host.id, faas.id, or device.id—or the documented x-instana-host alternative. The endpoint is specific to the Instana region; identify the correct region in the Instana UI rather than assuming one endpoint works globally. Configure TLS and protect the key as a credential.
IDOT automatically configures required endpoints, authentication keys, resource attributes, and TLS settings according to IBM’s backend-ingestion guidance. A self-configured Collector or application may need those settings supplied explicitly.
Preserve trace continuity across services
For an OpenTelemetry span to join the right request across service boundaries, the participating services must propagate compatible trace context. Instana correlates OpenTelemetry traces with Instana-generated traces using W3C Trace Context, the OpenTelemetry default. IBM documents that Instana’s default context propagator cannot be combined with propagators other than W3C Trace Context. See IBM’s tracing guidance.
- Use W3C Trace Context propagation across OpenTelemetry-instrumented services and services traced by Instana.
- Check that trace and parent context survive each service boundary, especially where instrumentation or propagation settings differ.
- Validate a request that crosses both OpenTelemetry-instrumented and Instana AutoTrace services; confirm its spans appear in one trace rather than as disconnected traces.
IBM lists support for commonly used trace and resource semantic-convention attributes, as well as span events and links. Consistent service and resource identity helps make spans and infrastructure intelligible in the backend; avoid assuming that every custom or newly introduced convention will be mapped identically.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Keep attributes stable and discoverable
Instana represents OpenTelemetry attributes as dynamic or static tags. Dynamic tags are derived from incoming attributes and appear in the call tag catalog; IBM documents a limit of 500 different attribute names in that catalog. This is a limit on distinct names, not on the number of values a stable attribute can carry. Static tags support filtering or grouping by the OpenTelemetry tag or resource-tag key and do not have that catalog limit. IBM’s attribute guidance advises against creating a new attribute name for every user.
Best Value
- Use stable keys such as
customer.idwith varying values rather than generating attribute names from user, request, or tenant values. - Prefer semantic-convention fields where they fit, and keep resource attributes consistent across instances of the same service.
- Choose dynamic tags for attributes that should be available in the call tag catalog; use static tags when filtering or grouping by a stable key is the goal.
Unbounded attribute-key creation can exhaust the documented dynamic-tag name catalog and make analysis harder. High-cardinality values can also complicate filtering; keep keys predictable and send only values that serve a diagnostic purpose.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plan log ingestion and host correlation
IBM documents two OTLP log routes: send logs directly to the backend’s otlp-acceptor, either from the application or through a Collector, or send them through an Instana agent. Log ingestion may require an add-on or additional configuration, so confirm entitlement for your specific plan with IBM. Logs also need host or entity identification. IBM lists resource identities including service.instance.id, container.id, Kubernetes object IDs, and host.id, or the x-instana-host alternative. Consult IBM’s log ingestion documentation for the supported identity fields and deployment details.
Instana’s documented log mapping can explain differences between a source record and what appears in the product: it maps trace ID, span ID, and body without alteration; uses ingestion time for the timestamp it considers; derives log level primarily from SeverityText and falls back to SeverityNumber; and maps attributes as key-value custom tags.
Make log records consistent and avoid host misattribution
IBM recommends consistent timestamps, levels, error codes, and context, and sending only essential logs. Excess volume adds processing, memory, network, retention, and analysis load. Its log best practices recommend configuring a Collector to send logs to an agent on the same host where possible: sending logs from multiple hosts to one agent can cause incorrect host attribution and failed correlation.
- Give log records stable host, container, or Kubernetes identity that matches the telemetry source.
- Keep timestamp, severity, error, and trace-context fields structured consistently.
- Route logs to an agent on the originating host where possible, rather than funneling multiple hosts through one agent.
- Filter unnecessary volume before ingestion when appropriate, while retaining the records needed for diagnosis and compliance.
Validate the integration before relying on it
- Choose the route. Decide whether an agent is the receiver, whether a Collector is needed for sources or processing, or whether direct backend delivery is appropriate.
- Verify destination settings. For an agent route, confirm the OTLP receiver and ports. For direct delivery, confirm the Instana region,
otlp-acceptorendpoint, agent key, TLS, and host identity. - Check resource identity. Send a test trace, metric, and—if entitled—log record with stable service and host or entity attributes. Confirm the expected entity is identified in Instana.
- Test trace propagation. Follow a request across at least one OpenTelemetry-instrumented service and one Instana-traced service, then verify that W3C context joins the spans.
- Inspect mapping and tags. Check whether timestamps, severity, trace IDs, and attributes appear as expected, and make sure attribute names remain stable.
- Exercise failure handling. Check behavior when the Collector or agent is unavailable, and ensure credentials, TLS, and routing are managed by the team responsible for the chosen path.
What changed for older Collector configurations
If an older configuration uses the OpenTelemetry Contrib Collector’s instanaexporter, IBM says that exporter was removed on 8 October 2024. Use an OTLP exporter instead, targeting the Instana agent or backend with the corresponding route’s configuration. IBM’s OpenTelemetry overview documents the removal.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
