Vector Explained

Vector is a high-performance observability data pipeline developed by Datadog Vector.

Think of it as:

A modern replacement for Fluentd, Fluent Bit, Logstash, and sometimes Filebeat.

Vector can collect, transform, enrich, filter, and route:

• Logs
• Metrics
• Events
• Traces

to multiple destinations.

Why OpenShift Uses Vector

Historically:

Pods
 |
Fluentd
 |
Elasticsearch

Problems:

• High memory usage
• Ruby-based
• Difficult to scale
• CPU intensive

Modern OpenShift Logging:

Pods
 |
Vector
 |
Loki

Benefits:

• Rust-based
• Extremely fast
• Lower memory consumption
• Better Kubernetes integration
• Easier operations

How Vector Works

Vector consists of three parts:

Sources

Collect data from somewhere.

Examples:

sources:
  kubernetes_logs:
    type: kubernetes_logs

Sources can read:

• Kubernetes logs
• Journald
• Syslog
• Files
• Kafka
• OpenTelemetry

Transforms

Process data.

Examples:

• Filter
• Parse JSON
• Remove secrets
• Add labels
• Enrich metadata

Example:

transforms:
  filter_errors:
    type: filter

Sinks

Send data somewhere.

Examples:

• Loki
• Elasticsearch
• Splunk
• Kafka
• Azure Event Hub
• S3

Example:

sinks:
  loki:
    type: loki

OpenShift Logging Architecture

Application Pods
       |
       |
    Vector
       |
       |
    LokiStack
       |
       |
    Grafana

or

Application Pods
       |
       |
    Vector
       |
       |
Elasticsearch
       |
       |
    Kibana

Vector as a DaemonSet

In Kubernetes/OpenShift:

Node 1
 └─ Vector Pod
Node 2
 └─ Vector Pod
Node 3
 └─ Vector Pod

One Vector instance per node.

This is very similar to:

• Filebeat
• Fluent Bit
• Node Exporter

What Logs Does Vector Collect?

Container logs:

/var/log/containers

Pod logs:

/var/log/pods

Node logs:

journald

Audit logs:

/var/log/audit

Infrastructure logs:

kubelet
crio
ovn

Kubernetes Metadata Enrichment

One of Vector’s biggest advantages.

A log:

{
  "message": "Database timeout"
}

becomes:

{
  "message":"Database timeout",
  "namespace":"banking",
  "pod":"payment-api",
  "container":"api"
}

This makes searching much easier in Loki or ELK.

Vector Remap Language (VRL)

Vector has its own transformation language.

Example:

Remove sensitive information:

del(.password)
del(.creditcard)

Add hostname:

.hostname = get_hostname!()

Normalize logs:

.level = upcase(.level)

Very useful in enterprise environments.

Real OpenShift Example

Suppose your application generates:

{
 "level":"error",
 "message":"DB connection failed"
}

Vector:

1. Reads log
2. Adds Kubernetes metadata
3. Parses JSON
4. Filters sensitive data
5. Sends to Loki

Final log:

{
 "namespace":"banking",
 "pod":"payment-api",
 "level":"ERROR",
 "message":"DB connection failed"
}

Vector vs Fluentd

Vector vs Filebeat

Since you’ve worked extensively with Filebeat and ELK:

Example: Send Logs to Loki

sources:
  kubernetes_logs:
    type: kubernetes_logs
sinks:
  loki:
    type: loki
    endpoint: http://loki:3100

Flow:

Pod Logs
   |
 Vector
   |
 Loki
   |
 Grafana

Example: Send Logs to Elasticsearch

sources:
  kubernetes_logs:
    type: kubernetes_logs
sinks:
  elasticsearch:
    type: elasticsearch
    endpoints:
      - http://elasticsearch:9200

Flow:

Pod Logs
   |
 Vector
   |
 Elasticsearch
   |
 Kibana

Enterprise OpenShift Deployment

For a banking or government OpenShift platform:

Applications
      |
      |
    Vector
      |
      +----------------+
      |                |
      v                v
    Loki            SIEM
      |                |
   Grafana       Sentinel/Splunk

This provides:

• Operational logs in Loki
• Security logs in SIEM
• Compliance retention
• Centralized visibility

Interview Question

“What is Vector and why is it used in OpenShift?”

A strong answer:

Vector is a high-performance observability data pipeline written in Rust. It collects logs, metrics, and events from Kubernetes and OpenShift workloads, enriches them with metadata, transforms them using VRL, and routes them to destinations such as Loki, Elasticsearch, Splunk, Kafka, or cloud storage.

Red Hat adopted Vector as the primary log collector in OpenShift Logging because it is significantly more efficient than Fluentd, consumes fewer resources, scales better, and integrates naturally with Kubernetes metadata. In modern OpenShift deployments, Vector typically runs as a DaemonSet on every node, collecting container, infrastructure, and audit logs before forwarding them to LokiStack or an external logging platform.

Architect-Level Follow-Up

If an interviewer asks:

“Why would you choose Vector + Loki instead of Filebeat + ELK?”

Answer:

For OpenShift-centric environments, Vector + Loki provides lower infrastructure cost, lower operational complexity, and better Kubernetes-native metadata handling. For organizations already heavily invested in ELK, advanced full-text searching, SIEM workflows, or existing Elasticsearch expertise, Vector can still be used as the collector while forwarding logs to Elasticsearch. This gives the benefits of Vector’s efficient collection and transformation layer while preserving the existing ELK ecosystem.

If an interviewer asks:

“Would you use Vector or Node Exporter?”

A strong answer is:

They serve different purposes. Node Exporter collects host-level metrics such as CPU, memory, disk, and network usage for Prometheus. Vector collects and forwards logs from applications, containers, and operating systems to platforms like Loki, Elasticsearch, or Splunk. In a production OpenShift or Linux environment, I would deploy both. Node Exporter provides infrastructure observability, while Vector provides log observability. Together they form a complete monitoring and troubleshooting solution.