Logs ingestieren (VictoriaLogs)¶

VictoriaLogs ist der Log-Sink der SDP. Diese Seite beschreibt, wie Logs ankommen — Zugang und Abfrage: Access & Observability, Observability CLI. Komponenten: VictoriaLogs.

Drei Ingest-Pfade:

K8s Pods ── Vector (VL-Block) ──► VLAgent ──► VLSingle / VLCluster
Satellite-Cluster (mode: agent) ── VLAgent remoteWrite ──► zentrales VictoriaLogs

rsyslog / Netzwerkgeräte ── UDP :514 ──► Service victoria-logs-syslog ──► VLSingle / VLInsert

Linux-Host ── Vector (hardening) ── HTTP /insert/elasticsearch ──► VictoriaLogs
                 ├── journald
                 └── /var/log/audit/audit.log  (wenn auditd.enabled)

Abhängigkeit: der Block victoria-logs setzt den VictoriaMetrics Operator voraus (ayedo/k8s/victoria-metrics-stack). Remote-Read über VMAuth: ayedo/k8s/victoria-metrics-auth.

Kubernetes — Container-Logs¶

Der VL-Block installiert immer Vector (Helm-Chart, Rolle Agent) und einen VLAgent. Vector liest Node-Container-Logs (kubernetes_logs) und schreibt nach

http://vlagent-<block>.<namespace>.svc.cluster.local:9429/insert/elasticsearch.

Stream-Felder: kubernetes.pod_name, kubernetes.container_name, kubernetes.pod_namespace plus Polycrate-Labels aus dem Workspace.

Mode single und cluster — Sink im selben Cluster¶

mode: single (Default) speichert lokal in VLSingle. mode: cluster verteilt auf VLInsert / VLSelect / VLStorage. VLAgent schreibt in beiden Fällen automatisch auf die lokale Instanz; zusätzliche vlagent.remotewrite-URLs sind optional.

blocks:
  - name: victoria-logs
    from: cargo.ayedo.cloud/ayedo/k8s/victoria-logs
    kubeconfig:
      from: k8s
    config:
      namespace: victoria-logs
      mode: single
      vlsingle:
        retention: 14
        pvc:
          size: 100Gi
          class: longhorn

Cluster-Beispiel und HA-Schalter: Block-README bzw. Hub ayedo/k8s/victoria-logs.

Mode agent — nur Collector, Remote-Write¶

Kein lokaler Speicher. Der Block legt nur VLAgent (+ Vector) an. vlagent.remotewrite ist pflicht. Typisch: Workload- oder Satellite-Cluster schickt Logs ins zentrale Platform-VictoriaLogs.

blocks:
  - name: victoria-logs
    from: cargo.ayedo.cloud/ayedo/k8s/victoria-logs
    kubeconfig:
      from: k8s
    config:
      namespace: victoria-logs
      mode: agent
      vlagent:
        remotewrite:
          - url: "https://logs-user:secret@logs.acme.example/insert/elasticsearch"

Vector bleibt unverändert am lokalen VLAgent; der Agent leitet an die Remote-URL weiter.

Syslog an VictoriaLogs¶

VLSingle und VLInsert können einen UDP-Syslog-Listener auf Port 514 öffnen. Optional legt der Block den LoadBalancer-Service victoria-logs-syslog mit fester VIP an (Cilium LB-IPAM / MetalLB — Network Access).

Schlüssel sitzen unter vlsingle.syslog bzw. vlinsert.syslog — nicht mehr unter config.syslog (älter als Block 0.2).

blocks:
  - name: victoria-logs
    from: cargo.ayedo.cloud/ayedo/k8s/victoria-logs
    kubeconfig:
      from: k8s
    config:
      namespace: victoria-logs
      mode: single
      vlsingle:
        syslog:
          enabled: true
          loadbalancer:
            enabled: true
            ip: "10.0.0.28"
        pvc:
          size: 100Gi
          class: longhorn

Im Cluster-Mode dieselben Schlüssel unter vlinsert.syslog.

Beispiel rsyslog auf einem Host oder einer Appliance (UDP, Ziel = Syslog-VIP):

*.* @10.0.0.28:514

Gerät oder Host muss die VIP auf UDP/514 erreichen (Firewall, NetworkPolicy). TLS-Syslog ist in diesem Block nicht vorgesehen — für authentifizierten Versand den Hardening-Vector (HTTP + Basic Auth) nutzen.

Prüfung nach dem ersten Event:

polycrate logs --query '_msg:sshd' --start 15m \
  -w /home/user/.polycrate/workspaces/acme/platform

Linux-Hosts — Hardening als Collector¶

ayedo/linux/hardening ist ein Foundation-Block: SSH, Firewall, auditd und optional Vector auf den Linux-Hosts (Bare Metal / VMs, typisch neben k8s-1.27).

Wenn collectors.vector.logs.enabled gesetzt ist, sammelt Vector:

Metriken (node_exporter und weitere Exporter) gehen parallel per Remote-Write nach VictoriaMetrics, wenn collectors.vector.metrics.enabled gesetzt ist.

blocks:
  - name: hardening
    from: cargo.ayedo.cloud/ayedo/linux/hardening
    inventory:
      from: vpc
    config:
      auditd:
        enabled: true
      collectors:
        enabled: true
        node_exporter:
          enabled: true
        vector:
          enabled: true
          cluster: platform
          logs:
            enabled: true
            path: /insert/elasticsearch
            endpoint: https://logs.acme.example
            username: logs-user
            password: secret
          metrics:
            enabled: true
            endpoint: https://metrics.acme.example
            username: metrics-user
            password: secret

polycrate run hardening install

Vector läuft als systemd-Unit, Config unter /opt/polycrate/hardening/vector/vector.yml. Events tragen Polycrate-Labels (organizations.polycrate.io/name, workspaces.polycrate.io/name, hosts.polycrate.io/name, source_type).

# Host-Logs der letzten Stunde
polycrate logs --query 'source_type:auditd' --start 1h \
  -w /home/user/.polycrate/workspaces/acme/platform

polycrate logs --query 'systemd_unit:sshd' --start 15m \
  -w /home/user/.polycrate/workspaces/acme/platform

Komplettes Hardening-Beispiel (Firewall, Fail2ban, Toolbox): Block-README auf dem Hub.

Labels und Abfrage¶

Explore in Platform Grafana: Datasource VL (victorialogs). CLI: polycrate logs --query '…'. Datasource-UIDs nicht umbenennen — Access & Observability.

Weiterführend¶

• Access & Observability
• User Alerts
• Observability CLI
• SDP Features — Observability
• Kubernetes Distro / Foundation
• Hub: ayedo/k8s/victoria-logs, ayedo/linux/hardening