edp-doc/docs/user-documentation/victoria-k8s-stack.md

Victoria k8s Stack

We use Victoria Metrics k8s stack and Vector.

Why do we use it?

• compare it with competitors like ELK, Loki, Prometheus

• it delivers logging and metrics

• in ELK we replaced the 'E'(ElasticSearch) by VictoriaLogs and VictoriaMetrics, L(Logstash) is replaced by Vector, 'K'(Kibana) by Grafana

• Loki (also the 'E'): has 5 components (like distrubutor, querier, querier-frontend....), VM

• ELK is hard to manage

• Durability: We need to store logs for years, there should be a 'shrink' process

• Challenge: Scaling, there are huge amounts of data (like TB/d)

• we urde for simplicity, cost, scalability

Big Picture

Architecture

The high level deployment picture of VictoriaMetrics k8 s Stack looks like this:

Deployment

In detail, after having deployed it, we see the following components:

1. vector-vector: the log shipper to victorialogs, twice because it is a daemon-set and thus deploed on each node in the cluster
2. prometheus-node-exporter: a metrics generator and metrics endpoint of node metrics, also deployed on each node
3. vmagent: the central agent scraping data from the metrics collectors
4. vmalert: not used yet
5. vmsingle-victoria-metrics: the metrics server, getting the data from vmagent
6. vlogs: the logging server, getting the data from vector
7. victoria-metrics-operator: the operator providing and managing the custom resources we deploy