1.

Introduction au Monitoring & Logging

Dans un environnement cloud moderne, les systèmes informatiques deviennent de plus en plus
distribués, dynamiques et complexes. Cette complexité rend indispensable la mise en place de
mécanismes permettant de comprendre en permanence ce qui se passe dans l’infrastructure et dans
les applications.

C’est exactement le rôle du Monitoring et du Logging, deux piliers essentiels pour assurer la
performance, la disponibilité et la sécurité des ressources cloud.

Rôle du Monitoring dans le Cloud

Le monitoring consiste à observer en temps réel l’état des ressources et des applications à l’aide de
métriques.

Cela permet de :

 détecter rapidement les anomalies (CPU saturé, latence élevée, mémoire insuffisante) ;

 anticiper des problèmes avant qu’ils n’affectent les utilisateurs ;

 optimiser l’utilisation des ressources et réduire les coûts ;

 garantir la haute disponibilité et respecter les engagements de service (SLA).

Autrement dit, le monitoring donne une vision continue de la santé du système et permet d’agir de
manière proactive.

Difference

Le Monitoring consiste à suivre en temps réel l’état d’un système à travers des métriques telles que
l’utilisation CPU, la mémoire, le débit réseau ou encore la latence des applications.

Le Logging, quant à lui, permet d’enregistrer l’ensemble des événements et actions qui se produisent
au sein des services, des applications ou des utilisateurs.

Un troisième concept complète ces deux notions : le Tracing, qui permet de suivre le parcours d’une
requête de bout en bout, particulièrement utile dans les architectures à microservices.

Ces trois piliers — métriques, logs et traces — constituent la base de l’Observabilité, dont l’objectif
est d’aider les équipes à comprendre rapidement l’origine d’un incident, à analyser le comportement
du système, et à améliorer durablement ses performances et sa sécurité

Observabilité
L’observabilité est la capacité à comprendre l’état interne d’un système ou d’une application à tout
moment grâce aux données collectées en temps réel. Elle permet de savoir ce qui se passe dans un
système complexe, de détecter rapidement les problèmes et d’analyser leurs causes.

Avantages de l’observabilité

Meilleure visibilité : Dans les systèmes distribués, il est souvent difficile pour les développeurs de
savoir quels services sont actifs, si les performances sont bonnes, qui est responsable d’un service ou
l’état du système avant le dernier déploiement. L’observabilité fournit une vision en temps réel qui
facilite cette compréhension.
Meilleure alerte : Elle permet de détecter et résoudre rapidement les problèmes en identifiant ce qui
a changé dans le système, en déboguant efficacement et en évaluant les impacts de ces
changements.

Meilleure organisation du travail : L’observabilité offre un suivi complet des requêtes et des données
contextuelles sur chaque problème, ce qui simplifie l’investigation et le débogage, tout en optimisant
les performances des applications.

Moins de temps en réunions : Les informations sur l’état du système et la responsabilité des services
sont accessibles immédiatement, ce qui réduit les recherches fastidieuses et les réunions.

Accélération de la productivité : En rendant la surveillance et le dépannage plus efficaces,

l’observabilité permet d’augmenter la vitesse de livraison et de libérer du temps pour l’innovation.

Resume
 Monitoring = observer les métriques et l’état du système.

 Logging = enregistrer les événements pour analyse.

 Tracing = suivre le parcours des requêtes pour comprendre le flux.

 Observabilité = capacité globale à comprendre le système en combinant monitoring, logging et

tracing.

II. Amazon CloudWatch

Présentation et architecture
Amazon CloudWatch est un service de surveillance pour les ressources AWS et les applications. Il
collecte des métriques, des logs et des événements en temps réel afin d’aider à détecter les
anomalies, optimiser les performances et automatiser les réponses aux incidents.

L’architecture d’Amazon CloudWatch repose sur un flux très simple : collecter, analyser et agir.
Plusieurs services AWS comme Lambda, API Gateway ou EC2 envoient automatiquement leurs
métriques, logs et événements vers CloudWatch. Ces données sont ensuite centralisées et traitées
dans le service, où elles sont stockées sous forme de séries temporelles et visualisées à travers des
graphiques et des dashboards. CloudWatch permet ensuite de définir des alarmes basées sur des
seuils, qui peuvent déclencher des actions automatiques comme un scale-out, ou envoyer des
notifications via SNS ou webhooks. Enfin, les équipes peuvent consulter ces informations en temps
réel via des dashboards pour suivre la performance, diagnostiquer des anomalies et assurer une
supervision continue de l’infrastructure

