Réponse.

L'organisation de la surveillance et de la journalisation dans des architectures informatiques distribuées est essentielle pour garantir la résilience, identifier et analyser les erreurs, ainsi qu'évaluer la performance des services. Il est important de mettre en place une journalisation centralisée et un système de métriques pour tous les services afin d'obtenir une vue d'ensemble de ce qui se passe dans le système.

Étapes générales :

1. Journalisation centralisée - tous les services écrivent des journaux dans un système unique (par exemple, la pile ELK : Elasticsearch, Logstash, Kibana, ou Grafana Loki).
2. Traçage des requêtes - utilisation de systèmes de traçage distribué (par exemple, Jaeger, Zipkin) pour suivre le “parcours” de la requête entre les services.
3. Surveillance et alertes - utilisation de Prometheus, Grafana pour la collecte et la visualisation des métriques et la configuration des alertes.

Exemple de configuration de la journalisation en Python :

import logging
from pythonjsonlogger import jsonlogger

logger = logging.getLogger()
logHandler = logging.StreamHandler()
formatter = jsonlogger.JsonFormatter()
logHandler.setFormatter(formatter)
logger.addHandler(logHandler)
logger.setLevel(logging.INFO)

logger.info('Service démarré', extra={'service': 'orders', 'env': 'prod'})

Caractéristiques clés :

• Permet d’obtenir une vue unique et transparente de toute l'infrastructure.
• Simplifie la recherche et l'analyse des incidents dans un environnement multiple.
• Permet de réagir rapidement à la dégradation ou aux pannes des composants.

Questions pièges.

Faut-il toujours journaliser toutes les actions du service au niveau INFO ?

Réponse : Non, car cela peut rapidement conduire à une augmentation du volume des journaux, réduire la performance et compliquer la recherche des erreurs réelles. Il est préférable de respecter la sémantique des niveaux de journaux (DEBUG pour le débogage, ERROR pour les problèmes critiques, INFO pour les événements importants).

---

Peut-on collecter des métriques uniquement au niveau de l'infrastructure (CPU, RAM) et ignorer les métriques au niveau de l'application ?

Réponse : Non. Les métriques au niveau de l'application (par exemple, le temps de réponse, le nombre d'erreurs) sont critiques pour l'analyse commerciale et la réactivité, elles aident à identifier les “goulots d'étranglement” dans la logique des services, et non seulement dans le matériel.

---

Dans un système distribué, est-il toujours suffisant d'utiliser le traçage HTTP standard des requêtes par le biais du serveur web ?

Réponse : Faux. Pour des scénarios complexes incluant des chaînes de services, un traçage distribué complet avec un Trace-Id unique est nécessaire pour voir le parcours et le temps de traitement de la requête à toutes les étapes.