Skip to content

Runbook: LokiIngestionSlow

Alerte : LokiIngestionSlow (PrometheusRule, severity warning)

Symptôme :

logs layer ingestion rate < 80% du target, ou queue size > 5000 entries depuis plus de 10 min. Risque : perte de logs (buffer log shipper saturé).

Severity : 🟡 warning — notif Slack #akko-observability

Diagnostic

1. Métriques 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 (devrait 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 rate limit events

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

4. Etat promtail (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 + fix

Cause Symptôme logs Fix
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 cardinality labels (voir ci-dessous)
Stockage object storage saturé upload to S3 failed, no space left Libérer S3 bucket loki OR bump retention plus agressive
CPU throttling ingester context deadline exceeded Bump resources.limits.cpu logs layer
Compactor en retard too many small chunks Vérifier compactor Running + logs
Mauvaise indexation Latence querys élevée Vérifier schema_config version et period

Réduire la cardinality (fix #1 pour "too many streams")

Labels à BANNIR de log shipper pipeline (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)

Fix pérenne (R02)

Bump limits logs layer

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

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

Purger les vieux logs

# Boulot 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 per tenant
  • Streams per tenant
  • Rate limit hits
  • Ingester CPU/Memory
  • PrometheusRule précoce : warning à 70% de la limite
  • Review mensuel des labels log shipper → détecter nouvelles explosions cardinality

Lessons learned

  • L10 — logs layer retention 30j 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