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