How do I connect OpenTelemetry log records to Tares?

Tares receives OpenTelemetry log records through its otlp connector. You create one otlp source, mark the service label as primary, and point your exporter at the Tares endpoint. One source takes logs, traces and metrics from every service, and the resource attribute service.name becomes the service label, so each service’s logs line up on one timeline.

How it works

The otlp connector is a push connector. Your app or OpenTelemetry Collector sends OTLP/HTTP to Tares, and Tares listens at these paths:

• /v1/logs for log records
• /v1/traces for spans
• /v1/metrics for metric points

The connector has no fields of its own, only the universal labels array. Resource attributes are available as label fields, and service comes from service.name. When you mark service as the primary label, it becomes the key. Logs from the same service then correlate with every other source you key the same way, such as metrics, alerts and deploys.

OTLP/gRPC is optional. It needs the otlp-grpc extra, and the receiver then listens on port 4317. You can change that port with TARES_OTLP_GRPC_PORT, or set it to off to disable the receiver.

The OpenTelemetry (OTLP) connector page has the full reference. The connectors index lists the other ways to get logs in: Docker logs by container, Vercel through a log drain, and any other JSON sender through the webhook connector.

Set it up

1. Start Tares and open the console.

   tares up

2. Create the source. You have three options:

   • Console: go to Sources → Add source → otlp. No config is required. Add the service label and save.
   • Agent: ask a connected agent, “Use tares to create an OTLP source keyed by service.” The agent calls create_source.
   • YAML or API: declare the source in your catalog, or POST /api/sources with the same object.

   - name: otel
     connector: otlp
     config:
       labels:
         - { name: service, field: service, primary: true }

3. Point your exporter at Tares. For OTLP/HTTP, set the endpoint to the Tares address. For gRPC, install the extra with pip install 'tares[otlp-grpc]' and use port 4317.

   OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:8787   # OTLP/HTTP → /v1/{logs,traces,metrics}
   # or gRPC (otlp-grpc extra): OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

4. If your Tares instance runs with auth on (tares up --auth), the exporter sends an Authorization header with a Bearer value holding an ingest-scoped API key. You can set it through OTEL_EXPORTER_OTLP_HEADERS. Without auth, no header is needed.

5. Check that records arrive. Open the source and look at Recent events, which shows spans, logs and metric points as they come in. Then open Explore and look for your services under the service key. If a service is missing, check that its exporter sets service.name.

What you get

• Every service that exports OTLP shows up under the service key with no per-service setup.
• Log records, spans and metric points from one service sit on one timeline in Explore.
• The same service key joins the OpenTelemetry logs with your Prometheus metrics, alerts and deploy events, so an agent reads one correlated timeline. The AI SRE guide builds this end to end, with OTLP as one of the log options.
• Triggers can watch the otlp source like any other, and a connected agent can read the logs through the MCP endpoint.
• The source is set up the same way in the console, through an agent, or as YAML, and all three produce the same stored config.

When something else fits

• If your logs live in a running container and are not instrumented with OpenTelemetry, the Docker logs connector tails the container directly. For a Vercel project, a log drain pointed at a Tares ingest URL fits better.
• If a system only posts plain JSON and has no OTLP exporter, use the webhook connector. The connectors index compares all the options.

Related