Types d'événement
Pour vous aider à gérer la qualité de service de vos applications, Instana détecte trois types d'événement.
Incident
Un incident vous aide à comprendre les situations ayant un impact sur vos services de périphérie et votre infrastructure critique en apprenant automatiquement leur comportement et leur état de santé, puis en envoyant des alertes lorsqu'elles perdent leur intégrité. Les services de périphérique sont ce à quoi les clients ou les autres systèmes en dehors de l'application surveillée ont réellement accès ; ce sont les livrables externes de l'application.

Les incidents sont créés dès que Instana détecte qu'un indicateur de performance clé (KPI) fait l'objet d'une infraction sur un service de bord ou une question d'infrastructure critique. Pour plus de contexte, consultez notre blogue Analyze and Derive Application Health .
Pour les services d'application reconnus, Instana suit les indicateurs clés de performance suivants :
- Charge (appels/seconde).
- Latence (temps de réponse en millisecondes).
- Erreurs (taux d'erreur).
Instana mesure automatiquement ces indicateurs clés de performance pour chaque service et applique l'apprentissage automatique sur chacun pour déterminer l'intégrité d'un service. Les incidents types détectés sont les suivants :
- Le taux d'erreur est supérieur à la normale.
- Les performances du service sont lentes.
- La charge chute de manière soudaine.
Les indicateurs clés de performance sont déterminés par la capture et l'analyse de chaque trace entre les services et l'application. Les traces enregistrent automatiquement les erreurs, telles que les codes d'état ou les exceptions, afin de déterminer si un problème s'est produit. Les traces permettent également de mesurer le temps passé dans chaque service et ses composants sous-jacents. Dans l'architecture Dapper d' Google, une trace est une arborescence composée de segments, chaque segment constituant une unité de travail de base. Dans le monde du microservice, une étendue équivaut normalement à une demande de service ou de composant, comme une base de données. Cela signifie que nous n'avons pas seulement une trace de bout en bout de l'application, mais aussi des informations sur les performances de chaque service et chaque composant.
Si l'état de santé d'un service est affecté, Instana crée un nouvel incident et, en parcourant le graphique dynamique des problèmes et des événements, met en corrélation tous les autres incidents. Cela donne un aperçu complet de la situation concernant le service et l'incidence sur les événements.
Problème
Un problème est un événement qui est déclenché si quelque chose sortant de l'ordinaire se produit.
Les problèmes d'infrastructure critiques, tels que la saturation du disque et les situations de divisions de cerveau de cluster Elasticsearch, déclenchent des incidents car ils finissent probablement par provoquer une perte de données.

Dans l'exemple précédent, le temps d'utilisation de l'unité centrale sur une machine Linux est suspect et est donc présentée comme un problème. Un problème en lui-même ne déclenche pas d'alerte, Instana note simplement que c'est arrivé. Si le service auquel ce système est connecté présente des dysfonctionnements, ce problème est considéré comme faisant partie de l'incident. Cette méthodologie est l'un des principaux avantages d'Instana car elle vous évite de devoir corréler manuellement les événements et les problèmes de performance. Ce n'est pas parce qu'un processus utilise trop de ressources CPU pendant un certain temps qu'il y a nécessairement un problème. Cette information ne sera pertinente que dans le cas où un service est touché.
Instana enregistre le moment où un problème se produit d'abord et également le moment où la condition cesse d'exister (heure de début et de fin). Dans ce cas, vous voyez que le vol de l'unité centrale a dépassé la limite de 5 % pendant seulement deux minutes et demie (de 07:08:37 à 07:10:54). Cliquez sur la ligne du ticket pour afficher les détails dans le panneau des détails du ticket. L'augmentation du vol d'UC est évidente vers 17h10.
Le lien « Afficher l'événement intégré » vous redirige directement vers la définition correspondante dans les paramètres « Événements et alertes » de ce ticket. Cela permet de comprendre sur quelle base une question particulière a été créée.
Remarque :
- Les applications, services ou points de terminaison qui ne reçoivent qu'un trafic sporadique, par exemple un appel toutes les 15 minutes, ne sont pas considérés comme offrant une base suffisante pour notre détection des incidents.
- La gravité d'un problème peut changer au cours de sa durée de vie. Elle représente la plus grande gravité qui ait été atteinte par ce problème particulier.
Changer
Un changement au sein d'un environnement comprend, sans s'y limiter, les déploiements, les modifications de configuration, les démarrages ou les arrêts de serveurs, et est classé selon les catégories suivantes :
- Modifications - Modification de la configuration des composants.
- Hors ligne/En ligne - Suivi de la présence des composants gérés.
Instana reconnaît les modifications par le suivi des configurations spécifiques à chaque technologie surveillée, et en surveillant s'il se passe quelque chose en ligne (surveillé par Instana) ou hors ligne (n'est plus surveillé par Instana).
Chaque modification est enregistrée et n'a généralement qu'une durée de 1 seconde (différence entre l'heure de début et l'heure de fin). À l'instar des problèmes, les événements de modification sont également mis en corrélation dans un incident, au cas où ils seraient pertinents, ce qui vous permet de recevoir une alerte simplement parce qu'un système est passé hors ligne. Il a peut-être été éteint parce que la charge a diminué à la fin de la journée de travail et qu'il n'était plus nécessaire.
