Deployment Strategies

Vector is designed to be the single and only tool needed to get data from A to B. This means Vector can be deployed as a daemon, sidecar, or a service. You combine these strategies to form topologies which are covered in the next section. In this section we'll cover each strategy in detail and help you understand when to use each.

Daemon

The daemon deployment strategy is designed for data collection on a single host. Vector runs in the background, in its own process, collecting all data for that host. Typically data is collected from a process manager, such as Journald via Vector's journald source, but can be collected through any of Vector's sources. The following diagram demonstrates how it works.

Vector daemon deployment strategyVector daemon deployment strategy
1. Your service logs to STDOUT
STDOUT follows the 12 factor principles.
2. STDOUT is captured
STDOUT is captured by your platform.
3. Vector collects & fans-out data
Vector collects data from your platform.

When to use

  • You are responsible for the host machine and have the ability to install Vector directly on the host.
  • You are operationally proficient and understand how to reliably install, manage, and configure software.
  • You want a single robust solution for collecting and shipping your observability data on each host.

When NOT to use

  • You do not control the host machine or environment.
  • You do not feel comfortable installing, managing, and configuring host-level software.
  • You want to shift responsibility of collecting and shipping observability data to each service owner.

Sidecar

The sidecar deployment strategy is designed to collect data from a single service. Vector has a tight 1 to 1 coupling with each service. Typically data is collected by tailing local files via Vector's file source, but can be collected through any of Vector's sources. The following diagram demonstrates how it works.

Vector Sidecar Deployment StrategyVector sidecar deployment strategy.
1. Your service logs to a shared resource
Such as a file on a shared volume or anything Vector can access.
2. Vector ingests the data
Such as tailing a file on a shared volume.
3. Vector forwards the data
Vector forwards the data to one or more downstream services.

When to use

  • You are not responsible for the host machine and do not have the ability to install Vector directly on the host.
  • You want to couple data collection with each service, shifting responsibility to the service owner.
  • You find it simpler for each service to have it own specific Vector instance and configuration file.

When NOT to use

  • You do not like the idea of having multiple Vector instances on a single host.

Service

The service deployment strategy treats Vector like a separate service. It is designed to receive data from an upstream source and fan-out to one or more destinations. Typically, upstream sources are other Vector instances sending data via the vector sink, but can be collected through any of Vector's sources. The following diagram demonstrates how it works.

Vector Service Deployment StrategyVector service deployment strategy
1. Vector receives data
Vector receives data from another upstream Vector instance.
2. Vector processes data
Vector parses, transforms, and enriches data.
3. Vector fans-out data
Vector receives data from another upstream Vector instance.

When to use

  • You need to batch data to optimize throughput and reduce the downstream request rate.
  • You want to perform operations across multiple hosts, such as aggregating data in a global context.
  • Vector is a stream consumer, continually pulling data from services like Kafka, Kinesis, or SQS.
  • You are receiving data from other upstream Vector instances via the vector sink.

When NOT to use

  • Your downstream services support streaming where each individual host can write data directly to the services.
  • You do not need to perform operations across multiple hosts.