Salut,

Pour ma part c'est Centreon depuis plusieurs années, j'ai délaissé entièrement nagios pour ce dernier. Ca fait très bien le boulot pour monitorer tout ce qu l'on souhaite.

Benoit

On Thu, 24 Aug 2017 16:31:15 +0200, Thomas Cheronneau wrote:

Hello,

Pour ma part j’ai pas mal joué avec Prometheus. Je le trouve vraiment top avec Grafana et une fois que tu as chopé le PromQL c’est juste un plaisir. Par contre, effectivement si le plugin n’existe pas faut le faire … Ou passer par la pushgateway qui récupère tout et publie ça pour le serveur.

Après c’est un projet jeune quand même et effectivement pour avoir check de mon côté à part Zabbix ou Nagios pour de la production c’est compliqué.

Sinon tu as http://influxdata.com/ [6] qu’il peut être intéressant de regarder également.

Thomas.

...

Le 24 août 2017 à 16:26, soltani@imad.fr [3] a écrit :

tu as regarde du cote de http://shinken.io [4] ?

il me semble que c'est ce qui sera le plus simple pour quelqu'un qui a un "vieux nagios" et si ta supervision est essentiellement web , tu retrouveras tes billes facilement ( re-utilisation de la conf possible )

IS

Le 2017-08-24 16:11, ML a écrit :

...

Bonjour cher confrères, Notre nagios commence à se faire vieux et hormis Zabbix, je peine à lui trouver un remplaçant simple à mettre en oeuvre. On adore la nagios bar pour firefox et les app sur android... mais pareil ça commence à ne plus être compatible avec les versions récentes. Quels sont vos outils préférés pour monitorer vos serveurs (chez nous on a que du serveur web a surveiller) ? Voici ce que mes recherches ont donné jusqu'ici :

• Zabbix : pas mal mais un peu complexe à mettre en place et pas

d'extensions pour navigateur ou smartphone

• Netdata : très bien pour faire des graphes en temps réel mais

les alertes sont mal foutues et peu explicites

• Centreon : pas testé.
• Prometheus.io [1] : faut tout faire soit même ? pas bien

compris. Merci d’avance pour vos réponses. Quentin _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ [2]

---

Liste de diffusion du FRsAG http://www.frsag.org/ [5]

Links:

[1] http://Prometheus.io [2] http://www.frsag.org/ [3] mailto:soltani@imad.fr [4] http://shinken.io [5] http://www.frsag.org/ [6] http://influxdata.com/

Merci à tous pour vos réponses (ultra) rapides, je vais regarder du côté de shinken & icinga 2

Le 24/08/2017 à 16:26, soltani@imad.fr a écrit :

tu as regarde du cote de http://shinken.io ?

il me semble que c'est ce qui sera le plus simple pour quelqu'un qui a un "vieux nagios" et si ta supervision est essentiellement web , tu retrouveras tes billes facilement ( re-utilisation de la conf possible )

IS

Le 2017-08-24 16:11, ML a écrit :

...

Bonjour cher confrères,

Notre nagios commence à se faire vieux et hormis Zabbix, je peine à lui trouver un remplaçant simple à mettre en oeuvre. On adore la nagios bar pour firefox et les app sur android... mais pareil ça commence à ne plus être compatible avec les versions récentes.

Quels sont vos outils préférés pour monitorer vos serveurs (chez nous on a que du serveur web a surveiller) ?

Voici ce que mes recherches ont donné jusqu'ici :

• Zabbix : pas mal mais un peu complexe à mettre en place et pas

d'extensions pour navigateur ou smartphone

• Netdata : très bien pour faire des graphes en temps réel mais les

alertes sont mal foutues et peu explicites

• Centreon : pas testé.
• Prometheus.io : faut tout faire soit même ? pas bien compris.

Merci d’avance pour vos réponses.

Quentin

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

nagios vieux car :

plus présent dans debian 9 compatibilité de l'extension nagios checker bar dans ffx qui déconne pas d'application iphone / je sais pas si celle d'android marche encore

sinon il marche impec et depuis le temps que je l'utilise je le connais par coeur ^^

tout à fait d'accord concernant promethus / grafana / influxDB ça s'approche plus de la métrologie que du monitoring server.

Le 24/08/2017 à 16:43, Wallace a écrit :

Shinken en remplacement oui, oubli Centreon qui est une usine à gaz (tu supprimes des machines d'un poller elle restent dans l'interface, t'as la base SQL qui grossit sans jamais se vider ...)

Néanmoins j'adore dans Nagios avoir automatisé la création de la configuration, le fait que simplement on peut lui dire ce serveur est en maintenance, ne supervise plus tel service pendant 5 min ...

Un ami dans une entreprise intl de gestion de paye me disait être revenu à Nagios car les dernières versions ont sacrément accéléré en performance par rapport à l'époque du lancement du Shinken.

Ils ont mis pas mal de fonctionnalités en plus mais plutôt dans la version payante.

Shinken le seul intérêt que j'y vois c'est la compatibilité Nagios et avec un peu de conf en plus le multi poller facile à déployer.

Zabbix j'adhère pas du tout à l'organisation et l'esprit de l'interface.

Les autres pas testé mais clairement je met pas les solutions qui s'articulent autour d'ELK dans la catégorie supervision, pour moi c'est de la métrologie qui si elle détecte quelque chose doit informer la supervision.

La vrai question c'est pourquoi tu estimes que Nagios se fait vieux? Quel besoin tu as? Des interfaces y en a des tonnes y compris des récentes sur github pas forcément publiée sur nagios exchange.

Le 24/08/2017 à 16:11, ML a écrit :

...

Bonjour cher confrères,

Notre nagios commence à se faire vieux et hormis Zabbix, je peine à lui trouver un remplaçant simple à mettre en oeuvre. On adore la nagios bar pour firefox et les app sur android... mais pareil ça commence à ne plus être compatible avec les versions récentes.

Quels sont vos outils préférés pour monitorer vos serveurs (chez nous on a que du serveur web a surveiller) ?

Voici ce que mes recherches ont donné jusqu'ici :

• Zabbix : pas mal mais un peu complexe à mettre en place et pas

d'extensions pour navigateur ou smartphone

• Netdata : très bien pour faire des graphes en temps réel mais les

alertes sont mal foutues et peu explicites

• Centreon : pas testé.
• Prometheus.io : faut tout faire soit même ? pas bien compris.

Merci d’avance pour vos réponses.

Quentin

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

Yop,

Dans la veine de Nagios: - Shinken, classique, la suite logique de nagios. - Shinken Pro: A éviter comme la peste, vraiment, j'ai eu de sales surprises avec :-( (Utilisé une version courante il y'a moins d'un an) - Alignak, un fork "hostile" de Shinken, car le mainteneur principal refusait d'implémenter des tests unitaire, et d'autres bebelles... (jamais testé, mais c'est des copains qui développent la solution)

