Monitoring : Graylog, Uptime Kuma et Prometheus

Introduction

Un homelab qui héberge des services critiques (DNS, proxy, mail, web) nécessite une observabilité complète. Sans monitoring, les pannes sont découvertes par les utilisateurs, les dégradations de performance passent inaperçues, et le diagnostic post-incident devient un exercice de devinette. Cet article présente la stack de monitoring en trois piliers : Graylog pour la centralisation des logs, Uptime Kuma pour la disponibilité, et Prometheus pour les métriques système et applicatives.

Architecture globale

┌────────────────────────────────────────────────────────────────────┐
│                      Stack Monitoring                               │
│                                                                    │
│  ┌─────────────┐     ┌─────────────┐     ┌─────────────────────┐  │
│  │  Services   │     │  Graylog    │     │   Dashboards        │  │
│  │  (sources)  │────▶│  7.x        │────▶│   Graylog UI        │  │
│  │             │     │  Pipelines  │     │                     │  │
│  └─────────────┘     └─────────────┘     └─────────────────────┘  │
│        │                                                           │
│        │             ┌─────────────┐     ┌─────────────────────┐  │
│        │             │ Uptime Kuma │     │   Notifications     │  │
│        └────────────▶│ 30+ checks  │────▶│   Alertes           │  │
│        │             └─────────────┘     └─────────────────────┘  │
│        │                                                           │
│        │             ┌─────────────┐     ┌─────────────────────┐  │
│        └────────────▶│ Prometheus  │────▶│   Home Assistant    │  │
│                      │ Exporters   │     │   Lovelace Cards    │  │
│                      └─────────────┘     └─────────────────────┘  │
└────────────────────────────────────────────────────────────────────┘

Graylog 7.x : Centralisation des logs

Graylog est le cerveau de l'analyse de logs du homelab. Déployé sur un container LXC dédié avec MongoDB et un DataNode OpenSearch intégré, il reçoit les logs de l'ensemble des services via des inputs Syslog UDP.

Sources de logs

Tous les composants de l'infrastructure envoient leurs logs vers Graylog :

Firewall : logs de toutes les règles (accept, drop, reject) avec IPs source/destination, ports, protocole
DNS (BIND9) : queries et réponses, clients, domaines demandés, vues (interne/externe)
Proxy (Squid) : accès HTTP/HTTPS, URLs, codes de réponse, temps de latence, cache hit/miss
ICAP (ClamAV) : résultats d'analyse antivirus sur le trafic web proxifié
Web (nginx/WAF) : requêtes HTTP, User-Agents, codes de statut, règles ModSecurity déclenchées
IPS (Suricata) : alertes et drops de l'Intrusion Prevention System

Les 4 pipelines d'extraction

Les logs bruts sont traités par des pipelines de processing qui extraient des champs structurés pour permettre une recherche et une visualisation efficaces :

1. Pipeline Firewall

Extrait depuis les messages syslog du routeur :

source_ip / destination_ip : IPs impliquées dans la connexion
source_port / destination_port : ports TCP/UDP
fw_rule : nom de la règle firewall ayant matché
fw_action : accept, drop, ou reject
GeoIP enrichment : pays, ville, coordonnées géographiques à partir des IPs publiques

2. Pipeline DNS

Parse les query logs BIND9 :

dns_client_ip : IP du client ayant fait la requête
dns_domain : domaine demandé (ex: example.com)
dns_query_type : A, AAAA, MX, TXT, etc.
dns_view : vue BIND ayant répondu (interne/externe/iot)
GeoIP sur le client pour les requêtes depuis l'extérieur

3. Pipeline Web

Décompose les access logs nginx/WAF :

http_method : GET, POST, PUT, DELETE
http_url : URI de la requête
http_status : code de réponse (200, 301, 403, 404, 500)
http_user_agent : navigateur ou bot
http_response_time : temps de réponse en millisecondes

4. Pipeline Proxy

Parse le format custom de Squid et les logs ICAP :

squid_client_ip : IP du client proxifié
squid_request_url : URL complète demandée
squid_result_code : TCP_HIT, TCP_MISS, TCP_DENIED
squid_response_time : latence totale
icap_mode : reqmod ou respmod
icap_response_code : résultat de l'analyse ICAP (200=clean, 403=blocked)

Gotcha : application_name absent en RFC3164

Un piège classique avec Graylog et rsyslog : lorsque les messages sont forwardés au format RFC3164 (le format syslog legacy, le plus courant), le champ application_name n'est PAS peuplé par l'input Syslog UDP de Graylog. Le programme source est inclus dans le champ message brut sous la forme HOSTNAME APP[PID]: MSG.

Pour filtrer sur un programme spécifique dans les pipelines, il faut utiliser contains(to_string($message), "named[") et NON $message.application_name == "named". Cette subtilité cause régulièrement des pipelines silencieusement inactifs lors de leur première création.

Uptime Kuma : Monitoring de disponibilité

Uptime Kuma surveille la disponibilité de plus de 30 services via des probes régulières. Déployé en container Podman sur le routeur principal (dans sa propre zone réseau isolée), il a une visibilité sur tous les segments du réseau.

Types de monitors

HTTP/HTTPS : vérifie le code de réponse, le contenu de la page, le certificat TLS (expiration, validité)
TCP : vérifie qu'un port est ouvert et accepte les connexions
DNS : vérifie la résolution d'un domaine et la cohérence de la réponse
Domain Expiry (RDAP) : vérifie la date d'expiration des domaines pour anticiper les renouvellements

Gotcha : Squid doit être monitoré en HTTP, pas en TCP

