On 30/08/2017 19:05, Steven Le Roux wrote:
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.
Ton retour d'xp sur une plateforme telle que celle d'ovh est extrêmement intéressant. Ce que j'en retiens c'est que le tout métriques est possible et même souhaitable. Cependant j'en retiens aussi que vous avez développé tout un écosystème pour, notamment pour l'alerting qui quasi un projet en soi.
Pour les sociétés/team de taille medium pour lesquelles 3/4 alertes grafana/prometheus ne suffisent pas, et qui n'ont pas le temps de créer un système d'alerting custom, cela conforte mon intuition sur le fait qu'il n'existe pas encore de solution/projet.
On va donc devoir supporter Zabbix/Nagios* encore quelque temps... A moins que l'on se décide à créer un vrai alerter autour de prometheus/influx.
-- Raphael Mazelier