Suivez une requête lente avant de redimensionner

Choisissez une requête avec un résultat attendu clair

Pour un point de terminaison de rapport illustratif, consignez le modèle de route, la taille approximative des données, le contexte d'authentification et si cela crée un travail en arrière-plan. Utilisez un compte de test et des données représentatives anonymisées. Ne copiez pas de jetons, d'identifiants clients ou de corps de requête complets dans une note d'incident.

Séparez le coût de démarrage de la première requête du comportement stable répété. Consignez la fenêtre UTC et la révision de version. Déterminez si toutes les routes sont lentes, si seuls les rapports volumineux sont affectés, ou si le délai suit une dépendance externe. Ces distinctions rendent la mesure suivante plus utile qu'une vaste collecte de métriques sans rapport.

Construisez une chronologie sans double comptage

Les traces OpenTelemetry relient les spans associés via un contexte propagé à travers les frontières de service. La correspondance des horodatages seule ne suffit pas. Les spans synchrones imbriqués et les appels parallèles peuvent se chevaucher. Les enfants asynchrones peuvent survivre à leur parent, donc additionner toutes les durées de span peut double-compter le temps écoulé. Suivez les opérations qui déterminent quand la requête se termine.

Référence technique : Traces OpenTelemetry · Comportement de fin de span OpenTelemetry.

L'intervalle le plus long suggère où inspecter, pas la cause racine. Un intervalle de base de données mesuré dans l'API peut inclure l'attente d'une connexion avant qu'une requête n'atteigne la base de données. Une télémétrie manquante ne prouve pas non plus qu'aucun travail n'a eu lieu ; inspectez l'échantillonnage et la couverture d'instrumentation.

Corrélez les observations applicatives et hôtes

Collectez les temps de requête, les erreurs, l'utilisation des connexions à la base de données, l'âge de la file d'attente, la pression CPU, mémoire et disque pour la même fenêtre. Notez les sauvegardes, migrations ou versions concurrentes. Une seule capture d'utilisation peut manquer la rafale qui a affecté la requête.

Utilisez des identifiants de corrélation et des horodatages dans des journaux expurgés avec une rétention et des contrôles d'accès appropriés. Évitez les secrets bruts, les charges utiles clients et les étiquettes de métriques non bornées. Instrumentez la frontière nécessaire à l'hypothèse et évaluez la surcharge. Un nouvel agent de traçage est lui-même un changement qui mérite d'être observé.

Inspectez la requête sans provoquer un autre incident

Identifiez d'abord la forme de la requête, les caractéristiques de taille d'entrée et les attentes de connexion ou de verrou. PostgreSQL EXPLAIN décrit un plan ; EXPLAIN ANALYZE exécute réellement l'instruction et ajoute une surcharge d'instrumentation. Une écriture peut modifier les données, tandis qu'une lecture coûteuse crée quand même de la charge. Utilisez une base de données représentative isolée pour l'investigation initiale.

Le coût du planificateur n'est pas des millisecondes écoulées. Une minuscule table de test peut produire un plan différent de celui du jeu de données plus volumineux de l'application. Examinez les statistiques, les index et la distribution, puis comparez la même forme de requête après l'avoir modifiée. Ne collez jamais une écriture inconnue dans une commande d'analyse en production simplement pour obtenir un chronométrage.

Référence technique : PostgreSQL EXPLAIN.

Prédisez ce qu'une modification devrait améliorer

Si l'attente de pool domine, inspectez les connexions des workers ou les requêtes qui conservent une connexion inutilement. Si l'exécution de requête domine, inspectez le plan et les lignes demandées. Si une API externe domine, examinez les délais d'attente, les réessais et si le travail doit être synchrone. La saturation CPU pendant la sérialisation indique une expérience différente.

Écrivez une prédiction : réduire la concurrence des exports devrait réduire l'attente du pool API tandis que les exports prennent plus de temps. Cela expose le compromis. Répétez le même mélange de requêtes, comparez la latence et les erreurs, et vérifiez que l'amélioration n'a pas simplement déplacé l'échec vers une file d'attente en croissance continue.

Conservez le résultat et son incertitude

Consignez l'observation d'origine, la modification testée, la méthode de comparaison et l'incertitude restante. Si les preuves contredisent l'hypothèse, annulez la modification isolée le cas échéant et investigatez une autre frontière. Évitez d'accumuler des changements de réglage permanents sans explication.

Redimensionnez lorsque les mesures identifient une contrainte de ressource qu'une allocation supplémentaire pourrait résoudre. Utilisez le budget de charge de travail et capturez une régression de version dans le brief d'incident. Le résultat est un diagnostic raisonné, pas une latence promise ni un benchmark de fournisseur.