Est-ce qu’il serait pertinent en utilisant une technique de NLP de prédire à partir d’une phrase l’action qui vient de se produire (notamment grâce à la négation dans le phrase) et d’informer en cas de besoin l’utilisateur par mail sans que celui-ci n’ai besoin de checker les logs manuellement ?
Non. C’est dégainer un missile intercontinental pour écraser un moustique.
Tu peux obtenir des résultats beaucoup plus facilement en te contentant de structurer tes logs, dans un format comme json ou logfmt. Rien qu’avec ça, les logs deviennent triviaux à parser / indexer / requêter avec un scrapper comme Loki (que j’utilise au boulot), ce qui permet de configurer des alertes ou des dashboards sur le contenu des logs avec Grafana.
De plus, la partie observabilité est généralement l’une des plus critiques de n’importe quel système. En cas de défaillance de n’importe quel composant (voire même de tout le système), c’est d’elle que tu dépends pour comprendre ce qui se passe. Moins tu la surcharges avec des composants complexes/coûteux et faillibles (comme du NLP), plus tu la délègues à des outils qui sont faits pour ça par des spécialistes et que t’as pas besoin de remettre en question, mieux tu te portes.
Enfin, la dernière raison pour laquelle le ML n’est pas une bonne idée ici, c’est que d’expérience, quand tu vas explorer les logs, tu te bases sur des indices extrêmement différents selon le problème que tu investigues et le système que tu observes.
Par exemple, si 10 erreurs avec le même message se produisent à la même seconde, je vais certainement me poser au moins ces questions :
- est-ce que ça a échoué 10 fois de suite pour le même utilisateur ou 10 utilisateurs distincts ? Est-ce que ça touche toutes les répliques ou bien c’est juste une instance qui s’est vautrée ? (C’est là que c’est utile d’avoir des logs structurés pour isoler/filtrer les user_ids/pid/nom du pod…).
- est-ce que ça coïncide avec d’autres événements remarquables ? (Ici il faut définir "remarquable" : les logs du proxy qui voit passer les requêtes qui ont échoué font doublon et ne sont pas remarquables par exemple, en revanche 10000 requêtes à des méthodes différentes du même service au même moment peuvent indiquer un pic de charge…)
- est-ce que l’erreur s’est propagée à d’autres services ? (Ici il faut savoir déceler les messages qui peuvent avoir une cause commune, donc savoir ce que fait chaque service et comment).
- Est-ce que ce pattern d’erreurs se reproduit dans le temps ? Périodiquement ?
Rien de tout ça ne peut se déduire avec du NLP sur les messages individuels de log. Par contre tous ces cas se résolvent en tweak-ant/filtrant une requête à Loki pour faire apparaître des coïncidences éventuelles. L’intelligence qui entre en jeu ici, c’est une connaissance profonde du système observé et de son fonctionnement, le ML n’est donc d’aucun secours : pour vraiment aider celui qui debugge, c’est sur la facilité à requêter et recroiser les infos que tout se joue, et pas seulement les infos contenues dans les logs : si tu as un Prometheus qui expose des métriques au même Grafana, tu veux pouvoir également exploiter ces métriques pour avoir encore plus de contexte et comprendre ce qui s’est passé à cet instant.
Le mot-clé ici, c’est le contexte :
- Une erreur "connexion à la BDD refusée" isolée, ça arrive, ça peut être transitoire et absolument pas remarquable : si le client réessaye sa requête dans la foulée et qu’elle réussit, ça passe totalement inaperçu pour lui et il n’y a vraiment pas de quoi te faire réveiller à 2h du matin.
- Si toutes les requêtes pendant 5 minutes ou plus échouent avec cette même erreur, là tu as un incident que tu dois investiguer urgemment : ça veut dire que l’appli ne fonctionne vraiment plus pour les utilisateurs.
J’aurais aucune confiance en une IA pour apprendre à faire la différence entre ces deux cas, alors qu’une simple heuristique dans la conf de mes alertes suffit.
