Dépannage des problèmes de flux d'appels SMF avec des requêtes PromQL personnalisées

Introduction

Ce document décrit comment utiliser Grafana/Prometheus dans Cisco SMF pour créer des requêtes personnalisées afin de résoudre les problèmes liés au flux d'appels.

Abréviations

SMF	Fonction de gestion de session
UDM	Gestion unifiée des données
AMF	Fonction d'accès et de mobilité
PDU	Unité de données de protocole

Pourquoi personnaliser les requêtes pour résoudre les problèmes de flux d'appels SMF ?

Bien que les tableaux de bord intégrés fournissent de grands graphiques en ce qui concerne les indicateurs de performance clés et les statistiques d'intégrité des noeuds, afin d'utiliser tout le potentiel des requêtes PromQL et des grafana pour dépanner des scénarios de problèmes réguliers, les requêtes personnalisées jouent un rôle important. Les requêtes et les graphiques promql personnalisés offrent plus de polyvalence et de commodité pour isoler une défaillance spécifique.

Avantages des tableaux de bord intégrés :

• Grafana fournit une interface graphique et facile à utiliser pour parcourir les statistiques SMF.
• Il existe des tableaux de bord de grafana intégrés disponibles pour vérifier la plupart des indicateurs de performance clés et des statistiques.

Exemple :

Tableau de bord SMF 5G

• Taux de réussite/échec de création de PDU 5G
• Taux de réussite/échec de création de PDN 4G

• Taux de réussite par procédure

 

  

• Pourcentage de cause d'échec par procédure.
• Pourcentage de raison de déconnexion.
• Requête HTTP et pourcentage de cause de réponse correspondant.

Pour dépanner plus loin :

• Le tableau de bord et les panneaux disponibles portent principalement sur les pourcentages et les indicateurs de performance clés. Pendant que vous approfondissez vos recherches, vous devrez peut-être examiner des détails précis pour identifier le scénario et le message qui ont déclenché cet échec.
  
  
• Les requêtes personnalisées utilisant des expressions régulières spécifiques doivent permettre de corréler ces statistiques et d'isoler le déclencheur.
  
  
• Ces requêtes peuvent être utilisées pour tracer des graphiques dans la grafana SMF ou dans la grafana hors connexion avec le vidage des métriques du paquet tac-debug.
  
  
• La plage de métriques associée à différents services peut être utilisée et peut également être filtrée par des paires clé/valeur d'étiquette pour résoudre le problème du scénario spécifique.

Grafana et Prométhée

  

Grafana

“ Grafana est un logiciel de visualisation et d'analyse open source. Il vous permet d'interroger, de visualiser, d'alerter et d'explorer vos mesures, quel que soit l'endroit où elles sont stockées. ”

Cisco SMF utilise une grafana intégrée pour tracer les données statistiques en temps réel des conteneurs d'applications.

Prométhée

Prometheus fournit un modèle de données multidimensionnel avec des données de séries chronologiques identifiées par des paires nom métrique et clé/valeur et un langage de requête flexible nommé PromQL pour accéder à ces données.

Prométhée est utilisé pour collecter des statistiques/compteurs à partir des microservices.

Métriques : identificateurs des statistiques de la série chronologique.

    

Étiquettes - Les mesures sont composées d'étiquettes. Quelles sont en fait les paires clé-valeur ? Les combinaisons d'étiquettes d'une mesure particulière identifient une instance particulière de données de séries chronologiques

Exemple :   

       

La mesure “ smf_service_stats ” mise en surbrillance en vert, comporte de nombreuses étiquettes qui sont mises en surbrillance en jaune.

À l'aide de ces paires clé/valeur d'étiquette, vous pouvez sélectionner une série particulière de données.

Requête PromQL

Prometheus fournit un langage de requête fonctionnel appelé PromQL. Les fonctions intégrées sont disponibles dans PromQl (ex. Sum(), by(), count() etc) nous permet de sélectionner des données de séries chronologiques particulières dans un format graphique ou tabulaire.

