Skip to main content
The pages in this section show you how to instrument your application with the OpenTelemetry SDK to send logs, metrics, and traces to Bronto over OTLP/HTTP. The recommended setup enables all three signals: bridge your existing logging framework, record measurements through a meter provider, and create spans through a tracer provider.

​
Two ways to instrument

With the OpenTelemetry SDK. Add a dependency and a short initialisation block to each service — or, in Java, Kotlin, PHP, and Erlang/Elixir, attach an agent or set a few environment variables and skip the code entirely. This gives you all three signals, custom attributes, and spans around your own business logic. It requires a redeploy per service. That is what the language guides below cover. With eBPF, and no code at all. OpenTelemetry eBPF Instrumentation (OBI) attaches to already-running processes and captures HTTP and gRPC traffic from the kernel — producing distributed traces and RED metrics with no SDK, no code change, and no redeploy. It sees the process boundary rather than what happens inside it, so there are no custom attributes and no logs. The two are complementary and share one OTLP pipeline into Bronto, with matching trace IDs. A common pattern is eBPF for immediate breadth across every service, then an SDK in the services that warrant deeper detail.
Bronto supports OTLP sums, gauges, summaries, and explicit histograms. Exponential histograms are not supported. The Metric Explorer also does not currently provide a Rate function.
Want to see Bronto with real data before instrumenting your own app? Try Bronto with the OpenTelemetry Demo — spin up a sample microservices app and route its logs, metrics, and traces into Bronto in minutes.
Calling an LLM (OpenAI, Anthropic, Amazon Bedrock, etc.)? Every language page below also has a GenAI semantic conventions section covering gen_ai.* spans — auto-instrumentation where it exists, manual spans where it doesn’t, and the experimental prompt/response capture flags. See LLM Observability for how Bronto surfaces that data.

​
Choose your language

Python

Python

.NET

.NET

Java

Java

Kotlin

Kotlin

Node.js / JavaScript

Node.js

Go

Go

Ruby

Ruby

PHP

PHP

Erlang / Elixir

Erlang / Elixir

Rust

Rust

C++

C++

Swift

Swift

​
How OTel logging works

OpenTelemetry provides a Log Bridge API. You attach an OTel handler or appender to your existing logging framework — Logback, Python’s logging, ILogger, Winston, and so on. Every log record your application emits passes through the bridge, which enriches it with structured metadata and forwards it to the OTel exporter. Nothing in your application code changes. logger.info(), log.warn(), console.log() — all of these keep working exactly as before.

​
What the bridge adds

Here is the same log event before and after the bridge:
The trace_id and span_id were injected automatically because this log was emitted inside a traced request. The service.name and service.namespace were set once at application startup and are now attached to every log record — no per-statement boilerplate.

​
Why it’s worth adopting

Automatic trace correlation When a log is emitted inside a traced request, the active trace_id and span_id are injected automatically — no manual MDC propagation or context threading needed. In Bronto, trace_id is a queryable field. Click it to jump from a log line directly to the corresponding trace. Structured by default Every OTel log record follows a defined schema: timestamp, severity, body, attributes, resource, and instrumentation_scope. Not “structured if you remembered to configure JSON output” — structured unconditionally, in a format Bronto understands natively. Service identity is automatic service.name and service.namespace are Resource attributes — set once at SDK initialisation, then attached to every log record that process emits. You do not add them to individual log statements. In Bronto, they map directly to Dataset and Collection with no extra configuration. Semantic conventions OTel defines standard attribute names across all languages: http.request.method, exception.type, db.system, user.id, and hundreds more. When all your services use the same attribute names, your Bronto queries work identically regardless of which language or framework emitted the log. One pipeline for logs, metrics, and traces Logs, metrics, and traces all flow through the same OTel SDK and Collector. They share one API key and resource identity while using a signal-specific OTLP endpoint. You can enable any subset of signals if a service does not need all three. Vendor portability OTLP is an open standard. Switching your observability backend requires changing one endpoint URL, not rewriting instrumentation. Zero code churn Adoption is a configuration change, not a refactor. Existing log statements are untouched.

​
How OTel concepts map to Bronto

No Bronto-specific SDK attributes are needed. Standard OTel Resource attributes are sufficient.

​
Endpoints

All requests require the header x-bronto-api-key: <YOUR_API_KEY>. See API Keys for how to create one.

​
Two ways to get data into Bronto

Your application exports to an OTel Collector reachable in its environment, which batches, filters, and forwards to Bronto. The Collector can enrich attributes, route signals to multiple destinations, and apply sampling rules before data leaves your infrastructure. Best for: multi-service environments, existing Collector infrastructure, or pipelines that need transformation or fan-out before ingestion.
See Connect Open Telemetry to Bronto for Collector setup.

​
Direct export

The OTel SDK inside your application exports logs, metrics, and traces directly to Bronto over OTLP/HTTP. No additional components are required. Best for: new projects, simple architectures, or teams that want the least possible operational overhead.

​
Send only the signals you need

The examples in these guides enable logs, metrics, and traces by default. OpenTelemetry configures exporters and pipelines per signal, so you can omit any exporter, provider, or Collector pipeline you do not need. See Send Metrics to Bronto and Send Traces to Bronto for signal-specific reference material.