A éviter: - Nagios: ca devait etre cool en 1950 (je devais pas etre né) - Centréon: Usine à gaz, clairement. Tout se fait en cliquant, pleins de briques qui sont assemblée ensemble, mais c'est pas super bien fait. (Utilisé en prod il y'a 3 ans, j'ai viré cette techno de mon CV) - Sensu: Simple a installer/configurer, mais c'est du moniroting de kikoolol, il manque trop de fonctionnalités pour que ça soit interressant pour un vrais prod. Si tu as de simples besoins, ca devrait tout de meme faire l'affaire, mais pas plus. (je l'utilise actuellement)

-- MrJK Website: http://jeznet.org/

Le 24 août 2017 à 10:51, ML lists@websiteburo.com a écrit :

nagios vieux car :

plus présent dans debian 9 compatibilité de l'extension nagios checker bar dans ffx qui déconne pas d'application iphone / je sais pas si celle d'android marche encore

sinon il marche impec et depuis le temps que je l'utilise je le connais par coeur ^^

tout à fait d'accord concernant promethus / grafana / influxDB ça s'approche plus de la métrologie que du monitoring server.

Le 24/08/2017 à 16:43, Wallace a écrit :

Shinken en remplacement oui, oubli Centreon qui est une usine à gaz (tu supprimes des machines d'un poller elle restent dans l'interface, t'as la base SQL qui grossit sans jamais se vider ...)

Néanmoins j'adore dans Nagios avoir automatisé la création de la configuration, le fait que simplement on peut lui dire ce serveur est en maintenance, ne supervise plus tel service pendant 5 min ...

Un ami dans une entreprise intl de gestion de paye me disait être revenu à Nagios car les dernières versions ont sacrément accéléré en performance par rapport à l'époque du lancement du Shinken.

Ils ont mis pas mal de fonctionnalités en plus mais plutôt dans la version payante.

Shinken le seul intérêt que j'y vois c'est la compatibilité Nagios et avec un peu de conf en plus le multi poller facile à déployer.

Zabbix j'adhère pas du tout à l'organisation et l'esprit de l'interface.

Les autres pas testé mais clairement je met pas les solutions qui s'articulent autour d'ELK dans la catégorie supervision, pour moi c'est de la métrologie qui si elle détecte quelque chose doit informer la supervision.

La vrai question c'est pourquoi tu estimes que Nagios se fait vieux? Quel besoin tu as? Des interfaces y en a des tonnes y compris des récentes sur github pas forcément publiée sur nagios exchange.

Le 24/08/2017 à 16:11, ML a écrit :

Bonjour cher confrères,

Notre nagios commence à se faire vieux et hormis Zabbix, je peine à lui trouver un remplaçant simple à mettre en oeuvre. On adore la nagios bar pour firefox et les app sur android... mais pareil ça commence à ne plus être compatible avec les versions récentes.

Quels sont vos outils préférés pour monitorer vos serveurs (chez nous on a que du serveur web a surveiller) ?

Voici ce que mes recherches ont donné jusqu'ici :

• Zabbix : pas mal mais un peu complexe à mettre en place et pas

d'extensions pour navigateur ou smartphone

• Netdata : très bien pour faire des graphes en temps réel mais les alertes

sont mal foutues et peu explicites

• Centreon : pas testé.
• Prometheus.io : faut tout faire soit même ? pas bien compris.

Merci d’avance pour vos réponses.

Quentin

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

Je ne sais pas où tu es allé cherché ces explications, mais la raison pour laquelle j'ai forké est que je voulais introduire les revues de code + forcer tous les commit à passer par des pull-requests pour améliorer la qualité du code et tu n'as pas voulu (aussi parce que ça impliquait que tu donne des droits d'admins à d'autres personnes que toi).

Donc c'est uniquement pour ça que j'ai forké.

Et pour info, la première version officielle arrivera dans quelques jours, soit plus de 2 ans après le fork, c'est le temps qu'il nous a fallu pour commenter le code, recoder des parties, ajouter un backend, une webui...

Je ne veux pas rentrer dans des guerres de tranchées, mais je tenais à donner mon opinion, étant la personne qui a forké.

David Durieux

On Fri, 25 Aug 2017 10:06:18 +0200 naparuba at gmail.com (nap) wrote:

(disclamer: je suis le créateur de Shinken)

2017-08-24 17:04 GMT+02:00 Mrjk <mrjk.78 at gmail.com>:

...

Yop,

[...]

• Alignak, un fork "hostile" de Shinken, car le mainteneur principal

refusait d'implémenter des tests unitaire, et d'autres bebelles...

Hum c'est un peu inexact là quand même ^^

Non je n'ai jamais refusé les tests unitaires, et on en avait déjà une tripotée bien avant que les forkeurs arrivent sur le projet ^^

Par contre je suis d'accord sur le fait que l'on était pas d'accord sur la maintenance du code:

• je voulais que ça reste maintenable/hackable par des administrateurs
• ils souhaitaient que ça soit de niveau professionnel avec toutes les

techniques d'héritages et autre magie python possible, en acceptant sans se cacher que seul des sociétés de consulting (dont ils faisaient parti) soient capable de modifier le code.

Je ne dit pas qu'ils avaient tord, leur manière de faire fera que le code sera meilleur d'un point de vue purement développeur, mais d'un point de vue projet c'est de mon point de vue inacceptable car la quasi totalité des contributeurs du projet (hors les forkeurs) sont des admins.

D'un point de vue commercial ils avaient raison aussi, mais ça j'ai été clair avec eux sur le fait que je ne modifierai pas la philosophie du projet pour leur intérêts économiques.

De leur point de vue ils ont eu raison de forker et je ne leur en veux pas.

(jamais testé, mais c'est des copains qui développent la solution)

...

Vu ta réponse j'en déduis que par contre ils en ont contre moi. Dommage

mais j'arriverai à vivre avec ;)

J'ai pas mal de clients (dont des gros) qui utilisent Shinken Enterprise (et pas Shinken Pro). Après je dis pas que tous ceux qui l'ont testé ont tous adoré ou n'ont pas eu de soucis (de bug ou de compréhension), mais jusqu'ici on a jamais perdu un client en 4ans, donc je pense que ton avis est un poil trop tranché ;)

Jean Gabès

En fait, j'ai carrément abandonné le monitoring, pour ne faire que de la métrologie avec des seuils sur les métriques appropriées

Pareil ici, terminé le monitoring à papa. Le même outils pour les alertes et la planification de capacité. Pouvoir faire des alertes sur seuil et sur évolution, c'est le pied (genre un disque se rempli trop rapidement, ça permet d'agir avant le point de non retour).

Denis

On 24/08/2017 21:15, Olivier Delhomme wrote:

...

