Webinar Monitoring Applications 8 Juillet 2021

Le monitoring des serveurs est aujourd’hui largement déployé ; celui des applications demande un effort sur le code, mais des outils standards le rendent presque gratuit. Le 8 juillet 2021, ce webinar a montré comment instrumenter son code simplement et comment corréler informations système et informations applicatives, avec des exemples basés sur StatsD et Prometheus. Le replay et les slides sont disponibles ci-dessous.

Ce que couvrait le webinar

Des serveurs aux applications

Surveiller le disque, la mémoire, le CPU et le réseau est devenu un standard, tout comme les statistiques des services courants. Mais avec des applications de plus en plus complexes et découpées en microservices, une seule équipe système ne peut plus tout connaître : Google a introduit le rôle de SRE, Amazon le principe « you build it, you run it ». Les équipes qui développent une application sont les mieux placées pour définir ses métriques.

StatsD : pousser ses métriques

Créé par Etsy, StatsD reçoit les données envoyées par l’application et les transmet à un backend — historiquement Graphite, couple très répandu dans les startups des années 2010. Trois types de valeurs couvrent l’essentiel : le compteur, la gauge (une valeur qui monte et descend) et la durée. Des bibliothèques légères existent pour la plupart des langages ; il faut en revanche déployer le démon StatsD et un backend. Prometheus propose un exporter StatsD pour faire le lien entre les deux mondes.

Prometheus : exposer ses métriques

Avec Prometheus, l’application expose une page texte lisible par un humain, une métrique par ligne, que le serveur vient lire régulièrement. Les données s’interrogent ensuite en PromQL et alimentent tout l’écosystème : Alertmanager, Grafana… La démonstration instrumentait une petite application Django avec django-prometheus ; son code est publié sur github.com/bleemeolabs/quote.

Couvrir toute la pile

Le même serveur Prometheus peut collecter les métriques des serveurs (node exporter, cAdvisor ou un agent comme Glouton), des services (via leurs exporters), de Kubernetes (kube-state-metrics) et de l’application instrumentée. C’est ce qui permet de rapprocher une hausse du taux d’erreurs applicatif d’une saturation mémoire sur le nœud qui l’héberge. Pour aller plus loin, OpenTelemetry est le cadre à regarder.

Aller plus loin

• Monitoring des applications avec Bleemeo.
• Prometheus dans le cloud : un backend managé pour les métriques de votre code.
• Gestion centralisée des logs.
• Logs monitoring with mtail (article en anglais).

Replay

Voir le replay sur la chaîne Youtube de Bleemeo:

Slides

Les slides présentés lors de ce webinar: