Lightweight Kubernetes Logging: Vector & Victoria Logs

As soon as you start deploying multiple applications on a Kubernetes cluster, having centralized access to your logs becomes essential. The moment a pod crashes, trying to hunt down the logs manually via kubectl is a recipe for frustration.

The Problem with the "Standard" Stack

When we talk about Kubernetes logging, the industry standard is often the PLG stack (Promtail, Loki, Grafana). While it’s incredibly powerful, it can also be significantly oversized if you are running a modest cluster. If your homelab or cloud edge environment is running on resource-constrained nodes—like an AWS EC2 t3.small or t3.micro—deploying a full Grafana and Loki stack can easily eat up a huge chunk of your available RAM and CPU before you even deploy your first application.

A Leaner Alternative: Vector + Victoria Logs

Recently, I decided to look for a more lightweight alternative for my infrastructure, and I found an incredible combination: Vector (for log collection) and Victoria Logs (for log storage and querying).

Both tools are extremely resource-efficient, written in compiled languages (Rust and Go, respectively), and can be deployed via Helm in minutes. The best part? Victoria Logs comes with a built-in, beautifully minimal Web UI that you can easily expose securely behind a reverse proxy or VPN on a custom subdomain.

Configuring Vector with FluxCD

While Victoria Logs basically runs perfectly out of the box, Vector acts as a highly flexible router and requires some configuration to know exactly what to collect, how to process it, and where to send it.

Since I manage my cluster using GitOps principles with FluxCD, here is the actual HelmRelease manifest I use. Notice the resource constraints (just 64Mi of RAM requested!) and the custom transformations to drop noisy logs before they even reach the database:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: vector
  namespace: logging
spec:
  interval: 1h
  chart:
    spec:
      chart: vector
      version: ">=0.30.0"
      sourceRef:
        kind: HelmRepository
        name: vector
        namespace: flux-system
  install:
    createNamespace: true
  values:
    role: Agent

    service:
      enabled: false

    resources:
      requests:
        cpu: 50m
        memory: 64Mi
      limits:
        memory: 256Mi

    customConfig:
      data_dir: /vector-data-dir

      sources:
        kubernetes_logs:
          type: kubernetes_logs
          # Prevent infinite logging loops by ignoring the logging namespace
          extra_field_selector: "metadata.namespace!=logging"

      transforms:
        drop_health_checks:
          type: filter
          inputs:
            - kubernetes_logs
          # Keep our database clean from noisy readiness/liveness probes
          condition: '!contains(string!(.message), "GET /health")'

      sinks:
        to_victorialogs:
          type: elasticsearch
          inputs:
            - drop_health_checks
          endpoints:
            - http://victorialogs-victoria-logs-single-server.logging.svc.cluster.local:9428/insert/elasticsearch/
          mode: bulk
          api_version: v8
          healthcheck:
            enabled: true
          buffer:
            type: disk
            max_size: 268435488
            when_full: block
          query:
            _msg_field: message
            _time_field: timestamp
            # Properly map Kubernetes metadata to VictoriaLogs streams
            _stream_fields: "kubernetes.pod_namespace,kubernetes.pod_name,kubernetes.container_name"

Why this exact setup rocks

• Smart Filtering: By using Vector's transforms, I am silently dropping HTTP /health checks and ignoring the logging namespace entirely. This saves disk space and prevents potential ingestion loops.
• Tiny Footprint: Vector is running with a memory request of just 64Mi. Compare that to JVM-based shippers, and you'll see why it's perfect for edge nodes.
• Seamless Integration: Victoria Logs natively accepts the Elasticsearch bulk API format. By defining _stream_fields, we ensure that logs are perfectly indexed by namespace, pod, and container for extremely fast querying in the UI.

The Result

By moving away from heavier default stacks, I managed to centralize all my Kubernetes logs without dragging down my node's performance. It’s a perfect fit for edge nodes, homelabs, or cloud setups where compute efficiency is a top priority.

Have you tried Vector or Victoria Logs in your own clusters? What's your go-to logging stack for small environments? Let me know in the discussion below!