Si vous avez un contre exemple de truc ou un monitoring est nécessaire et ne peut être remplacé par la métrologie, je suis preneur (ce n'est pas un troll, c'est une vrai question).

Alerte de mises à jour des firmwares du hardware des machines ?

Je suis moi aussi partagé sur ce point. Idéalement tout est métrique (même admettons ce genre de checks qui deviennent des booléens, c'est étrange mais pourquoi pas). C'est même un peu le principe de Zabbix, collecter des métriques et définir des triggers dessus.

Un avantage est de n'avoir à poller une seule fois les cibles (avec un seul agent embarqué ou non). Sur ce point rien ne change, snmpd, nrpe, zabbix_agent, ou les plus récents (telegraf and co) cela reste des agents locaux qui ne font qu'exporter des métriques.

On a d'ailleurs toujours pu faire de la métrologie avec zabbix ou même nagios (avec plus ou moins de bonheur ok), ou du monitoring avec cacti.

Ce qui change en revanche c'est l'utilisation d'une vrai tsdb (influxdb ou prometheus au pif) avec un vrai langage de query, et donc de pouvoir décider après coup ce que l'on veut grapher/monitorer.

Ce qui change aussi c'est l'apparition d'une vraie interface permettant de grapher ses métriques facilement (grafana).

Il manquent tout de même quelques points pour utiliser ces tsdb comme outils de monitoring.

- un outil d’automatisation de création des alertes (ou j'ai loupé un truc) - une vrai interface de visualisation des incidents en cours (alerta est peut être la solution) - et surtout un vrai alert manager, avec corrélation des alertes, escalades, acknowledgment, dowmtime, multi supports.

Ceci dit je suis complètement ouvert si vous avez des solutions ou outils que je l'ai loupé.

-- Raphael Mazelier

+1 pour icinga2 Métrologie : Prometheus + grafana.

Nicolas Girardi.

Le 25 août 2017 à 08:47, Ronan Ducamp r.ducamp@gmail.com a écrit :

Salut à tous,

J'ai testé shinken, c'est bien mais apparemment ce n'est plus mis à jour depuis 2016 si j'en crois le github du créateur.. ( je peux me tromper )

Testé zabbix également, ça change un peu et j'ai pas assez de recul pour donner un avis constructif.

Testé icinga2 aussi, ça a l'air d'être le meilleur des trois avec les plugins qui vont bien (slack, etc..).

En tout cas merci à tous pour vos retour d'XP !

Ronan Ducamp

Le 24 août 2017 22:38, "Raphael Mazelier" raph@futomaki.net a écrit :

...

On 24/08/2017 21:15, Olivier Delhomme wrote:

...

...

Si vous avez un contre exemple de truc ou un monitoring est nécessaire et ne peut être remplacé par la métrologie, je suis preneur (ce n'est pas un troll, c'est une vrai question).

Alerte de mises à jour des firmwares du hardware des machines ?

Je suis moi aussi partagé sur ce point. Idéalement tout est métrique (même admettons ce genre de checks qui deviennent des booléens, c'est étrange mais pourquoi pas). C'est même un peu le principe de Zabbix, collecter des métriques et définir des triggers dessus.

Un avantage est de n'avoir à poller une seule fois les cibles (avec un seul agent embarqué ou non). Sur ce point rien ne change, snmpd, nrpe, zabbix_agent, ou les plus récents (telegraf and co) cela reste des agents locaux qui ne font qu'exporter des métriques.

On a d'ailleurs toujours pu faire de la métrologie avec zabbix ou même nagios (avec plus ou moins de bonheur ok), ou du monitoring avec cacti.

Ce qui change en revanche c'est l'utilisation d'une vrai tsdb (influxdb ou prometheus au pif) avec un vrai langage de query, et donc de pouvoir décider après coup ce que l'on veut grapher/monitorer.

Ce qui change aussi c'est l'apparition d'une vraie interface permettant de grapher ses métriques facilement (grafana).

Il manquent tout de même quelques points pour utiliser ces tsdb comme outils de monitoring.

• un outil d’automatisation de création des alertes (ou j'ai loupé un truc)
• une vrai interface de visualisation des incidents en cours (alerta est peut être la solution)
• et surtout un vrai alert manager, avec corrélation des alertes, escalades, acknowledgment, dowmtime, multi supports.

Ceci dit je suis complètement ouvert si vous avez des solutions ou outils que je l'ai loupé.

-- Raphael Mazelier

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

Salut NAP,

Merci pour ces precisions, je suis dans une boîte d'infogerance donc on est sur de grosses infras, et mes tests je les ai fait sur une infra perso. J'attend donc tes MAJ sur shinken et n'hésiterai pas à te proposer des améliorations et aider à faire vivre ton projet ;)

GG a+

Ronan Ducamp

Le 25 août 2017 10:23, "nap" naparuba@gmail.com a écrit :

2017-08-25 8:47 GMT+02:00 Ronan Ducamp r.ducamp@gmail.com:

...

Salut à tous,

J'ai testé shinken, c'est bien mais apparemment ce n'est plus mis à jour depuis 2016 si j'en crois le github du créateur.. ( je peux me tromper )

Oui et non.

Il n'y a plus de code sur le branche principale ni de sortie depuis l'année dernière, uniquement une branche de développement où j'ai mis des patch provenant de la version Enterprise.

Après je ne l'ai pas abandonné mais mis en pause dans sa forme actuelle:

• il fait le taf en matière de polling sur de gros parcs, mais en matière

d'agent de supervision (afin d'être bien plus proactif/rapide sur les checks) c'est la loose (dois-je parler de la calamité NRPE? mais même nsclient++ ou même l'agent de Zabbix sont trop limités)

• on va lâcher tout ce qui n'est pas interface visuel de la version

Enterprise dans la version open Source courant de l'année. Or vu que ça me prennait un temps fou de backporter petit morceaux par petit morceaux, j'ai mis ça de côté car je vais juste écraser les sources en entier, ça sera bien plus rapide ^^

• côté agent, j'ai commencé il y a 3 ans (putain déjà!)

https://github.com/naparuba/opsbro (il s'appelait kunai à l'époque). Il fait bien plus que la supervision, mais ça restera quand même un gros morceaux de l'outil. Il sera plus que juste l'agent pour Shinken, et pourrait même être utilisé sans shinken/nagios/icinga mais le but est de leur permettre d'aller bien plus bas que les classiques 5min de polling et multiplier le nombre de "services/checks" par 10 sans que ça atomise les perfs des serveurs de supervision ^^

...

Testé zabbix également, ça change un peu et j'ai pas assez de recul pour donner un avis constructif.

Testé icinga2 aussi, ça a l'air d'être le meilleur des trois avec les plugins qui vont bien (slack, etc..).

En tout cas merci à tous pour vos retour d'XP !

Ces deux là sont clairement excellents, avec icinga2 qui a pris le risque de changer radicalement le format de configuration par rapport à nagios.

Ensuite ils restent lourds à mettre en place (Shinken aussi hein). Si les besoins sont léger et que l'environnement est relativement petit, j'aurai tendace à sugérer Sensu qui "fait le taf". Tu n'auras aucune des grosses features puissantes de Nagios/icinga/Zabbix/AUTRE mais si c'est pour avoir des notifications quand quelque chose va mal sur un parc petit/moyen ça fait le taf.

Par contre dès que tu auras des besoins spécifiques en terme d'organisation/workflow, là tu va être très limité.

Tu peux aussi tester Consul, qui mine de rien peux faire le taf de supervision, un peu à la manière de Sensu.

Jean

---

Liste de diffusion du FRsAG http://www.frsag.org/

Le 26/08/2017 à 10:46, ML a écrit :

...

En fait, j'ai carrément abandonné le monitoring, pour ne faire que de la métrologie avec des seuils sur les métriques appropriées (disk free, taux de 5xx, you name it). Tant qu'à emmerder les serveurs pour savoir s'ils vont bien, autant mesurer et collecter des métriques. On peut tout transformer en chiffre mesurable (nombre de noeuds dans un cluster, RTT avec un serveur) et alerter si les métriques n'arrivent plus.

J'ai quelques stacks qui sont surveillées par influx/grafana et jusqu'à présent, je n'ai jamais ressenti le besoin de (re)mettre en service un outil de monitoring dédié. IMHO, c'est bien plus souple en utilisant la métrologie pure. C'est pluggué sur email/slack/sms et ça va plutôt bien.

Par contre, pour le coup, il faut monitorer la métrologie :D Un uptimerobot/statuscake/pingdom suffisent pour ça.*

par curiosité, combien de temps tu as passé pour déployer tout ça ?

C'est assez rapide de déployer un influxdb et un grafana pour recevoir les métriques. Sur chaque serveur, c'est telegraf qui collecte et balance à influx. La aussi le déploiement est très rapide (j'utilise ansible mais même à la main, ça prend 10 minutes conf incluse). En général je déploie le plugin statsd de telegraf qui permet à des scripts externes (ou du code applicatif) d'envoyer facilement des métriques qui ne sont pas collectées nativement par telegraf (la conf est un peu plus trial & error pour cette partie, à cause du système de templating un peu abscons).

Le plus long, de loin, c'est de mettre en place les dashboards qui vont bien dans grafana, et de créer les alertes. C'est assez itératif notamment pour mettre les bon seuils sur les alertes.

@olivier

Alerte de mises à jour des firmwares du hardware des machines ?

Un outil de métrologie va exécuter un check pour ça. Au final, comme le dit Jean, on peut tout transformer en nombre; le check en question peut renvoyer 1 si des updates sont dispo (voire N=le nombre d'updates). Au final, c'est le même usage mais ça permet de n'avoir qu'une plateforme (metrologie) au lieu de deux (metro + monitoring). Le truc qui m'enniue avec la métrologie, c'est qu'en général, on en profite pas pour collecter des métriques utiles (à une fréquence utilisable).

@jean

Le vrai soucis que je vois n'est pas technique (car au final en effet tout peux être vue comme une forme de métrologie), mais plus humain: afficher des courbes c'est joli/vendeur/rassurant, mais ça> n'aide pas l'utilisateur final à comprendre ce qu'il voit.

Oui, tout à fait. Dans mon cas, je suis le seul utilisateur effectivement. Grafana offre pas mal de possibilités de documentation des dashboards (popups d'help, links, ...) ou des affichages différents (singlestat avec des mappings value -> text). Mais oui, ça reste probablement limité à une team technique de supervision, pas un client final.

A+ -- M

// j'ai modifié le sujet afin d'éviter de hijacker le thread original plus longtemps; désolé //

Le 26/08/2017 à 13:50, Francois Lafont a écrit :

Bonjour,

Toujours par rapport à la logique de « substituer complètement la métrologie au monitoring », comment est-ce que tu fais par exemple pour la supervision d'une page d'un serveur Web ? Par exemple typiquement avec le plugin Nagios "check_http" qui vérifie la présence d'une regex ainsi que le temps de réponse ?

Déjà, dans ce cas là, c'est la collecte d'une métrique faite sur le serveur Web lui-même que tu utilises ?

Auquel cas, c'est un check du site web sur localhost qui est effectué ce qui n'est sans doute pas aussi probant qu'un test fait sur un serveur distant (le poller). Non ?

Oui, tout à fait. Comme tu le dis, un check sur localhost, c'est pas l'idéal.

Je fais deux choses sur ce point précis.

- des checks internes (data collectée sur les serveurs, traitée par grafana) qui vont surveiller la santé de l'application (taux de 5xx & 4xx, nombre de process PHP actifs dans le pool, ...); ça nécessite quelques itérations pour placer les bon seuils d'alerte (par exemple, si tu place un nombre minimum de requêtes par seconde sur un site). Généralement ces alarmes n'ont pas la possibilité de me réveiller la nuit, sauf si cet aspect est critique pour le bon fonctionnement applicatif (un cluster qui n'a plus le quorum par exemple).

- un/des check(s) externalisé(s) depuis au moins deux sources (pingdom, statuscake, uptimerobot, ..., en m'assurant que le deux ne soient pas sur le même cloud provider de préférence...) qui va checker le site du point de vue utilisateur final; je demande également aux clients de me fournir un ou plusieurs endpoint de test qui vont vérifier que l'application peut causer aux datastores dont elle a besoin (mysql, redis, elastic, ...) et autres, et qu'elle "va bien" (quoi que ça puisse vouloir dire).

Ces points sont donc très custom et dépendent fortement de l'appli et de sa fréquentation.

À quelques exceptions près, les checks externes sont généralement les seuls qui font sonner la sirène. La philosophie, c'est de n'être réveillé que s'il y a un impact pour l'usager final. Un node qui tombe dans un cluster galéra ou un des trois frontaux qui se meurt, ça peut attendre le lendemain. Par contre, si la mort d'un frontal fait que la charge fait monter le nombre de process PHP au dessus d'un seuil sur les frontaux restants, là ça sonnera.

La difficulté de l'exercice c'est d'essayer d'être exhaustif sur les modes de défaillance pouvant impacter l'utilisateur final (ce qui peut être compliqué en fonction du site) et d'avoir les bons seuils. Être prévenu par le client que son site est HS, ça la fout mal :/

C'est très itératif. Quand j'ai un pépin imprévu, je place généralement une alerte grafana pour attraper le truc plus tôt la prochaine fois.

A noter que chaque déploy (code ou infra) laisse également une trace dans la métrologie (il suffit d'un curl pour envoyer un point à influxdb). Ça aide pas mal à diagnostiquer d'éventuelles régressions.

Le point noir que je vois dans mon approche actuelle par rapport à du monitoring est l'absence de corrélation. Si un panne survient, je suis bombardé par les alertes. Je rejoins ceux qui ont suggéré Alerta (et peut être Riemann). Mais il faut arriver à déployer ça sans SPOF et je n'ai pas trop envie de charger ma propre infra, sinon je vais finir par ne bosser que pour moi-même...

Autre point noir: la grafanamania. Tes dashboards sont tellement pratiques pour amorcer un diagnostic qu'ils finissent par devenir indispensables. Si pour une raison quelconque tu ne les a plus sous la main, tu fais un léger whiteout du cerveau avant de trouver par quel bout prendre le problème. Mais ça s'applique probablement à la métrologie aussi.

Tout ça a plutôt bien marché pour moi depuis le début. Mais c'est mon contexte (clients sur les doigts d'une main, une 50aine de serveurs physiques). J'ai eu aussi la chance de souvent arriver sur des projets "greenfield" et de bosser avec des clients/développeurs compréhensifs, compétents et sympas, donc c'était "facile".

YMMV...

A+ -- M

Je ne peux qu'appuyer cette approche. Une fois que tu as toutes les métriques nécessaires au suivi de l'activité, plus besoin de monitoring à l'ancienne (shinken/nagions/icinga/zabbix/...)

Chez OVH on a fait pareil.

En résumé : on a une stack interne (@OvhMetrics)

La plateforme est "protocol agnostic" : elle supporte OpenTSDB/Warp10/InfluxDB/Prometheus/Graphite... et s'intègre donc nativement avec les outils comme grafana. On peut donc pousser ses points avec un proto et les query avec un autre protocole. Le but initial était de faciliter les déploiements des différentes solutions internes (et on avait de tout...)

Pourquoi on a fait Metrics ? La plupart des team à OVH avait des problèmes pour faire scaler leur solutions de monitoring (nagios like, shinken, ...) Ces solutions de monitoring ne sont plus adapté à la maturité des gens pour gérer des infrastructures. Ce qu'on veut aujourd'hui ce sont des solutions qui permet de croiser les données, d'apprendre sur les pattern observés pour anticiper les failure à venir, le capacity planning utilise des algo de forecasting et du ML pour également anticiper des effets de plafond (plus de bande passante réseau, plus de load CPU dispo). Les besoins analytiques sont vitaux et chez nous tout passe par une approche métrique : du business model à la facturation.

Comment on gère le monitoring à OVH On a publié un petit Billet qui détaille l'approche : https://medium.com/@d33d33/bd089f26af2d On utilisait scollector et consorts, et selon le profils hardware, ces soft génèrent entre 300 et 1000 series temporelles par machine. A notre échelle, comme celle de tout le monde, c'est beaucoup trop. On a donc publier Noderig : https://github.com/runabove//noderig qui s'intègre avec Prometheus en exposant un /metrics handler en http. Noderig est aussi compatible avec les custom collector Scollector ce qui favorise les migrations custom. Prometheus c'est cool, mais pour un projet perso. Ce n'est pas authentifié, pas de multitenancy, etc. On a donc créé Beamium ( https://github.com/runabove/beamium ) qui vient scraper les endpoints prometheus, et pousse sur notre plateforme au format Warp10. Le couple noderig/beamium fonctionne du tonnerre :) Noderig permet aussi d'avoir une visu immediate des métriques sur la machine en faisant un simple curl 127.0.0.1:9000/metrics Pour certains besoins custom, on a fait des collecteurs dédié orienté perf comme pour haproxy.

Comment on gère les alertes? Maintenant que tout est métrique, on a dev un scheduler distribué ( Metronome sur github ) et on utilise https://functions.ovh/ pour générer et process l'alerting. L'alerting est un projet à part, as code, est générique et utilise des backends (Metrics, Logs, MySQL, custom...). On va le mettre un peu sous pression en interne puis on le fera tester sur labs.ovh.com :) On l'intègre également avec NCSA pour les gens qui ont déjà des déploiement nagios/shinken/... Ainsi les alertes sont également des métriques qu'on peut suivre, croiser, analyser, etc.

L'approche métrique permet également d'enrichir les graph de métrologie par des annotations (sur grafana par ex.) ce qui corrèle plus rapidement les évènements discrets. L'instrumentation de code (https://prometheus.io/docs/instrumenting/clientlibs/ ou http://metrics.dropwizard.io/3.2.3/ ) permet aussi de corréler le comportement d'une stack ou d'un soft avec le comportement de l'infra. On mesure par exemple des buffers qui s'empile (ring buffer ou pas), et on est capable de corréler ça avec des métriques network lors d'une congestion, ou d'un CPU qui lock, etc.

Disclamer : On a transformé notre plateforme de monitoring pour en faire une solution SaaS.

2017-08-24 17:24 GMT+02:00 Michel Blanc mblanc.networks@gmail.com:

Le 24/08/2017 à 16:51, ML a écrit :

...

tout à fait d'accord concernant promethus / grafana / influxDB ça s'approche plus de la métrologie que du monitoring server.

Sur ce point en fait je ne vois rien de rédhibitoire.

En fait, j'ai carrément abandonné le monitoring, pour ne faire que de la métrologie avec des seuils sur les métriques appropriées (disk free, taux de 5xx, you name it). Tant qu'à emmerder les serveurs pour savoir s'ils vont bien, autant mesurer et collecter des métriques. On peut tout transformer en chiffre mesurable (nombre de noeuds dans un cluster, RTT avec un serveur) et alerter si les métriques n'arrivent plus.

J'ai quelques stacks qui sont surveillées par influx/grafana et jusqu'à présent, je n'ai jamais ressenti le besoin de (re)mettre en service un outil de monitoring dédié. IMHO, c'est bien plus souple en utilisant la métrologie pure. C'est pluggué sur email/slack/sms et ça va plutôt bien.

Par contre, pour le coup, il faut monitorer la métrologie :D Un uptimerobot/statuscake/pingdom suffisent pour ça.

Si vous avez un contre exemple de truc ou un monitoring est nécessaire et ne peut être remplacé par la métrologie, je suis preneur (ce n'est pas un troll, c'est une vrai question).

A+

-- M

---

Liste de diffusion du FRsAG http://www.frsag.org/

Re,

...

Comment on gère les alertes? Maintenant que tout est métrique, on a dev un scheduler distribué ( Metronome sur github ) et on utilise https://functions.ovh/ pour générer et process l'alerting. L'alerting est un projet à part, as code, est générique et utilise des backends (Metrics, Logs, MySQL, custom...). On va le mettre un peu sous pression en interne puis on le fera tester sur labs.ovh.com :)

...

créer un système d'alerting custom, cela conforte mon intuition sur le fait qu'il n'existe pas encore de solution/projet.

1) Totalement d'accord, ce mail était très clair et super intéressant. Au passage cela m'a permis aussi de découvrir qu'OVH s'est mis au Serverless avec Functions (qui n'existe pas encore sur labs). Le serverless étant pour moi vraiment l'avenir pour beaucoup de startups qui font des APIs... je serais hébergeur aujourd'hui, j'investirais à fond là-dessus (avant que tout le monde parte chez AWS).

2) Ma conclusion sur le système d'alerting n'est pas la même... ce que je retiens c'est que Metronome est un event scheduler (distribué) qui permet donc de déclencher le lancement des alertes (genre un sms.sh), le tout basé sur des métriques. Donc tu l'as ton système d'alerting relié à tes métriques. A priori la partie qu'il faudra dev custom c'est celle du calendrier d'astreinte... mais ça c'est un problème qui existe dans nombre de solutions existantes. Le travail ensuite c'est de définir les bons seuils sur les bonnes métriques, comme on faisait sur un nagios-like. Non ?

A+,

Re,

aimer son métier et ce que sa boite produit. Quand on voit les ravages des startups bigdata enfermées chez Amazon dans le sens où les frais de sortie s'élèvent à plus cher que ce que la boite a gagné en 5 ans ...

Big data = own infra... et je connais bien le sujet :) Sinon effectivement les coûts sont largement supérieurs à ce que tu peux faire toi-même (on avait calculé).

Ajouté au fait que des DB aas et du code aas c'est autant de données en libre service même chiffré car le code lui saura y accéder.

Tu peux faire de l'auth, quand même... je ne vois pas la différence.

Serverless sur une stack logiciel que l'on peut déployer où l'on veut sur sa propre infra (cloud, premise, cloud privé) oui là ok.

C'est ca qui est bien... à partir du moment où tu peux déploy du serverless sur aws/ovh/other,

l'enfermement du code chez un prestataire. Je refais pas le schéma du prestataire qui tousse, qui change ses conditions de vente / norme de code / ... et vous avez du jour au lendemain une boite qui ne tourne plus.

J'ai tendance à faire confiance aux gens pour sortir des libs multi-plateformes. A l'image des scripts de déploiement multi-cloud ou même de ce que fait

...

existe dans nombre de solutions existantes. Le travail ensuite c'est de définir les bons seuils sur les bonnes métriques, comme on faisait sur un nagios-like.

Oui les métrics apportent beaucoup plus de données mais une alerte type nagios du genre check_http en état failed = alerte est relativement simple. Après la multitude des données fait que l'on est noyé sous le nombre d'alertes potentielles qui peuvent être créées.

Le cas OVH est relativement particulier sur la partie hosting/PaaS/IaaS dans la mesure où une grande partie de leurs services et monitorable en mode passif (métriques) + pings. Mais ils ont de plus en plus de services sur lesquels on veut monitorer et l'état et la QoE (qualité d'expérience, ie : ça rame/ça rame pas). Avec les langages à GC (Java/C#) et les archis micro-services en cascade (très adaptées au monde agile), on peut très bien avoir un HTTP qui répond (genre HEAD / ou port 80 open) et un service qui est complètement dans les choux (gros lag de 2s), c'est pour cela que le bon mix c'est les checks actifs, de la corrélation de logs (via Kafka, Logstash, etc) ET les métriques dans le code et l'infra (error codes HTTP, latence de chaque requête, fonction, etc). On vit une époque formidable pour la data, elle n'a jamais été aussi importante et on n'a jamais eu autant d'outils simples pour la traiter... :)

Cordialement,

2017-09-05 14:18 GMT+02:00 Wallace wallace@morkitu.org:

Le 05/09/2017 à 12:49, Philippe Bourcier a écrit :

...

Re,

...

aimer son métier et ce que sa boite produit. Quand on voit les ravages des startups bigdata enfermées chez Amazon dans le sens où les frais de sortie s'élèvent à plus cher que ce que la boite a gagné en 5 ans ...

Big data = own infra... et je connais bien le sujet :) Sinon effectivement les coûts sont largement supérieurs à ce que tu peux faire toi-même (on avait calculé).

Donc on est bien d'accord que le code aas c'est une erreur monumentale si c'est pas sur ta propre infra.

Code != BigData

Là encore c'est pondérable. Si l'activité business implique des jobs en fin de mois, alors provisionner un cluster BD juste pour 2j de workload dans le mois peut être difficile à amortir, là où utiliser une plateforme BigData en service peut diminuer le cout. Surtout quant à la gestion même du cluster (SRE). Si par code, on entend un PaaS : git push & run, alors quelque soit le provider, ton code est universel. Tu le builds en local, il build sur la plateforme. Concernant le serverless, encore mieux, juste des fonctions unitaires... c'est à priori ultra portable. Je pense que tu fais plus référence à des Heroku ou Google App Engine, ou là effectivement, tu as des primitives dans le code qui te lie au provider.

...

...

Ajouté au fait que des DB aas et du code aas c'est autant de données en libre service même chiffré car le code lui saura y accéder.

Tu peux faire de l'auth, quand même... je ne vois pas la différence.

J'arrive pas à retrouver un superbe article qui parlait très bien de ce sujet qui disait en gros Amazon veut vos bases de données et où la personne expliquait comment même avec du chiffrement basé sur l'authentification des personnes distantes Amazon se servait dans les données.

Si tu donnes ta clé privée oui, si tu la gères chez toi, assez peu de risque quand même.

...

...

Serverless sur une stack logiciel que l'on peut déployer où l'on veut sur sa propre infra (cloud, premise, cloud privé) oui là ok.

C'est ca qui est bien... à partir du moment où tu peux déploy du serverless sur aws/ovh/other,

Pour le moment cette solution n'existe pas et c'est bien là le souci, donc clairement code aas est oublier pour le moment.

Heroku like vs code standard

Le serverless OVH, c'est du code qui n'a pas de dépendance OVH. De manière générale, tous nos services prennent en compte la problématique de réversibilité. On veut convaincre par la valeur ajoutée du service, pas par un principe de lock-in. Mais tu as raison de te méfier des solutions qui t'enferme dans une API propriétaire...

Re,

Tu viens à l'OVH Summit en octobre ?

Non, mais je crois que des milliers de gens y vont déjà :)

• Cloud Desktop

Intéressant... je crois beaucoup plus en cette approche qu'a la proposition de la startup qui veut mettre les PC de gamers dans le cloud :)

Pas loin. Metronome n'est que le scheduler. Il ne sera même pas exposé

OK, pour la faire courte, on peut dire que Metronome c'est la version monitoring de ce que fait puppet/chef/ansible dans le monde du déploiement et de la gestion de conf, du MonDevOps.

Si la réalisation suit, ça peut être une bonne solution. Je crois que la qualité/simplicité/souplesse/puissance de la syntaxe de la config est pour beaucoup dans le succès de ce genre d'outils...

infra. Cette vue permettrait aussi de se faire une page status par ex.

Relativement utile, pour remplir les grands écrans pour se la péter "on fait un taff compliqué" dans les open-spaces :)

