Le maintien d’une infrastructure et l’optimisation des ressources sont des tâches qui nécessitent une vigilance quotidienne et des plateformes comme Grafana, Kibana ou Chronograf sont une pierre angulaire dans la surveillance des systèmes d’information.

Cette supervision est très importante dans un contexte DevOps : une meilleure vision des ressources facilite les prises de décisions, facilite le suivi de performance et permet de réfléchir plus durablement sur l’intérêt d’automatiser les tâches. La bonne mise en place et configuration de ces outils de supervision facilite une notion importante du DevOps : le dialogue entre le Dev et les Ops renforcé par des métriques fiables et partagées.

Nous allons nous pencher sur Grafana et plus spécifiquement la version 6 (une des dernières versions disponibles au moment où nous écrivons cet article). Dans un premier temps, nous aborderons l’intérêt de se baser sur AWS pour établir son outil de monitoring puis nous suivrons pas à pas la mise en place de l’infrastructure proposée.

Grafana est une plateforme open source de visualisation de métriques et de surveillance permettant de réaliser des tableaux de bord et des graphiques. La visualisation des métriques est remontée dès que les données sont disponibles et la plateforme supporte des data sources comme Cloudwatch, Influxdb, Elastichsearch ou Prometheus… Un des avantages de Grafana est aussi sa comptabilité avec plusieurs types d’authentification et ne nécessite donc pas d’utilisateurs IAM à gérer.

Voici quelques avantages à déployer Grafana sur AWS :

• Scalabilité de la base de données
Par défaut Grafana utilise SQLite3 en local mais supporte également MySQL et PostgreSQL. En utilisant Aurora MySql serverless, plus de problème d’évolutivité et le coût est indexé sur l’activité (pay as you go).

• Services managés
Avec des services comme Amazon Aurora ou l’utilisation de Docker avec Amazon ECS et AWS Fargate, plus besoin de gérer la maintenance de base de données ou de cluster ce qui se traduit par un gain de temps considérable.

Notre architecture de test

L’architecture est la suivante : un Application Load Balancer redistribue la charge sur le cluster ECS Fargate qui interroge la base de données Aurora MySQL Serverless.
D’autres services sont appelés afin de superviser (CloudWatch) ou de sécuriser (IAM, Certificate Manager et Route 53).

Place à la pratique

Pour ce tutoriel, on part du principe que le compte AWS est opérationnel et que la couche réseau (VPC, Subnets …) a été créée au préalable.

Création de la base de données Aurora MySQL

Création du cluster ECS

+ Configuration du cluster : création de Task definition Grafana (utilisation du Docker hub pour récupérer l’image Docker)

+ Configuration du cluster : inclure les variables d’environnement qui commence par GRAFANA_DATABASE_*

Task Definition ECS Fargate

+ Configuration de ECS Fargate : création du Service ECS

+ Configuration de ECS Fargate : Configuration du réseau

Permettre l’accessibilité de Cloud Watch <> Grafana avec les policies IAM

Ajouter l’IAM Policy (JSON) disponible sur le site de Grafana.

Configuration des data sources pour Grafana

Cas d’usage : monitoring le coût de run efficacement
IAM Policy pour avoir l’accès à la facturation :

Un exemple d’un tableau de bord concernant la facturation de services AWS.

Conclusion

Comme vu précédemment, la mise en place d’une plateforme de supervision est une pierre angulaire dans un environnement. Une supervision centralisée, résiliente et capable de croitre selon les besoins peut ne pas être un besoin critique au départ mais s’avère rapidement indispensable. Grâce à AWS, la notion d’agilité est possible grâce au scalling in / out et au paiement à la ressource consommée.

Vous êtes intéressés par le sujet du DevOps ? Notre prochain article à paraitre courant juin, reprends quelques bases sur ce sujet complexe !

Comments

comments