Types de métriques dans Amazon CloudWatch

Amazon CloudWatch collecte et analyse différents types de métriques pour permettre une
supervision complète des ressources, applications et opérations. Ces métriques sont généralement
classées en trois catégories principales.

Les métriques d’infrastructure sont automatiquement collectées par AWS pour surveiller la santé des
ressources physiques ou virtualisées, comme les instances EC2, les bases RDS ou les load balancers,
en mesurant notamment l’utilisation CPU, le réseau, le stockage ou le nombre de requêtes.
Les métriques d’application permettent quant à elles d’évaluer le comportement fonctionnel d’un
service, qu’il s’agisse de la durée d’exécution d’une fonction Lambda, de la latence d’une API ou du
taux d’erreur d’un microservice.

Enfin, les métriques personnalisées étendent la surveillance en permettant à l’utilisateur d’envoyer

ses propres indicateurs, par exemple un KPI métier, le nombre d’utilisateurs actifs ou des mesures
internes spécifiques à une application. Ensemble, ces trois catégories offrent une vision complète de
la performance technique et fonctionnelle d’un système cloud.

Logs et CloudWatch Logs Insights

Amazon CloudWatch ne se limite pas aux métriques : il inclut également un service puissant de
gestion de journaux permettant de collecter, stocker, analyser et interroger des logs provenant de
différentes sources.

1. CloudWatch Logs

CloudWatch Logs est le service AWS destiné à collecter, stocker et centraliser les journaux (logs)
provenant de divers environnements

Avec CloudWatch Logs, vous pouvez envoyer les fichiers journaux d'application et système de vos
ressources vers CloudWatch, où ils peuvent être surveillés, recherchés, analysés et archivés.

 Collecte automatique des journaux provenant de sources telles que EC2, Lambda et
CloudTrail
 Les données de journalisation sont stockées dans des groupes de journaux, qui contiennent
des flux de journaux pour chaque source.
 Permet de définir des indicateurs et de déclencher des alertes en fonction des modèles de
journalisation. Permet la surveillance en temps réel des journaux avec les tableaux de bord
CloudWatch.
 Permet l'analyse et l'interrogation des journaux à l'aide de CloudWatch Logs Insights
 Assure la sécurité grâce aux autorisations IAM et aux contrôles d'accès
 S'intègre avec des services tels que CloudTrail, les journaux de flux VPC et Route 53.

2. CloudWatch Logs Insights

CloudWatch Logs Insights est un moteur d’interrogation (query engine) conçu pour analyser
les logs rapidement et efficacement.

Il permet d’exécuter des requêtes SQL-like sur les logs pour :

 rechercher des erreurs,

 analyser des tendances,
 diagnostiquer des incidents,
 créer des rapports ou des dashboards.

Les résultats obtenus peuvent ensuite être visualisés sous forme de graphiques ou être directement
intégrés dans des dashboards CloudWatch, ce qui permet un suivi continu et clair de l’état des
applications et des systèmes.

✅ CloudWatch Logs : service qui collecte, stocke et centralise les journaux (logs) provenant de tes
ressources.
✅ CloudWatch Logs Insights : outil d’analyse avancée qui permet d’interroger, filtrer et visualiser
ces logs avec un langage de requête.

Dashboards

Les dashboards CloudWatch offrent une interface visuelle qui permet de suivre en temps réel l’état
des ressources, des applications et des logs. Ils donnent la possibilité de créer des graphiques
personnalisés réunissant plusieurs sources de données — métriques, résultats de Logs Insights,
alarmes ou événements — afin d’obtenir une vue centralisée et cohérente de l’ensemble du système.
Cette visualisation personnalisable facilite l’analyse, la détection d’anomalies et le pilotage
opérationnel des environnements AWS.

Alarmes CloudWatch : seuils, actions automatisées

Les alarmes dans Amazon CloudWatch permettent de surveiller vos ressources AWS et vos
applications en temps réel et de déclencher des actions automatiques en cas d’anomalie ou
de seuil dépassé. Elles sont essentielles pour le monitoring proactif et l’automatisation des
réponses aux incidents.

