/docs/collector-quickstart
OTLP HTTP + gRPC, x-api-key
free plan / 1 gb-mo
telemtra.io
// collector guide

OpenTelemetry Collector quickstart
for Telemtra.

Forward standard OTLP logs, traces, and metrics from your services to Telemtra in under two minutes. No proprietary SDK, no agent - just the OpenTelemetry Collector with an otlp/telemtra exporter.

When to use the OpenTelemetry Collector with Telemtra

Use this configuration when your services already emit OpenTelemetry logs, traces, or metrics and you want a Collector in front to batch, retry, enrich, and forward telemetry to Telemtra. The Collector also lets you run side-by-side with another observability backend during migration — see Run alongside another backend.

If you have a single language to wire and no Collector yet, the quickstart covers Python, Node.js, Go, Java, .NET, Rust, Docker, and Kubernetes paths that talk to Telemtra directly without a Collector hop.

OpenTelemetry Collector config for Telemtra

Save the YAML below as config.yaml. It exposes OTLP receivers on the standard ports (4317 gRPC, 4318 HTTP), keeps memory bounded with memory_limiter, batches before export for efficiency, and ships everything to Telemtra over the otlp/telemtra exporter authenticated with your workspace API key.

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

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    timeout: 1s
    send_batch_size: 1024

exporters:
  otlp/telemtra:
    endpoint: ingest.telemtra.io:443
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/telemtra]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/telemtra]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/telemtra]

Collector environment variables

The otlp/telemtra exporter reads the API key from $${env:TELEMTRA_API_KEY} at start — keep the key out of the YAML file so the config is safe to commit to version control. Export it in the shell, your systemd unit, the container env, or a Kubernetes Secret.

export TELEMTRA_API_KEY=tk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Run the Collector and send your first span

Two common launch paths: a local binary for development and a container for production. Both read the same config.yaml from above.

# Local binary (otelcol-contrib)
otelcol-contrib --config config.yaml

# Docker
docker run --rm \
  -e TELEMTRA_API_KEY \
  -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml \
  -p 4317:4317 -p 4318:4318 \
  otel/opentelemetry-collector-contrib:latest

Point any OpenTelemetry SDK at the Collector's OTLP port (localhost:4317 for gRPC, localhost:4318 for HTTP). Within a few seconds your first span lands in the Telemtra workspace under Traces, and the Service Map draws the first edge as soon as two services exchange a request.

Run alongside another observability backend

The Collector supports multiple exporters in the same pipeline. Add the otlp/telemtra exporter next to your existing one and your telemetry fans out to both backends — useful for evaluating Telemtra side-by-side before cutting over.

exporters:
  otlp/telemtra:
    endpoint: ingest.telemtra.io:443
    headers:
      x-api-key: ${env:TELEMTRA_API_KEY}
  otlp/current-backend:
    endpoint: otlp.your-current-vendor.com:4317
    headers:
      authorization: ${env:CURRENT_VENDOR_TOKEN}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/telemtra, otlp/current-backend]

OpenTelemetry Collector best practices

  • Set a stable service.name and deployment.environment on each emitting service before telemetry leaves your network. Telemtra groups, filters, and scopes by these resource attributes.
  • Always run memory_limiter before batch in production. The Collector drops samples gracefully when memory is tight instead of OOM-killing the host.
  • Keep API keys in environment variables or a secret manager — never in checked-in YAML.
  • Start with all three pipelines (traces, logs, metrics), then disable any signal you do not need.
  • For long-running production, set sending_queue.enabled: true and retry_on_failure.enabled: true on the otlp/telemtra exporter so transient network failures buffer instead of dropping.
  • Use Data Shaper rules on the Telemtra side to drop noisy fields after they arrive — keep Collector configs lean.

Next steps