opentelemetry-application-insights

opentelemetry-application-insights is a Rust exporter crate that plugs into the OpenTelemetry Rust SDK and sends traces, metrics, and logs to Azure Application Insights using its public ingestion protocol. It converts OpenTelemetry spans into Application Insights Request and RemoteDependency envelopes, maps span events to Exception and Message telemetry, and applies Application Insights’ own semantic conventions (roles, instance IDs, operation IDs) via resource and tag mapping.

The crate is transport-agnostic: consumers supply their own HttpClient implementation (via opentelemetry-http, with reqwest support built in) so it works across sync and async runtimes including Tokio. Uploads are gzip-compressed, batched, and retried with exponential backoff against Application Insights’ quota and throttling responses (429, 439, 503). An optional live-metrics feature streams near-real-time telemetry to the Live Metrics view, reporting process-level CPU and memory alongside request/dependency/exception counts.

Because it targets one external service’s ingestion API rather than a general-purpose backend, it functions as an SDK layer on top of the vendor-neutral OpenTelemetry SDK — letting Rust services standardize on OpenTelemetry instrumentation while still shipping telemetry to an existing Azure Monitor setup.

What You Get

• An Exporter that implements OpenTelemetry’s SpanExporter, PushMetricExporter, and log exporter traits, constructed from an Application Insights connection string or environment variable.
• Automatic mapping of span kinds to Application Insights Request (server/consumer spans) or RemoteDependency (client/producer/internal spans) telemetry, plus span events mapped to Exception and Message data.
• Gzip-compressed, exponential-backoff retry logic tuned to Application Insights’ specific throttling and quota status codes (408, 429, 439, 503).
• Pluggable HTTP transport via opentelemetry-http, so the exporter works with any async runtime instead of hard-coding one HTTP client.
• An optional live-metrics feature that streams live request/dependency/exception counts and process CPU/memory to the Application Insights Live Metrics view.
• Feature-gated trace, metrics, and logs support so consumers can compile in only the telemetry signals they use.

Common Use Cases

• Instrumenting a Rust web service with OpenTelemetry and routing the resulting traces, metrics, and logs into an existing Azure Application Insights resource without a separate collector.
• Migrating a Rust application off Application Insights’ now-legacy SDK onto standard OpenTelemetry instrumentation while keeping the same Azure Monitor backend.
• Watching live request/dependency/exception activity for a Rust service in the Application Insights Live Metrics stream during a deployment or incident.
• Running a Rust service across mixed async runtimes (Tokio, current-thread, etc.) where the exporter’s transport-agnostic HTTP client model avoids locking the whole app into one runtime.

Under The Hood

Architecture The crate is organized around a single Exporter<C> struct (generic over an HttpClient) implemented across trace.rs, metrics.rs, and logs.rs, each converting its respective OpenTelemetry SDK type into models::Envelope structures defined in src/models/. convert.rs and tags.rs hold the shared attribute-to-property and resource-to-tag mapping logic reused by all three signal types, while uploader.rs and uploader_quick_pulse.rs own the actual HTTP upload path (batching, gzip, retry) separately from telemetry construction — a clean separation between “build the envelope” and “ship the envelope” that would let either half change independently. connection_string.rs isolates parsing of the Application Insights connection-string format (ingestion endpoint, instrumentation key, live endpoint) behind its own FromStr implementation and typed ParseError, and quick_pulse.rs implements the live-metrics protocol as a distinct span processor rather than folding it into the main trace path.

Tech Stack Built against opentelemetry, opentelemetry-sdk, and opentelemetry-http (0.32-series APIs) with opentelemetry-semantic-conventions for attribute keys. HTTP transport is abstracted through opentelemetry-http’s HttpClient trait, with reqwest as the exercised concrete client in examples and tests. Retries use the backon crate’s ExponentialBuilder with a futures-timer sleeper; payloads are compressed with flate2, serialized via serde/serde_json/serde_repr, and errors are typed with thiserror. The optional live-metrics feature pulls in sysinfo for process CPU/memory sampling and futures-util for stream handling. Development relies on insta for snapshot testing, test-case for parameterized tests, and tokio as the async runtime under test.

Code Quality The crate has a real test suite: tests/http_requests.rs builds full OpenTelemetry pipelines against a recording HTTP client and asserts against insta snapshots of the exact wire payloads sent for traces, logs, metrics, live metrics, and resource-attribute variants — a strong way to catch accidental protocol regressions. CI (ci.yml) builds each feature combination individually (trace-only, logs-only, metrics-only) in addition to --all-features, runs cargo fmt --check and cargo clippy, and a separate job checks external type leakage via cargo_check_external_types against an explicit allowlist in Cargo.toml. Errors are modeled through a dedicated thiserror-based Error enum and a ParseError enum for connection-string parsing rather than stringly-typed failures. Doc-comment density is uneven — core files like lib.rs, trace.rs, and quick_pulse.rs are well documented (including runnable doctests), while conversion and mapping modules carry fewer inline comments.

API Design The public surface is small and intentional: construct an Exporter from a connection string or APPLICATIONINSIGHTS_CONNECTION_STRING env var, hand it to the standard OpenTelemetry TracerProvider/MeterProvider/LoggerProvider builders, and everything downstream uses ordinary OpenTelemetry APIs. There’s no custom pipeline builder to learn — a past major version removed one in favor of configuring providers directly, which lines up the crate with how the rest of the OpenTelemetry Rust ecosystem is configured. Feature flags (trace, metrics, logs, live-metrics, internal-logs) let consumers opt into only what they need, and the crate ships nine runnable examples covering attributes, multiple HTTP client setups, logs, metrics, and live metrics, which meaningfully lowers the barrier to a first working integration despite the fairly involved OpenTelemetry provider setup required upstream.