Fly.io

This guide configures logs. Replace YOUR_INGEST_KEY with your key on your server, never in a public example.

1. Install Fly Log Shipper in your organization

Keep the shipper private. Preserve the supplied NATS source and transforms. Select the application/region SUBJECT you intend to collect. Review and pin the shipper revision before deployment.

git clone https://github.com/superfly/fly-log-shipper.git
cd fly-log-shipper
fly launch --no-deploy

2. Append an HTTP sink to vector.toml

The official shipper configuration uses the log_json transform. Preserve it and its NATS source when adding this sink. Store the key as a Fly secret and use Vector environment substitution in production. Keep a single NATS consumer queue for replicas to avoid duplicate logs.

[sinks.siteqwality]
type = "http"
inputs = ["log_json"]
uri = "https://otlp.siteqwality.com/ingest"
method = "post"
encoding.codec = "json"
framing.method = "newline_delimited"
batch.max_bytes = 1000000
[sinks.siteqwality.request.headers]
Authorization = "Bearer YOUR_INGEST_KEY"
"Content-Type" = "application/x-ndjson"
"X-Service" = "my-service"
"X-Env" = "production"

3. Deploy the shipper configuration

Inspect fly logs for sink errors and open Logs in Site Qwality. Add the private Vector health check from Fly documentation so a stalled shipper is visible.

fly deploy --file-local="/etc/vector/vector.toml=./vector.toml"

See your data

Open Logs, Traces or Metrics. New data usually shows up within a minute, and a page that says it is waiting for data switches to your data on its own. Nothing arriving? See what each status code means in failure handling.

Production checklist

Store the key in your platform secret mechanism, rotate it when exposed and remove test keys. Set a stable service.name and deployment.environment.name; avoid user IDs or unbounded values in metric labels. Prefer a persistent queue, bounded retries and exporter failure monitoring. Review redaction and processors before increasing traffic.