VictoriaMetrics et VictoriaLogs dans Kubernetes et Grafana¶

VictoriaMetrics et VictoriaLogs viennent de la même équipe et partagent la même philosophie : un binaire simple, peu gourmand en CPU, RAM et disque, et une installation identique dans Kubernetes. Je te propose donc de monter les deux ensemble : VictoriaMetrics pour tes métriques, VictoriaLogs pour tes logs, déployés en as code avec Terraform et Argo CD, puis branchés sur Grafana.

Présentation des deux briques¶

VictoriaMetrics¶

VictoriaMetrics est une base de données time series open source, compatible avec l'écosystème Prometheus : elle reçoit les métriques en remote_write, se requête en PromQL et dans son extension MetricsQL, avec une consommation CPU/RAM et disque réduite. Pour lui envoyer tes métriques, vois Vector ou Prometheus en mode Agent.

VictoriaLogs¶

VictoriaLogs est la base de données de logs open source de la même équipe. Elle stocke tes logs avec très peu de ressources, se requête avec son langage LogsQL, et ingère les logs via de nombreux protocoles (Elasticsearch bulk, Loki push, OpenTelemetry, syslog...). Côté collecte, tu peux par exemple lui envoyer tes logs avec Vector.

En un coup d'œil¶

Je te montre une stack complète (Vector, kube-state-metrics, VictoriaMetrics et Grafana) dans cet article.

Single ou cluster ?¶

Les deux outils existent en version single (un seul binaire qui fait tout) et en version cluster (composants séparés pour l'ingestion, la requête et le stockage, qui passent à l'échelle horizontalement). On part ici sur le mode single : il couvre la grande majorité des besoins et reste beaucoup plus simple à opérer.

Pré-requis : le provider Terraform Argo CD¶

Pour la suite du cours je vais te donner l'ensemble du code réalisé avec Terraform. Cela va nous permettre d'amener résilience et robustesse : un seul terraform apply et on retrouve notre cluster en bonne santé :)

Utilisant déjà Argo CD comme outil pour déployer nos Helm charts, on va utiliser son provider Terraform. Je te montre la configuration que j'utilise, sachant que je suis sur minikube avec un Argo CD non exposé au net, donc juste appelable en local.

Ici tu peux utiliser soit le traditionnel username:password, soit un auth_token généré par Argo CD avec ton compte admin. On mentionne en contexte le nom de notre cluster, ainsi que le namespace où est installé notre argocd-server.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

terraform {
  required_providers {
    argocd = {
      source  = "argoproj-labs/argocd"
      version = "7.17.2"
    }
  }
}

variable "argocd_admin_password" {
  type      = string
  sensitive = true
}

provider "argocd" {
  #auth_token                  = ".bjphcGlLZXkiLCJuYmYiOjE3MTQ"
  username                    = "admin"
  password                    = var.argocd_admin_password # ne jamais commiter de mot de passe en clair
  port_forward_with_namespace = "argocd"
  kubernetes {
    config_context = "minikube"
  }
}

Déployer VictoriaMetrics¶

On déclare une Application Argo CD qui pointe sur le chart victoria-metrics-single :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

resource "argocd_application" "victoria_metrics" {
  metadata {
    name      = "victoria-metrics"
    namespace = "argocd"
  }

  spec {

    destination {
      server    = "https://kubernetes.default.svc"
      namespace = "argocd"
    }

    sync_policy {
      automated {
        prune       = false
        self_heal   = true
        allow_empty = true
      }

      sync_options = ["Validate=true"]
      retry {
        limit = "5"
        backoff {
          duration     = "30s"
          max_duration = "2m"
          factor       = "2"
        }
      }
    }

    source {
      repo_url        = "https://victoriametrics.github.io/helm-charts"
      chart           = "victoria-metrics-single"
      target_revision = "0.49.0"

      helm {
        release_name = "victoria-metrics"
        values = yamlencode({
            # CUSTOM VALUES A AJOUTER
        })
      }
    }
  }
}

Le bloc values est vide pour garder l'exemple lisible, mais en pratique tu vas au minimum fixer la rétention et la taille du volume. Par défaut, le chart garde un mois de données (retentionPeriod: 1, l'unité par défaut étant le mois) :

1
2
3
4
5
6
7
8
9

values = yamlencode({
  server = {
    retentionPeriod = "30d" # unités h, d, w, y ; sans unité = mois ; minimum 24h
    persistentVolume = {
      enabled = true
      size    = "20Gi"      # à dimensionner selon ton volume de séries et ta rétention
    }
  }
})

Déployer VictoriaLogs¶

Même principe pour VictoriaLogs, avec le chart victoria-logs-single :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

resource "argocd_application" "victoria_logs" {
  metadata {
    name      = "victoria-logs"
    namespace = "argocd"
  }

  spec {

    destination {
      server    = "https://kubernetes.default.svc"
      namespace = "argocd"
    }

    sync_policy {
      automated {
        prune       = false
        self_heal   = true
        allow_empty = true
      }

      sync_options = ["Validate=true"]
      retry {
        limit = "5"
        backoff {
          duration     = "30s"
          max_duration = "2m"
          factor       = "2"
        }
      }
    }

    source {
      repo_url        = "https://victoriametrics.github.io/helm-charts"
      chart           = "victoria-logs-single"
      target_revision = "0.13.10"

      helm {
        release_name = "victoria-logs"
        values = yamlencode({
            # CUSTOM VALUES A AJOUTER
        })
      }
    }
  }
}

