Observer le service et ses utilisateurs

Partir de la question

La supervision vérifie des conditions connues. L’observabilité aide à examiner le comportement du système, y compris des défaillances imprévues. Davantage de tableaux de bord ne donne pas automatiquement de meilleures réponses.

Pour un service d’export fictif, partez d’une question utilisateur : un utilisateur autorisé peut-il recevoir le bon export dans le délai convenu ? Choisissez ensuite des signaux qui éclairent cette question et aident à expliquer les échecs.

OpenTelemetry fournit une instrumentation et des standards de télémétrie. Il peut envoyer des signaux à des backends compatibles. Il vous faut encore du stockage, des requêtes, des contrôles d’accès, des règles de conservation et des personnes qui agissent sur les preuves. Introduction à l’observabilité.

Relier les différentes formes de preuves

Une métrique mesure une quantité dans le temps. Un journal consigne un événement. Une trace relie les opérations associées au parcours d’une requête dans un système. Un span représente une opération au sein d’une trace.

Pour le travail asynchrone, préservez une corrélation sûre entre la tâche soumise et l’exécution du worker. Une réponse HTTP 202 peut signifier que le travail est accepté. Elle ne prouve pas que l’export est terminé.

Alerter lorsqu’une action est nécessaire

Définissez le SLI et son dénominateur avant de fixer le SLO. Dans cet exemple, comptez les exports admissibles correctement terminés dans le délai convenu. Définissez comment les tâches longues et abandonnées entrent dans la mesure.

Un budget d’erreur décrit les échecs permis dans la fenêtre du SLO. Un taux de consommation décrit la vitesse à laquelle les échecs épuisent ce budget. Les recommandations de Google utilisent plusieurs fenêtres pour équilibrer la rapidité de détection et le bruit des alertes. Alertes fondées sur les SLO.

Alertez une personne d’astreinte lorsque la condition exige une action rapide. Envoyez le travail moins urgent dans une file. Chaque alerte nécessite un responsable, une description de l’impact, un lien d’investigation et une instruction de réponse. Revoyez les alertes qui ne conduisent régulièrement à aucune action.

N’utilisez pas un seuil générique pour tous les services. L’effet sur les utilisateurs, le trafic, les horaires métier et la capacité de réponse influencent la décision.

Protéger le pipeline de télémétrie

La télémétrie peut contenir des données personnelles, des tokens, des paramètres de requête et des documents confidentiels. Définissez les champs autorisés avant la collecte. Limitez les accès et la conservation. Masquez les secrets avant l’export vers un backend externe. Télémétrie sensible.

N’utilisez pas l’adresse e-mail d’un client ou un identifiant unique de tâche comme label de métrique. Les labels non bornés augmentent le nombre de séries temporelles et peuvent exposer des identifiants. Utilisez des dimensions contrôlées pour les métriques. Placez les identifiants de corrélation approuvés dans des journaux ou des traces à accès contrôlé.

Mesurez le pipeline lui-même. Vérifiez les échecs d’ingestion, les données perdues et l’ancienneté de la dernière observation. Une courbe d’erreurs plate peut signifier qu’il n’y a aucune erreur ou qu’aucune télémétrie n’arrive. Rendez cette distinction visible.

Examiner une défaillance concrète

Le service fictif renvoie HTTP 202 pour chaque requête. L’ancienneté des tâches en attente passe de quelques secondes à 15 minutes. Les journaux des workers montrent des dépassements de délai répétés sur la base. Les traces échantillonnées placent l’essentiel du temps des workers dans les appels à la base.

Ces preuves permettent une investigation ciblée. Elles n’établissent pas si la cause est une requête modifiée, des connexions épuisées ou la capacité de la base. Comparez ces hypothèses avec la méthode de débogage.

Taiga Monitoring fournit une vue de la santé du produit avec des signaux de disponibilité et d’expérience dans le navigateur. Il complète l’observabilité de l’infrastructure et de l’application ; il ne remplace pas ces systèmes. Monitoring.