Aller au contenu

Runbook : LokiIngestionSlow

Alerte : LokiIngestionSlow (PrometheusRule, severity warning)

Symptôme :

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

Severity : 🟡 warning — notif Slack #akko-observability

Diagnostic

1. Métriques d'ingestion

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl port-forward -n akko svc/akko-loki 3100:3100 &
curl -sS http://localhost:3100/metrics | grep -E "loki_ingester|loki_distributor"

Métriques clés : - loki_ingester_chunks_stored_total (doit croître) - loki_distributor_bytes_received_total - loki_ingester_chunks_flushed_reasons_total

2. Vérifier les limites

kubectl get configmap -n akko akko-loki -o yaml | grep -A20 'limits_config:'
# Les quotas pertinents :
#   ingestion_rate_mb
#   ingestion_burst_size_mb
#   max_streams_per_user
#   max_line_size

3. Logs logs layer pour les events rate limit

kubectl logs -n akko -l app.kubernetes.io/name=loki --tail=200 | grep -iE "rate|limit|throttle"

4. État log shipper (producteur)

kubectl get pod -n akko -l app.kubernetes.io/name=promtail
kubectl logs -n akko -l app.kubernetes.io/name=promtail --tail=100 | grep -iE "error|drop|fail"

Causes fréquentes + correctif

Cause Symptôme (logs) Correctif
Rate limit logs layer dépassé per-stream rate limit exceeded Bump ingestion_rate_mb + ingestion_burst_size_mb dans loki values.yaml
Trop de streams uniques per-user too many streams Réduire la cardinality des labels (voir ci-dessous)
Stockage object storage saturé upload to S3 failed, no space left Libérer le bucket object storage loki OU rétention plus agressive
CPU throttling ingester context deadline exceeded Bump resources.limits.cpu logs layer
Compactor en retard too many small chunks Vérifier que le compactor tourne + ses logs
Mauvaise indexation Latence requêtes élevée Vérifier la version et la période du schema_config

Réduire la cardinality (correctif #1 pour « too many streams »)

Labels à bannir de la pipeline log shipper (trop variables) : - pod_name (change à chaque restart) - container_id - trace_id - request_id - user_id sans bucket

À préférer : - namespace, app, component (cardinality limitée) - level (info/warn/error — 5 valeurs max)

Correctif pérenne (R02)

Bump des limites logs layer

# monitoring/loki/values.yaml ou helm/akko/charts/akko-monitoring/.../values-loki.yaml
loki:
  limits_config:
    ingestion_rate_mb: 20           # était 10
    ingestion_burst_size_mb: 40     # était 20
    max_streams_per_user: 25000     # était 10000
    retention_period: 720h          # 30 jours

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

Purger les vieux logs

# Travail du compactor logs layer. S'il n'arrive pas à compacter, forcer :
kubectl exec -n akko deploy/akko-loki-compactor -- \
  loki -config.file=/etc/loki/config.yaml -target=compactor.delete-request-cancel-period=1h

Prévention

  • Dashboard Dashboards « logs layer Ingestion » avec panels :
  • Bytes/s par tenant
  • Streams par tenant
  • Rate limit hits
  • CPU/Mémoire de l'ingester
  • PrometheusRule précoce : warning à 70 % de la limite
  • Revue mensuelle des labels log shipper → détecter les nouvelles explosions de cardinality

Lessons learned

  • L10 — Rétention logs layer 30 j en prod par défaut. logs layer n'est pas un data warehouse : les logs > 90 jours doivent aller en cold storage (object storage direct).

Liens utiles