OpenTelemetry is the CNCF-backed standard for collecting traces, metrics, and logs from applications and infrastructure in a vendor-neutral way. The OpenTelemetry Collector is the agent and pipeline component — it receives telemetry over OTLP, Jaeger, Zipkin, or Prometheus scrape, applies processors such as batching and attribute transformation, and exports to backends like Jaeger, Prometheus Remote Write, or any commercial observability platform. Running the Collector as a systemd service on RHEL 8 gives you a durable, restart-safe telemetry pipeline for all workloads on the host. This tutorial walks through installation, configuration, and a working end-to-end trace flow.

Prerequisites

  • RHEL 8 server (or AlmaLinux 8 / Rocky Linux 8) with sudo access
  • At least 512 MB RAM; 1 GB recommended for production collector workloads
  • An observability backend reachable from the server — this tutorial uses Jaeger all-in-one (see the Jaeger tutorial) for traces and a Prometheus-compatible endpoint for metrics
  • Ports 4317 (OTLP gRPC) and 4318 (OTLP HTTP) open if remote applications will push to this collector
  • curl and tar installed

Step 1 — Download the OpenTelemetry Collector Binary

The OpenTelemetry project publishes pre-built binaries for Linux/amd64. The otelcol-contrib distribution includes all community receivers and exporters; the core otelcol binary is smaller but has fewer connectors. Choose contrib for flexibility.

OTEL_VERSION="0.102.1"

curl -LO "https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v${OTEL_VERSION}/otelcol-contrib_${OTEL_VERSION}_linux_amd64.tar.gz"

tar xzf otelcol-contrib_${OTEL_VERSION}_linux_amd64.tar.gz

sudo mv otelcol-contrib /usr/local/bin/otelcol
sudo chmod +x /usr/local/bin/otelcol
otelcol --version

Step 2 — Create the Configuration File

Create the configuration directory and write a pipeline that receives OTLP traces and Prometheus scrapes, batches data, then exports to Jaeger over gRPC and to a Prometheus Remote Write endpoint. Adjust the endpoint addresses for your environment.

sudo mkdir -p /etc/otelcol

sudo tee /etc/otelcol/config.yaml > /dev/null <<'EOF'
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: "0.0.0.0:4317"
      http:
        endpoint: "0.0.0.0:4318"
  prometheus:
    config:
      scrape_configs:
        - job_name: "otelcol-self"
          scrape_interval: 30s
          static_configs:
            - targets: ["localhost:8888"]

processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
  memory_limiter:
    check_interval: 1s
    limit_mib: 256

exporters:
  otlp/jaeger:
    endpoint: "localhost:14250"
    tls:
      insecure: true
  prometheusremotewrite:
    endpoint: "http://localhost:9090/api/v1/write"
  logging:
    verbosity: normal

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/jaeger, logging]
    metrics:
      receivers: [prometheus]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite, logging]
EOF

Step 3 — Create a systemd Service

Run the collector under a dedicated system user so it does not require root at runtime. Create the user, then write a systemd unit file.

sudo useradd --system --no-create-home --shell /sbin/nologin otelcol

sudo tee /etc/systemd/system/otelcol.service > /dev/null <<'EOF'
[Unit]
Description=OpenTelemetry Collector
After=network.target

[Service]
Type=simple
User=otelcol
ExecStart=/usr/local/bin/otelcol --config /etc/otelcol/config.yaml
Restart=on-failure
RestartSec=5s
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now otelcol
sudo systemctl status otelcol

Step 4 — Configure an Application to Send Traces via OTLP

Any OpenTelemetry-instrumented application can send traces to the collector by setting the OTLP endpoint environment variable. The example below shows a Python application using the opentelemetry-sdk and opentelemetry-exporter-otlp packages.

# Install the SDK and OTLP exporter
pip install opentelemetry-sdk opentelemetry-exporter-otlp-proto-grpc

# Set the collector endpoint before running your app
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
export OTEL_SERVICE_NAME="my-python-app"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment=production"

# Run your instrumented application (example: a Flask app with auto-instrumentation)
pip install opentelemetry-instrumentation-flask
opentelemetry-instrument python app.py

For a Go application, set the same environment variables before running the binary. The OpenTelemetry Go SDK reads OTEL_EXPORTER_OTLP_ENDPOINT automatically when using the environment-variable exporter configuration.

Step 5 — Verify the Pipeline and View Spans in Jaeger

Check the collector logs to confirm spans are being received and exported without errors, then open the Jaeger UI to search for traces from your service.

# Tail the collector logs in real time
sudo journalctl -u otelcol -f

# Check the collector's own Prometheus metrics endpoint
curl -s http://localhost:8888/metrics | grep otelcol_receiver_accepted_spans

# Verify the collector configuration is valid
otelcol validate --config /etc/otelcol/config.yaml

Open the Jaeger UI at http://<your-server-ip>:16686. In the search panel, select your service name from the Service dropdown and click Find Traces. Each trace shows the full span tree with timing, tags, and log events attached during processing.

Conclusion

You have installed the OpenTelemetry Collector contrib distribution on RHEL 8, written a multi-pipeline configuration that accepts OTLP traces and Prometheus metrics, deployed it as a systemd service under a least-privilege account, and confirmed that span data flows through to a Jaeger backend. The Collector’s processor chain — memory limiter followed by batcher — protects the host from memory spikes during traffic bursts while improving export efficiency. You can extend this pipeline at any time by adding additional receivers (Jaeger, Zipkin, Kafka) or exporters (Elasticsearch, Datadog, OpenSearch) without changing application code.

Next steps: Sending Logs to OpenSearch via the OpenTelemetry Collector, Building a Tail-Sampling Processor for High-Volume Traces, and Instrumenting a Go Microservice with the OpenTelemetry SDK.