Les "checks" réseaux/système et l'analyse des journaux visent le même objectif (maintenance préventive via détection de problèmes le plus tôt possible), sont assez proches ("évènements", "dans le temps") mais ont une différence fondamentale :
les checks/vérifications se font sur une base régulière (surveillance "quasi-continue" de l'état du service)
les journaux lèvent des alertes ponctuelles, liées à des évènements particuliers
La relation qu'il peut y avoir entre les deux, c'est de 1 vers 2 : un check qui échoue lève une alerte dans les logs. Il ne "reste" alors plus qu'à surveiller les logs, c'est-à-dire :
les rassembler (rsyslog, systemd-journal-remote, ELK pour des besoins plus complexes)
les présenter de façon accessible et "cherchables". En CLI, journalctl fait le job, en GUI, systemd-journal-gatewayd est un peu fruste mais j'en propose une nouvelle version (sans succès pour le moment).
alerter, à partir de là (mail, SMS, ce que tu veux) en fonction de la gravité de l'alerte. Un premier niveau sans doute assez simple serait de lever une alerte pour les évènements de criticité 0 (emergency) à 4 (warning), puis mettre en place une whitelist d'alertes mineures pour ne pas lever trop d'alertes.
Je me suis justement lancé il y a quelques jours dans l'écriture d'un journal sur "la supervision" (métriques, checks, journaux). Mais les urgences font que ça attendra sans doute un peu.
EDIT : ah, et il y a un aspect sur lequel je ne réponds pas. Centreon, je ne sais pas, mais les nagios-like permettent de "checker" des choses qui ne sont pas des métriques. Par exemple: tel port est-il ouvert ? Tel certificat TLS est-il valide ? (date ? autorité ? sujet ?)
Prometheus part de l'idée que "tout est métrique", et on lève des alertes à partir de là. À mon sens, c'est une erreur (on peut certes convertir un état "on/off" en métrique 0/1, mais c'est vouloir adapter la réalité de ce qu'on fait à l'outil ou l'idée qu'on a sous la main plutôt que l'inverse).
# Journaux et checks : deux aspects différents de la supervision
Posté par Samuel (site web personnel) . En réponse au message Lecture et gestion des logs. Évalué à 4. Dernière modification le 01 décembre 2020 à 11:20.
Salut,
Les "checks" réseaux/système et l'analyse des journaux visent le même objectif (maintenance préventive via détection de problèmes le plus tôt possible), sont assez proches ("évènements", "dans le temps") mais ont une différence fondamentale :
La relation qu'il peut y avoir entre les deux, c'est de 1 vers 2 : un check qui échoue lève une alerte dans les logs. Il ne "reste" alors plus qu'à surveiller les logs, c'est-à-dire :
Je me suis justement lancé il y a quelques jours dans l'écriture d'un journal sur "la supervision" (métriques, checks, journaux). Mais les urgences font que ça attendra sans doute un peu.
EDIT : ah, et il y a un aspect sur lequel je ne réponds pas. Centreon, je ne sais pas, mais les nagios-like permettent de "checker" des choses qui ne sont pas des métriques. Par exemple: tel port est-il ouvert ? Tel certificat TLS est-il valide ? (date ? autorité ? sujet ?)
Prometheus part de l'idée que "tout est métrique", et on lève des alertes à partir de là. À mon sens, c'est une erreur (on peut certes convertir un état "on/off" en métrique 0/1, mais c'est vouloir adapter la réalité de ce qu'on fait à l'outil ou l'idée qu'on a sous la main plutôt que l'inverse).