Forum Linux.général Lecture et gestion des logs

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes : aucune
2
30
nov.
2020

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  . Évalué à -1 (+0/-3).

    Salut,

    Il est possible que ça ne réponde pas à ta question.

    par expérience quelle méthode avez-vous pour surveiller votre infra ?

    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.

    • [^] # Re: Les utilisateurs

      Posté par  (site Web personnel) . Évalué à 2 (+1/-0). Dernière modification le 30/11/20 à 11:38.

      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.

      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.

      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.

      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  . Évalué à 0 (+0/-2).

        Salut,

        Je ne cherche pas à éliminer la panne car c'est impossible

        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.

        si c'est l'utilisateur qui t'averti c'est que le problème est bien plus grave

        Je confirme. :)

      • [^] # Re: Les utilisateurs

        Posté par  . Évalué à 3 (+1/-0). Dernière modification le 30/11/20 à 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  . Évalué à 4 (+3/-0). Dernière modification le 01/12/20 à 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 :

    1. les checks/vérifications se font sur une base régulière (surveillance "quasi-continue" de l'état du service)
    2. 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).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.