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.netwo...@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/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