Le fonctionnement est simple : on définit une métrique à surveiller, un seuil, et une action à
exécuter lorsque ce seuil est atteint. Par exemple, une alarme peut surveiller la charge CPU
d’une instance EC2, et lorsqu’elle dépasse 80 % pendant plusieurs minutes, elle peut
envoyer une notification, déclencher une fonction Lambda, ou ajuster automatiquement le
nombre d’instances via l’Auto Scaling.

SNS signifie Simple Notification Service. C’est un service AWS qui permet de diffuser des
notifications à grande échelle de manière simple et fiable.

Fonction principale

SNS est utilisé pour envoyer des messages automatiquement lorsqu’un événement se
produit, par exemple lorsqu’une alarme CloudWatch est déclenchée.

Exemple avec CloudWatch

 Une alarme CloudWatch détecte que le CPU d’une instance EC2 dépasse 80 %.
 L’alarme publie un message dans un topic SNS.
 Les abonnés du topic reçoivent la notification immédiatement (mail, SMS ou fonction
Lambda).

Monitoring d’applications serverless (Lambda + API Gateway)

Dans une architecture serverless, le code s’exécute sous forme de fonctions Lambda, souvent
déclenchées par des appels HTTP via API Gateway, ou d’autres événements. Contrairement aux
serveurs classiques, il n’existe pas de machine fixe à surveiller, ce qui rend le monitoring essentiel
pour garantir la disponibilité et la performance de l’application.

Amazon CloudWatch permet de collecter et visualiser les métriques et logs pour ces services :
  Lambda : nombre d’invocations, durée d’exécution, erreurs, fonctions throttlées,
consommation de mémoire, cold starts. Avec Lambda Insights, il est possible d’obtenir des
métriques système détaillées (CPU, mémoire, réseau).

 API Gateway : métriques comme le nombre de requêtes, latence, erreurs 4XX/5XX, latence
d’intégration.

Le suivi peut être combiné à des alarmess CloudWatch pour notifier automatiquement les équipes ou
déclencher des actions correctives (via SNS, Lambda ou Auto Scaling). La centralisation des logs et des
métriques, associée à la création de dashboards personnalisés, permet une vision complète de l’état
de l’application et facilite le diagnostic des incidents.

Lorsqu’un utilisateur appelle l’API Gateway, chaque étape du traitement—exécution des fonctions
Lambda, accès à DynamoDB—génère automatiquement des métriques et des logs. Ces informations
sont envoyées à Amazon CloudWatch, qui centralise l’ensemble des données de performance et
d’erreurs. Des alarmes peuvent ensuite être déclenchées via SNS pour notifier l’équipe en cas
d’incident, garantissant une surveillance continue et proactive du système.

3. AWS CloudTrail

AWS CloudTrail est un service de journalisation et de surveillance des activités au sein d’un compte
AWS. Il enregistre toutes les actions effectuées sur les ressources AWS, qu’elles soient réalisées via la
console AWS, les API ou les SDK, sous forme de logs d’événements.

 Suivi des actions utilisateurs et services AWS

AWS CloudTrail permet de suivre toutes les actions réalisées dans un compte AWS. Chaque fois qu’un
utilisateur, un rôle IAM ou un service AWS effectue une action — comme lancer une instance EC2,
modifier une règle IAM ou créer un bucket S3 — CloudTrail enregistre cet événement.
Ce suivi garantit une visibilité complète sur “qui a fait quoi”, ce qui est essentiel pour les audits et la
conformité.

Video screen

 Journalisation des appels API

Dans AWS, toutes les actions (créer, supprimer, modifier une ressource, accéder à un service…)
sont réalisées via des appels API.
AWS CloudTrail enregistre automatiquement chacun de ces appels dans des logs, ce qui permet
de garder une trace complète des activités du compte.
Chaque log contient :
 l’utilisateur ou service ayant effectué l’action,
 le type d’action (appel API),
 la date et l’heure,
 l’adresse IP source,
 la ressource impactée,
 le résultat (succès ou échec),
 les paramètres utilisés.
La figure ci-dessus illustre comment chaque action réalisée sur les services AWS, qu’il s’agisse de
créer, modifier ou supprimer une ressource, génère un appel API. CloudTrail enregistre
automatiquement ces appels et les stocke dans un bucket Amazon S3. Ces logs peuvent ensuite être
utilisés pour générer des alertes, être analysés avec des outils comme Elasticsearch, ou être exploités
par d’autres outils open source ou partenaires pour des besoins de monitoring et d’audit. Cette
 architecture garantit la traçabilité complète des actions, ce qui renforce la sécurité et la conformité
