Dragon Lizard System Operation and Maintenance Alliance : Comment Kindling-OriginX intègre les données de DeepFlow pour améliorer l'explication des pannes du réseau

Note de l'éditeur : En 2023, la communauté Dragon Lizard a officiellement créé l'alliance d'exploitation et de maintenance du système, qui comprend l'Académie des technologies de l'information et des communications, Alibaba Cloud, ZTE, l'Université Fudan, l'Université Tsinghua, l'Université du Zhejiang, Yunguan Qiuhao, Chengyun Digital. , Yunshan Network, il a été co-parrainé par 12 unités, dont Inspur Information, Tongxin Software et China Unicom Software Institute. Cet article est reproduit à partir de Yun Guan Qiu Hao et présente Kindling-OriginX, membre de la System Operation and Maintenance Alliance, pour générer automatiquement des rapports interprétables sur les causes profondes des pannes en combinant les capacités complètes de données réseau de DeepFlow.

DeepFlow est un projet open source qui exploite la technologie eBPF pour fournir une haute observabilité des infrastructures cloud complexes et des applications cloud natives. Grâce à la technologie eBPF, DeepFlow collecte des données précises de suivi des liens, des indicateurs de performances du réseau et des applications, avec une couverture complète des liens et de riches indicateurs de performances TCP. Ces fonctionnalités offrent aux utilisateurs professionnels et aux experts en réseau une assistance puissante en matière de dépannage et de localisation des problèmes.

Kindling-OriginX est un produit de dérivation de la cause première du défaut. L'objectif est de fournir aux utilisateurs un rapport interprétable sur la cause première du défaut, permettant aux utilisateurs de comprendre directement la cause première du défaut et avec le processus de raisonnement de la cause première pour vérifier la cause première. l'exactitude de la cause profonde du sexe. Les pannes de réseau sont difficiles à expliquer simplement. Il ne suffit pas d'indiquer simplement aux utilisateurs quel segment de réseau présente des problèmes. Les utilisateurs ont besoin de plus d'indicateurs et d'illustrations pour les aider à mieux comprendre quelles pannes se sont produites dans le réseau et où elles se sont produites.

Cet article présente Kindling-OriginX, qui combine les capacités complètes de données réseau de DeepFlow pour générer automatiquement des rapports interprétables sur les causes profondes des pannes.

soma-chaos simule une panne de réseau

• Injectez une erreur de simulation de réseau retardée de 200 ms dans le service du siège.

• Ensuite, nous utilisons d'abord DeepFlow pour identifier les pannes de réseau de 200 ms et prendre les mesures correspondantes.

Processus de dépannage manuel simplifié

Étape 1 : Utilisez le système Trace pour affiner la portée

Dans un environnement de microservices, lorsqu'un problème de performances survient sur une interface, la première étape consiste à utiliser le système de suivi pour vérifier quel lien est à l'origine de la lenteur et comprendre les performances spécifiques.

Grâce au système Tracing, les utilisateurs peuvent localiser avec précision des traces spécifiques. Après avoir analysé la trace, il a été constaté que le temps d'exécution du service de siège était long et qu'un long appel de service de configuration s'est produit en même temps. Dans ce cas, les indicateurs de réseau liés aideront à identifier la source du problème de réseau.

Étape 2 : Utilisez le graphique de flamme DeepFlow pour déterminer sur quel segment de réseau le défaut se produit

Saisissez le traceid du représentant de la panne dans DeepFlow dans le graphique de flamme, recherchez les performances de Trace au niveau du réseau, puis analysez le graphique de flamme en profondeur. Si vous avez une bonne compréhension des graphiques de flamme et une expérience experte en matière de connaissances du réseau, vous. peut utiliser le graphique de flamme selon le graphique de flamme. L'analyse humaine a révélé que ce défaut aurait dû se produire chez l'appelant, qui est le service du siège, et que le problème s'est produit pendant la période pendant laquelle l'appel système a été envoyé à la carte réseau, c'est-à-dire Autrement dit, il y a eu un problème pendant la période du réseau de conteneurs (ce qui est cohérent avec une injection de fautes).

(Graphique de flamme du réseau Image/DeepFlow)

Étape 3 : Déterminez quels indicateurs de réseau sont anormaux dans le réseau de conteneurs

Sur la base de l'expérience de dépannage, les utilisateurs doivent vérifier les indicateurs réseau des modules de siège-service et de config-service. À ce stade, l'utilisateur doit accéder à la page des indicateurs de réseau au niveau du pod de DeepFlow. Grâce à cette page, les utilisateurs peuvent visualiser une mutation du délai de 200 ms dans l'établissement de la connexion et une mutation de l'indicateur RTT.

