Funk-lab/admin/incidents.md

Incidents — Historique et résolutions

Index

Date	Composant	Résumé	Sévérité
2026-05-14	Grafana	OOMKilled — limite 256Mi trop serrée pour Grafana 13	Warning
2026-05-13	AlertManager	Receiver "null" non défini — ReconciliationFailed	Warning
2026-05-13	llama-server	/metrics retourne 501 Not Implemented — flag --metrics absent	Warning
2026-05-13	nftables storage-01	Règle monitoring ajoutée après le drop — paquets bloqués	Warning
2026-05-13	storage-01	Corruption EXT4 + réinstallation hermes-agent	Critique
2026-05-11	storage-01	Boucle fsck après coupure de courant — XFS corrompu	Critique

---

2026-05-14 — Grafana : OOMKilled (limite mémoire trop serrée)

Symptôme

Erreurs "No available server" intermittentes sur grafana.lab.local. Pod en CrashLoop.

kubectl describe pod -n monitoring -l app.kubernetes.io/name=grafana
# → Last State: Terminated, Reason: OOMKilled, Exit Code: 137
# → RESTARTS: 5

Cause

Limite mémoire à 256Mi dans k8s/infra/monitoring/values.yaml. Grafana 13 consomme plus que ses prédécesseurs — OOM systématique. Traefik perd le backend pendant chaque redémarrage.

Résolution

Augmenter les limites dans k8s/infra/monitoring/values.yaml :

grafana:
  resources:
    requests:
      memory: 256Mi
    limits:
      memory: 1Gi   # était 256Mi

git push → ArgoCD applique → pod redémarre proprement.

---

2026-05-13 — AlertManager : ReconciliationFailed — receiver "null" non défini

Symptôme

AlertManager en erreur dans ArgoCD. Logs :

level=error msg="loading configuration" err="undefined receiver \"null\" used in route"

Cause

kube-prometheus-stack génère en interne une sous-route référençant le receiver "null" pour le heartbeat Watchdog. Une config AlertManager custom qui ne définissait pas ce receiver cassait la validation.

Résolution

Ajouter explicitement le receiver et la route dans values.yaml :

alertmanager:
  config:
    route:
      routes:
        - matchers:
            - alertname = "Watchdog"
          receiver: "null"
          repeat_interval: 24h
    receivers:
      - name: "null"   # obligatoire même si vide

---

2026-05-13 — llama-server : /metrics retourne 501 Not Implemented

Symptôme

Prometheus ne scrappe rien sur les jobs llama-server-*. Targets en erreur avec 501 Not Implemented.

Cause

Le flag --metrics doit être passé explicitement à llama-server pour activer l'endpoint /metrics. Sans lui, la route existe mais répond 501.

Résolution

Ajouter --metrics dans le service systemd (template Ansible llama-server.service.j2) :

ExecStart=/opt/llama.cpp/build/bin/llama-server \
    ...
    --metrics \
    --log-disable

Fix live sur les 3 instances + daemon-reload + restart :

# Sur gpu-01
for svc in llama-server llama-server-system llama-server-monitor; do
  sudo sed -i 's/--log-disable/--metrics \\\n    --log-disable/' /etc/systemd/system/$svc.service
done
sudo systemctl daemon-reload
sudo systemctl restart llama-server llama-server-system llama-server-monitor

---

2026-05-13 — nftables storage-01 : règle monitoring bloquée par le drop

Symptôme

Prometheus ne pouvait pas scrapper storage-01:9100 (node_exporter) ni recevoir les webhooks AlertManager sur :9093. Targets en connection refused dans Prometheus.

Cause

nft add rule ajoute la règle en fin de chaîne, après la règle terminale log prefix "nft-drop:" drop. Les paquets étaient droppés avant d'atteindre la nouvelle règle.

# Vérifier l'ordre
sudo nft -n -a list chain inet filter input
# → handle 22 : log drop  (terminal)
# → handle 27 : tcp dport { 9093, 9100 } accept  (ajouté APRÈS → jamais atteint)

Résolution

Supprimer la règle mal placée et la réinsérer avant le drop avec insert rule position :

sudo nft delete rule inet filter input handle 27
sudo nft insert rule inet filter input position 22 \
  tcp dport { 9093, 9100 } ip saddr 192.168.10.0/24 accept

Fix permanent dans le template Ansible nftables.conf.j2 : placer la règle avant la règle drop.

---

2026-05-13 — storage-01 : corruption EXT4 après arrêt brutal + reinstall hermes-agent

Symptômes

• hermes-agent en boucle de crash : SyntaxError: source code string cannot contain null bytes
• Erreurs EXT4 au démarrage des services : Directory block failed checksum, deleted inode referenced
• dmesg : EXT4-fs (md0): error count since last fsck: 655
• sdb : erreurs ATA bus (SError: { RecovComm HostInt PHYRdyChg PHYInt }) et I/O error sector 13405184

Cause racine

Arrêt brutal du cluster la veille (funk-stop --k8s) → journal ext4 non rejoué correctement → 655 erreurs de corruption sur /dev/md0. sdb avait des erreurs transitoires mais SMART PASSED (pas de défaillance matérielle).

Résolution étape par étape

1. Vérifier SMART sdb

smartctl -H /dev/sdb
# SMART overall-health self-assessment test result: PASSED → purement logiciel

2. Arrêter les services et démonter

sudo systemctl stop hermes-agent litellm qdrant postgresql-16 nfs-server
sudo umount /srv/data

3. Réparer le filesystem