du compte AWS.
➡ En résumé : la journalisation des appels API permet de tracer toutes les actions réalisées dans
AWS afin d’assurer audit, sécurité et transparence.

Resume
1) Journalisation API (technique)
CloudTrail enregistre :
➡ “eventName: DeleteBucket, user: admin-hakima”
2) Suivi des actions (interprétation)
On comprend :
➡ “Hakima a supprimé un bucket S3 à 22h30.”

🎯 Une phrase pour retenir

✔La journalisation = enregistrer les actions.
✔ Le suivi = analyser ces actions pour savoir qui a fait quoi.

 Détection d’activités anormales

Grâce aux journaux d’événements, CloudTrail permet de détecter des actions inhabituelles telles
que :
- tentatives d’accès non autorisées,
- création soudaine de clés d’accès,
- suppression inattendue de ressources,
- connexions provenant de pays inhabituels,
- modifications sensibles de configurations.
En analysant les logs, on peut repérer rapidement des comportements suspects ou potentiellement
malveillants et réagir avant qu’un incident majeur ne survienne.

 Intégration CloudTrail + CloudWatch pour les alertes de sécurité

CloudTrail peut envoyer ses logs vers CloudWatch Logs, où ils sont analysés et surveillés en temps réel.
Grâce à cette intégration, on peut :
- créer des filtres de métriques (Metric Filters)
- détecter un événement précis (ex : suppression d’une clé KMS, modification d’un groupe de
sécurité),
- déclencher une alarme CloudWatch,
- qui peut ensuite activer :
o une notification SNS,
o une fonction Lambda (pour bloquer une action, désactiver des credentials, envoyer
un rapport…),
o ou un workflow de sécurité.
Cela permet de transformer CloudTrail en un véritable système d’alerte et de réponse automatisée aux
incidents.
Audit et preuve (CloudTrail Logs)
Le "Bad Actor" tente une action suspecte (ex. suppression de ressource). CloudTrail enregistre
chaque appel API avec détails : utilisateur, ressource, date et IP, fournissant un journal légal
d’audit.
Analyse en temps réel (CloudWatch Metric Filter & Alarm)
 Les logs CloudTrail sont envoyés à CloudWatch Logs. Un Metric Filter détecte des motifs
précis (ex. erreurs, modifications critiques). Si la métrique dépasse un seuil, une alarme
CloudWatch se déclenche.
Orchestration (EventBridge)
EventBridge reçoit l’alerte de CloudWatch et déclenche automatiquement des actions
multiples en parallèle, rendant l’architecture flexible et réactive.
Réponse automatisée (Lambda Function)
La fonction Lambda s’exécute à la suite de l’alerte, identifie le "Bad Actor" via les logs et
applique des mesures correctives (ex. bloquer l’IP, désactiver un utilisateur, ajuster un
Security Group).
Notification (SNS)
Amazon SNS envoie un message à l’équipe de sécurité avec les détails de l’incident et des
actions prises automatiquement.
Exemple Concret :
Imaginez une attaque par force brute (quelqu'un essaie plein de mots de passe).
1. CloudTrail note chaque "Échec de connexion".
2. CloudWatch compte ces échecs. Arrivé à 5 échecs, l'alarme sonne.
3. EventBridge réveille Lambda.
4. Lambda regarde qui essaie de se connecter, voit que c'est l'IP "[Link]", et ajoute cette IP à
la liste noire du pare-feu.
5. SNS vous envoie un mail : "Attaque bloquée venant de [Link]".

CloudWatch surveille les performances et la santé des ressources AWS en collectant des
métriques et logs en temps réel, tandis que CloudTrail enregistre l’historique des actions (API
calls) effectuées dans le compte pour l’audit et la traçabilité.
4. Azure Monitor

 Vue d’ensemble de la plateforme

Scrippt : Azure Monitor est une solution complète de monitoring qui collecte et analyse des données
de télémétrie pour optimiser la disponibilité et les performances. Il importe des données des
environnements cloud et locaux dans une plateforme commune, avec des outils pour corréler,
analyser et visualiser.

 Architecture de Haut Niveau

Scrippt : L'architecture d'Azure Monitor comprend des sources de données comme les
applications, VMs, conteneurs et bases de données. Les données sont collectées et routées
vers une plateforme de données commune, puis consommées via des outils d'analyse, de
visualisation et de réponse.
  Sources de Données
Azure Monitor collecte des données de diverses sources : applications (Données de
performances, d’intégrité et d’activité de l’application) , infrastructures (conteneurs, SYSTEM
D’EXPLOITATION , et les applications qui s’exécutent dans des conteneurs.), plateforme Azure
(ressources, abonnements), et sources personnalisées via API REST par exemple.

 Metrics & Logs

Script : Pour bien utiliser Azure Monitor, il faut comprendre qu'il repose sur deux types de données
distincts.
D'un côté, les Métriques. Ce sont des chiffres, comme le pourcentage de CPU ou l'utilisation
mémoire. C'est léger, c'est rapide, et c'est parfait pour être alerté en temps réel d'une anomalie.
De l'autre, les Logs. Ici, on stocke des événements riches et détaillés dans des espaces de travail Log
Analytics. C'est là qu'on va chercher le "pourquoi" d'un problème en utilisant le langage KQL (Kusto
Query Language).
donc les métriques nous disent qu'il y a un problème, les logs nous expliquent ce qui s'est passé
Azure Monitor Metrics
Azure Monitor Metrics est une fonctionnalité d'Azure Monitor qui collecte des données numériques à
partir de ressources surveillées dans une base de données de séries chronologiques. Les métriques
sont des valeurs numériques qui sont collectées à intervalles réguliers et décrivent certains aspects
d'un système à un moment donné.

