Vector’s hot reload feature lets you update its configuration without taking down the agent and losing data.
Let’s see it in action. Imagine you have a Vector agent running, collecting logs from your application.
# vector.toml
[sources.app_logs]
type = "file"
include = ["/var/log/myapp.log"]
[transforms.parse_json]
type = "remap"
inputs = ["app_logs"]
source = '''
.message = parse_json(.message)
'''
[sinks.stdout]
type = "console"
inputs = ["parse_json"]
target = "stdout"
This config reads from /var/log/myapp.log, parses each line as JSON, and prints it to the console. Now, suppose you want to change the sink to write to a file instead of stdout. You could stop Vector, edit vector.toml, and restart it. But with hot reload, you can skip the downtime.
Here’s how you’d trigger it. First, make sure your vector.toml is being watched for changes. This is typically enabled by default in most setups. If not, you’d add watch = true to the [global_options] section of your configuration.
[global_options]
watch = true
Now, let’s modify the sink section to write to a file:
# vector.toml (after change)
[sources.app_logs]
type = "file"
include = ["/var/log/myapp.log"]
[transforms.parse_json]
type = "remap"
inputs = ["app_logs"]
source = '''
.message = parse_json(.message)
'''
[sinks.file_output] # Changed sink name and type
type = "file"
inputs = ["parse_json"]
path = "/var/log/vector_output.log"
mode = "append"
Save this file. If Vector is running with watch = true, it will detect the change. You’ll see a log message from Vector indicating it’s reloading the configuration.
2023-10-27T10:00:00.123Z INFO vector: Configuration reloaded successfully.
The agent has now switched to writing to /var/log/vector_output.log without dropping a single log line.
The core problem Vector’s hot reload solves is the operational cost of configuration updates. In distributed systems, restarting a service can mean a brief period of unavailability, potential data loss if not handled carefully, and increased operational overhead. Hot reload aims to eliminate this by allowing configuration changes to be applied dynamically.
Internally, Vector uses a mechanism where it periodically checks the timestamp of its configuration file. When it detects a modification, it parses the new configuration. If the new configuration is valid, it constructs a new Config object. Then, it initiates a graceful shutdown of old components (like the previous sink) and starts new components (the new file sink) using the updated Config. This process is designed to be atomic at the application level, ensuring that data is not lost and no service interruption occurs. The inputs directive in your configuration is crucial here; it defines the data flow, and when a component upstream of a sink changes, the sink needs to be reconfigured to accept data from the potentially new output of that upstream component.
What most people don’t realize is that hot reload isn’t just about changing a sink’s destination. You can fundamentally alter the topology of your data pipeline. For instance, you could add entirely new sources, insert complex transforms in the middle of existing flows, or even remove parts of the pipeline. The system is designed to re-evaluate the entire directed acyclic graph (DAG) of your data flow and reconfigure components accordingly. This means you can introduce new enrichment steps, switch from one log parsing strategy to another, or reroute data to different destinations all on the fly.
The next thing you’ll want to explore is how to handle more complex reload scenarios, like when a source itself needs to be reconfigured.