Poseidon : Prédire les crashs de serveurs avec l’IA chez DigitalOcean

Temps de lecture : 6 min

Le défi des environnements cloud à grande échelle

Dans les infrastructures cloud modernes, les crashs imprévisibles d’hyperviseurs ont un coût opérationnel bien réel. L’approche réactive traditionnelle, avec ses seuils statiques et ses alertes post-mortem, ne suffit plus face aux signaux non linéaires stochastiques qui précèdent les défaillances matérielles. Aujourd’hui, en avril 2026, la haute disponibilité est une norme, et le passage de l’observation réactive à la décision proactive devient une nécessité architecturale.

Ce défi prend une dimension nouvelle avec l’explosion des infrastructures GPU. DigitalOcean a investi massivement dans ses datacenters dédiés à l’IA à Richmond et Atlanta, hébergeant les dernières puces NVIDIA H100 (Hopper) et Blackwell (B300), ainsi que les accélérateurs AMD Instinct MI350X. Ces GPU Droplets alimentent des pipelines d’entraînement de grands modèles de langage (LLM) et des moteurs d’inférence, des charges de travail où une seule panne de nœud peut ralentir ou bloquer des semaines d’entraînement critique. Dans cet environnement à haute tension, les seuils de monitoring classiques sont obsolètes.

Pour dépasser la simple mitigation réactive, DigitalOcean développe Poseidon : un système d’intelligence hybride multi-étapes qui combine Machine Learning (ML) et IA Générative (GenAI) pour identifier les nœuds « à risque » avant un crash imminent. Poseidon opère en arrière-plan sur l’ensemble du parc mondial, filtrant la télémétrie et les logs d’événements système pour isoler la petite fraction de nœuds montrant des signes de détresse matérielle.

Le paradoxe données-coût

La première difficulté dans la modélisation prédictive pour le cloud réside dans le paradoxe données vs coût. Notre infrastructure compte des milliers d’hyperviseurs générant des volumes massifs de données. Les traiter toutes serait prohibitif. Poseidon résout ce problème avec une approche d’investigation en plusieurs niveaux, qui concentre les ressources de calcul là où elles sont vraiment nécessaires.

Concrètement, la première étape de Poseidon est un double filtre qui agit comme un portier. En combinant des modèles ML statistiques légers avec une analyse sémantique de logs basée sur l’IA générative, on élimine efficacement plus de 98 % de l’espace de recherche. Cela permet au système de consacrer ses ressources de « collecte profonde » exclusivement aux quelques nœuds restants qui justifient une investigation plus poussée. Dans nos tests internes, la liste des nœuds « à risque » après cette étape ne représente jamais plus de 2 % du total.

Étape 1 : Un filtrage haute vélocité

La première ligne de défense du pipeline de Poseidon est un filtre de télémétrie haute vitesse, conçu pour une économie de calcul maximale. On exploite la plateforme d’observabilité existante pour exécuter une série de requêtes PromQL ciblées, agissant comme des déclencheurs de détection d’instabilité matérielle.

Ces requêtes extraient des métriques à fort signal et à faible latence, en se concentrant sur :

• Les variations rapides de température CPU et GPU
• Les pics non linéaires d’utilisation CPU et mémoire
• Les instabilités de l’alimentation (PSU)

Concrètement, voici deux exemples de requêtes PromQL typiques :

• Température CPU moyenne (5 min) : Cette requête agit comme un détecteur thermique rapide. En moyennant la température sur une fenêtre glissante de 5 minutes, on obtient un indicateur instantané de la santé thermique du nœud.
• Fréquence CPU moyenne (10 min) : On calcule la vitesse d’horloge moyenne sur 10 minutes, convertie en Gigahertz. On utilise cette métrique légère pour détecter le thermal throttling, moment où un CPU stressé réduit volontairement sa performance pour survivre à une surchauffe.

Ces fenêtres temporelles serrées fournissent un rapport quasi instantané de l’état du nœud sans congestionner le réseau. Les données brutes sont ensuite streamées vers un modèle ML léger optimisé pour la vitesse d’inférence. Ce modèle n’essaie pas de poser un diagnostic complet : il est entraîné à détecter les motifs stochastiques subtils que les seuils statiques traditionnels ignorent. Si le modèle détecte une signature de risque, le nœud est marqué et transmis à l’étape suivante.

Analyse sémantique des logs avec un LLM

Dans chaque serveur de notre flotte se trouve le contrôleur de gestion de carte mère (BMC), un microcontrôleur dédié qui fonctionne indépendamment du CPU hôte et du système d’exploitation. Il constitue la source de vérité sur la santé matérielle, capturant ses observations dans le journal d’événements système (SEL) : un registre horodaté et granulaire qui consigne tout, des fluctuations de tension aux erreurs mémoire catastrophiques.

Les logs SEL sont extrêmement précieux pour la forensique matérielle, mais difficiles à analyser à grande échelle. Leurs formats varient considérablement entre fabricants et même entre versions de firmware. Les analyseurs regex classiques échouent souvent devant cette hétérogénéité ou perdent le contexte sémantique. Poseidon résout ce problème en streamant ces logs à travers un LLM affiné personnalisé. Au lieu de chercher des chaînes de caractères littérales, le LLM interprète l’intention et la gravité des signaux de détresse du matériel.

Le modèle de langage catégorise alors les nœuds en trois catégories :