types de Métriques :
Les métriques d'Azure Monitor se divisent en trois catégories essentielles : les Métriques de
Plateforme, qui sont collectées automatiquement et sans frais à partir des ressources Azure pour
indiquer leur santé de base ; les Métriques Personnalisées, qui exigent une configuration et sont
utilisées pour suivre des indicateurs spécifiques au sein de nos applications ou systèmes
d'exploitation (via des agents ou Application Insights) ; enfin, les Métriques Prometheus, qui sont le
standard pour la surveillance de nos clusters Kubernetes (AKS) et sont analysées à l'aide d'outils
dédiés comme Grafana. L'ensemble nous permet de disposer d'une vue complète et flexible, de
l'infrastructure de base jusqu'aux charges de travail conteneurisées avancées

les différentes sources de collecte de métriques :

Azure Monitor centralise l'évaluation des performances en collectant des métriques provenant de
diverses sources, ce qui permet une analyse unifiée. Les Ressources Azure fournissent
automatiquement leurs métriques de plateforme toutes les minutes, offrant une visibilité immédiate
sur leur santé. Pour les applications, Application Insights crée des métriques de performance
spécifiques (temps de réponse, exceptions). L'Agent Azure Monitor recueille les métriques des
systèmes d'exploitation invités des machines virtuelles. En complément, nous pouvons définir nos
propres métriques personnalisées via l'API. Enfin, pour les environnements conteneurisés, un service
géré collecte les métriques de clusters Kubernetes (y compris Prometheus) et les stocke dans Azure
Monitor Metrics.
Metrics Explorer
Metrics Explorer est l'outil qui vous permet de transformer vos données en graphiques interactifs
pour voir leur évolution dans le temps. Une fois créés, vous pouvez épingler ces graphiques sur vos
tableaux de bord ou récupérer les données brutes via l'API Azure.

Azure Monitor Logs :

Azure Monitor Logs est un logiciel centralisé en tant que plate-forme de service (SaaS) pour la
collecte, l'analyse et l'action sur les données de télémétrie générées par Azure et les ressources et
applications non Azure.

Comment fonctionne Azure Monitor Logs

Azure Monitor Logs nous fournit les outils pour:

 Collectez toutes les données en utilisant les méthodes de collecte de données Azure
Monitor. Transformez les données en fonction de vos besoins pour optimiser les coûts,
supprimer les données personnelles, etc., et acheminer les données vers les tables dans votre
espace de travail Log Analytics.

 Gérez et optimisez les données et les coûts de journalisation en configurant notre espace de
travail et nos tableaux de journal Log Analytics, y compris les schémas de table, les plans de
table, la conservation des données, l'agrégation de données, qui a accès aux données et les
coûts liés au journal.

 Récupérer des données en temps quasi réel en utilisant le langage Kusto Query (KQL), ou les
outils et fonctionnalités KQL qui ne nécessitent pas de connaissances de ce langauge .

 Utilisez les données de manière flexible pour une gamme de cas d'utilisation, y compris
