How do I confirm lines from OpenTelemetry log records are arriving in Tares?

Open the otlp source’s Recent events in the Tares console to see log records as they arrive, then read the service from an agent. Explore lists each service under the service key, so a service that appears there is sending data. The agent read returns the same lines on the service’s timeline.

How it works

The OpenTelemetry (OTLP) connector receives OTLP/HTTP logs, traces and metrics. One source ingests every service. Resource attributes such as service.name become labels, so everything your SDK or Collector exports correlates by service with no per-service setup.

Three places in the console and the agent surface show you that data arrived:

• Recent events on the source shows spans, logs and metric points as they arrive.
• Explore lists services under the service key. A service appears once an event carrying its service.name has landed.
• An agent reading the service gets its log lines merged on the service’s timeline, alongside any other sources keyed by service.

A label reads its value by path. Use resourceAttributes.<key> for resource attributes, attributes.<key> for log record attributes, and text for the log line. There is no bare service field, so a label written as field: service gets no value from an OTLP event and the service never shows up under the service key.

Set it up

1. Create the source. In the console go to Sources → Add source → otlp and save. There is no required config, but add a service label as the primary key. The equivalent YAML is:

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

2. Point your exporter at Tares. For OTLP/HTTP, logs go to the /v1/logs path on the daemon:

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

3. If Tares has auth on, the exporter sends a Bearer Authorization header holding an ingest-scoped API key. Without auth on, no key is needed. For gRPC, install the otlp-grpc extra first. The receiver listens on port 4317.

4. Generate a few log records from your app, then open the otlp source in the console and check Recent events. Log records appear as they arrive. If the list stays empty, recheck the endpoint, the protocol (HTTP or gRPC) and the key.

5. Open Explore and look under the service key. Your service name from service.name should be listed. Pick it to see its timeline with the log lines.

6. Read the service from an agent. Start Tares and the MCP endpoint, connect your MCP client, then ask for the service:

tares up
tares mcp

Ask something like: “Use tares: what happened to api-server in the last 15 minutes?” Replace api-server with your own service name. The client calls read for that service and answers from the correlated timeline. Your log lines show up there in order. The AI SRE guide shows this read against a full set of sources.

What you get

• Confirmation at the source level: Recent events shows each record as Tares receives it.
• Confirmation at the service level: Explore lists the service under the service key, so you know the label resolved.
• Confirmation at the agent level: the read returns your log lines on the service’s timeline, which is what an agent works from during an investigation.
• A quick way to spot a bad label. If events show up in Recent events but the service is missing from Explore, the label path is wrong. Use resourceAttributes.service.name, not service.

When something else fits

If you also want to check traces or metrics, the same source and the same Recent events view cover them. If your system does not speak OpenTelemetry, pick another entry from the connectors index, such as webhook for anything that can POST JSON, and verify it the same way.

Related