Configuration

The Collector reads one file, /etc/otelcol/config.yaml. This page explains the default pipelines and how to add an exporter.

Where things live

Path	What it is
/etc/otelcol/config.yaml	The Collector configuration (root and otelcol only, mode 0640)
/var/lib/otelcol/tls/	This instance's certificate and private key
/usr/local/share/sushi/otelcol/cert.pem	Public copy of the certificate, for clients
/var/lib/otelcol/out/telemetry.json	The default local destination
/opt/otelcol/bin/otelcol	The Collector binary
/opt/sushi/evidence/otelcol-components.txt	The components built into this binary

First boot writes config.yaml only if it does not exist yet, so your edits are kept across reboots.

The default pipelines

• Receiver otlp: gRPC on 127.0.0.1:4317 and HTTP on 127.0.0.1:4318, both with this instance's certificate and key.
• Processors: memory_limiter (check every second, limit_mib: 512, spike_limit_mib: 128) and batch (200 ms or 256 items).
• Exporter file: JSON to /var/lib/otelcol/out/telemetry.json, rotated at 32 MB, keeping three backups.
• Extension health_check on 127.0.0.1:13133.
• Pipelines: traces, metrics and logs, each otlp → memory_limiter, batch → file.
• Telemetry: the Collector's own logs at info level, and its metrics on 127.0.0.1:8888.

No redaction by default

The default pipelines pass attributes, log bodies and resource fields through unchanged. Before you send telemetry to a remote backend, remove sensitive data in your instrumentation or with the attributes, resource or filter processors, which this build includes.

See which components are available

Only components built into the binary can be used in the config:

/opt/otelcol/bin/otelcol components

The core build includes, among others, the otlp, otlp_http, kafka, zipkin, prometheus and prometheusremotewrite exporters.

Add an exporter

For example, to send all three signals to another OTLP endpoint over HTTP, add this under exporters:, next to the existing file exporter:

  otlp_http:
    endpoint: https://<your-collector-or-backend>:4318
    sending_queue:
      enabled: true
      queue_size: 1000
    retry_on_failure:
      enabled: true

Then add it to each pipeline that should use it, for example exporters: [file, otlp_http].

The sending queue is kept in memory, so queued data is lost if the Collector restarts. The destination must accept the protocol and authentication this build supports. This build cannot sign requests for AWS services.

Apply changes

sudo nano /etc/otelcol/config.yaml
sudo systemctl restart otelcol
systemctl is-active otelcol

If the service does not come back, the log shows why:

sudo journalctl -u otelcol -n 50 --no-pager

Accept telemetry from other hosts

The receivers listen on 127.0.0.1 only. TLS lets clients verify the server, but the receivers do not authenticate clients: any process that can reach the port can send data. Before you accept remote producers, plan client authentication, for example through a proxy you control, and allow only your own network in the security group. Do not bind the receivers to 0.0.0.0 or open them to the internet.

The walkthrough checks the defaults

demo.sh and the self-test it runs check the image's default settings. After you change the configuration, they can report a failure even when your setup works. Run them on a fresh instance, before you make changes.

Next: Operations.