l'analyse de données, le dépannage, l'alerte, les tableaux de bord et les rapports, les
applications personnalisées et d'autres services Azure ou non Azure.
Collecte, Routage et Espace de Travail
Les capacités de collecte de données d'Azure Monitor vous permettent de collecter des données à
partir de toutes vos applications et ressources s'exécutant dans Azure, dans d'autres clouds et sur
site. Un puissant pipeline d'ingestion permet de filtrer, transformer et acheminer les données vers les
tables de destination dans votre espace de travail Log Analytics pour optimiser les coûts, les capacités
d'analyse et les performances de requête.
  Application Insights (Monitoring applicatif)

 Le Rôle d'Application Insights et OpenTelemetry

Après avoir vu les Logs et les Métriques générales, nous allons nous concentrer sur l'application elle-
même. Application Insights est une solution dont Son rôle est de surveiller en temps réel la santé et
les performances de nos applications web. Le point essentiel est son intégration avec OpenTelemetry
la norme de l'industrie. Cela garantit que nos données de télémétrie sont collectées dans un format
standard, nous offrant ainsi une observabilité complète et multi-plateforme

 Les Outils d'Étude : Diagnostiquer la Santé et les Problèmes

Application Insights nous donne plusieurs outils pour diagnostiquer rapidement. L'outil le plus visuel
est la Cartographie d’application, qui nous montre instantanément comment les services
communiquent entre eux. Si un problème survient, nous utilisons la Recherche de transactions pour
suivre précisément le chemin d'un utilisateur dans l'application et identifier l'étape qui a échoué.
Enfin, nous gérons la réactivité de manière proactive grâce à l'Affichage de la disponibilité et, en cas
de crise, nous utilisons l'Affichage des défaillances pour isoler les exceptions majeures.

 Alerting : règles, groupes d’actions, notifications

 Le Rôle de l'Alerting et la Règle d'Alerte
L'alerting est l'outil fondamental qui nous permet d'être proactifs en production. Le cœur du système
est la Règle d'Alerte. Une règle est une simple combinaison : nous choisissons la ressource à
surveiller, nous sélectionnons un signal provenant des métriques ou des journaux, et nous
définissons une condition. C'est le 'Si-Alors' de notre surveillance. Si cette condition est validée,
l'alerte est immédiatement déclenchée, et le processus de réponse s'enclenche.

 Les Groupes d'Actions (Action Groups)

Le véritable atout d'Azure Monitor réside dans les Groupes d'Actions. Lorsqu'une règle d'alerte se
déclenche, elle appelle ce groupe, qui définit comment nous devons réagir. L'objectif va au-delà de la
simple notification. Il nous permet de configurer des workflows automatisés. Cela signifie qu'une
alerte critique peut non seulement avertir l'équipe, mais aussi exécuter un script via une Fonction
Azure pour tenter une correction automatique, ou créer directement un ticket de haute priorité dans
notre système ITSM. C'est l'automatisation de la réponse aux incidents

 Les Notifications et la Gestion d'État

Enfin, les Groupes d'Actions gèrent les Notifications directes (e-mail, SMS). Un point clé est la gestion
de l'État. Pour éviter que l'on reçoive des milliers de notifications pour le même problème de CPU, les
alertes sont souvent étatiques. Une fois qu'une alerte est 'Fired', elle ne se déclenchera plus avant
que la condition ne soit levée et que l'alerte ne passe à l'état 'Resolved'. Cette approche, combinée à
la possibilité de marquer l'alerte comme 'Reconnue' par un utilisateur, assure un suivi clair et efficace
des incidents

 Visualisation : Dashboards et Workbooks

Azure workbooks

Commençons par les Workbooks, que l'on peut voir comme des rapports dynamiques et flexibles. Un
Workbook est une toile qui nous permet de combiner la quasi-totalité de nos sources de données—
métriques, logs, et même des données externes—en une seule expérience unifiée et interactive.
C'est l'outil idéal pour créer des vues de surveillance de bout en bout pour un processus ou un
service complexe qui s'étend sur plusieurs ressources Azure.

Dashboards :

