2017-09-04 12:07 GMT+02:00 Philippe Bourcier <phili...@frnog.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. >
C'est pour ça que l'idée c'est de le proposer à tout le monde :) > > 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). > Tu viens à l'OVH Summit en octobre ? En plus de tout ce qui est IaaS, on va y présenter notre gamme de service Cloud pour les dev/devops : - Logs Data Platform - Metrics Data Platform - Containers - Queue - Functions - Cloud Desktop ... les roadmap et surtout on sera là bas pour discuter et échanger sur vos besoins/envies :) C'est tjrs super intéressant de découvrir des nouveaux cas d'usage. > 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 ? Pas loin. Metronome n'est que le scheduler. Il ne sera même pas exposé directement. Ce que l'utilisateur fournit via un repo git, c'est : - le check (lié à un type de backend) - les params liés au check - le endpoint du backend - un selecteur (un fetch de serie, un search ES, un select MySQL, ...) - les actions, escalade, etc... De notre côté, on schedule, check, etc... puis en cas de match, un composant s'occupe de tout ce qui est : - escalade - déduplication - backend (sms, email, pagerduty, etc.) - intégration on-call/astreinte/planning ( basé sur https://raw.githubusercontent.com/linkedin/oncall/master/docs/source/_static/demo.png ) L'idée étant de fournir une expérience intégrée, as code, qui s'intègre avec ce qui existe et qui scale pour un freelance comme pour une grosse entreprise. En bonus on va essayer de faire une vue synthétique qui permet d'avoir un aperçu hiérarchisé de l'état d'une infra. Cette vue permettrait aussi de se faire une page status par ex. Je pense que tout le monde fait le même postulat : le monitoring, ça ne passionne personne, ça doit être simple, fonctionner, s'oublier, et ne donner signe de vie que quand c'est nécessaire. > > > A+, > -- > Philippe Bourcier > web : http://sysctl.org/ > blog : https://www.linkedin.com/today/author/philippebourcier > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