Et pour le sujet du serverless, je pense aussi que tant qu'il ne faut pas rajouter de libs proprio pour que cela fonctionne (la fameuse "cloud jail"), il n'y a pas de problème... Certains protocoles à l'origine propres à un soft ou à une entreprise deviennent des standards assez rapidement : S3, protobuf, graphite, memcache... on peut donc dire que les trucs un peu fermés ne sont pas voués à le rester aussi longtemps qu'avant... pour peu qu'ils aient du succès. Bref, rien à craindre... Pour les startups qui devs des APIs le serverless c'est vraiment idéal, grossir facilement, redonder sur plusieurs clouds sans jamais faire d'infra et payer à l'usage réel (vs au vCPU/instance/etc)... j'y crois assez.

Cordialement,

Re,

et 2 ans (et quelques myons) plus tard (alors qu'à l'époque, on avait hurlé qu'il fallait pas y aller)

https://www.degroupnews.com/internet/bouygues-telecom-met-fin-a-son-service-...

L'histoire aime se répéter, j'ai retrouvé l'article, je pensais à ceci : http://www.numerama.com/tech/266891-shadow-lordinateur-dans-le-cloud-reussit...

51M de boules sur cette idée, quand même... avec un OVH et sûrement d'autres en face, sans pouvoir faire d'économies d'échelles (PU des salles, volumes chez Intel/Dell/etc, bande-passante...) et avec des bécanes obsolètes (comme chez tout le monde, cela dit) dans 3 ans... j'ai envie de dire "bonne chance" :)

