François monte une infra chez OVH.

On partage des infos sur ce pad : https://pad.chapril.org/p/mycelium

Ci dessous → le copier/coller brut du pad. trier les infos et mettre en forme.

Pour se connecter : debian@ip

https://icinga.haydcmzyga2tknjrbi.test.enough.community/icingaweb2/monitoring/list/hosts#!/icingaweb2/monitoring/host/show?host=monitoring-client-host

icingaweb2_user: “icingaadmin” icingaweb2_user_pass: “zoR9thie6Phud4mooYoo”

L'idée c'est de lutter contre la transpiration de l'admin sys. Prévenir plutôt que guérir (certificats SSL, disque plein, etc). Permet aussi de faire de l'amélioration continue : ajouter des tests pour des problèmes qui vont probablement se reproduire ailleurs. Pour faire de gros changements sur l'infra, le monitoring c'est nos yeux : on peut vérifier que les services ne sont pas cassés.

Solutions de monitoring évoquées :

1. monit : ne passe pas trop à l'échelle
2. nagios : projet un peu historique qui a donné naissance à icinga
3. icinga 1 et 2
4. zabbix
5. prometeus?
6. TIG (Telegraf, InfluxDB, Grafana)

Logique centralisée : tout remonte à l'ordonnanceur.

Géré en config texte. Une interface web existe mais c'est pas terrible.

Peut décrire les relations de dépendences entre les hôtes (parents).

Répartition des services via des groupes dans la config. Pas facile de mutualiser les tests, en cas d'hôtes hétérogènes.

Variables libres inscrites dans la conf, utilisées par les commandes.

Plusieurs niveaux de résultats/analyses des commandes.

Des tests sur des hôtes distants ?

• Oui avec NRPE (Nagios Remote Plugin Executor)… galère. Pas d'argument possible dans Debian. De plus NRPE est peu sécurisé et ça marche assez mal.
• Ou avec NSCA, un agent installé sur le client, mais aussi avec ses limites. Il ne semble d'ailleurs plus maintenu.

• host : machine et/ou équiments réseaux à monitorer.
• hostgroup : groupe d'hôtes.
• command : processus exécutés pour faire les tests. Dans nagios si le test renvoie 0, c'est ok.
• service : affecte une commande à un hôte ou un groupe d'hôtes.

L'un des forks de Nagios, les changements principaux sont dans le cœur avec quelques retouches dans l'interface Web.

Même chose que nagios sur la conf mais incompatibilité.

Pas toujours exhaustif sur les commandes et résultats.

Réécriture from scratch. Utilise du SSL donc sécurisé.

Installer un agent sur chaque machine, dont un maître. Modèle Master/Satellite/Client.

Plusieurs modèles d'agencement :

1. le maître cadence tout.
2. Des satellites reçoivent la config et se cadencent en chantant
3. Synchro lors du redémarrage du maître

Plus besoin de NRPE ! \o/ I Mais c'est encore possible.

Certains tests ont besoin de déployer sudo.

Logique d'application des services différentes, pas en fonction de groupes, gestion des exceptions.

Tests plus complets et structurés que nagios (expl avec le check d'un hôte https).

Langage de conf, avec variables.

master / satellite / client : https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/

Approche Bottom-up possible.

Conf en XML, plutôt écrite via l'interface web.

Degré d'erreurs (désastre, haut, moyen etc)

Problèmes de lenteur/charge de PostgreSQL.

Plus étoffé que Icinga (graphs déjà intégrés) mais aussi plus lourd en apparence.

items (éléments) + triggers (déclencheurs).

• https://admin.chapril.org/doku.php?id=admin:procedures:ajout-d-une-machine
• https://admin.chapril.org/doku.php?id=admin:monitoring:howto

• https://enough-community.readthedocs.io/en/latest/monitoring_architecture.html
• https://enough-community.readthedocs.io/en/latest/monitoring_howto.html

• https://icinga.com/docs/icinga2/latest/
• https://wiki.monitoring-fr.org/

• https://lab.enough.community/main/infrastructure/blob/master/molecule/icinga/icinga-playbook.yml
• https://lab.enough.community/main/infrastructure/tree/master/molecule/icinga/roles

• https://testinfra.readthedocs.io/en/latest/

https://icinga.com/docs/graphite/latest/

Nécessite icinga2 depuis stretch-backports

  # apt install graphite-carbon
  # apt install -t stretch-backports graphite-web

graphite-carbon :

• → carbon-cache.service
• → conf. dans /etc/carbon (par ex., dans carbon.conf, s/0.0.0.0/127.0.0.1/)

graphite-web :

• → cf. /usr/share/doc/graphite-web/README.Debian
• → editer la conf. dans /etc/graphite/local_settings.py

  # icinga2 feature enable graphite
  # systemctl restart icinga2.service

Option 1 : module graphite dans icinga2

• → https://github.com/Icinga/icingaweb2-module-graphite à cloner dans /usr/share/icingaweb2/modules/graphite
• → nécessite php-curl : # apt install php-curl
• → dans /etc/icinga2web/enabledModules :

  # ln -s /usr/share/icingaweb2/modules/graphite graphite

Option 2 : passer par grafana (à voir si graphite-web est nécessaire dans ce cas)