Gains :
- Capacité à comprendre les trois piliers de l'observabilité (métrique, log, trace) et les quatre signaux d'or et à faire en sorte que l'intelligence artificielle génère des requêtes PromQL, des règles d'alarme et des tableaux de bord
- Capacité à éviter la fatigue des alarmes en gardant les alarmes orientées vers l'action et au bon niveau d'urgence et en testant les seuils par rapport aux données historiques de votre propre système.
- Capacité à empêcher la confidentialité et les fuites de secrets en masquant les zones sensibles avant de transmettre les journaux à l'intelligence artificielle
Même si un système semble fonctionner, il peut être en train de mourir à l'intérieur : la mémoire se remplit lentement, les temps de réponse augmentent, le taux d'erreur augmente. La seule façon de s’en rendre compte est de surveiller constamment le système. Un concept plus avancé est l'observabilité : la capacité de comprendre ce qui se passe à l'intérieur du système en observant ses signes externes. Il existe trois piliers de l'observabilité, et le professionnel DevOps utilise les trois :
- Métrique : valeurs numériques mesurées au fil du temps : utilisation du processeur, nombre de requêtes, temps de réponse, taux d'erreur. "Combien?" répond à la question.
- Journal : enregistrements d'événements textuels produits par le système : "utilisateur connecté", "connexion à la base de données perdue". « Que s'est-il passé exactement ? répond à la question.
- Trace : le chemin suivi par une requête en passant d'un service à l'autre au sein du système et la durée de chaque étape. « Où est la lenteur ? répond à la question.
Outils les plus courants : Prometheus pour les métriques, Grafana pour la visualisation, Loki/ELK pour le journal, Jaeger/OpenTelemetry pour la trace. L'IA est très compétente dans l'écriture des langages de requête (en particulier PromQL de Prometheus), des règles d'alarme et des configurations de tableaux de bord pour ces outils. C’est également là que l’IA est la plus performante : résumer de gros morceaux de journaux et de métriques et signaler les anomalies.
Clarifions la différence entre la surveillance et l'observabilité en une phrase : la surveillance consiste à poser des questions que vous connaissez déjà (« Le processeur dépasse-t-il 90 % ? » ); l'observabilité, c'est être capable de poser des questions que vous ne connaissiez pas déjà (« pourquoi cette étrange lenteur ne se produit-elle que pour un certain client à un certain moment ? »). Les systèmes modernes sont si complexes qu’il est impossible de prédire tous les modes de défaillance ; Par conséquent, la capacité de collecter des métriques, des journaux et des traces riches, puis de les interroger en profondeur (c'est-à-dire l'observabilité) devient essentielle. C'est là que l'IA entre en jeu pour répondre à la « question jusqu'alors inconnue » : elle analyse rapidement les données brutes dont vous disposez, suggère des modèles et des anomalies, et vous accédez à la cause profonde en vérifiant ces indices.
Pas à pas : que surveiller et comment ?
- Choisissez les bonnes mesures. Dans l'industrie, « quatre signaux d'or » sont pris comme base : la latence, le trafic, les erreurs, la saturation — le niveau de remplissage de la ressource. Ceux-ci résument la santé de la plupart des services.
- Collectez des métriques. Laissez l'application présenter un point de terminaison que Prometheus peut lire.
- Mettre en place des tableaux de bord. Visualisez ces métriques dans Grafana.
- Écrivez des règles d'alarme. Qui sera prévenu en cas de dépassement d’un seuil et comment ?
- Centralisez les journaux. Rendre tous les journaux de service consultables en un seul endroit.
- Réduisez le bruit. Trop d’alarme crée une « fatigue d’alerte » ; L'alarme importante disparaît.
Astuce : Une bonne alarme répond à deux critères : elle est exploitable et présente la bonne urgence. Une alarme qui réveille quelqu’un à 3 heures du matin doit en fait nécessiter une intervention nocturne. Ne réveillez personne pour quelque chose qui ne nécessite aucune action en soi, comme « CPU 70 % » ; affichez-le au tableau.
Comment rédiger une règle d’alarme ?
Une alerte se compose de trois éléments : la condition (quelle métrique dépasse quel seuil et pendant combien de temps), la durée (« pendant 5 minutes » pour éviter de déclencher des fluctuations momentanées) et l'importance/l'action (à qui, par quel canal). L’IA établit magistralement ces trois éléments dans le bon contexte. Par exemple, traduire une règle telle que « alarme critique si le taux d'erreur dépasse 5 % pendant 5 minutes » en PromQL est une tâche d'une fraction de seconde pour l'IA, mais vous décidez si le seuil est adapté à votre système.
Attention : Les seuils d'alarme proposés par l'IA sont des hypothèses générales. La charge normale, la tolérance et l'impact du travail de votre système sont différents. Avant de définir un seuil directement dans la production, vous examinez vos données historiques et vous demandez : « combien de fois ce seuil a-t-il été déclenché dans le passé, combien d'entre eux étaient de réels problèmes ? » Répondez à la question.
Confidentialité des journaux : avertissement critique
Les journaux sont la source de fuite la plus fréquemment négligée. Une ligne de journal peut accidentellement contenir un mot de passe, un numéro de carte de crédit ou des données personnelles (sous KVKK/GDPR). Lors du collage de journaux dans une IA pour analyse :
- Masquer les zones sensibles. Remplacez les valeurs telles que le jeton, le mot de passe, l'e-mail, le numéro d'identification par <SUPPRIMÉ>.
- Donnez des exemples, pas tous. Au lieu d’un million de lignes, quelques centaines de lignes représentatives suffisent souvent.
- Choisissez un véhicule agréé par l'établissement. Surtout pour les journaux de production, utilisez un outil dont les données ne vont pas à la formation.
Quatre signaux dorés et tables d'alarme
signaler
mesuré par
Exemple de seuil d'alarme
urgence
latence
temps de réponse
p95 > 800 ms, 5 min
haut
trafic
Requête/s
Augmentation/diminution soudaine de 300 %
moyen
Erreur
Taux de demandes échouées
> 5%, 5 minutes
critique
Saturation
occupation des ressources
Disque > 85 %
haut
trois mini-cases
Cas 1 : 400 lignes de journal résumées en 30 secondes. Un service avait été ralenti. L'ingénieur a donné les 400 lignes de journal masquées à l'IA et a dit : "résumez les modèles d'erreurs récurrentes et l'intensité temporelle". L'IA a montré qu'un appel d'API externe particulier expire toutes les 30 secondes. Cause fondamentale trouvée en 30 secondes ; L'analyse manuelle des journaux prendrait une demi-heure.
Cas 2 : la fatigue liée aux alarmes est résolue. Une équipe recevait 200 alarmes par jour et les ignorait toutes, jusqu'à ce qu'une véritable alarme de panne soit également négligée. Donnez à l'IA toutes les règles d'alerte et demandez « lesquelles ne sont pas exploitables et lesquelles peuvent être combinées ? ont-ils demandé. Le nombre d'alarmes a diminué à 12 par jour ; Chaque alarme était désormais prise au sérieux.
Cas 3 : mauvais seuil détecté tôt. YZ a suggéré « Avertir lorsqu'il est plein à 95 % » pour le disque. L'ingénieur a examiné les données historiques : une fois que le disque atteignait 95 %, il restait peu de temps pour intervenir. Il a abaissé le seuil à 80 % et ajouté une deuxième alarme basée sur le « taux de croissance ». La vérification a empêché une véritable panne de courant à minuit.
Quatre modèles copiables
1) Résumé du journal (masqué) :
Analysez l'exemple de journal ci-dessous (j'ai masqué les valeurs sensibles avec <SUPPRIMÉ>). Donnez-moi : (1) les modèles d'erreurs récurrentes, (2) la concentration au fil du temps, (3) la cause profonde la plus probable et (4) 3 mesures que j'examinerai pour vérifier. Journal : [LIGNES]
2) Génération de règles d'alarme :
Écrivez une règle d'alarme pour Prometheus/Alertmanager : générez une alarme [SEVERITY] si [THRESHOLD] dépasse [METRIC][DURATION]. La règle doit être orientée vers l’action et inclure un champ de lien d’annotation et de runbook. Expliquez PromQL et écrivez pourquoi ce seuil est raisonnable.
3) Écriture/déclaration d'une requête PromQL :
Écrivez une requête PromQL qui mesure : [EX. 5xxpourcentage de taux d'erreur au cours des 5 dernières minutes]. Expliquez la requête étape par étape. Alors dites-moi quelle devrait être la plage saine pour cette valeur.
4) Conception du tableau de bord :
Concevoir un tableau de bord Grafana pour [SERVICE] : avec quels panneaux dois-je afficher les quatre signaux dorés (latence, trafic, erreur, saturation) ? Suggérer une métrique, un type de visualisation et un seuil raisonnable pour chaque panneau. Objectif : voir l'état de santé d'un gardien en 10 secondes.
Invite faible/Invite forte
Faible : "Qu'est-ce qu'il y a dans ce journal ?" (suivi de 5000 lignes de journal brut, des jetons dedans)
Résultat : vous divulguez des secrets et l’IA donne un résumé superficiel et non ciblé.
Fort : "Trouvez les modèles d'erreurs récurrentes et l'intensité temporelle dans l'exemple de journal masqué de 300 lignes ci-dessous ; dites-moi la cause première la plus probable et les mesures que je vais examiner pour vérifier. J'ai créé les jetons <SUPPRIMÉ>."
Différence : la deuxième invite donne un exemple masqué et ciblé, demandant un résultat d'analyse clair ; C’est à la fois sûr et utile.
Erreurs courantes
- Coller le journal dans AI sans le masquer. La fuite de données secrètes/personnelles la plus courante.
- Définir des alarmes pour tout. La fatigue des alarmes enterre la véritable alarme.
- Alarme non exploitable. C’est un bruit d’avertissement contre lequel personne ne peut rien faire.
- Accepter le seuil de l’IA sans aucun doute. Le seuil doit être défini en fonction de l'historique de votre système.
- Il suffit de regarder la métrique. Sans journal ni trace, la cause première ne peut pas être trouvée la plupart du temps.
- Ne pas régler une heure d'alarme (pour). Les fluctuations momentanées produisent de fausses alarmes.
En résumé
Observabilité ; C'est la capacité de comprendre l'intérieur du système depuis l'extérieur avec des métriques, des journaux et des traces. Les quatre signaux d'or (latence, trafic, erreur, saturation) résument la santé de la plupart des services. L'IA est très puissante pour écrire des requêtes PromQL, des règles d'alarme et des tableaux de bord, ainsi que pour résumer de gros morceaux de journaux et trouver des anomalies. Mais il est de votre responsabilité de vérifier les seuils d'alarme par rapport à l'historique de votre propre système, de maintenir les alarmes orientées vers l'action et de ne jamais partager les journaux sans les masquer.
Tâche de candidature
Pour un service (ou un exemple de service) : (1) Faites générer une règle d'alarme pour le taux d'erreur avec le modèle « Génération de règle d'alarme » et définissez le seuil suggéré sur « combien de fois s'est-elle déclenchée dans le passé ? Testez-le avec la question ; (2) masquer un échantillon de journal dont vous disposez et le faire analyser avec le modèle « Résumé du journal » ; (3) notez quelle mesure vous examinerez pour confirmer la cause première la plus probable.
liste de contrôle
- [ ] J'ai choisi les métriques à suivre en fonction de quatre signaux en or.
- [ ] J'ai masqué tous les logs que je donnais à l'IA en termes de zones sensibles.
- [ ] J'ai vérifié que chaque alarme était orientée vers l'action et de la bonne urgence.
- [ ] J'ai testé les seuils d'alarme par rapport aux données historiques de mon système.
- [ ] J'ai filtré les fluctuations instantanées en ajoutant for (durée) aux alarmes.
- [ ] J'ai utilisé ensemble métrique + journal + trace pour la cause première.