Bref, penser qu'en 2017, une startup pense encore révolutionner le monde avec ça ... comment dire ... (et ce n'est pas un problème de puissance de calcul, ni rien, c'est juste que le temps de sérialisation USB en local, ça n'a rien à voir avec un USB émulé à distance...)

L'autre truc, c'est la latence du h264... les mecs annoncent avoir optimisé de la mort leur codec... brevet à la clé... mais bon ça reste un codec à diff de frames, donc à 60 FPS, même avec le meilleur encodeur du monde tu te tapes déjà 17ms de lag... A moins que leur trip ce soit de tout encoder en 120... auquel cas on n'est plus qu'à 9ms...

Enfin, le prix mensuel est le même qu'un PC de gamer neuf avec le même GPU (GTX 1070) en amortissement sur 3 ans, du coup le gamer c'était vraiment la pire cible... le monde pro me semble tellement plus adapté. Des fois je dois être bête, je ne comprends pas... :)

Cordialement,

Le Thu, 24 Aug 2017 16:48:56 +0200, Mathieu Arnold mat@mat.cc a écrit :

Ici on est en train de passer de nagios à icinga, avec la version 2, ils ont un méta langage qui fait y'a tellement moins de configuration a écrire, par exemple, ajouter un check ssh à toutes les machines FreeBSD qui ont une ipv4 ou v6