Exemple :

sum(smf_service_stats{status="success"}) by (procedure_type)

 Cet exemple montre comment sélectionner les données de la métrique smf_service_stats par type_procédure où status = “ succès ”

somme (calcul de la somme sur les dimensions)

by(Regroupe la sortie par étiquettes)

Les filtres peuvent être utilisés à l'intérieur de la somme à l'aide de paires clé/valeur d'étiquette pour filtrer davantage les graphiques.

Exemple 1 :

   

sum(smf_disconnect_stats{namespace="smf-data",reason=~"disc_eutra.*"})by(reason, rat_type)

Ici l'espace de noms smf-data est sélectionné et comme raison, toute raison de déconnexion commençant par disk_eutra (c'est-à-dire les raisons de déconnexion 4G) doit être prise en compte.

Exemple 2 :

    

sum(smf_restep_http_msg{namespace="smf-data", api_name=~"sdm_.*"}) by(api_name,message_direction,response_status,response_cause)

Cette requête doit tracer les messages SMF - UDM sdm-subscribe avec la cause de la réponse.

Comment créer un tableau de bord et un panneau ?

Afin d'ajouter un nouveau tableau de bord.

Étape 1. Accédez à Créer > Tableau de bord, comme illustré dans cette image.

Afin d'ajouter Nouveau Panneau - Ajouter une requête.

Étape 2. Accédez à l'option Ajouter un panneau en haut pour ajouter un nouveau panneau.

Étape 3. Sélectionnez le bouton Ajouter une requête.

Sélectionnez Type de requête - Prométheus haute résolution.

Étape 4. Sélectionnez Prometheus hi-res dans la liste déroulante Requête.

Étape 5. Ajoutez ensuite la requête promql dans la zone donnée.

Étape 6. Enregistrez le panneau.

Exemple : Utiliser la requête et les graphiques personnalisés pour résoudre les problèmes

Échec de l'établissement de la session PDU - Échec de la réponse N1N2

Étape 1. L'observation de l'inclinaison de l'indicateur de performance clé (KPI) et l'identification de la session PDU créent un échec.

Query: sum by (procedure_type, pdu_type, status, reason) (smf_service_stats{namespace="smf",procedure_type="pdu_sess_create"})

Étape 2.  La cause de l'échec est “ n1n2_transfer_Failure_rsp_code ”. Examinons les raisons de la déconnexion :

Query: sum(smf_disconnect_stats{namespace=”smf"}) by (reason)

Étape 3. La raison de déconnexion “ disk_pdusetup_n1n2_transfer_rsp_fail ” indique une réponse négative de l'homologue AMF. Puisque l'interaction SMF-AMF est via une interface HTTP basée sur le service, les statistiques HTTP doivent être examinées plus en détail (métrique : smf_restep_http_msg)

Les statistiques HTTP indiquent que pendant l'échec, SMF a reçu un code d'état HTTP 401 - Non autorisé d'AMF 

Query: sum(smf_restep_http_msg{namespace="smf"}) by(api_name,message_direction,response_status)

Mesures importantes à dépanner :

  smf_disconnect_stats

  smf_proto_pfcp_msg_total

  smf_service_stats

  smf_restep_http_msg

  smf_n1_message_stats

  smf_proto_pfcp_msg_total

  nodemgr_msg_stats

  nodemgr_gtpc_msg_stats

  chf_message_stats

  policy_msg_processing_status

  procedure_protocol_total

  procedure_service_total

Informations complémentaires sur les métriques SMF :

 Comme le montrent ces exemples, on peut tracer ses propres graphiques personnalisés selon les besoins pour le scénario d'échec spécifique afin de corréler différents messages et d'isoler l'échec. De telles requêtes peuvent être exécutées dans des systèmes locaux aussi après que les données de mesure de Tac_debug_pkg ont été montées sur une grafana locale.