Logit.io
Hosted OpenTelemetry on Logit.io
← Back to blog
10/12/2026 · 7 min read

Hosted OpenTelemetry on Logit.io: one OTLP endpoint for logs, traces and metrics

Logit.io Team
Logit.io Team
Technical Content Team

Last updated 10/12/2026

NewsHow To Guides

Plenty of teams sending data to Logit.io already run an OpenTelemetry Collector. Until now, getting its output to us meant wiring up three exporters: the OpenSearch exporter for logs, OTLP to the APM endpoint for traces, and Prometheus remote write for metrics. Each came with its own hostname and credentials. It worked, but it was a lot of YAML to keep in step every time a stack changed.

New Logs stacks now get a hosted OTLP endpoint at {stackId}-otel.logit.io (existing Logs stacks on any plan can turn it on). Logs, traces and metrics all go to that one address, so a single exporter in your Collector config covers everything. The name follows the per-stack endpoints you already know (-es for OpenSearch, -apm for tracing, -vm for metrics), with -otel as the new one.

Contents

Hosted OpenTelemetry means Logit.io runs the OpenTelemetry Collector for you. Each Logs stack gets its own HTTPS endpoint, so your apps can send logs, traces and metrics straight from an OpenTelemetry SDK or zero-code agent, without running a Collector yourself. If you already run a Collector, for host metrics or file logs, just point its OTLP/HTTP exporter at the same endpoint.

What launched

Logs stacks with Hosted OpenTelemetry show a Hosted OpenTelemetry card on the stack's Endpoints page. It lists the HTTPS endpoint, the protocol (http/protobuf), and a username and API key for Basic auth, each with a Copy button. The hosted endpoint accepts OTLP/HTTP over HTTPS on port 443 only. There is no gRPC on the Logit.io side, and ports 4317/4318 are not exposed by Logit.io. Your apps can send to it directly from an OpenTelemetry SDK or zero-code agent. A Collector you already run, or anything else that exports OTLP/HTTP, can send to it too.

New Logs stacks come with the endpoint switched on. Hosted OpenTelemetry is available on every plan. Existing Logs stacks aren't switched on automatically. On the stack's Endpoints page, an account owner or administrator, or a stack administrator, presses Switch on on the Hosted OpenTelemetry card. Setup takes a few minutes, and then the connection details appear. The same Endpoints section has a button to rotate the credentials. Once you rotate, any Collector still holding the old API key stops authenticating until you update it.

The other half of the launch is in the dashboard itself. OpenTelemetry is the featured first option in the new onboarding flow, and its setup steps come with your stack's endpoint, username and API key already filled in, so you don't have to hunt through Integrations for connection details.

Why one endpoint for all three signals matters

The obvious win is less configuration. You maintain one exporter with one set of credentials, and when the API key rotates you change it in one place. If you run strict egress rules, there's a single hostname to allow.

The less obvious win is consistency. When logs, traces and metrics leave the same Collector through the same exporter, they carry the same resource attributes. A service.name or deployment.environment you add with one resource processor lands on every signal, instead of being maintained in separate exporter blocks that slowly drift apart. That's what makes it practical to jump from a slow trace to the logs for the same service without guessing at field names.

It also keeps your instrumentation portable. OpenTelemetry SDKs and the Collector are vendor-neutral, and the only Logit.io-specific part of the setup is the exporter block. That's a big part of why OpenTelemetry is the direction we're taking Logit.io, and why the hosted endpoint is now the default route in rather than an advanced option.

An example Collector config

Here is a complete config that receives OTLP from your applications and forwards all three signals to your stack. Replace the placeholders with the values from the Hosted OpenTelemetry section of your stack's Endpoints page.

extensions:
  basicauth/logit:
    client_auth:
      username: <your-otel-username>
      password: <your-otel-api-key>

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch: {}

exporters:
  otlphttp/logit:
    endpoint: https://<your-stack-id>-otel.logit.io
    auth:
      authenticator: basicauth/logit

service:
  extensions: [basicauth/logit]
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/logit]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/logit]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/logit]

