Corrélation Alarmes-KPIs OVOC et Incidents

Bonjour,

Dans la leçon précédente, nous avons plongé au cœur du dépannage média en analysant les flux RTP avec Wireshark pour résoudre les problèmes de "no audio". Cette approche est extrêmement puissante pour une analyse fine, mais elle n'est pas adaptée pour surveiller la santé globale d'une infrastructure VoIP complexe. Que faites-vous quand un utilisateur signale un problème, mais que vous ne savez pas quel appel analyser parmi des milliers ?

C'est là qu'intervient le One Voice Operations Center (OVOC). Cette leçon vous apprendra à passer du dépannage réactif au niveau du paquet à une supervision proactive à l'échelle du système. L'objectif est de vous rendre capable de corréler les alarmes et les indicateurs de performance dans OVOC avec un incident en cours. Nous allons apprendre à utiliser les tableaux de bord d'OVOC pour détecter un problème, l'isoler, puis descendre au niveau de l'appel pour une analyse ciblée.

1. La Vue d'Ensemble : Indicateurs de Performance et Dashboards

Votre première étape face à un incident n'est généralement pas d'ouvrir Wireshark, mais de consulter les tableaux de bord de supervision. OVOC collecte en permanence des centaines de métriques, appelées indicateurs de performance (Performance Monitors ou PMs), et les présente sous forme de graphiques faciles à interpréter.

Ces tableaux de bord sont votre système de détection précoce. Un pic soudain dans le graphique "Failed Calls" ou une chute du "Daily Call Quality" est une alerte visuelle immédiate qu'un incident est en cours.

Pour comprendre la richesse des données disponibles, il est utile de savoir ce qu'OVOC peut mesurer.

En pratique, si un opérateur (ITSP) vous signale un problème, vous pouvez filtrer ces tableaux de bord sur l'IP Group qui lui correspond pour voir si la dégradation ne concerne que ce partenaire.

2. De la Réaction à la Proaction : Le Système d'Alarmes

Surveiller des graphiques est utile, mais vous ne pouvez pas les regarder 24h/24. Le véritable pouvoir d'OVOC réside dans sa capacité à générer des alarmes de manière proactive lorsque quelque chose ne va pas.

Il existe deux types principaux d'alarmes :

1. Alarmes d'état : Elles sont générées par des événements système clairs, comme la perte de connectivité avec un SBC (Device Disconnected) ou l'échec des messages de supervision d'un trunk SIP (SIP Trunk Down).
2. Alarmes de seuil : Ce sont les plus puissantes pour le monitoring de la qualité. Vous pouvez configurer OVOC pour qu'il génère une alarme lorsqu'un indicateur de performance (PM) dépasse un seuil que vous avez défini.

Le document suivant vous montre comment les alarmes sont présentées dans l'interface d'OVOC.

Le lien entre les indicateurs de performance et les alarmes se fait via la configuration de seuils. Par exemple, vous pouvez définir une règle : "Si l'indicateur acPMSBCIPGroupAsr (ASR par IP Group) pour l'IP Group 'Teams_DirectRouting' tombe en dessous de 80% pendant plus de 15 minutes, générer une alarme de sévérité 'Major'".

Ceci est expliqué dans le premier guide que nous avons consulté.

3. La Méthode de Corrélation : Un Scénario de Dépannage

Mettons tout cela en pratique avec un scénario courant.
Incident : Un administrateur Microsoft Teams signale que "les utilisateurs ne peuvent plus passer d'appels sortants via Direct Routing depuis 10h00".

Voici votre plan d'action utilisant OVOC :

Étape 1 : Analyser la situation (Dashboards)

• Vous ouvrez le tableau de bord "Analytics" d'OVOC.
• Vous ajustez la plage de temps pour vous concentrer sur la période depuis 10h00.
• Vous filtrez les données pour n'afficher que l'IP Group correspondant à Microsoft Teams.
• Observation : Vous constatez une chute brutale de l'ASR et un pic de "Failed Calls" précisément à partir de 10h00 pour cet IP Group. Le symptôme est confirmé et isolé.

