Forum Linux.général Quel outil de monitoring pour une "infrastructure" avec 3/4 serveurs ?

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
3
25
mar.
2014

Hello,

Je dois mettre en place une infrastructure qui comporte quelques serveurs. Quelle solution de monitoring vous mettriez en place ? J'avais déjà mis en place Nagios et monit sur des infrastructures plus importantes, mais là ça me paraît un peu "too much" ; et peut-être qu'il existe des solutions plus récentes et simples à mettre en oeuvre ?

Merci pour vos retours.

  • # Collectd?

    Posté par  (site web personnel) . Évalué à 2.

    Salut,

    Chez moi je monitore 2 petits serveurs avec des démons collectd et CGP.

    C'est très peu consommateur de ressources (mes serveurs sont des raspberry pi) et il est très simple de rediriger les données de monitoring vers un serveur maître.
    Après, ça n'a probablement pas les possibilités de Nagios..

    • [^] # Re: Collectd?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      totof2000 a fait une réponse pertinente et qui me fait dire que collectd n'est pas adapté à ce que je veux : en priorité, ce dont j'ai besoin, c'est de superviser des processus (dans un second temps des graphes seraient bien, mais c'est clairement pas la priorité).

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # même cas

    Posté par  . Évalué à 1.

    Je suis plus ou moins dans le même cas que toi.
    J'ai un serveur avec ispconfig et un vps avec un TS et j'aimerai les superviser. Des solutions comme Nagios me parait over kill.

    Je vais suivre ce post avec intérêt :)

  • # D'abord qu'entends-tu par "monitorer" ?

    Posté par  . Évalué à 3.

    S'agit-il de supervision ou graphage ? Il faudrait que tu définisses précisément ce que tu veux faire.

    Ensuite, quel contexte ? Une petite infra perso ou une infra pro qui s'étendra à l'avenir? Y aura-t-il des plugins spécifiques à développer ? Si c'est la seconde solution, ne prend pas ta décision à la légère. En effet dans le cas de développement plugins spécifiques, si tu as choisi une solution "basique" non compatiblme avec d'autres solutions, et que tu dois changer d'outil parce que celui-ci est trop limité, tu risques de te retrouver coincé, et ça risquie de couter cher.

    • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      en fait je veux faire en priorité de la supervision : savoir si mes services sont up, détecter les instabilités. Pour ce qui est du "graphage", c'est bonus. Je cherche un truc intermédiaire entre "l'hébergeur fait des pings sur mon serveur" et "nagios qui supervise tout aux petits oignons (mais avec la complexité associée)".

      Mon cas est une infrastructure pro, mais qui sera remplacée si ça doit grossir. Nagios pourrait être adapté, si j'avais un setup genre "nagios-setup-for-basic-webapp.sh" qui me configure tout pour un besoin standard (lamp ou assimilé).

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

      • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

        Posté par  (site web personnel) . Évalué à 2.

        en fait je veux faire en priorité de la supervision : savoir si mes services sont up, détecter les instabilités.

        Je te recommande Monit. Simple à mettre en oeuvre, efficace et permet de surveiller une foule de choses.

        • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          monit ne peut pas être installé en remote, si ? Si je comprends bien, Monit est l'agent et M/Monit l'agrégateur ? Monit tout seul ne permet pas de déceler l'inacessibilité d'une machine, si ?

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

          • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

            Posté par  (site web personnel) . Évalué à 3.

            Il n'y a pas d'agent. Tu installes Monit sur ton serveur de supervision, et de là tu définis les tests dont tu as besoin (connectivité avec ICMP/ping, accès à une page web sur un serveur distant, …). Et quand les choses ne marchent pas comme prévu tu peux choisir de recevoir une alerte ou d'exécuter un script pour relancer un service, …

            Exemple pour vérifier qu'un commutateur répond bien au ping :

            check host mon-commutateur with address 192.168.1.1
            if failed icmp type echo
            then exec "/usr/local/bin/mon-script-d-alerte"
            if failed icmp type echo within 2 cycles then unmonitor

            Si le ping échoue je reçois un mail, si le ping échoue lors du cycle suivant (cinq minutes plus tard) je reçois un autre mail et le système arrête de surveiller le commutateur (parce que recevoir une alerte toutes les cinq minutes, au bout d'un moment c'est pénible ; je sais qu'il faut que je le redémarre ce commutateur). Évidemment comme toute solution de supervision, le gag est de ne pas perdre accès au système d'envoi des alertes…

            Une autre chose que j'aime bien avec Monit : il y a une interface web (HTTPS au besoin) pour avoir une vue d'ensemble mais les mêmes opérations sont possible en ligne de commande.

            M/Monit permet de superviser plusieurs Monit mais ce logiciel là n'est pas libre ni gratuit (il est possible d'essayer gratuitement apparemment).

      • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

        Posté par  . Évalué à 3.

        Des infos ici ou là

      • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

        Posté par  . Évalué à 3.

        Shinken est peut-être un peu « overkill » pour toi, mais c'est assez rapide à mettre en place.

        http://www.shinken-monitoring.org/wiki/shinken_10min_start

        Il est également dispo en paquet Debian depuis peu, mais attention uniquement en testing, il faut aimer le jeu, mais ça simplifie encore le processus de mise en place : apt-get install shinken et voila

        • [^] # Re: D'abord qu'entends-tu par "monitorer" ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Je l'ai essayé. C'est une rigolade, non, les 10 minutes ? Autant j'ai l'impression que Shinken est bien et puissant, autant en 10 minutes, tu fais juste le curl|/bin/bash. Mais la doc ne semble pas à jour, ou alors l'installation "one shot" est incomplète.

          Par exemple, l'installation d'un pack se fait via la commande

          shinken install postgresql

          Si tu suis l'install en 10 minutes, tu n'as pas de commande shinken. Du coup tu reviens sur le site, tu suis les instructions en mode "python" :
          pip install shinken

          Ca marche à peu près bien, mais du coup tu te retrouves sans l'interface web (par défaut en tout cas), tu n'as pas le script install.sh dispo pour installer les modules complémentaires…

          Faut être motivé pour y parvenir…

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # nagios vs smokeping

    Posté par  (site web personnel) . Évalué à 1.

    personnellement, dans un contexte d'une vingtaine de serveur sur des sites distants a surveiller (qualité de la liaison (perte de paquets, latence), serveur up ) j'ai mis en place Smokeping.
    léger, rapide, et pas mal paramétrable.

    démo ici : http://oss.oetiker.ch/smokeping-demo/?target=Customers.OP
    site ici : http://oss.oetiker.ch/smokeping/

    toutefois, ça dépend effectivement de ton besoin, moi il était relativement simple :
    le serveur est allumé ou pas, la liaison est ok, sur le secours (ping >100ms) ou coupée, et quand elle tombe, savoir quand, pour informer le fournisseur d'accès. Nous n'avions pas mis en prod les alertes, mais c'est relativement facile et efficace (ex: si perte de 10 paquets de suite, envoyer un mail, si perte de 100 paquets de suite, envoyer un sms…)

    Bon courage :)
    (troll : en meme temps, si tu as mis en place Nagios, tu en as du courage ! /troll)

    • [^] # Re: nagios vs smokeping

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      En fait je voudrais un truc un peu plus poussé que du ping, genre monitorer le processus apache, postgresql, etc.
      Pour ce qui est de Nagios… un prestataire l'avait mis en place, moi je l'avais simplement fait évoluer en l'enrichissant =)

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

      • [^] # Re: nagios vs smokeping

        Posté par  . Évalué à 2.

        En fait je voudrais un truc un peu plus poussé que du ping, genre monitorer le processus apache, postgresql, etc.

        Puis après tu auras un incident qu'il serait bien de pouvoir détecter via la supervision, puis un autre qu'on pourrait prévoir en supervisant tel ou tel service avant que ça ne tombe, …. et on en arrive vite à une usine à gaz … :) "Chef, la PF ne tient plus la charge, et on ne peut plus monitorer correctement nos services " "Eh bien faites avec, on a pas de budget pour une migration." Et c'est comme ça que tu traines un boulet … ;)

        Ce genre de chose est du vécu et arrive souvent.

        • [^] # Re: nagios vs smokeping

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Comme expliqué ci-dessus, l'infra n'est pas destinée à grossir. Pour être plus clair, une supervision nagios ou équivalent sera mise en place par la suite (avec l'infra finale et tout ce qui va avec), mais en attendant, j'ai pas le temps pour le moment de mettre en place un nagios complet, et j'en ai pas le besoin. Mais j'ai besoin d'un peu plus que d'un ping.

          C'est un peu comme quand tu développes un prototype : tu veux que ça fonctionne, mais sans embarquer toute la complexité liée à l'industrialisation. Voilà. Là, c'est pareil.

          #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

  • # Nagios mais pour les fainéants ...

    Posté par  . Évalué à 1.

    Si tu n'a pas besoin de prendre du temps pour l'install et la conf de nagios . Tu peux voir du coté de FAN (http://www.fullyautomatednagios.org/) [Nagios + Centréon]
    Tu peux alors te concentrer sur tes petits scripts de supervision (qui me semble classiques)

  • # Munin ?

    Posté par  (site web personnel) . Évalué à 2.

    Munin avec quelques seuils d'alertes configurés ne ferait pas l'affaire ?

  • # Et ZABBIX ?

    Posté par  (site web personnel) . Évalué à 2.

    Zabbix convient très bien même pour les petits trucs
    un exemple : Surveillance de la température d'une salle serveur

    Si la clim tombe en panne … la température monte et tout s'arrête. et je suis obligé de faire du vrai travail :(

    Alors j'ai pu bricolé un truc pour tester la température et remonter les problèmes si cela tombe en dessous ou en dessus de certain seuils, par l'envoi de sms
    Et la ZABBIX a été génial.

    Cela fonctionne nickel depuis Aout 2013 …

    • [^] # Re: Et ZABBIX ?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Je me posais la question de zabbix, justement, qui n'était pas cité. D'autres retours sur cette techno ?

      En fait, du coup j'ai l'impression que je vais soit tenter une install de shinken en dix minutes (cf. message ci-dessus), soit tester Zabbix… soit utiliser monit (mais du coup probablement en "jetant" tout par la suite pour utiliser une solution plus évolutive… comme le disait totof2000)

      #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

      • [^] # Re: Et ZABBIX ?

        Posté par  (site web personnel) . Évalué à 2.

        Salut,

        Pour ma part je suis passé à du 100% Zabbix, partout où je dois mettre de la supervision, que ce soit 1 serveur ou un parc de 1000000 serveurs.

        J'ai enfin pu me défaire de la complexité de Nagios et cie :)

        • [^] # Re: Et ZABBIX ?

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 02 avril 2014 à 17:12.

          +12

          Nagios est une usine à gaz
          Shinken m'a l'air pas mal mais il est aussi complexe (c'est du python donc c'est mieux :) )

          ZABBIX est rapide a mettre en oeuvre, surtout avec une VM toute prête :)

          Mais en plus c'est super simple de rajouter ses propres greffons.
          Un exemple complet dans mon blog

          et en plus il fonctionne a travers SSH :)

          • [^] # Re: Et ZABBIX ?

            Posté par  (site web personnel) . Évalué à 1.

            Et en plus il y a un joli dossier que j'ai écrit dans Linux Mag 158 l'an dernier, aucune excuse pour ne pas essayer de le découvrir :)

            • [^] # Re: Et ZABBIX ?

              Posté par  (site web personnel) . Évalué à 1.

              +24
              2 choses m'ont permis de découvrir Zabbix et sa facilité d'utilisation

              • Des "collègues" qui grâce à ZABBIX géraient des centaines de périphériques réseaux dans le monde entier
              • Ton SUPER dossier, qui est resté à mon chevet et sur mon bureau quelques temps … et qui si je me souviens bien, il ne manquait plus qu'un exemple concret de paramétrage "spécifique" pour être quasiment parfait.

              En tout cas, merci pour cet article qui m'a beaucoup aidé.

              • [^] # Re: Et ZABBIX ?

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Merci pour ces retours… j'ai testé Shinken, j'ai cru trouver l'outil qui me fallait, mais impossible de trouver une doc complète et à jour (certaines parties semblent faire référence à la v2, et d'autres parties à la version stable).

                Je vais tester Zabbix, dommage que cet article ne soit pas dans l'un des numéros que j'ai en stock.

                #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

Suivre le flux des commentaires

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