Monitoring et alertes



  • Bonjour à tou⋅te⋅s,

    avec notre nouvelle infra qui pointe le bout de son nez il est temps de discuter d’un système de monitoring à mettre en place.

    Le but est d’avoir un système simple tout en étant assez souple niveau configuration qui nous remontera des alertes en cas de soucis (par mail, IRC, SMS, pigeons voyageurs ou autres).

    N’hésitez pas à faire part de vos idées et des outils que vous connaissez 😉


  • administrators

    Coucou @Codimp !
    C’est une excellente idée ! Je suggère:

    • icinga
    • wazuh


  • Je plussoie Icinga.
    Sinon il existe aussi monit qui est pas mal, très souple et se configure assez aisément !



  • Idem pour Icinga, il est sympa.


  • administrators

    Je n’ai pas de religion sur l’outil, mais tout comme notre archi, il faut qu’il soit « scalable »c’est dire que di on ajoute un mid, il ne faille pas passer des heures l’ajouter la surveillance.

    Est-ce qu’on met goaccess en local sur le nginx ? (oui, j’aime bien goaccess)



  • Hum, si tout est géré à coup de ansible, normalement ajouter un nouveau mid ne sera qu’ajouter une ligne dans le bon fihcier de conf non ?
    Je ne pense pas qu’il y ait beaucoup de configuration personnalisée à ajouter sur chaque mid.
    Si mes souvenirs sotn bons, il n’est pas très dur d’ajouter une entrée dans la conf icinga.


  • ag_2018

    Perso quand je m’étais intéressé à la question, Prometheus, Icinga 2 et Sensu semblaient être les plus sympas à l’emploi. Je ne me suis pas intéressé à l’installation des deux derniers et ne sais donc pas ce qu’il en est, mais mettant un Prometheus en place au boulot en ce moment, je me suis appuyé sur une série de rôles (ceux de https://github.com/cloudalchemy/ dispos sur Ansible Galaxy) plutôt pas mal du tout.

    Quelle que soit la solution retenue, de toutes façons si la partie Ansible est bien faite en amont, un nouveau nœud ne devrait pas trop être un soucis.


  • administrators

    le soucis de icinga c’est que ca pue trop le nagios



  • @CapsLock roooh mais c’est justement parceque les gens n’aimaient pas Nagios qui allait trop lentement que Icinga à été fait non ?


  • administrators

    @codimp aucune idée; je sais que je l’ai mis en place une fois et que mon avis est mitigé. Ca marche bien, mais ca me parait tellement usine à gaz aussi. Et puis l’UI qui est là que pour faire beau et qui te guide pas tellement (tu dois savoir comment fonctionnent les arcanes d’icinga (et de nagios) pour faire certaines opérations dans le bon ordre/avec les bons prérequis, …) Sans compter le fait de devoir ajouter du plugin pour faire de l’administration d’icinga (je pense à icinga director qui, sans lui, fait que l’UI n’est qu’une simple interface de consultation. Des fois c’est bien, d’autres fois pas: tu peux avoir envie que des gens puissent ajouter un monitoring sur un service qu’iels ont mis en route sans pour autant les former à tout icinga/nagios, par exemple.



  • Bonsoir,

    en tant que nouveau je veux bien essayer prendre en charge la mise en place d’une supervision, mais j’ai quelques questions:

    • Quel est le but? Interne à Exodus-P ou externe?
    • Quelles sont les contraintes?
    • Que voulez-vous surveiller?
    • Quel type d’alertes?
    • Est-il possible d’imaginer un setup ‘temporaire’ histoire de générer des rapports/alertes dans un premier temps, puis quelque chose de plus évolutif par la suite?


  • Pour faire suite à la réponse de @Lovis_IX

    • Centreon me semble trop overkill et trop peu ‘scalable’. En revanche le côté personnalisation avec l’écriture de script pour les monitoring ou les alertes est parfait.
    • Incinga j’ai testé il y a quelques temps, et faire des ‘polling’ custom n’était pas possible sans vampiriser le code.
    • Munin à des gros défauts au niveau des alertes, mais les plugins sont très simples à mettre en place/écrire. Côté serveur il suffit de rajouter l’IP de la machine à poller, ce qui doit être facile à intégrer dans ansible.

    AMHA il pourrait être intéressant d’avoir un centreon ‘publique’ pour afficher des statistiques ou des dispo des services accessibles à tous, et un munin ‘interne’ pour avoir les informations de chaque services/machines pourrait être intéressant.


  • administrators

    Pourquoi avoir deux outils ? N’est-il pas possible d’avoir le même outil avec des vues différenciées. Une pour le grand public avec l’état des services et une interne plus détaillées ? Même si l’entrée interne ce fait par un port custom.

    Autre question, sur quelle machine ?
    Je peux fournir une jail sur la « boulangerie » pour mettre ça, mais c’est du FreeBSD et je ne sais pas si tout le monde s’y retrouvera (pour l’installation). Mais je peux faire cette installation.



  • Merci pour tes idées @nailyk !
    En effet je préfére aussi avoir un seul outil mais c’est à discuter, pour ce qui est du grand public pourquoi pas juste une page du genre https://cachethq.io/ afin d’informer des soucis ?

    Pour Icinga il y a moyen de faire plein de choses sans toucher au code normalement.
    Munin est sympa, à voir si on prend un mix des deux ?

    Je ne connais pas Centreon, je vais regarder ça 😉


  • administrators

    J’avais ça dans mes onglets ouverts.

    https://github.com/firehol/netdata


  • ag_2018

    Voui, je l’avais posté sur IRC 😛

    Après c’est plus pour avoir un recap d’une machine tel que je le comprend (jamais utilisé). Ça peut aussi faire exporter prometheus à la place de node_exporter.


  • administrators

    Coucou,

    Où en sommes nous ?
    J’ai commencé quelque part une liste de ce qu’il faut surveiller, mais je ne sais plus où. Du coup, je recommence.

    • process postgresql
    • queue d’APK
    • process Mongodb sur la boulangerie (utilisé par NodeBB et token_dispenser)
    • process de prod
    • process peertube (sur une jail sur la boulangerie)
    • retour backup borg
    • retour backup mongodb (script à créer)
    • monitorer la place utilisée par les backups (sur les deux plateformes)
    • Ajoutez vos idées ici même (édition du post) pour que nous ayons 1 seule liste.


  • Bonsoir!

    Avec 56846543486 jours de retards j’ai commencé à mettre en place le tinc (solution VPN) pour la supervision.
    J’ai choisi cette solution car elle est plus simple à mettre en oeuvre que d’autre solutions VPN (comme openvpn par ex).
    Petites explications sur la solution que je suis en train de mettre en place:

     - Dédié chez online: 
       |-> Une VM pour les deux instances tinc: 
            |--> Moi: 10.254.0.1/24
            |--> Exodus: 10.253.0.1/24
       |-> Une VM pour la supervision: 
            |--> 10.253.0.10/24
    

    Du coup, il est maintenant possible de configurer tinc sur les machines à superviser.
    La configuration est plutôt aisée. Exemple: https://smartystreets.com/blog/2015/10/how-to-setup-a-tinc-vpn

    L’idée est donc de faire écouter les services de supervision uniquement sur l’ip privée dans le tinc pour éviter les ‘fuites’.
    Je ne sais pas dans quelle mesure il est possible d’appliquer ce fonctionnement à des jails. Peut-être faudra il faire tourner tinc et le node exporter dans la même?

    En attendant que le VPN soit configuré sur toutes les machines qui ont besoin d’être supervisées, je vais essayer de jouer avec les nodes exporters de graphana pour comprendre l’utilisation. Attendez vous donc à des remontées de machines inconnues dans la supervision 😉

    Tous les commentaires et avis sont les bienvenus 🙂

    P.S.: edit important: La configuration de tinc est en mode ‘switch’. Toutes les machines connectées pourront communiquer entres-elles sur leurs IP du VPN.



  • prometheus + grafana fonctionnent:
    Re voici les urls:
    Prometheus: https://exosup.nailyk.fr/ (pas d’authentification)
    https://exosup.nailyk.fr/grafana (nécessite la création d’un compte par un des admin)

    Je n’arrive pas à configurer correctement les dashboards, mais ce n’est sûrement qu’une question de temps:
    0_1536419996080_Capture d’écran_2018-09-08_17-19-32.png

    En tout cas la partie collecte des données fonctionne correctement.
    Le fichier contenant les noeuds se trouve dans /opt/prometheus/targets.json et est relu automatiquement en cas de changements ce qui permet une souplesse pour l’ajout/surpression de machines.

    J’ai laissé la machine de test dans la configuration bien qu’elle n’existe plus, dans le but de construire/gérer les alertes.

    Tous commentaires/aide bienvenue 🙂