How MultiTool uses OpenTelemetry

OpenTelemetry is an open standard from the Cloud Native Computing Foundation for generating, collecting, and exporting observability data. It is supported across all major programming languages and provides a consistent way to work with traces, metrics, and logs. The specification is broad and well-tested, so most applications can adopt it without running into edge cases or gaps in support. Because it's an open standard, organizations can adopt it without vendor lock-in.

MultiTool uses OpenTelemetry (OTel) as its ingestion layer. Any service that emits OTel data can send that data directly to MultiTool. There is no need to adopt a custom SDK or change your instrumentation strategy.

Using your existing telemetry

MultiTool is designed to work with the telemetry you already produce. OTel defines a transport protocol called OTLP, which specifies how telemetry data is encoded and transported over HTTP or gRPC. MultiTool runs an OTLP server that ingests OTel data directly from running services, and maps your data to your account using the API key attached to the OTel request.

When you send OTel data to MultiTool, only the fields required for analysis are extracted; all other data is ignored. You can forward your existing telemetry without modification.

If you already run an OTel collector, you can use it alongside MultiTool with minimal overhead. Collection happens once in your application, and the batch processor built into the OTel library of your programming language sends the data to two destinations instead of one: MultiTool in addition to your existing observability provider.

Semantic conventions

OpenTelemetry allows flexibility in how data is structured, but it also defines a set of recommended standards called semantic conventions. Semantic conventions establish consistent names and formats for commonly used fields. For example:

• HTTP response codes are recorded using standard attribute names, and successful responses (e.g. 2XX response codes) are distinguished from unsuccessful ones (e.g. 4XX or 5XX).
• Deployment environments and service versions are attached to telemetry consistently.
• Metrics like CPU utilization distinguish between container CPU and host CPU, to avoid conflation.

These conventions make observability data interpretable across tools and cloud providers.

What MultiTool expects

MultiTool relies on these semantic conventions to understand your application. The following attributes must be present in your telemetry:

• Service name: whatever you call this particular service within your company or organization.
• Service version: a unique release or revision identifier.
• Deployment environment: the name of the environment in which the service is deployed, e.g. production or staging.
• API key: the OTLP collector rejects requests that are not from authorized users.

These fields uniquely identify a deployment of a particular service. Without them, MultiTool cannot tell which deployment a piece of telemetry belongs to.

MultiTool also expects OTel traces to include the http.response.status_code field set on server spans. Most telemetry libraries take care of this for you. Together, these fields provide the minimum context needed to analyze behavior across versions and environments. If they are missing or inconsistently defined, MultiTool cannot reliably interpret your data and cannot provide accurate alerts.

How MultiTool uses this data

MultiTool uses telemetry to build a model of your service's behavior. Because key fields are standardized, metrics can be grouped by version and environment, request outcomes can be classified accurately, and trends can be compared across releases. This is what allows MultiTool to establish a baseline of normal behavior and detect when new traffic deviates from it.

For example, if error rates increase or response patterns shift for a new version, MultiTool identifies the change as a potential regression and triggers an alert. Without semantic conventions, this analysis would not be possible: MultiTool would have no reliable way to distinguish between versions, interpret response outcomes, or identify which signals correspond to meaningful metrics.

Building on OpenTelemetry and its semantic conventions means MultiTool avoids requiring custom instrumentation while still enabling deep analysis. You keep full control over your observability pipeline, and MultiTool can still identify real production issues.