• Critique : Si le LLM identifie un motif d’erreur fatale connu.
• Risqué : Si les logs montrent des signes d’instabilité.
• Sain : Si le nœud poursuit un fonctionnement normal.

Si le modèle prédit un nœud critique, on le transmet directement à notre système d’automatisation pour action immédiate. S’il est classé risqué, on l’envoie vers la Phase 2 pour une analyse plus approfondie. En séparant le signal du bruit, on concentre nos efforts sur un sous-ensemble beaucoup plus restreint de nœuds potentiellement problématiques.

Phase 2 : Collecte profonde et modélisation hybride

Une fois la liste des candidats réduite, Poseidon déclenche un événement de collecte profonde pour les nœuds marqués. Dans cette phase, on exécute des requêtes PromQL à haute résolution sur des fenêtres temporelles étendues (de 60 minutes à 24 heures) pour capturer des métriques granulaires : fréquence CPU, utilisation mémoire, débit réseau, etc.

Ce que signifie concrètement « haute résolution » ? Il s’agit d’extraire des données de séries temporelles continues et très granulaires sur une longue période. Là où la Phase 1 utilise des instantanés courts et légers pour détecter un danger immédiat, la collecte profonde tire un historique dense et détaillé des métriques. Cela donne au modèle ML la fidélité nécessaire pour analyser les micro-tendances, la dégradation thermique lente, ou les pics transitoires qu’un rapide contrôle de santé manquerait.

Exemples de requêtes PromQL haute résolution :

• Utilisation CPU (12h) : Capture la charge de calcul sur une fenêtre de 12 heures, sans moyenne, point par point, pour cartographier la forme réelle de la charge de travail et repérer les motifs d’utilisation erratique.
• Température d’échappement (1h) : Fournit un flux continu de données environnementales pour différencier un stress matériel interne d’une panne de refroidissement externe, identifiant les baisses de performance des systèmes de climatisation ou les goulots d’étranglement localisés dans un rack.

Ces données de télémétrie haute résolution sont ingérées par un modèle ML hybride, qui fusionne le flux de données profond avec le contexte comportemental plus large collecté en Phase 1. Ce modèle calcule alors un score de probabilité précis pour un crash imminent dans la fenêtre d’observation à venir. Si ce score dépasse notre seuil de sécurité, le nœud est immédiatement remis à notre système d’automatisation pour prise en charge.

Boucle de rétroaction : amélioration continue

Un modèle prédictif ne vaut que par son dernier jeu d’entraînement. Pour que Poseidon évolue avec notre infrastructure, on a mis en place un pipeline d’amélioration continue :

• Curatation automatisée des jeux de données : Un cron job Kubernetes récurrent corrèle les nœuds ayant crashé en production avec leurs logs et leur historique de télémétrie.
• Expérimentation et réglage : Avec Ray Tune, on réalise de l’optimisation d’hyperparamètres sur différentes architectures de modèles (XGBoost, LSTMs, Transformers).
• Évaluation A/B : Les nouvelles versions de filtres sont exécutées en ombre contre le modèle de production. On ne promeut un modèle aux étapes de filtrage ou d’analyse approfondie que s’il démontre un meilleur F1-score ou un meilleur rappel sans augmenter significativement le taux de faux positifs.

Choix de conception clés

Voici les deux décisions architecturales qui méritent d’être soulignées :

• Inférence localisée, intelligence centralisée : Poseidon fonctionne comme un système distribué avec exécution locale dans chacun de nos 14 datacenters mondiaux. Cette approche « edge-first » garantit une latence minimale, permettant au système de réagir en quasi temps réel à une instabilité. Pendant que l’inférence se fait localement, la curation des données et le réentraînement des modèles se font à un hub central. Une fois validé, le nouveau modèle est automatiquement distribué à toute la flotte, chaque datacenter bénéficiant des insights globaux.
• Priorité au rappel sur la précision : Pour l’étape de filtrage, on a intentionnellement optimisé les modèles pour le rappel plutôt que pour la précision brute. En favorisant le rappel, on jette un filet large pour s’assurer qu’aucun indicateur subtil d’instabilité ne passe au travers.

Lutter contre la dérive des données

L’infrastructure n’est jamais statique. L’introduction de nouveaux matériels et firmwares fait évoluer les signatures de défaillance, un phénomène appelé dérive des données (data drift). Pour rester en avance, on maintient une boucle de réentraînement fréquent. Ce processus est gouverné par des « portes de sécurité » strictes : chaque modèle mis à jour doit passer des benchmarks automatisés de F1-score et de rappel avant d’être promu en production, garantissant que nos standards prédictifs ne fléchissent pas.

Conclusion : de la réaction à la prédiction

Le projet Poseidon représente un changement fondamental : passer du constat de ce qui est arrivé à la prévision de ce qui va arriver. En fusionnant l’intuition sémantique de l’IA générative avec la précision statistique du Machine Learning traditionnel, DigitalOcean construit une infrastructure qui ne se contente pas de signaler une panne, mais qui la devance. L’objectif est simple : nous gérons la complexité du matériel de nouvelle génération et la turbulence de la stabilité des hyperviseurs, pour que nos clients puissent se concentrer sur la construction de l’avenir de l’IA.

Poseidon est un projet en cours chez DigitalOcean. Si vous êtes intéressé à travailler sur des problèmes comme celui-ci — infrastructure prédictive, fiabilité matérielle à l’échelle cloud, ou systèmes ML qui s’améliorent avec le temps — nous recrutons.