Tableaux de bord de santé applicative

Surveillance et dépannage sur AWS

John Q. Martin

Principal Consultant

Conception de tableau de bord : hiérarchie de l'information

Pyramide à trois niveaux : un sommet étroit foncé, un milieu sarcelle plus large et une base verte la plus large

Comme à l'hôpital : accueil → unité → spécialiste

Haut – Sommaire exécutif

Santé globale du système
Indicateurs d'affaires clés, SLA, incidents en cours

Milieu – Santé des services

Taux d'erreurs, percentiles de latence, débit

Bas – Diagnostics détaillés

Traces, journaux, utilisation des ressources, santé des dépendances

Les quatre signaux d'or

Les quatre signaux d'or de la surveillance : latence, trafic, erreurs et saturation

Couvrez ces quatre aspects et vous couvrez la grande majorité des problèmes.

La méthode RED

RED pour les services à requêtes :

Méthode RED illustrant rate, errors et duration pour des services à requêtes

Lien avec les signaux d'or :

RED est un sous-ensemble ciblé des quatre signaux d'or
Conçue pour les services qui traitent des requêtes utilisateurs
Saturation (4e signal d'or) ajoutée pour la surveillance d'infrastructure

Utilisez RED comme point de départ, ajoutez la saturation pour des diagnostics plus poussés.

Trois sources de données

Schéma de trois sources de données pour tableau de bord : métriques CloudWatch, traces X-Ray et journaux CloudWatch

Widgets de métriques CloudWatch

Volume de requêtes :

["AWS/ApplicationELB",
 "RequestCount",
 {"stat": "Sum"}]

Taux d'erreurs (calcul de métrique) :

"metrics": [
  ["AWS/Lambda", "Errors",
   {"stat":"Sum","id":"errors"}],
  [".", "Invocations",
   {"stat":"Sum","id":"invocations"}],
  [{"expression":
    "(errors/invocations)*100",
    "label":"Error Rate %"}]
]

Percentiles de temps de réponse :

["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p50"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p95"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p99"}]

Volume des requêtes depuis ALB RequestCount
Taux d'erreurs avec calcul de métrique : errors / invocations × 100
Temps de réponse aux percentiles p50, p95, p99

Widgets X-Ray et journaux

Widgets X-Ray :

Carte des services – topologie applicative avec indicateurs de santé
Statistiques de traces – temps de réponse moyen, taux d'erreurs, taux de fautes
Latence par service – comparaison des temps de réponse par service

Widgets CloudWatch Logs :

Requête pour erreurs récentes :

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

Compte d'erreurs par type :

filter @message like /ERROR/
| stats count(*) as errors
    by errorType
| sort errors desc

Disposition complète du tableau de bord

Disposition d'un tableau de bord de santé : tuiles de sommaire en haut, carte des services au milieu et journaux d'erreurs en bas

Flux de dépannage d'incident

Pince-notes de triage à l'urgence avec bandes de priorité colorées et stéthoscope

Comme au triage à l'urgence : stabiliser → diagnostiquer → traiter → vérifier

Identifier – voyants rouges/jaunes, pics d'erreurs
Délimiter – quels services ? quand ? est-ce que ça empire ?
Corréler – erreurs + latence, trafic + ressources
Approfondir – carte des services → traces → journaux
Cause racine – dépendance, BD, mémoire, configuration
Corriger – disjoncteur, mise à l'échelle, retour arrière, basculement
Vérifier – taux d'erreurs normal, carte au vert, alarmes éteintes

Scénario 1 : pic de trafic soudain

Tableau de bord de surveillance durant un pic de trafic : courbes en forte hausse, jauges dans le rouge, bannières d'alerte rouges

Ce que vous voyez sur le tableau de bord :

Volume de requêtes 10× la normale
Taux d'erreurs 25 %
Latence 3000 ms
CPU 95 %

Analyse : Ressources saturées par une flambée de trafic

Actions :

Mise à l'échelle horizontale immédiate
Activer l'auto-scaling
Mettre en place une limitation de débit
Ajouter de la mise en cache pour réduire la pression sur l'arrière-plan

Scénario 2 : goulot d'étranglement BD

Tableau de bord montrant un goulot d'étranglement BD : icône de base de données rouge fissurée, jauges CPU et connexions au maximum en rouge, courbe de latence des requêtes en forte hausse, barre du bassin de connexions presque pleine

Ce que vous voyez sur le tableau de bord :

CPU BD 95 %
Connexions BD 95/100
Latence des requêtes 5000 ms
Latence appli 5500 ms

Analyse : La base de données est le goulot ; requêtes lentes qui épuisent le bassin de connexions

Actions :

Repérer les requêtes lentes dans les journaux
Ajouter des index, optimiser les requêtes
Augmenter la taille du bassin de connexions
Mettre la base de données à l'échelle

Scénario 3 : défaillance en cascade

Ce que vous voyez sur la carte des services :

Cascade sur la carte des services : nœud A ambre avec erreurs client, B et C en rouge avec fautes serveur, D sombre et complètement à l'arrêt, flèches descendant la chaîne

Analyse :

Un petit problème au service A a fait cascade dans la chaîne de dépendances

Actions :

Disjoncteurs pour arrêter la cascade
Délais d'attente à chaque niveau de service
Mécanismes de repli pour les dépendances en échec
Corriger la cause racine dans le service A

Pratiques exemplaires pour tableaux de bord

Six pratiques exemplaires recommandées pour des tableaux de bord de santé applicative

Résumé de la vidéo et fin du cours

Concevez selon la hiérarchie de l'information et les quatre signaux d'or
Combinez métriques CloudWatch, traces X-Ray et journaux en une vue
Flux d'incident en sept étapes : identifier → délimiter → corréler → approfondir → cause racine → corriger → vérifier

Vous pouvez maintenant :

Surveiller avec métriques, journaux et tableaux de bord CloudWatch
Configurer des alarmes et avis avec SNS et SQS
Mettre en œuvre le traçage distribué avec X-Ray
Bâtir des tableaux de bord de santé applicative pour l'excellence opérationnelle

Tableaux de bord de santé applicative

Surveillance et dépannage sur AWS