Output backends

Outputs are the destinations Prelude Collector forwards processed telemetry to after collection and transformation. Each backend is configured independently, can be enabled or disabled on its own, and is hot-reloaded at runtime — there is no need to restart the collector to flip an output on or off. After the first mention this page refers to Prelude Collector as "the collector".

For the conceptual definition see Output in the glossary.

What an Output does

Every Output receives the same Snapshot stream produced by the collection and transform pipeline and forwards it to its backend using the conventions of that backend. The collector publishes to every enabled Output in parallel, so adding a second Output never slows the first one down.

Each backend has its own way of naming records:

Enable or disable an Output

Each backend is configured through the API at /api/v1/outputs/{backend}. Sending a configuration with "enabled": true activates it; sending "enabled": false stops it without losing the saved configuration.

export BASE="https://collector.example.com"
export TOKEN="<your-api-token>"

# Enable NATS
curl -s -X PUT "$BASE/api/v1/outputs/nats" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "config": {
      "url": "nats://nats.example.com:4222"
    }
  }'

# Disable it later without losing the saved config
curl -s -X PUT "$BASE/api/v1/outputs/nats" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": false }'

Bruno: 08 Outputs / Update output config

Sensitive configuration fields (tokens, passwords, auth headers) are encrypted at rest and masked as "********" in API responses. When updating a config, sending "" or "********" for a sensitive field preserves the existing stored value.

Valid {backend} values are nats, influxdb, kafka, prometheus, webhook, and file.

Pick a backend

Each Output below has a "When to use" section that summarizes its sweet spot. For a head-to-head comparison and decision criteria, see Output selection.

Test connectivity

Once an Output is enabled, you can inject a synthetic record straight into the output pipeline (skipping the collection layer) to verify that the backend is reachable. The body is an array of ParsedData envelopes — kebab-case field names (device-id, model-name):

POST /api/v1/outputs/test-output
Authorization: Bearer <your-api-token>
Content-Type: application/json

[
  {
    "device": "router-01",
    "device-id": 1,
    "model-name": "cpu",
    "path": "test",
    "key": "cpu",
    "timestamp": "2024-01-01T12:00:00Z",
    "data-hash": "sha256:test",
    "data": { "usage": 42.5 }
  }
]

The response reports how many records were injected and how many failed:

{ "injected": 1, "failures": 0 }

A maximum of 1000 records can be injected per request.

Inspect runtime metrics

Per-backend success and failure counters are available on a single endpoint:

GET /api/v1/outputs/metrics
Authorization: Bearer <your-api-token>

{
  "nats": {
    "successes": 1024,
    "failures": 0,
    "last-output-at": "2024-01-01T12:00:05Z",
    "last-failure-at": ""
  }
}

Use these counters to confirm an Output is delivering, and to alert when failure rates climb.

API summary

PUT and DELETE both trigger a hot reload — there is no need to restart the collector for either to take effect.

For the complete schema and field-level reference, see the API reference.

See also

• Output selection
• Glossary: Output
• Data flow