Pour les logs, la rétention se règle en temps, mais aussi en espace disque, ce qui évite de saturer le volume quand une application se met à loguer beaucoup plus que prévu :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

values = yamlencode({
  server = {
    retentionPeriod              = "14d"
    retentionMaxDiskUsagePercent = 80 # supprime les plus anciennes données au-delà de 80 % du disque
    persistentVolume = {
      enabled = true
      size    = "50Gi"
    }
  }
})

Envoyer des données¶

Une fois les deux bases en place, il faut les alimenter :

• Métriques : tout composant compatible Prometheus remote_write peut écrire dans VictoriaMetrics, par exemple :

  remote_write:
    - url: http://victoria-metrics-victoria-metrics-single-server.argocd.svc.cluster.local:8428/api/v1/write
  

• Logs : choisis l'endpoint qui correspond à ton collecteur. Vector peut écrire en protocole Elasticsearch bulk, Grafana Alloy en protocole Loki, et un OpenTelemetry Collector en OTLP sur /insert/opentelemetry/v1/logs.

Pour vérifier rapidement que des logs arrivent, interroge directement l'API de VictoriaLogs (après un kubectl port-forward sur le port 9428) :

curl http://localhost:9428/select/logsql/query -d 'query=_time:5m error'

Brancher VictoriaMetrics et VictoriaLogs sur Grafana¶

Installer les plugins¶

On ajoute les deux plugins officiels dans Grafana pour créer des data sources dédiées :

• victoriametrics-datasource, identifiant victoriametrics-metrics-datasource ;
• victorialogs-datasource, identifiant victoriametrics-logs-datasource.

Avec l'image Docker officielle de Grafana, la variable d'environnement GF_PLUGINS_PREINSTALL (liste séparée par des virgules) installe les plugins au démarrage : GF_PLUGINS_PREINSTALL=victoriametrics-metrics-datasource,victoriametrics-logs-datasource. C'est la méthode documentée sur les versions récentes de Grafana, à la place de l'ancienne GF_INSTALL_PLUGINS.

Le provider Terraform Grafana¶

On installe le provider Grafana afin de faire nos data sources as code avec Terraform.

Ici on fait simple, notre Grafana n'étant pas exposé, on va simplement faire un port-forward sur le pod de ce service. Je l'expose sur http://localhost:3000/.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

terraform {
  required_providers {
    grafana = {
      source  = "grafana/grafana"
      version = "4.50.0"
    }
  }
}

provider "grafana" {
  auth = "admin:admin"
  url  = "http://localhost:3000/"
}

Créer les data sources¶

Il ne reste plus qu'à créer nos deux data sources basées sur ces plugins. Pense à mettre les endpoints de tes propres services VictoriaMetrics et VictoriaLogs.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

resource "grafana_data_source" "vm" {
  type = "victoriametrics-metrics-datasource"
  name = "vm-datasource"
  url  = "http://victoria-metrics-victoria-metrics-single-server.argocd.svc.cluster.local:8428"
}

resource "grafana_data_source" "vl" {
  type = "victoriametrics-logs-datasource"
  name = "vl-datasource"
  url  = "http://victoria-logs-victoria-logs-single-server.argocd.svc.cluster.local:9428"
}

Tu as désormais accès à tes métriques et à tes logs depuis Grafana !

Premières requêtes¶

Côté métriques, tes requêtes PromQL habituelles fonctionnent telles quelles dans l'explorateur Grafana, par exemple le taux de requêtes HTTP en erreur :

sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)

Côté logs, LogsQL enchaîne des filtres puis des pipes séparés par | :

• _time:5m error : les logs des 5 dernières minutes qui contiennent le mot error ;
• {namespace="production"} error _time:1h : la même recherche sur une heure, limitée aux streams du namespace production ;
• _time:5m error | stats count() errors : le nombre de logs en erreur ;
• _time:5m | stats by (level) count() rows : la répartition des logs par niveau.

Dans Grafana, le filtre de temps est passé automatiquement par la data source : tu peux omettre _time et laisser le sélecteur de période faire le travail.

Pièges courants en production¶

• Volume plein : une rétention en temps ne protège pas contre un pic de logs. Combine retentionPeriod et retentionMaxDiskUsagePercent (ou retentionDiskSpaceUsage) côté VictoriaLogs, et surveille l'espace disque de tes PVC.
• Mises à jour de chart : épingle target_revision comme dans les exemples et lis le changelog du chart avant de monter de version, les valeurs par défaut évoluent.
• Pas de HA en single : voir l'encart plus haut. Une alerte sur la disponibilité des deux pods est le minimum.
• Identifiants Grafana et Argo CD : ne laisse jamais admin:admin ni un mot de passe en clair dans ton code Terraform ou ton state : passe par des variables sensibles ou un gestionnaire de secrets.
• Cardinalité : côté métriques, une étiquette à forte cardinalité (ID utilisateur, URL complète) fait exploser le nombre de séries ; côté logs, c'est le piège des stream fields vu plus haut.

Pour aller plus loin¶

• Les alternatives de la stack Grafana : Grafana Mimir pour les métriques et Grafana Loki pour les logs
• Alerter sur tes métriques avec Prometheus Alertmanager
• Les slides du cours d'observabilité : stockage des métriques avec Mimir et VictoriaMetrics et stockage des logs avec Loki et VictoriaLogs