Je confirme. Avec icinga2, comparé à icinga/nagios on peut avoir à peu de frais une description très déclarative de l'host (par ex: volumes disques, vhosts http, processes) et utiliser cette description pour définir automagiquement les services associés.

Pour se faire une idée : https://admin.chapril.org/doku.php?id=admin:procedures:ajout-d-une-machine

Et le code qui parse ces descriptions pour définir des services est relativement trivial.

Le tout en se débarrassant de nrpe.

François

On 24/08/2017 17:22, François Poulain wrote:

Je confirme. Avec icinga2, comparé à icinga/nagios on peut avoir à peu de frais une description très déclarative de l'host (par ex: volumes disques, vhosts http, processes) et utiliser cette description pour définir automagiquement les services associés.

Pour se faire une idée : https://admin.chapril.org/doku.php?id=admin:procedures:ajout-d-une-machine

Et le code qui parse ces descriptions pour définir des services est relativement trivial.

Le tout en se débarrassant de nrpe.

+1.

Si on veut rester en terrain connu (nagios like) icinga2 est certainement la meilleure option. Et en plus la gui est relativement sexy de base :)

-- Raphael Mazelier

Bonjour,

Que pensez-vous de OM Distro avec check_mk ?

Cordialement

Le 24 août 2017 17:38, "Greg" greg-frsag@duchatelet.net a écrit :

Bonjour,

bonne question que je me suis posé aussi, mais au final je reste sur Nagios:

• il est fiable et c'est le plus important...
• j'ai fais un générateur de config, c'est assez facile de générer des

fichiers plats

• j'utilise Nagstamon pour avoir un retour sur le bureau (plutot qu'un

plugin ff)

• aNag sur Android, aucun problème, fonctionne bien

Par contre on l'a complété avec Observium qui est plus efficace pour les équipements réseaux, et Grafana pour les métriques.

Greg

Le 24 août 2017 à 17:25, SERRUT Arnaud qqqrno@gmail.com a écrit :

...

Bonjour,

Je n'ai pas encore eu l'occasion de le tester, mais Shinken m'a vendu du rêve, avec de la hiérarchisation de problème (Si un switch tombe, il l'affiche en tête de liste, pas après les 15 machines qui sont derrière) hardware mais aussi logiciel (si l'appli plante à cause d'un problème sur la bdd, il va afficher en premier la bdd) En soit, rien de vraiment magique mais l'ergonomie semble au rendez vous.

Je me souviens plus trop de tout ce qu'il permet et de ses spécificités, mais je compte en mettre un en parallèle de celui que l'on utilise courant septembre, je pourrai vous faire un retour par la suite.

Néanmoins je suis également preneur pour d'autres solutions à comparer.

Arano

Le 24 août 2017 4:12 PM, "ML" lists@websiteburo.com a écrit :

Bonjour cher confrères,

Notre nagios commence à se faire vieux et hormis Zabbix, je peine à lui trouver un remplaçant simple à mettre en oeuvre. On adore la nagios bar pour firefox et les app sur android... mais pareil ça commence à ne plus être compatible avec les versions récentes.

Quels sont vos outils préférés pour monitorer vos serveurs (chez nous on a que du serveur web a surveiller) ?

Voici ce que mes recherches ont donné jusqu'ici :

• Zabbix : pas mal mais un peu complexe à mettre en place et pas

d'extensions pour navigateur ou smartphone

• Netdata : très bien pour faire des graphes en temps réel mais les

alertes sont mal foutues et peu explicites

• Centreon : pas testé.
• Prometheus.io : faut tout faire soit même ? pas bien compris.

Merci d’avance pour vos réponses.

Quentin

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

-- Greg

---

Liste de diffusion du FRsAG http://www.frsag.org/

Ah ben, justement j'allais poser la question ;)