A few notes on what each part does:

  • Receivers are local. Ports 4317 (gRPC) and 4318 (HTTP) are the standard OTLP ports your applications send to on your own Collector. They are not exposed by Logit.io and have nothing to do with the hosted endpoint.
  • The exporter must be otlphttp (not otlp/gRPC), pointed at https://<your-stack-id>-otel.logit.io on port 443. The Collector appends /v1/logs, /v1/traces and /v1/metrics itself, so the same exporter serves all three pipelines.
  • Auth uses the basicauth extension, which ships in the contrib distribution. Run otelcol-contrib or the contrib container image, not the core build.
  • Batching is optional but worth keeping. It cuts the number of requests without changing what arrives.

If you only need to instrument a single service and would rather skip the Collector, most OpenTelemetry SDKs read the standard environment variables. OTEL_EXPORTER_OTLP_ENDPOINT takes the same base URL, OTEL_EXPORTER_OTLP_PROTOCOL should be http/protobuf (gRPC will not work), and OTEL_EXPORTER_OTLP_HEADERS carries the Basic auth header (written as Authorization=Basic%20 followed by the base64 of username and API key). Onboarding shows that value ready-made as the Header credential, so you can copy it rather than encode it yourself. For the wider set of Collector options, the OpenTelemetry Collector configuration reference is the place to look.

Start Free Trial

Unlock complete visibility with hosted ELK, Grafana, and Prometheus-backed Observability

Start Free Trial

What happens to signals with no matching stack

Because one endpoint takes everything, you can easily end up sending a signal your account has nowhere to put. The common case is a Collector that emits traces when there's no APM stack on the account, or metrics without a Metrics stack.

The endpoint accepts that data rather than returning errors to your Collector, but with no APM or Metrics stack there's nowhere to store it, so it's discarded. It isn't discarded silently: the dashboard shows how many traces or metrics arrived without a home and prompts you to add APM or Metrics. Add the matching stack before you rely on that signal.

That means you can roll out one Collector config across every environment on day one and let the dashboard tell you what's missing. You don't need a separate config for teams that haven't bought tracing yet. When you're ready, APM pricing starts at $20/mo and Metrics pricing at $12/mo, both billed annually.

OpenTelemetry in the new onboarding flow

OpenTelemetry is the featured first option in the new onboarding flow on a Logs stack, ahead of Quick start, Linux servers & log files, Applications & code and Containers & Kubernetes. Inside it you'll find Servers & log files (marked Recommended), Applications, Kubernetes, Host metrics, Send a test signal and I already run a Collector.

Each option shows the Endpoint, Username, API key and Header for your stack with Copy buttons, and the config blocks come with those values already in place. If you're running your own Collector, I already run a Collector gives you the extension and exporter to merge into the config above. The older shipper categories now point to their OpenTelemetry equivalent where there is one.

Filebeat, Winlogbeat and the HTTPS JSON API are still in onboarding, and existing shippers keep working as they are. There's no need to rip out a Beats setup that does its job.

Moving from the three-exporter setup

If you followed our earlier OpenTelemetry Collector integration guide, your config probably has opensearch, otlp and prometheusremotewrite exporters, with separate credentials for each. Moving across is mostly deletion:

  1. Add the basicauth/logit extension and the otlphttp/logit exporter from the example above.
  2. Switch one pipeline at a time to the new exporter. Logs is usually the easiest to check first.
  3. Confirm the data is arriving, then remove the old exporter and its auth extension.
  4. Repeat for traces and metrics.

If you run old and new exporters side by side in the same pipeline while you test, expect to see duplicates for that window.

Get started

Already a customer? If the Hosted OpenTelemetry card on your stack's Endpoints page says it's off, switch it on. An account owner or administrator, or a stack administrator, presses Switch on on the Hosted OpenTelemetry card. Setup takes a few minutes, and then the connection details appear. It's available on every plan. Then copy the details into the config above and restart your Collector, or open onboarding and pick OpenTelemetry, the featured first option. New to Logit.io? Logs pricing covers every plan, and Hosted OpenTelemetry is included on all of them.

For more detail on each signal, see the guides to OpenTelemetry for logs, OpenTelemetry for traces and OpenTelemetry for metrics, or read more about OpenTelemetry logging on Logit.io.

Get the latest Elastic Stack & logging resources when you subscribe

Want to see this in action?
Start a free trial and connect logs to your alert workflows.