Aller au contenu

Runbook : LokiIngestionSlow

Alerte : LokiIngestionSlow (PrometheusRule, severity warning)

Symptôme :

Le taux d'ingestion des logs est < 80 % du target, ou la file d'attente dépasse 5 000 entries depuis plus de 10 min. Risque : perte de logs (buffer du log shipper saturé).

Severity : 🟡 warning, notif Slack #akko-observability

Alerte historique, opt-in uniquement

À lire en premier. Le chemin de logs AKKO par défaut est Fluent Bit -> VictoriaLogs. Il n'y a ni Loki ni Promtail dans une installation standard.

Le nom d'alerte LokiIngestionSlow est conservé pour compatibilité. Il est conditionné par loki.enabled dans prometheusrule-akko.yaml, et loki.enabled vaut false par défaut. L'alerte ne se déclenche que si un client réactive explicitement un backend Loki avec loki.enabled: true. Sur une installation par défaut, cette alerte ne se déclenche jamais.

Si vous êtes sur le chemin par défaut, allez directement à Chemin par défaut : Fluent Bit -> VictoriaLogs.

Chemin par défaut : Fluent Bit -> VictoriaLogs

Sur une installation standard, des logs lents ou perdus proviennent de l'un de ces trois points : la santé d'ingestion VictoriaLogs, la contre-pression (backpressure) de Fluent Bit, ou le stockage/rétention VictoriaLogs.

1. Santé d'ingestion VictoriaLogs

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl port-forward -n akko svc/akko-victorialogs 9428:9428 &
curl -sS http://localhost:9428/metrics | grep -E "vl_rows_ingested_total|vl_http_requests_total"

Métriques clés : - vl_rows_ingested_total (doit croître) - vl_http_requests_total{path="/insert/loki/api/v1/push"} (endpoint de push Loki-compat) - vl_free_disk_space_bytes (doit rester bien au-dessus de zéro)

Vérifiez aussi que le pod VictoriaLogs est sain :

kubectl get pod -n akko -l app.kubernetes.io/name=victoria-logs-single
kubectl logs -n akko -l app.kubernetes.io/name=victoria-logs-single --tail=200 | grep -iE "error|reject|cannot"

2. Contre-pression Fluent Bit (le log shipper)

kubectl get ds akko-fluent-bit -n akko
kubectl logs ds/akko-fluent-bit -n akko --tail=200 | grep -iE "error|retry|backpressure|drop|chunk"

Symptômes de contre-pression : - [warn] [engine] failed to flush chunk (VictoriaLogs n'absorbe pas assez vite) - [error] [output] ... connection refused (service VictoriaLogs down ou mauvais endpoint) - compteurs de retry qui augmentent

Vérifiez la config Fluent Bit (endpoint, mem_buf_limit, politique de retry) :

kubectl get configmap akko-fluent-bit-config -n akko -o yaml | grep -A30 '\[OUTPUT\]'

3. Stockage et rétention VictoriaLogs

La rétention VictoriaLogs par défaut est de 14 j sur un PVC de 50Gi. Si le PVC est plein, l'ingestion ralentit ou se bloque.

kubectl get pvc -n akko -l app.kubernetes.io/name=victoria-logs-single
kubectl exec -n akko -it <pod-victorialogs> -- df -h /storage

Causes fréquentes + correctif (chemin par défaut)

Cause Symptôme Correctif
PVC VictoriaLogs plein vl_free_disk_space_bytes proche de 0, ingestion bloquée Réduire la rétention (14 j par défaut) ou augmenter storageSize dans les values akko-observability, puis helm upgrade
Flush Fluent Bit en échec failed to flush chunk dans les logs akko-fluent-bit Vérifier que le service VictoriaLogs est joignable ; augmenter mem_buf_limit dans akko-fluent-bit-config
Service VictoriaLogs down connection refused côté Fluent Bit Redémarrer / vérifier le pod akko-victorialogs, vérifier le service sur le port 9428
Endpoint mal configuré 404 au push, 0 ligne ingérée Corriger l'endpoint OUTPUT dans akko-fluent-bit-config (Loki-compat /insert/loki/api/v1/push ou push VictoriaLogs natif)
Pic de volume de logs latence d'ingestion, retries qui montent Réduire les sources bruyantes au niveau INPUT/FILTER de Fluent Bit

Réduire le volume de logs (correctif #1 pour les pics)

Réduisez les sources bruyantes au niveau de Fluent Bit plutôt que de jeter des données au stockage. Champs à ne pas promouvoir en champs de flux à forte cardinality : - pod_name (change à chaque restart) - container_id - trace_id - request_id - user_id sans bucket

À préférer, des champs stables à faible cardinality : - namespace, app, component - level (info/warn/error, quelques valeurs)

Correctif pérenne (R02)

Ajuster la rétention et la taille VictoriaLogs

# helm/akko/charts/akko-observability/values.yaml (slot logs)
logs:
  backend: victorialogs
  victorialogs:
    retention: "14d"        # défaut ; abaisser pour libérer, ou augmenter storageSize
    storageSize: 50Gi

Puis commit + push + helm upgrade. Jamais kubectl edit configmap.

Libérer le stockage VictoriaLogs

VictoriaLogs applique la rétention automatiquement. Si le PVC est plein avant que la rétention n'agisse, abaissez retention ou augmentez storageSize dans les values ci-dessus, puis helm upgrade. Ne modifiez jamais les données du PVC à la main.

Prévention

  • Dashboard Perses « Logs Ingestion » (page Logs du cockpit) avec panels :
  • Lignes/s ingérées (vl_rows_ingested_total)
  • Retries de flush / chunks perdus côté Fluent Bit
  • Espace disque libre VictoriaLogs
  • PrometheusRule précoce : warning quand l'espace disque libre passe sous 20 %
  • Revue mensuelle des sources de logs bruyantes dans akko-fluent-bit-config

Lessons learned

  • L10 : La rétention VictoriaLogs est de 14 j par défaut. VictoriaLogs n'est pas un data warehouse : les logs plus vieux que la fenêtre de rétention doivent aller en cold storage (object storage direct).

Liens utiles