sudo e2fsck -f -y /dev/md0
# 655 erreurs corrigées : HTREE invalides, blocs multiplement revendiqués,
# checksums de répertoires incorrects, compteurs d'inodes wronge

4. Remonter et redémarrer les services

sudo mount /srv/data
sudo systemctl start postgresql-16 qdrant litellm hermes-agent nfs-server

5. Hermes-agent toujours en erreur après fsck

Le e2fsck a zéroïsé des blocs appartenant à plusieurs inodes simultanément → des fichiers du venv Python et du code source hermes_cli/ ont été corrompus (null bytes).

Tentatives de réparation du venv échouées (pip install -e . crash, uv.lock corrompu).

6. Réinstallation complète de hermes-agent

# Supprimer le code source corrompu (les profils dans /srv/data/hermes/profiles/ ne sont PAS touchés)
sudo rm -rf /srv/data/hermes/hermes-agent
sudo rm /opt/hermes/.local/bin/hermes

# Réinstaller depuis le script officiel (depuis un répertoire valide)
cd /srv/data/hermes
sudo -u hermes bash -c 'cd /srv/data/hermes && HOME=/opt/hermes HERMES_HOME=/srv/data/hermes curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash'

Lors du sudo rm -rf, ne pas rester dans le répertoire supprimé — le shell perd le CWD et le script d'installation échoue avec getcwd: cannot access parent directories.

Résultat : hermes-agent réinstallé dans /opt/hermes/.hermes/hermes-agent/ (SSD OS, plus de RAID5). Tous les profils (funk-ai, brain, system, monitor) intacts dans /srv/data/hermes/profiles/.

Changement d'architecture post-incident

Avant	Après
Code hermes-agent : /srv/data/hermes/hermes-agent/ (RAID5)	Code hermes-agent : /opt/hermes/.hermes/hermes-agent/ (SSD OS)
Venv : /srv/data/hermes/hermes-agent/venv/	Venv : /opt/hermes/.hermes/hermes-agent/venv/
Profils/données : /srv/data/hermes/	Profils/données : /srv/data/hermes/ (inchangé)

Le code étant désormais sur le SSD, une corruption future du RAID5 n'impactera plus l'installation — seulement les profils et données.

Surveillance post-incident

# Santé RAID et disques
cat /proc/mdstat
smartctl -H /dev/sdb    # à surveiller

# Vérifier que e2fsck n'a pas schedulé un check au prochain boot
sudo tune2fs -l /dev/md0 | grep -E "check|count|error"

---

2026-05-11 — storage-01 : boucle fsck après coupure de courant

Symptômes

• Boucle infinie de fsck au démarrage sur /dev/md0
• You are in emergency mode. Give root password for maintenance — mot de passe impossible à saisir (messages défilants)
• Après résolution : hermes-agent en boucle d'erreurs (cause : /srv/data non monté)

Architecture concernée

Composant	Détail
Disque système	NVMe nvme0n1 — LVM (almalinux-root XFS 70G, swap 14.7G, home 845G)
RAID données	RAID5 software md0 — 4 disques SATA 931.5G (sda1, sdb2, sdc1, sdd1)
Point de montage	/srv/data (ext4)

Cause racine

La coupure de courant a corrompu le système de fichiers XFS sur almalinux-root. Au redémarrage, systemd tentait de vérifier /srv/data avant que le RAID md0 soit assemblé → boucle bloquante.

Résolution étape par étape

1. Shell de secours via GRUB

Au démarrage, appuyer sur Shift pour afficher le menu GRUB. Appuyer sur e pour éditer la ligne linux :

• Remplacer ro par rw
• Ajouter init=/bin/bash en fin de ligne

Démarrer avec Ctrl+X.

2. Activer le LVM

lvm vgchange -ay
# 3 logical volume(s) in volume group "almalinux" now active

3. Réparer le XFS (pas fsck)

XFS nécessite xfs_repair, pas fsck :

umount /dev/mapper/almalinux-root
xfs_repair /dev/mapper/almalinux-root
# Phases 1 à 7 — succès

4. Désactiver temporairement /srv/data dans fstab

vi /etc/fstab
# Commenter la ligne /srv/data pour permettre le boot sans RAID

5. Reboot → système normal, RAID intact [4/4] [UUUU].

Fix permanent — fstab

Modifier la ligne /srv/data dans /etc/fstab :

# Avant
UUID=3add8360-fa01-47eb-0aa1-0e84bacbbc15 /srv/data ext4 defaults,noatime,nodiratime 0 2

# Après
UUID=3add8360-fa01-47eb-0aa1-0e84bacbbc15 /srv/data ext4 defaults,noatime,nodiratime,_netdev 0 0

Changement	Effet
0 2 → 0 0	Désactive la vérification fsck automatique au boot
_netdev	Force systemd à attendre que tous les périphériques (RAID) soient prêts avant de monter

Surveillance post-incident

# État du RAID
cat /proc/mdstat

# Santé des disques (sdb a généré des erreurs I/O — à surveiller)
smartctl -a /dev/sda
smartctl -a /dev/sdb
smartctl -a /dev/sdc
smartctl -a /dev/sdd

# Monter /srv/data manuellement si besoin
mount /srv/data

# Logs de boot
journalctl -xb | grep -i "error\|fail"

Points d'attention

• sdb a généré des erreurs I/O pendant l'incident — il est revenu opérationnel mais doit être surveillé régulièrement avec smartctl.
• Envisager un onduleur (UPS) pour prévenir ce type d'incident sur coupure de courant.
• Le fix fstab (_netdev, 0 0) est permanent — ne pas revenir aux valeurs précédentes.