Étape 2 : Vérifier les alarmes

• Vous allez dans la page Monitor > Alarms.
• Observation : Vous trouvez une alarme de sévérité "Critical" apparue à 10h01 : acPerformanceMonitoringThresholdCrossing, avec la description : "Le nombre d'échecs sortants ('Out User Defined Failures') pour l'IP Group 'Teams' a dépassé le seuil". Vous avez maintenant une confirmation proactive du problème.

Étape 3 : Isoler un exemple (Drill-Down)

• Maintenant que vous savez quoi chercher (échecs sortants sur le trunk Teams), vous devez trouver un exemple concret.
• Dans OVOC, vous utilisez la fonction de recherche de CDR (Call Detail Records). Vous filtrez sur :
  • IP Group source : 'Teams'
  • Statut : 'Failed'
  • Période : Après 10h00.
• Vous obtenez une liste d'appels qui ont échoué. Vous en sélectionnez un.
• OVOC vous présente alors la vue "Call Flow".

• Observation : Dans la vue "Call Flow", vous voyez que le SBC envoie un INVITE à l'opérateur, mais reçoit en retour un 401 Unauthorized.

Étape 4 : Analyser la cause racine

• Vous avez maintenant une information extrêmement précise : l'opérateur rejette les appels de Teams avec une erreur d'authentification.
• Le problème n'est probablement pas lié au routage ou au média, mais à la signalisation SIP (peut-être un mot de passe de trunk qui a expiré ou une adresse IP qui n'est plus autorisée).
• Avec le Call-ID obtenu depuis la vue "Call Flow", vous pouvez maintenant faire l'analyse de bas niveau que nous avons vue dans les leçons précédentes :
  • Rechercher ce Call-ID dans les Syslogs du SBC pour voir des détails supplémentaires.
  • Contacter l'opérateur avec une heure précise et un code d'erreur clair.
  • Si besoin, lancer un Debug Recording pour un nouvel appel test afin de capturer la trace complète pour Wireshark.

Vous avez bouclé la boucle : Symptôme (Dashboard) → Confirmation (Alarme) → Isolation (Call Flow) → Analyse (Logs/Traces).

Conclusion

La corrélation entre les indicateurs de haut niveau d'OVOC et les incidents spécifiques est une compétence essentielle pour gérer efficacement une infrastructure AudioCodes. Elle vous permet de passer d'une posture réactive, où vous attendez qu'un utilisateur signale un problème, à une posture proactive, où le système vous alerte avant même que l'impact ne soit généralisé.

Points Clés à Retenir :

• Commencez toujours votre diagnostic par les tableaux de bord d'OVOC pour avoir une vue d'ensemble et isoler le périmètre de l'incident (quel partenaire, quelle direction, depuis quand).
• Utilisez les alarmes comme votre système de détection automatique. Configurez des seuils sur les indicateurs de performance clés (ASR, NER, échecs d'appels) pour être notifié des dégradations.
• La vue Call Flow d'OVOC est le pont entre la surveillance de haut niveau et l'analyse de bas niveau. Elle vous fournit un exemple concret d'appel en échec avec le code d'erreur SIP.
• Le processus de corrélation est un entonnoir : partez du plus large (tous les appels) pour finir sur le plus précis (un message SIP dans une trace).

Aperçu de la prochaine leçon :

Dans cette leçon, nous avons assemblé une partie cruciale du puzzle du dépannage : comment passer de la surveillance à l'analyse. Dans la prochaine et dernière leçon de ce module, nous allons formaliser tout ce que nous avons appris. Nous allons définir une méthodologie de dépannage structurée de A à Z, du premier signalement d'un symptôme jusqu'à la validation de la correction. Cela vous donnera un plan d'action fiable à appliquer pour n'importe quel incident.