Passons aux Dashboards, ou Tableaux de Bord. Ces derniers sont conçus pour l'efficacité
opérationnelle et le partage. Ils nous permettent de visualiser rapidement les indicateurs clés. Le
processus est simple : nous écrivons une requête KQL dans Log Analytics, et nous l'épinglons sur
notre tableau de bord sous forme de graphique ou de jauge. C'est parfait pour créer une 'salle de
contrôle' où tout le monde peut voir l'état des systèmes les plus critiques.
Tableau comparatifs :
Caractéristique Workbooks (Classeurs) Dashboards (Tableaux de Bord)

Analyse de données, investigation, Surveillance opérationnelle rapide, état

Objectif Principal
documentation. de santé.

Haute (Possibilité de modifier les Faible (Principalement statique, tuiles

Interactivité
paramètres, filtres). simples).

Sources de Toutes les sources Azure, y compris les Principalement des résultats de
Données données brutes. requêtes de Logs pré-enregistrées.

Rapports détaillés post-mortem, guides Alertes visuelles, affichage sur grand

Meilleur pour ?
de dépannage, vues hybrides Azure Arc. écran, vues rapides pour la direction.

Pour résumer, comment choisir entre les deux ? Utilisez les Dashboards pour la surveillance
opérationnelle rapide et l'affichage des alertes visuelles. C'est la vue simple et synthétique que l'on
affiche sur un grand écran. Ou bien Utilisez les Workbooks pour l'analyse approfondie. Leur
flexibilité et leur capacité à intégrer de multiples sources d'information les rendent indispensables
pour les rapports complexes, les investigations détaillées, et la documentation de nos
environnements hybrides. Les deux outils travaillent ensemble pour nous donner une vision complète
: le Dashboard nous dit quand quelque chose ne va pas, et le Workbook nous aide à comprendre
pourquoi

5. Bonnes Pratiques Monitoring / Logging

  Centralisation et Corrélation des Données

"La première bonne pratique est d'assurer une centralisation complète de nos logs et de nos
métriques sur des plateformes externes comme Azure Monitor. Cette centralisation permet l'étape la
plus importante : la corrélation. La corrélation, c'est ce qui nous permet de passer de 'Le CPU est
élevé' à 'Le CPU est élevé parce que l'application génère trop d'erreurs sur cette fonction spécifique'.
C'est le contexte qui rend les données exploitables. De plus, il est important que nos logs soient
générés dans un format structuré comme JSON pour faciliter leur analyse et leur exfiltration par
KQL."

 Définition des KPIs et Gestion des Alertes

"Concernant l'alerting, la clé est la pertinence. Nous devons d'abord nous entendre sur les KPIs clés à
surveiller, en distinguant clairement les métriques métiers de celles de ressources. Une fois ces
métriques sélectionnées, nous devons classer nos alertes par niveau de gravité : de l'alerte
informationnelle, qui ne génère qu'une notification dans le système, à l'alerte Critique, qui doit
déclencher un appel direct en plus de l'automatisation. Cette classification garantit que nos équipes
ne sont pas noyées sous les notifications inutiles (trop de faux positifs) et peuvent se concentrer sur
ce qui compte vraiment."

 Rétention, Résilience et Intégration

Pour conclure cette section sur les bonnes pratiques, je voudrais souligner que le monitoring doit être
pensé sur le long terme et non comme une simple solution ponctuelle.

Premièrement, la Rétention et l'Archivage sont des exigences non négociables. Nous devons définir
clairement nos politiques de conservation des données pour l'audit et la conformité réglementaire. Il
est impératif d'utiliser des mécanismes de stockage à faible coût pour archiver les données
d'événements sur de très longues périodes tout en préservant les performances de notre plateforme
d'analyse quotidienne. C'est un équilibre financier et légal .

Deuxièmement, la Résilience de la Supervision est vitale. Le système qui nous alerte ne doit jamais
être un point unique de défaillance. Nous devons prévoir la duplication de notre plateforme de
monitoring elle-même, garantissant ainsi que la collecte de logs et de métriques ne s'arrête pas,
même en cas de panne. C'est la garantie de la continuité opérationnelle de notre observabilité.

Enfin, le système de monitoring doit être ouvert et s'intégrer à notre écosystème. L'Intégration est
essentielle pour que ces données servent l'ensemble de l'organisation. Les logs doivent pouvoir être
transmis à des plateforme SIEM pour l'analyse de sécurité. De même, l'intégration avec des outils de
visualisation avancée comme Grafana ou les systèmes de gestion des incidents permet de garantir
que l'observabilité devient un pilier stratégique, servant à la fois l'IT, la sécurité et la prise de décision
métier.