Ship logs from fly to other providers using NATS and Vector
In this repo you will find various Vector Sinks along with the required fly config. The end result is a Fly.IO application that automatically reads your organisation logs and sends them to external providers.
Quick start
Create a new fly logger app based on our docker image
Thats it - no need to setup NATs clients within your apps, as fly apps are already sending monitoring information back to fly which we can read.
However for advanced uses you can still configure a NATs client in your apps to talk to this NATs server. See NATS
NATS source configuration
Secret
Description
ORG
Organisation slug (default to personal)
ACCESS_TOKEN
Fly personal access token (required; set with fly secrets set ACCESS_TOKEN=$(fly auth token))
SUBJECT
Subject to subscribe to. See [[NATS]] below (defaults to logs.>)
QUEUE
Arbitrary queue name if you want to run multiple log processes for HA and avoid duplicate messages being shipped
After generating your fly.toml, remember to update the internal port to match the vector internal port
defined in vector-configs/vector.toml. Not doing so will result in health checks failing on deployment.
The subject schema is logs.<app_name>.<region>.<instance_id> and the standard
NATS wildcards can be used.
In this app, the SUBJECT secret can be used to set the subject and limit the scope of the logs streamed.
Queue
If you would like to run multiple vm's for high availability, the NATS endpoint supports
subscription queues to ensure messages are only sent to one
subscriber of the named queue. The QUEUE secret can be set to configure a queue name for the client.
Vector
The nats source component sends logs to other downstream transforms and sinks in the Vector config.
This processes the log lines and sends them to various providers.
The config is generated from a shell wrapper script which uses conditionals on environment variables to
decide which Vector sinks to configure in the final config.