---
title: Vector
slug: telemetry-pipeline/vector
docTags: 
createdAt: 2025-04-21T00:47:37.055Z
---

## Vector Source

Collect logs, metrics, and traces from another **upstream Vector instance**.
 This source is designed to receive data emitted by the **Vector sink**, enabling Vector-to-Vector communication across hosts, clusters, or network boundaries.

It is commonly used to build **tiered telemetry pipelines**, such as agent → aggregator or edge → core architectures.

## Collection Model

- Listens on a network socket for incoming Vector protocol connections 
- Receives structured telemetry data emitted by upstream Vector instances 
- Preserves event types (logs, metrics, traces) without implicit conversion 
- Designed for reliable, backpressure-aware data forwarding 

This source participates in Vector’s **end-to-end acknowledgement mechanism**, enabling delivery guarantees across multiple pipeline stages.

## Typical Architecture Patterns

- **Agent → Aggregator** 
- **Node-level Vector → Cluster-level Vector** 
- **Edge collection → Central processing** 
- **Multi-hop telemetry pipelines** 

The Vector source is optimized for **Vector-native communication** and should not be used as a generic log receiver.

## Network Binding

### address (required)

Defines the socket address on which the Vector source listens for incoming connections.

Operational notes:

- Must include a port number 
- Determines where upstream Vector sinks connect 
- Should be reachable from upstream instances, considering firewalls and network policies 

## Acknowledgement Handling

### acknowledgements (deprecated)

Source-level acknowledgement configuration is deprecated.

Important notes:

- Enabling or disabling acknowledgements at the source level has **no effect** 
- Acknowledgement behavior is now controlled globally or at the sink level 
- This ensures consistent, end-to-end delivery semantics 

For details, refer to Vector’s end-to-end acknowledgement model.

## Delivery Semantics

- **At-least-once delivery** is supported when acknowledgements are enabled upstream 
- Events are acknowledged only after successful downstream processing 
- Provides protection against data loss during transient failures 

This makes the Vector source suitable for **reliable aggregation tiers**.

## TLS Support

TLS can be enabled to secure Vector-to-Vector communication.

When enabled:

- Connections are encrypted 
- Server identity is verified 
- Optional mutual TLS (mTLS) can be enforced 

### TLS Enablement

### tls.enabled (optional)

Controls whether TLS is required for incoming or outgoing connections.

When enabled for incoming connections:

- A server certificate is mandatory 
- Clients must negotiate TLS successfully to connect 

### Certificate Configuration

TLS configuration supports:

- Server certificate and private key 
- Encrypted private keys with passphrases 
- Custom Certificate Authority bundles 
- Inline or file-based certificate material 

### Verification Controls

### tls.verify\_certificate (optional)

Enforces certificate chain validation.

If enabled:

- Certificates must be valid and not expired 
- Issuers must be trusted 
- Full chain verification is performed up to a root certificate 

Disabling this weakens security and should only be done in controlled environments.

### tls.verify\_hostname (optional)

Enables hostname verification for outgoing connections.

Ensures that:

- The hostname matches the certificate’s Common Name or SAN entry 

Only relevant when the component initiates connections.

### ALPN Support

### tls.alpn\_protocols (optional)

Defines supported ALPN protocols during TLS negotiation.

Protocols are prioritized in the order they are declared.

## Protocol Versioning

### version (optional)

Specifies the Vector protocol configuration version.

Currently supported:

- **Version 2** 

This acts as a compatibility marker between communicating Vector instances.

## Reliability Characteristics

- Stateless operation 
- Supports backpressure-aware streaming 
- Integrates with Vector’s acknowledgement pipeline 
- Suitable for high-throughput, production-grade telemetry forwarding 

## Common Use Cases

- Central aggregation of logs, metrics, and traces 
- Secure Vector-to-Vector communication across networks 
- Building scalable, multi-tier observability pipelines 
- Reducing complexity compared to generic protocols (Syslog, HTTP) 
- Preserving structured telemetry without re-parsing