New component: NATS as a Receiver and Exporter

[yeongjonglim]

The purpose and use-cases of the new component

NATS is a common tool being deployed as part of an IoT solution thanks to its simplicity to deploy in edge location. Usually the edge location would contain other components that are worth monitoring (for all traces, metrics and logs). On top of that, NATS support data replication from edge to cloud making it a great candidate to stream telemetry data over internet reliably. Here I would like to propose to have a component which export OTLP data to NATS and a receiver to consume the OTLP data from NATS.

Example configuration for the component

receivers:
  nats:
    server_url: nats://localhost:4222
    tls:
      insecure: false
      ca_file: server.crt
      cert_file: client.crt
      key_file: client.key
      min_version: "1.1"
      max_version: "1.2"
    logs:
      subject: telemetry.logs
      encoding: otlp_proto
    metrics:
      subject: telemetry.metrics
      encoding: otlp_proto
    traces:
      subject: telemetry.traces
      encoding: otlp_json
    auth:
      # Option 1: Basic auth
      username: ${env:NATS_USERNAME}
      password: ${env:NATS_PASSWORD}
      # Option 2: Token-based auth
      token: ${env:NATS_TOKEN}
      # Option 3: TLS cert-based auth
      tls:
        cert_file: /etc/otel/certs/client-cert.pem
        key_file: /etc/otel/certs/client-key.pem
        ca_file: /etc/otel/certs/ca.pem
      # Option 4: NKey auth
      nkey: ${env:NATS_NKEY}
      # Option 5: JWT auth
      jwt: {env:NATS_JWT}

exporters:
  nats:
    server_url: nats://localhost:4222
    tls:
      insecure: false
      ca_file: server.crt
      cert_file: client.crt
      key_file: client.key
      min_version: "1.1"
      max_version: "1.2"
    logs:
      subject: telemetry.logs
      encoding: otlp_proto
    metrics:
      subject: telemetry.metrics
      encoding: otlp_proto
    traces:
      subject: telemetry.traces
      encoding: otlp_json
    auth:
      # Option 1: Basic auth
      username: ${env:NATS_USERNAME}
      password: ${env:NATS_PASSWORD}
      # Option 2: Token-based auth
      token: ${env:NATS_TOKEN}
      # Option 3: TLS cert-based auth
      tls:
        cert_file: /etc/otel/certs/client-cert.pem
        key_file: /etc/otel/certs/client-key.pem
        ca_file: /etc/otel/certs/ca.pem
      # Option 4: NKey auth
      nkey: ${env:NATS_NKEY}
      # Option 5: JWT auth
      jwt: {env:NATS_JWT}

processors:
  resource:
    attributes:
      - key: edge_device
        value: junction_123
        action: upsert

service:
  pipelines:
    metrics:
      receivers: [nats]
      processors: [resource]
      exporters: [nats]

Telemetry data types supported

traces, metrics and logs

Code Owner(s)

Looking for a code owner

Sponsor (optional)

Looking for a sponsor — open to guidance from maintainers or anyone involved with NATS

Additional context

No response

[Amoolaa]

Worth mentioning the current licensing situation

https://www.cncf.io/blog/2025/04/24/protecting-nats-and-the-integrity-of-open-source-cncfs-commitment-to-the-community/

[ChrsMark]

Looks like a legit proposal to have these receiver/exporter components. The tough part would be to find code-owners for this.

I'm going to remove the needs triage label now and leave this open to keep the request and the discussion open.

Pinging some NATS folks @ColinSullivan1 @derekcollison @wallyqs in case they are interested.

[ColinSullivan1]

Very cool. Thanks for reaching out. I may be able to contribute some time on this in late June / July. I've looked through a few of the exporters and receivers - would there be a particular receiver and producer that you would suggest looking at as an example?

[ChrsMark]

I think a good example would be kafkareceiver and kafkaexporter :)