Bonjour à tous,
Je gère depuis de nombreuses années plusieurs serveurs physiques, VM (vmware) et depuis peu Docker est entré dans la partie. Jusqu'à présent je "m'amuse" le matin à lire les rapports de logs que je reçois par mail de chaque serveurs. C'est pas intéressant, malgré des filtres/règles il est possible qu'un mail passe au travers et surtout je n'ai pas une vision global (un problème sur un serveur peut être causé par un autre serveur).
En premier palliatif (et surtout gérer le problème en urgence) j'ai mis en place Centreon, pour le moment je surveille que la partie réseau le temps de comprendre le fonctionnement. Il me permet de couvrir les erreurs potentielles dont les "codes" sont connue à l'avance :
- un lien qui tombe
- un switch qui sature;
[…]
Je peux reporter ce comportement pour les serveurs :
- un serveur qui ne répond pas;
- une interface réseau qui sature;
- un disque dépassant 80% d'occupation;
[…]
Avec Centreon la majorité des erreurs ou warning sont basés sur une métrique mais comment gérer, par exemple, un message du kernel qui renvoi des erreurs d'écriture sur un disque ? En gros comment gérer tout ce qui n'est pas mesurable ?
Question annexe : par expérience quelle méthode avez-vous pour surveiller votre infra ?
# Les utilisateurs
Posté par _kaos_ . Évalué à -1.
Salut,
Il est possible que ça ne réponde pas à ta question.
Tu peux surveiller tout ce que tu veux pour éviter les pannes, mais elles arriveront quand même d'une manière ou d'une autre.
Pour moi, les utilisateurs sont la meilleure sonde. Évidemment, au début, l'utilisateur peut être mécontent d'un dysfonctionnement. Mais si la demande est prise en compte (les délais peuvent varier, là n'est pas la question), ça transforme un mécontent en un utilisateur entendu. Il y a des chances qu'il reste plus fidèle, même si la résolution n'est pas immédiate.
Matricule 23415
[^] # Re: Les utilisateurs
Posté par Philippe M (site web personnel) . Évalué à 2. Dernière modification le 30 novembre 2020 à 11:38.
Je ne cherche pas à éliminer la panne car c'est impossible, mais les systèmes nous renvoient assez d'informations pour en premier être au courant qu'il y a un problème et en second agir et non attendre bêtement que se soit un utilisateur qui appel pour dire qu'il arrive pas à accéder à un service.
Ok pour ce qui touche l'utilisateur directement mais quand tu es sur des problèmes liés à l'infra qui n'ont pas d'impact immédiat sur l'utilisateur et bien souvent dans ce contexte si c'est l'utilisateur qui t'averti c'est que le problème est bien plus grave.
Et d'une manière globale je préfère anticiper et gérer le problème dans le calme est la sérénité au lieu de jouer au sapeur pompier ou à l'admin windows ;)
Mon journal est peut être mal tourné mais mon objectif est de trouver une solution qui me permet de traiter la quantité d'information envoyée par les systèmes. Le traitement du problème est un autre sujet.
Born to Kill EndUser !
[^] # Re: Les utilisateurs
Posté par _kaos_ . Évalué à 0.
Salut,
J'ai compris que tu as compris :)
Moi, je suis plus dans le dev que l'infra, mais c'est pas si loin, en fait.
Je confirme. :)
Matricule 23415
[^] # Re: Les utilisateurs
Posté par freem . Évalué à 3. Dernière modification le 30 novembre 2020 à 17:26.
Peut-être une piste ici.
À lire avec un peu de contexte, vu que ce n'est pas le 1er billet de la personne sur le sujet (je crois que c'est le 2nd, il en mentionne un autre, j'avais lu tout ça mais ça fait quelques temps)
# Journaux et checks : deux aspects différents de la supervision
Posté par Samuel (site web personnel) . É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).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.