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.

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.

When you send OTel data to MultiTool only the fields required for analysis are extracted and all other data is ignored. This means you can forward your existing telemetry without modification. MultiTool does not require a custom schema, and it does not interfere with your current observability pipeline.

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
• Deployment environments follow a defined naming convention
• Service versions are attached to telemetry consistently

These conventions ensure that observability data is interpretable across tools and systems.

What MultiTool expects

MultiTool relies on these semantic conventions to understand your application. In particular, MultiTool expects the following attributes to be present in your telemetry:

• Service version (e.g. release or revision identifier)
• Deployment environment (e.g. production, staging)
• HTTP response status code

These fields provide the minimum context needed to analyze behavior across versions and environments. If these attributes are missing or inconsistently defined, MultiTool cannot reliably interpret your data.

How MultiTool uses this data

MultiTool uses semantically consistent 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 (e.g. success vs. error) can be accurately classified, and trends can be compared across releases. This allows MultiTool to establish a baseline of normal behavior and detect when new traffic deviates from that baseline.

For example, if error rates increase or response patterns shift for a new version, MultiTool can identify this as a potential regression and trigger an alert. Without semantic conventions, this analysis would not be possible. MultiTool would not be able to distinguish between versions, interpret response outcomes, or identify which signals correspond to meaningful metrics.

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