Comment l'assistant On-Call d'Ongrid investigate les incidents directement dans les messagers

Imaginez un scénario on-call typique. À trois heures du matin, une alerte se déclenche : les temps de réponse de l'API ont quintuplé. Vous ouvrez votre ordinateur portable d'un œil ensommeillé, plissez les yeux devant une douzaine de tableaux de bord dans Grafana, puis vous vous connectez en SSH aux nœuds via un hôte bastion et vous greppez frénétiquement dans les logs. Trouver la cause racine prend une demi-heure, alors que le problème n'était qu'un pod crashé ou une transaction bloquée.

Les auteurs du projet open source Ongrid ont décidé de déléguer cette routine à une combinaison d'agents IA spécialisés et d'une pile d'observabilité prête à l'emploi.

Ce que le système peut faire

Ongrid fonctionne comme un ingénieur on-call autonome. Il se connecte aux messagers comme Telegram ou Slack, écoute les alertes entrantes et lance immédiatement l'investigation.

Le système est construit sur une architecture coordinator et specialists étroits. Lorsqu'une alerte arrive, l'agent principal crée un worker pour l'analyse de la cause racine. Ce worker interroge les agents pour les bases de données, les réseaux ou le SRE, collecte les métriques, les logs et les traces, construit une carte de dépendances et livre un rapport prêt dans le chat pointant vers la ligne de code spécifique ou le service défaillant.

Sécurité et contrôle d'accès

Le pire cauchemar de tout administrateur système qui entend « un agent en production » est l'hallucination du modèle qui exécute une commande dangereuse et fait tomber la base de données. Les développeurs d'Ongrid ont abordé cela de manière pragmatique.

Premièrement, les utilitaires hôtes et le bac à sable bash fonctionnent en mode lecture seule par défaut. L'agent peut exécuter des commandes de diagnostic, vérifier l'état des processus ou inspecter les états des sockets, mais ne redémarrera pas silencieusement le serveur.

Deuxièmement, toutes les actions potentiellement destructives sont protégées par un gateway d'approbation spécial. Avant d'appliquer un correctif, le bot demandera l'approbation de l'ingénieur on-call dans le chat ou l'interface web.

Troisièmement, les hôtes n'ont pas besoin de ports entrants ouverts du tout. Un agent Edge léger est installé sur les serveurs cibles, qui établit une connexion sortante vers le serveur Ongrid lui-même. L'accès SSH via le terminal web fonctionne sur un tunnel inverse, sans exposer le port 22 vers l'extérieur et sans se battre avec les clés sur les hôtes bastion. Chaque invocation est journalisée à des fins d'audit.

Observabilité, topologie et Kubernetes

À l'intérieur, une pile préconfigurée de Prometheus, Loki, Tempo et Grafana est déjà en place. La différence est que l'agent lui-même écrit les requêtes dedans, corrélant les timestamps des événements avec les traces OpenTelemetry.

La gestion des clusters Kubernetes a été récemment ajoutée au projet. L'agent connecte les clusters via Edge, suit les événements de workload, aide à gérer les mises à niveau et projette les pods sur une carte topologique partagée.

La carte topologique aide à évaluer le rayon d'impact d'un incident. Si un switch réseau ou une base de données tombe, le système visualise tous les services dépendants, en filtrant les faux positifs.

Base de connaissances et expansion des compétences

Tout LLM est inutile sans contexte sur votre infrastructure. Ongrid inclut un coffre-fort de connaissances où vous pouvez télécharger des runbooks, des postmortems passés et des dépôts de code. La recherche vectorielle basée sur Qdrant trouve les instructions pertinentes et les transmet à l'agent pendant l'analyse des incidents.

Si les outils standards ne suffisent pas, vous pouvez en ajouter d'autres via le MCP (Model Context Protocol) ou construire votre propre scénario dans l'éditeur de workflows visuel.

Les rapports et tableaux de bord générés sont sauvegardés dans le centre d'artefacts, où ils sont faciles à partager avec l'équipe pendant les postmortems.

Sous le capot et pile de modèles

Le backend de la plateforme est écrit en Go, et le frontend est construit avec React et TypeScript. La solution peut être déployée entièrement sur vos propres serveurs sous la licence AGPLv3.

En ce qui concerne les modèles de langage, le projet n'est pas lié à un seul fournisseur. Vous pouvez utiliser Claude d'Anthropic, OpenAI, DeepSeek, Gemini ou des instances locales, en changeant le routage des modèles à la volée selon la complexité de la tâche.

Comment déployer sur votre propre serveur

L'installation sur Ubuntu, Debian ou Rocky Linux se fait avec un script prêt à l'emploi :

# Для архитектуры AMD64
wget https://github.com/ongridio/ongrid/releases/download/v0.12.0/ongrid-v0.12.0-linux-amd64.tar.xz
tar -xf ongrid-v0.12.0-linux-amd64.tar.xz && cd ongrid-v0.12.0-linux-amd64
sudo ./install.sh

Pour ARM64, remplacez simplement le nom de l'archive par la release correspondante. Le script lancera le composant serveur et l'interface web, après quoi vous n'aurez plus qu'à configurer la connexion au messager et installer l'agent Edge sur les hôtes.

Qui devrait l'essayer

Ongrid est utile pour les équipes opérationnelles petites et moyennes où il n'y a pas de centre d'opérations réseau (NOC) 24h/24, et où les développeurs se relaient en on-call. Cela atténue la vague initiale de panique pendant un incident en collectant immédiatement les logs et en localisant le problème jusqu'à un résumé clair.

Le projet est encore jeune (environ 700 étoiles sur GitHub), mais architecturalement il semble mature grâce à son focus sur la sécurité et l'utilisation des standards de télémétrie ouverte.