Un probe TCP sur le port du proxy Squid établit une connexion TCP nue sans envoyer de requête HTTP. Squid attend des données HTTP, ne les reçoit pas, et génère une erreur transaction-end-before-headers dans ses logs pour chaque probe. Avec un intervalle de 60 secondes, cela pollue massivement les logs.

Solution : utiliser un probe HTTP vers http://<proxy-ip>:<port>/ qui retourne une erreur 400 (ERR_INVALID_URL) — parfaitement valide comme indicateur de santé. Configurer le monitor avec accepted_statuscodes: ["400"].

Gotcha : RDAP .fr et "Invalid Date"

Les monitors domain expiry pour les domaines en .fr (gérés par l'AFNIC) retournent systématiquement "Invalid Date" même lorsque le service RDAP est joignable. Le format de date renvoyé par l'AFNIC dans ses réponses RDAP ne correspond pas au format standard attendu par Uptime Kuma. C'est un warning bénin — le monitoring HTTP du domaine lui-même reste fonctionnel.

Prometheus : Métriques système et applicatives

Prometheus collecte les métriques time-series depuis tous les hôtes et services via le protocole pull (scrape HTTP sur les endpoints /metrics).

Exporters déployés

node_exporter (tous les hôtes)

Présent sur chaque machine physique et VM, expose :

CPU : utilisation par core, temps idle, iowait, steal
RAM : utilisée, disponible, buffers, cache, swap
Disque : IOPS, latence, utilisation par partition, santé SMART
Réseau : bytes/paquets in/out par interface, erreurs, drops
Température : sondes hwmon (CPU, chipset, disques)

phpfpm-exporter (pods K3s)

Tourne en sidecar dans les pods WordPress, expose les métriques du pool PHP-FPM :

Processus actifs / idle / total
Requêtes lentes (slow requests) au-delà du seuil configuré
Queue d'attente (listen queue) — indicateur de saturation
Nombre de processus créés/détruits (churn)

nginx-exporter (pods K3s)

Également en sidecar, expose les métriques nginx :

Connexions actives / reading / writing / waiting
Requêtes totales et par seconde
Distribution des codes de statut HTTP (2xx, 3xx, 4xx, 5xx)

Intégration Proxmox

L'hyperviseur Proxmox expose des métriques spécifiques via node_exporter :

RAPL (Running Average Power Limit) : consommation électrique en watts mesurée par les compteurs intégrés au CPU Intel
Températures : CPU package, cores individuels, chipset PCH
GPU NVIDIA : utilisation, mémoire, température, puissance (via nvidia_gpu_exporter pour le transcodage Plex)

Visualisation : Home Assistant Lovelace

Les données Prometheus sont consommées par Home Assistant via des senseurs REST qui interrogent l'API Prometheus. Des custom Lovelace cards développées en JavaScript affichent :

Diagrammes de consommation électrique en temps réel
Graphiques de température avec seuils d'alerte
Status des VMs et containers avec indicateurs de santé
Métriques réseau agrégées par VLAN

Flux de données complet

┌──────────────────────────────────────────────────────────────┐
│                    Flux de monitoring                          │
│                                                              │
│  Services ──rsyslog──▶ Graylog UDP ──▶ Pipelines ──▶ Search  │
│     │                                                        │
│     │──node_exporter──▶ Prometheus ──▶ HA Lovelace           │
│     │                                                        │
│     └──HTTP probes────▶ Uptime Kuma ──▶ Notifications        │
│                                                              │
│  Alertes :                                                   │
│    • Graylog : stream rules → email/webhook si pattern       │
│    • Kuma : down > 3 checks → notification instantanée       │
│    • Prometheus : alertmanager rules (optionnel)              │
└──────────────────────────────────────────────────────────────┘

Bonnes pratiques opérationnelles

Rétention et dimensionnement

Graylog : index rotation par taille (1 Go) avec rétention 30 jours. Les logs firewall (très volumineux) ont un index séparé avec rétention 7 jours
Prometheus : rétention locale 15 jours, suffisant pour le troubleshooting court terme
Uptime Kuma : historique SQLite, pas de purge automatique (volume négligeable)

Séparation des concerns

Graylog pour le diagnostic ("que s'est-il passé ?")
Uptime Kuma pour la disponibilité ("est-ce que ça marche ?")
Prometheus pour la performance ("comment ça se comporte ?")

Chaque outil a son rôle précis. Éviter de demander à Graylog de faire du monitoring de disponibilité ou à Prometheus d'analyser des logs textuels.

Alerting sans fatigue

Le piège classique du monitoring est l'alert fatigue : trop d'alertes non-actionnables finissent ignorées. Règles appliquées :

Alertes uniquement sur les conditions actionnables immédiatement
Seuils adaptés aux patterns normaux (pas d'alerte CPU à 80% si c'est le niveau habituel pendant les backups nocturnes)
Notifications groupées pour les événements corrélés
Revue mensuelle des alertes déclenchées pour ajuster les seuils

Conclusion

La combinaison Graylog + Uptime Kuma + Prometheus couvre les trois dimensions essentielles de l'observabilité : logs, disponibilité et métriques. Chaque composant est spécialisé dans son domaine, évitant la complexité d'une solution monolithique. Le coût opérationnel est maîtrisé : Uptime Kuma et les exporters Prometheus sont quasi-autonomes, et les pipelines Graylog ne nécessitent une attention que lors de l'ajout de nouvelles sources de logs. Cette architecture supporte facilement la croissance du homelab — ajouter un nouveau service revient à configurer son envoi syslog vers Graylog et déployer le probe Kuma correspondant.