# 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.

```bash
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` :

```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` :

```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`) :

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

Fix live sur les 3 instances + `daemon-reload` + restart :
```bash
# 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.

```bash
# 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` :

```bash
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**

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

**2. Arrêter les services et démonter**

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

**3. Réparer le filesystem**

```bash
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**

```bash
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**

```bash
# 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

```bash
# 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**

```bash
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` :

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

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

```bash
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

```bash
# É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.