(Indicateurs de surveillance du niveau Image/DeepFlow-pod)

(Indicateurs de surveillance du niveau Image/DeepFlow-pod)

Étape 4 : Éliminer les éventuels facteurs d'interférence

Selon l'expérience, lorsque le processeur et la bande passante de l'hôte sont pleins, une perte et un retard de paquets se produiront également dans le réseau virtuel. Il est donc nécessaire de vérifier le processeur et la bande passante au niveau du nœud du nœud où se trouvent le service de siège et le service de configuration. se trouvent à ce moment-là, assurez-vous que les ressources au niveau du nœud ne sont pas saturées.

Confirmez le nœud où se trouvent les deux pods via la commande k8s, puis accédez à la page de surveillance des indicateurs de nœud de DeepFlow pour vérifier les indicateurs correspondants. Il s'avère que les bps, pps et autres indicateurs du nœud se situent dans une plage raisonnable. gamme.

(Image/Trouver le nœud où se trouve le pod via la commande k8s)

(Indicateurs de surveillance du niveau du nœud Image/DeepFlow (client))

(Indicateurs de surveillance de niveau image/nœud DeepFlow (serveur))

Comme il n'y avait aucune anomalie évidente dans les indicateurs de réseau au niveau des nœuds, il a finalement été déterminé que l'indicateur rtt du service de siège au niveau du pod était anormal.

Résumé du dépannage manuel

Après une série de processus de dépannage, l'utilisateur final peut résoudre le problème, mais les exigences suivantes lui sont imposées :

• Connaissance très riche du réseau

• Compréhension approfondie du graphique de flamme du réseau

• Maîtrise des outils pertinents

Comment Kindling-OriginX combine les métriques DeepFlow pour produire des rapports de défauts explicables

Kindling-OriginX Basé sur différents besoins des utilisateurs et scénarios d'utilisation, Kindling-OriginX traite et présente les données DeepFlow.

Par analogie avec le processus de dépannage manuel le plus simplifié, le processus de dépannage utilisant Kindling-OriginX est le suivant :

Analysez automatiquement chaque trace

Au vu de la panne à ce moment, chaque Trace est automatiquement analysée, et les Traces répertoriées sont regroupées selon le nœud de la panne. Le service de voyage est causé par des pannes en cascade. Cet article ne se concentre pas sur les pannes en cascade. Si vous êtes intéressé, vous pouvez vous référer à la façon de gérer les pannes en cascade des microservices.

Examiner le rapport racine de panne où le nœud de panne est siège-service

Conclusion de la cause première du défaut :

Pour la sous-requête 10.244.1.254:50332->10.244.5.79:15679 indicateur rtt, il y a un délai d'environ 200 ms.

Raisonnement et vérification des défauts

Depuis que Kindling-OriginX a identifié qu'il y a un problème avec le réseau où le service de siège appelle le service de configuration, il n'a pas besoin de présenter complètement toutes les données du graphe de flamme de DeepFlow à l'utilisateur. Il lui suffit de se connecter à DeepFlow et. demandez uniquement au service de siège d'appeler la configuration. Les données liées à l'appel de service réseau sont suffisantes.

En utilisant le service de siège de DeepFlow pour appeler les données du service de configuration, il a été automatiquement analysé que le réseau de conteneurs du pod client avait un retard de 201 ms.

Kindling-OriginX simulera l'expérience d'analyse d'experts et corrélera davantage les indicateurs de retransmission de DeepFlow et les indicateurs RTT pour déterminer les causes du retard dans l'appel du service de configuration du service de siège.

Kindling-OriginX intégrera également les indicateurs d'utilisation du processeur et de bande passante du nœud pour éliminer les facteurs d'interférence.

Kindling-OriginX complète l'intégralité du raisonnement des erreurs dans un rapport d'une page, et chaque source de données est digne de confiance et vérifiable.

Résumé

Kindling-OriginX et DeepFlow utilisent tous deux la technologie eBPF et s'efforcent de fournir des solutions flexibles et efficaces aux utilisateurs ayant des besoins différents dans différents scénarios. Nous sommes également impatients de voir l'émergence d'un plus grand nombre de produits nationaux dotés de capacités complémentaires à l'avenir.

DeepFlow peut fournir des données de base très complètes sur le réseau full-link, rendant les applications cloud natives profondément observables, et est très utile pour résoudre les problèmes de réseau.

Kindling-OriginX utilise eBPF pour collecter les indicateurs de dépannage North Star, les algorithmes d'IA et l'expérience d'experts afin de créer un moteur de raisonnement des pannes afin de fournir aux utilisateurs des rapports explicables sur les causes profondes.

—— Fin ——

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!