Observability in the CLOUD
Introduction
Depuis que le système d’information s’est implémenté dans le CLOUD, les entreprises doivent pouvoir surveiller les métriques de leurs CSP comme elles le faisaient dans le legacy. Il est d’autant plus important lorsqu’il s’agit d’applications hébergées dans un CSP public. La surveillance est nécessaire pour les entreprises afin de s’assurer que le système est opérationnel et fonctionnel.
Par moment, il est suffisant d’utiliser les outils du cloud provider (CloudWatch, stack driver, logs analytics,…). Cependant, les outils de surveillance open source viennent compléter parfaitement les fonctionnalités manquantes pour surveiller nes composants de nos infrastructures avec beaucoup de personnalisation.
Outils
Dans notre exemple nous allons utiliser une solution “hybrides” :
Pour les composants PaaS :
Azure monitor pour les logs et métriques. BlackBox exporter pour tester les “expositions” (latence réseau, entrée dns..)
Pour les composants IaaS :
BlackBox exporter pour tester les endpoints de chacun des nœuds (latence réseau, expiration de nos certificats, entrée dns, smtp, test de port , test ssh…) loki pour remonter les logs de nos composants IaaS
Scénario d’une supervision mutalisée
Dans ce scénario, nous devons superviser sur mesures chacun de nos clients, en mutualisant au maximum notre stack pour optimiser nos coûts et nos montées de version dans le CLOUD
Four Golden Signals :
Nous nous baserons sur les “Goldens signals metrics” pour construire notre supervision. Pour rappel ce sont quatre métriques qui nous donnerons une très bonne idée de la santé et des performances réelles de nos applications telles que vues par les acteurs interagissant avec ce service, qu’ils soient des utilisateurs finaux ou un autre service de votre application de microservice.
- Latency
- Traffic
- Errors
- Saturation
Il existe de nombreux articles qui expliquent en détails ce qu’est les “goldens signales” donc je n’épiloguerai pas plus sur ce sujet.
Pour collecter ces signals ?
Alerter : notifier quand quelque chose ne va pas Dépannage : aidez-nous à isoler et à résoudre le problème Tuning/Capacity Planning : pour nous aider à améliorer notre configuration au fil du temps
Nos outils
Dans notre cas, nous utiliserons ces composants sur un docker :
- Thanos pour la rétention (sur un bucket de notre CSP)
- Prometheus pour orchestrer la supervision
- AlertManager pour générer nos alertes
- Grafana pour réstituer nos métriques/logs
- Loki pour analyser nos LOGs
- Nginx pour sécuriser et exposer notre stack
Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome
See the ApplicationsRegistrations.ps1
