Re: [FRsAG] [Couplage monitoring et cmdb - SaltStack & co] remplacer ce bon vieux nagios
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 trap
[FRsAG] Phishing OVH ?
Hello la liste ! Si y'a des sysadmins qui sont chez OVH, ou d'autres qui voudraient protéger un peu leurs clients, voici un petit lien bien pourri qui affiche la page de paiement d'ovh: http://www.meetingviacolvento.it/ Alors comme OVH n'a pas daigné me répondre sur leur abuse ( https://www.ovh.com/fr/abuse/ ) je fais passer, "in case". @++ -- Lifo. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Phishing OVH ?
http://travaux.ovh.net/?do=details&id=26947 http://travaux.ovh.net/?do=details&id=26949 Romain Le 30 août 2017 à 18:19, Sébastien COUREAU a écrit : > Hello la liste ! > > Si y'a des sysadmins qui sont chez OVH, ou d'autres qui voudraient > protéger un peu leurs clients, voici un petit lien bien pourri qui affiche > la page de paiement d'ovh: > http://www.meetingviacolvento.it/ > > Alors comme OVH n'a pas daigné me répondre sur leur abuse ( > https://www.ovh.com/fr/abuse/ ) je fais passer, "in case". > > @++ > > -- > Lifo. > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] remplacer ce bon vieux nagios
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 : > 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