Pour l'instant les 2 Centreons (et oui 2!) dont un IMP me plaisent pas trop, je les utilise mais bon... C'est lourd, les pollers s'écroulent de temp en temps, mais on fait beaucoup de check applicatifs qui sont lents.

Non, je cherche un outil peut-être plus tourné vers la métrologie, je pense que ça correspond + à mes besoins. Je vais tester la soluce de Michel, je vous fait un retour.

2017-08-24 19:10 GMT+02:00 Adrien Lefaut adrien@lefaut.fr:

On 24/08/2017 18:41, Jean Milot wrote:

...

Bonjour,

Que pensez-vous de OM Distro avec check_mk ?

Cordialement

Ce n'est qu'une surcouche à Nagios donc ca marche.

L'aspect multi-site est intéressant mais je ne suis pas fan pour plusieurs raisons :

• Une partie de la configuration se fait via l'interface web (WATO) qui

n'est pas très ergonomique à mon sens

• L'autre partie se fait via des fichiers qui servent à générer une

config nagios

• Trouver la configuration check_mk qui donnera la config nagios que tu

veux est loin d'être aisé (impossible parfois?) _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/

Bonjour,

J'ai changé le titre, car désolé, mais ça risque de partir en troll. Je m'en excuse par avance.

Voici mon petit retour d'xp sur la question...

J'ai toujours détesté nagios (trop usine à gaz, en perl, dont le développement est clairement parti dans tous les sens). Du coup, comme certains d'entre vous, j'ai essayé d'autres outils de monitoring (pas tous (je n'ai notamment pas testé icinga2 et shinken, car je les trouvais trop jeune à l'époque, mais qui sont très appréciés semble t-il)), mais ils avaient toujours un défaut à mes yeux (ex. zabbix grosse usine à gaz par exemple dont la GUI est souvent bordélique).

D'autres, plus simples, m'ont donné une satisfaction partielle (collectl, collectd, ganglia, munnin)... Souvent, ce que je reproche, c'est le stockage de la donnée en base RRD. Ce type de base, selon la définition de la base au départ, peu s'avérer pratique quand on manque d'espace, comme sur un raspPI, ne permet pas souvent de revenir suffisamment en arrière sur l'historique pour retracer un problème (pour info, j'ai d'ailleurs trouvé de petits outils sympas en js qui permettent d'afficher plus de détails sur une représentation graphique d'une base rrd). Car, en général, on arrive facilement à rectifier un problème, mais il est bien plus intéressant d'en trouver l'origine. Et si les données qu'on a ne sont pas assez précises pour avoir le timestamp exact, alors il est difficile de le corréler à des logs.

D'où l'intérêt des bases de données temporelles, InfluxDB, elasticsearch, and co., voir éventuellement de se faire aussi son propre système, si la solution choisie ne permet pas de définir un stockage différent du RRD. Mais ces bases grossissent, et beaucoup. Ceci dit, quand on a de l'espace, pourquoi s'en priver.

Pour ceux qui ne connaissent pas, il y a d'ailleurs plein d'outils "cloud" qui font ce type de job magnifiquement bien (voir par exemple "sysdig cloud" pour vous faire une idée, mais il en existe plein d'autres, si on reste peu regardant sur la confidentialité/le stockage de ces informations).

Je me suis alors mis à faire de la métrologie comme certains ici, avec, pour le rendu, de pauvres tableaux html qui me disent quand tout va bien (vert) ou pas (rouge) et qui me suffisent amplement. La métrologie est faite avec SaltStack qui me remonte plein d'information sur mes machines. Cependant, c'est pour du petit/moyen parc, et je suis d'accord pour dire que c'est loin d'être aussi complet qu'un nagios qui vous remontera des infos par snmp sur tout un tas d'équipements réseau, que pour l'instant, je suis dans l'incapacité de monitorer, étant donné qu'il faudrait pouvoir y déployer à minima, le client Salt (salt-minion) ou un client SSH.

L'intérêt, c'est que je ne rajoute que rarement un outil de monitoring à mon système de gestion de conf (sauf pour monitorer la température, l'électricité, le trafic réseau, ou bien l'activité de mes clusters de calcul), et je ne suis pas débordé par un trop plein d'informations (intérêt des métriques et des seuils d'alerte). Car de mon point, la problématique à vouloir absolument tout monitorer, c'est qu'au final, on se retrouve avec trop d'infos, et comme le dit l'adage trop d'informations tue l'information.

Pour ceux qui utilisent Salt et souhaite approfondir la question, vous pouvez regarder la doc des beacons : https://docs.saltstack.com/en/latest/topics/beacons/

@+

Rémy

Le 29/08/2017 à 09:57, Benoit Poulet a écrit :

Le 24/08/2017 à 22:14, L.M.J a écrit :

...

Et pour les autres :

• Centreon : énième nagios repackagé/refondu... What's the point ?

Vous avez une vue faussée de Centreon, je vais vous en parler un peu car je l'utilise au quotidien

Quand vous parlez de Centreon, vous parlez généralement de la WEBUI, cette interface est assez bien foutue, complète, bien pour les gens ayant besoin de gérer des droits finement (Auth LDAP/AD), on peut par exemple filtrer les actions possible par un utilisateur. Pour mon besoin, on a des utilisateurs qui vont du commercial au technicien en passant par des clients, l'ergonomie de l'outil est un vrai plus Mais Centreon, la société française (cocorico) a fait bien plus :

• Centreon peut être managé en CLI, l'outils s'appelle «clapi». Mais

aussi via une API Rest.

• Nagios à été forké depuis longtemps et fortement optimisé =>

Centreon-Engine

• Ils ont développé un broker (connexion entre un satellite et le

central pour la remontée de données) codé en C++, performant et avec des mécanismes intégrés de rétention de données en cas de coupure réseau. Broker est modulaire, on le configure avec des inputs/outputs, c'est lui qui écrit les RRD, et peux même sortir les métrics dans InfluxDB => Centreon-Broker

• Il ont dev un mega plugin modulaire compatible Nagios, qui permet

de vérifier un nom de choses incroyable et d'une façon standardisée : https://github.com/centreon/centreon-plugins

• il y a une gestion native des traps SNMP avec un moteur de règles

qui peut décortiquer la trap, la router, .... => centreontrapd (La gestion se fait via la webui)

• Il ont une solution d'interface de secours sur les satellites en

cas de désastre.

• On peut ajouter une base de connaissance dans la webui, ajouter

des widgets, ....

La solution n'est pas parfaite (laquelle l'est ?), mais a quand même de sacrés atouts dans sa manche. Et tous les outils sont open-sources (sauf les extensions payantes)

Vous pouvez voir l'ensemble de leurs composants ici : https://documentation.centreon.com/

Et venez tester leur démo là : https://demo.centreon.com/centreon/index.php _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/