Résumé : En tant qu'excellent logiciel de base de données distribuée open source, TiDB a reçu de plus en plus d'attention et d'applications de la part des utilisateurs. Cependant, dans le processus d'assurance de l'exploitation et de la maintenance, il est également confronté à des îlots d'exploitation et de maintenance, à des difficultés de délimitation et de positionnement, et à des difficultés de délimitation et de positionnement. Cet article résume les meilleures pratiques permettant aux utilisateurs de TiDB de créer une observabilité complète basée sur DeepFlow, notamment comment utiliser la technologie d'observabilité hautes performances et sans intrusion de DeepFlow pour éliminer les angles morts du suivi des liens complets sur du côté TiDB et comment utiliser la technologie d'observabilité haute performance et sans intrusion de DeepFlow pour éliminer les angles morts du côté TiDB .Il
01 : Enjeux d’exploitation et de maintenance des bases de données distribuées
Dans l'exploitation et la maintenance quotidiennes, les administrateurs de bases de données distribuées sont généralement confrontés à trois défis :
- Performances en temps réel des données d'observation : étant donné que la méthode d'instrumentation traditionnelle entraînera des pertes de performances évidentes, le DBA n'activera la capacité de traçage distribué intégrée de TiDB qu'après qu'une exception métier se soit produite. La gestion des erreurs ne peut être effectuée que par une récurrence post-analyse et répétée. , et positionnement passif.
- exhaustivité des données d'observation : l'exploitation et la maintenance traditionnelles des bases de données reposent principalement sur les propres données de la base de données, manquant de données en temps réel provenant des applications clientes, des ressources système, de la lecture et de l'écriture des fichiers de la base de données, des performances du réseau du serveur et d'autres dimensions, et l'environnement environnant est dans un angle mort diagnostique.
- Continuité de l'observation et du diagnostic : les outils de surveillance traditionnels ont des données séparées les unes des autres. Le diagnostic des défauts doit souvent être transféré entre différentes équipes d'exploitation et de maintenance. Le processus d'analyse nécessite souvent de basculer entre plusieurs outils de surveillance. La continuité du diagnostic est souvent interrompue.
Les problèmes ci-dessus ont conduit à une déconnexion entre l'exploitation et la maintenance de la base de données et les autres opérations et maintenance, formant un îlot d'exploitation et de maintenance. Les risques opérationnels de l'entreprise sont difficiles à détecter, les pannes sont difficiles à délimiter, les cycles de récupération sont longs, la communication et la collaboration sont nombreuses. , et les conflits d’exploitation et de maintenance sont nombreux.
DeepFlow fournit à TiDB des capacités d'observation complètes, à liaison complète et prêtes pour la production grâce à plusieurs fonctionnalités de base telles que l'absence d'intrusion, la collecte de données d'observation hautes performances, l'accès ouvert aux données d'observation et l'analyse unifiée de corrélation des données d'observation, aidant ainsi DBA à construire des -surveillance des liens, délimitation rapide des défauts, analyse des causes profondes et autres capacités pour améliorer efficacement l'efficacité de l'exploitation et de la maintenance des bases de données distribuées et résoudre les problèmes d'exploitation et de maintenance mentionnés ci-dessus.
02 : Solution de déploiement d’observabilité TiDB
Dans le plan de pratique d'observabilité TiDB, nous déployons automatiquement l'agent DeepFlow dans le nœud du cluster d'entreprise et le cluster de bases de données distribuées TiDB pour collecter et collecter des données d'observation multidimensionnelles ; les données d'observation structurées sont transmises via le réseau et traitées uniformément (étiquetage unifié des données) ; , données associées unifiées et données d'analyse unifiées) sont stockées de manière centralisée sur le serveur DeepFlow ; grâce à une conception fonctionnelle qui suit de près le scénario d'exploitation et de maintenance, ces données fournissent des capacités d'observation et d'analyse complètes flexibles et multidimensionnelles, de la macro à la micro. .
DeepFlow Agent collecte et collecte de riches données d'observation, notamment :
- Données zéro intrusion eBPF : suivi de la chaîne d'appels, indicateurs de performances SQL, journaux d'appels SQL, indicateurs de performances réseau, journaux de flux réseau, événements de lecture et d'écriture de fichiers, performances CPU et autres données d'observation
- Données d'instrumentation OpenTelemetry : données de suivi de la chaîne d'appels au sein de chaque composant de TiDB
- Données Prometheus Exporter : indicateurs système K8s, indicateurs de performance TiDB
03 : Suivi de la chaîne d'appels
Dans la pratique de l'observation complète de TiDB par DeepFlow, nous avons obtenu des capacités de suivi de la chaîne d'appels à lien complet, y compris les applications frontales, les réseaux intermédiaires, TiDB-Proxy et TiDB via la technologie eBPF. Par rapport à la technologie APM traditionnelle, la chaîne d'appels. implémenté par DeepFlow Tracking présente les fonctionnalités avantageuses suivantes :
- Aucun angle mort : élimine les angles morts de suivi dans TiDB, le middleware de passerelle et les réseaux intermédiaires ;
- Hautes performances : le suivi hautes performances et sans intrusion obtenu grâce à la technologie eBPF renforce les capacités de suivi et d'observation sans échantillonnage prêtes pour la production pour TiDB ;
- Rechargement à chaud : grâce à la fonction d'échange à chaud de code de la technologie eBPF, les capacités de suivi en ligne sont disponibles à tout moment dans les applications et les clusters TiDB . Même les petites instabilités de performances peuvent être observées en permanence à un niveau précis pour découvrir et éliminer rapidement les risques du système.
- Pile inter-technologique : grâce à la capacité de suivi de la pile complète, un suivi unifié et une collaboration unifiée de plusieurs piles technologiques d'exploitation et de maintenance telles que DBA, le développement de bases de données, l'exploitation et la maintenance du système, ainsi que l'exploitation et la maintenance des applications sont réalisés pour déterminer rapidement les limites des pannes et améliorer l’efficacité de la collaboration technique.
1) Suivi de la chaîne d'appels sans angles morts
Nous pouvons répondre à cette question à l'aide d'un simple diagramme schématique : pourquoi, par rapport aux solutions d'instrumentation traditionnelles, la collecte sans intrusion DeepFlow eBPF permet-elle réellement de suivre la chaîne d'appels sans angles morts ?
Instrumentation d'application
La technologie APM traditionnelle suit la chaîne d'appels d'application via l'instrumentation du code d'application. La portée d'observation est limitée à la portée de l'application qui peut être instrumentée. La capacité de suivi forme un angle mort d'observation du côté de TiDB. impossible de déterminer rapidement si TiDB est à l'origine du problème.
Instrumentation applicative + instrumentation TiDB
Afin d'étendre la capacité de suivi de la chaîne d'appels de l'application à TiDB, nous avons soumis un PR à la communauté TiDB pour la réparation du code et implémenté la capacité de suivi du côté de TiDB. Cependant, nous avons découvert plus tard qu'il y avait encore trois problèmes avec l'instrumentation dans TiDB :
- Le réseau dans l'environnement d'exploitation TiDB se trouve dans un angle mort de suivi et l'impact du réseau sur les performances SQL ne peut pas être diagnostiqué ;
- TiDB-Proxy devant TiDB est dans un angle mort de suivi et ne peut pas diagnostiquer l'impact de TiDB-Proxy sur les performances SQL ;
- Les performances de réponse après l'instrumentation TiDB ont chuté de manière significative (voir ci-dessous pour les données spécifiques) et elles ne peuvent pas être utilisées en continu dans un système de production.
Collecte zéro intrusion DeepFlow eBPF
La capacité de suivi de la chaîne d'appels sans intrusion construite grâce à la technologie eBPF de DeepFlow élimine les angles morts de suivi de TiDB et dispose de capacités de suivi complètes pour les emplacements suivants dans tout processus d'appel d'application : 1) application frontale 2) TiDB-Proxy ; 4) Réseau K8.
À ce stade, nous pouvons suivre une certaine réponse lente dans le graphique de flamme de traçage de chaîne d'appels DeepFlow, observer intuitivement la proportion de contribution de chaque position au délai de réponse, et ainsi déterminer rapidement l'emplacement source d'une certaine réponse lente :
Par exemple, dans la figure suivante, nous pouvons clairement déterminer dans une partie d'un graphe de flamme de traçage de chaîne d'appels DeepFlow que l' COM_QUERY COMMITappel MySQL dans un certain processus métier introduit un délai de 480 ms dans le traitement du processus tidb-proxy :
2) Suivi performant de la chaîne d’appels
Le problème le plus critique qui entrave la mise en œuvre de l’observabilité TiDB dans les systèmes de production réels est la performance de la collecte des données d’observation.
Nous avons constaté que lorsque des technologies telles que l'instrumentation intégrée à l'application et l'amélioration du bytecode de l'agent Java sont utilisées pour implémenter la collecte de chaînes d'appels, elles peuvent entraîner une consommation de ressources supplémentaire importante et difficile à définir, et peuvent introduire d'importantes pertes de performances commerciales, conduisant à ce type de les solutions techniques ne peuvent pas être mises en œuvre dans des systèmes ayant des exigences élevées de concurrence, de performances et de fiabilité élevées. De nombreuses entreprises ne peuvent activer de telles capacités de suivi que dans les systèmes de test ou les systèmes de production non importants, tandis que les systèmes de production plus importants ne peuvent utiliser qu'un échantillonnage et un suivi à forte proportion pour réduire l'impact négatif sur les activités, en particulier sur les systèmes de production de base du secteur financier. l'industrie abandonnera complètement les capacités de suivi pour garantir que les performances de l'entreprise ne sont pas affectées, mais cela entraînera de faibles capacités de support opérationnel et des risques d'exploitation et de maintenance incontrôlables.
DeepFlow utilise la technologie eBPF pour obtenir une observabilité sans intrusion (Zero Code) qui résout très bien ces problèmes. Le retard commercial (temps de réponse) n'a généralement qu'un impact inférieur à la milliseconde, et la consommation des ressources de l'agent est prévisible et configurable. Grâce à la technologie Just-in-Time (JIT), l'efficacité d'exécution du code eBPF de DeepFlow Agent peut être comparable aux performances du code natif du noyau et n'affectera pas le processus de traitement de l'application pendant le processus de collecte, de sorte que l'application puisse appelons le processus de traitement de zéro intrusion.
Dans la pratique d'observation full-stack de DeepFlow de TiDB, nous avons testé et vérifié les différentes performances commerciales du cluster TiDB lors de l'utilisation de l'instrumentation Jaeger et de l'utilisation de la technologie zéro intrusion eBPF de DeepFlow pour la pratique d'observabilité.
Délai de réponse SQL de TiDB lors de la collecte de l'instrumentation Jaeger : Nous avons activé la fonction OpenTracing de TiDB et observé les performances de réponse de l'emplacement de l'instance d'application (ordre svc) accédant à tiproxy. Nous pouvons voir que le délai de réponse SQL moyen est stable à 300 ~ 400 ms. dans certains cas, le délai maximum moyen dépasse 1,5 s .
Délai de réponse SQL TiDB lors de la collecte DeepFlow eBPF : nous utilisons DeepFlow Agent pour collecter des données d'observation non échantillonnées sur le cluster distribué TiDB et observer les performances de réponse de l'emplacement de l'instance d'application (ordre svc) lors de l'accès à tiproxy. Vous pouvez voir la réponse SQL. le délai moyen est réduit à 3 ~ 5 ms et le délai maximum ne dépasse pas 38 ms .
À partir des données de comparaison des performances ci-dessus, nous avons constaté que l'observabilité sans intrusion obtenue par DeepFlow grâce à la technologie eBPF résout les problèmes de performances commerciales causés par la solution d'instrumentation, afin qu'elle puisse créer une solution simple et prête pour la production pour le système distribué TiDB. base de données du système de production informatique de base. Capacités d’échantillonnage et de suivi.
3) Suivi de la chaîne d'appels avec chargement à chaud à tout moment
En raison des pertes de performances commerciales causées par des moyens techniques tels que l'instrumentation intégrée à l'application et l'amélioration du bytecode de l'agent Java, d'importants systèmes de production de base désactivent les capacités de traçage dans les opérations quotidiennes. Cependant, en cas de pannes ou d'exceptions, un traçage plus fin est requis. , mais a constaté que le processus de démarrage de l'instrumentation et de l'agent Java nécessite le redémarrage des instances d'application et des instances de composants TiDB du système de production principal. À ce stade, il devient une décision difficile et douloureuse d'activer ou non la fonction de suivi, ce qui conduit finalement à cela. statu quo d’exploitation et d’entretien :
- Les défauts mineurs passent inaperçus , laissant le système fonctionner avec des dangers cachés.
- Un investissement important est réalisé pour les défauts intermédiaires , l'environnement de test est testé à plusieurs reprises et la cause profonde est déterminée par la chance.
- Tous les efforts ont été déployés pour éliminer les défauts majeurs et toute l'équipe a travaillé 24 heures sur 24, 7 jours sur 7, quel qu'en soit le coût, jusqu'à la reprise de l'activité.
La loi de Hayne nous dit que derrière tout accident grave, il existe 29 accidents mineurs et 300 dangers potentiels cachés. Le même schéma existe dans l'exploitation et la maintenance des systèmes informatiques. C'est précisément en raison des actions de redémarrage nécessaires au démarrage de l'instrumentation et de l'agent Java qu'un grand nombre de dangers cachés potentiels et de défauts mineurs dans l'environnement de production sont difficiles à diagnostiquer et à localiser. La relocalisation des défauts intermédiaires consomme beaucoup de main-d'œuvre. des défauts majeurs continuent à apparaître.
L'observabilité sans intrusion de DeepFlow résout parfaitement ce problème. Lorsque vous devez activer la fonctionnalité de suivi de la chaîne d'appels pour un système d'application ou TiDB, vous pouvez déployer l'agent DeepFlow à tout moment en un seul clic pour démarrer la collecte de données de suivi. Lors du déploiement de l'agent, vous n'avez pas besoin d'envahir le POD et la TiDB de l'application. composant POD, et vous n'avez pas non plus besoin de redémarrer l'application, TiDB ou le système d'exploitation, l'agent peut instantanément charger à chaud dans le noyau du système d'exploitation et commencer à suivre la collecte de données à chaque emplacement uniquement via la technologie eBPF du. Système d'exploitation Linux. Même pour les systèmes d'entreprise avec une charge très élevée, lorsque vous souhaitez désinstaller la fonctionnalité de suivi, vous pouvez désactiver le commutateur de collecte eBPF de l'agent en ligne ou désinstaller l'agent, et le code de collecte de données de suivi peut être instantanément désinstallé du noyau du système d'exploitation . Pendant tout ce processus, l'application de couche supérieure et le programme de composants TiDB n'en ont aucune conscience.
La capacité de suivi de la chaîne d'appels de DeepFlow Agent peut être chargée à chaud à tout moment dans le noyau du système d'exploitation, ce qui nous permet de suivre et d'observer les fonctionnalités en ligne et hors ligne à tout moment dans le système d'application et le cluster TiDB, sans nous soucier des perturbations de l'application, et pour détecter les défauts mineurs et les défauts intermédiaires à tout moment. Effectuez des observations précises pour découvrir et éliminer rapidement les dangers du système afin d'éviter les pannes majeures.
4) Suivi de la chaîne d'appels pour une collaboration unifiée entre les piles technologiques
Le suivi APM de la technologie d'instrumentation traditionnelle convient aux développeurs d'applications et aux développeurs TiDB. La chaîne d'appel reflète davantage la relation d'appel de fonction au sein du processus, ce qui est difficile à comprendre sans une expérience de développement. Par conséquent, pendant le processus de délimitation des erreurs, DBA et autres. Les opérations doivent Les rôles dimensionnels sont de peu d’aide pratique. La plate-forme d'observabilité DeepFlow réalise la capacité de traçage complète de tout appel d'application depuis l'application vers le système d'exploitation et le réseau sous-jacent, afin de pouvoir créer l'exploitation et la maintenance de TiDB, le développement de TiDB, le développement d'applications, l'exploitation et la maintenance de K8 et l'exploitation de middleware. et la maintenance. Grâce aux capacités de collaboration complètes en matière d'exploitation et de maintenance de chaque pile technologique, nous pouvons obtenir des informations claires sur les performances de chaque lien de traitement dans l'ensemble du processus de tout appel d'application et déterminer rapidement la limite des pannes.
Prenons l'exemple de la figure ci-dessus, dans la plateforme observable DeepFlow :
- Développement, exploitation et maintenance d'applications métier : Diagnostiquer et découvrir rapidement les dangers ou défauts cachés dans les applications métier grâce au délai d'appel des microservices des applications métier ;
- Fonctionnement et maintenance du K8s : grâce au délai d'appel de la carte réseau entre chaque instance de microservice ; diagnostic rapide pour découvrir les dangers ou défauts cachés dans la plateforme K8s ;
- Exploitation et maintenance du middleware : diagnostiquez et découvrez rapidement les dangers ou les défauts cachés dans le middleware grâce au délai d'appel de l'emplacement TiDB-Proxy ;
- DBA : Utilisez le délai d'appel TiDB collecté par eBPF pour diagnostiquer rapidement les dangers ou défauts cachés côté TiDB ;
- Développement de bases de données : après avoir activé à la demande les données d'instrumentation OpenTelemetry de TiDB, les développeurs de bases de données peuvent rapidement diagnostiquer les dangers cachés ou les pannes dans les fonctions internes clés de TiDB.
04 : Observation globale
En plus du suivi de la chaîne d'appels, lors de l'exploitation et de la maintenance quotidiennes de TiDB, le panorama commercial, les performances du réseau, les performances des ressources système, les performances de lecture et d'écriture des fichiers du système d'exploitation et les performances des fonctions d'application sont autant de dimensions qui doivent être observées et analysées de manière exhaustive pour trouver rapidement le problème.La cause fondamentale est que la pratique de l'observabilité doit ouvrir les silos de plusieurs types de données d'observation, établir des connexions entre les données d'observation et concevoir un flux d'opérations d'observation fluide, afin que le personnel d'exploitation et de maintenance complet puisse efficacement et Effectuez en douceur le processus d'opération et de maintenance d'observation. Observez les données complètes et trouvez des conclusions dans les données plus rapidement et plus facilement.
Dans la pratique d'observabilité de TiDB, nous avons mis en œuvre une collecte et une analyse unifiées de plusieurs types de données dans la plate-forme DeepFlow, et grâce à des flux de fonctionnement fluides, nous pouvons accéder efficacement à divers types de données et obtenir une gamme complète de capacités d'observation, notamment :
- Observation panoramique d'affaires
- Observation des performances du réseau
- traçabilité des instructions SQL
- Observation des performances des ressources système
- Observation des performances de lecture et d'écriture de fichiers
- Observation des performances des fonctions (profilage du CPU)
1) Observation panoramique d'entreprise
DeepFlow obtient dynamiquement des balises de ressources et des balises commerciales via un ancrage en temps réel avec des interfaces API cloud natives, et appelle des balises de balises de données pour les applications collectées en temps réel, réalisant ainsi la possibilité de créer un panorama commercial automatisé et mis à jour dynamiquement avec l'entreprise. .
Dans la pratique d'observabilité TiDB basée sur DeepFlow, nous avons construit un panorama commercial de bout en bout, depuis les clusters d'applications cloud natives jusqu'aux clusters de bases de données distribuées TiDB (comme indiqué ci-dessous) :
En créant une topologie panoramique d'entreprise de clusters d'applications cloud natives et de clusters de bases de données TiDB, nous pouvons observer l'image globale du système informatique d'entreprise d'un point de vue macro. Lorsque des anomalies de performances commerciales locales sont détectées dans le panorama commercial, nous pouvons progressivement explorer de manière microscopique et. trouver rapidement des inconnues inconnues.
2) Observation des performances du réseau
La perte de paquets réseau et le retard du réseau sont souvent des problèmes suspectés dans le processus de diagnostic des pannes du cluster de bases de données TiDB. DeepFlow peut déterminer rapidement si une certaine défaillance commerciale d'une base de données distribuée est causée par une défaillance du réseau grâce à l'observation des performances du réseau.
Dans l'observation des performances du réseau, nous pouvons observer les performances d'interaction réseau de l'accès externe au cluster TiDB et de l'accès mutuel des composants internes du cluster TiDB à travers les six indicateurs suivants, et diagnostiquer et déterminer différents types de problèmes de transmission réseau :
- Octets (taux de débit) - observez la pression du débit du réseau
- Taux de retransmission TCP - observez la perte de paquets réseau
- Rapport de fenêtre TCP zéro - observation de la congestion TCP
- Taux d'établissement de connexion-échec : observez les anomalies d'établissement de connexion TCP
- Délai moyen d'établissement de la connexion TCP - RTT réseau observé
- Latence moyenne du système TCP/ICMP - observez la vitesse de réponse du système d'exploitation
Exemple 1 : Observez rapidement les performances d'interaction réseau du client accédant au portail TiDB
Exemple 2 : Observez rapidement les performances d'interaction réseau entre les composants internes de TiDB
3) Traceback des instructions SQL
Les instructions SQL déraisonnables occuperont une grande quantité de ressources CPU et mémoire, augmenteront le délai de réponse de TiDB et réduiront les performances globales de TiDB. Par conséquent, le retour en arrière rapide des instructions SQL inefficaces est une partie importante du fonctionnement et de la maintenance de la base de données. Les requêtes qui n'utilisent pas d'index, les analyses de tables complètes, les requêtes trop complexes et l'utilisation de fonctions ou de types de données inappropriés sont tous des types de « mauvais SQL » qui nécessitent un retour en arrière et une concentration sur les instructions SQL.
Dans la pratique d'observabilité de TiDB, DeepFlow utilise des capacités de collecte de contournement sans intrusion pour enregistrer complètement les détails de chaque instruction SQL, y compris les instructions SQL, les délais de réponse, les temps d'occurrence, les nœuds sources, etc., qui peuvent être récupérés lors de la recherche et de la récupération du journal des appels. suivez la fréquence d'apparition des mauvais SQL en temps réel et déterminez la source du SQL.
4) Observation des performances des ressources système
Une utilisation excessive du processeur et de la mémoire du système d'exploitation, ou une congestion du débit de l'interface réseau au cours de la même période, peut entraîner l'apparition d'un SQL lent. Par conséquent, afin de trouver plus rapidement et avec plus de précision la cause première des problèmes de SQL lent, analysez rapidement la TiDB. composants pendant le processus de diagnostic des pannes. Les indicateurs de processeur, de mémoire et d'interface réseau d'une instance sont un élément clé de l'amélioration des capacités d'observation, des capacités d'exploitation et de maintenance, ainsi que de l'efficacité du dépannage des bases de données distribuées.
Dans la pratique de l'observabilité TiDB, nous collectons les indicateurs système via Grafana Agent et importons uniformément les données dans la plate-forme d'observabilité DeepFlow. Les données sont uniformément marquées, corrélées et présentées pour pouvoir observer les données des indicateurs POD des composants TiDB. en découvrant le POD source du SQL lent dans le suivi de la chaîne d'appels, vous pouvez afficher la courbe de changement d'utilisation du processeur, la courbe de changement d'utilisation de la mémoire et la courbe de changement de débit réseau du POD en un seul clic, et déterminer facilement l'événement SQL lent grâce aux valeurs de l'indicateur pendant la période problématique. Corrélation avec les performances du processeur système, de la mémoire et des ressources de l'interface réseau.
5) Observation des performances de lecture et d'écriture de fichiers
Les performances de lecture et d'écriture des fichiers auront un impact significatif sur les performances de réponse SQL de TiDB. Bien que l'utilisation de ressources de stockage hautes performances puisse éviter autant que possible la possibilité d'une lecture et d'une écriture lentes des fichiers, deux questions doivent encore être fréquemment répondues. Exploitation et maintenance de TiDB :
- En cas de lenteur sporadique de SQL, comment déterminer si une lecture et une écriture lentes sporadiques de fichiers sont à l'origine du problème ?
- Lorsqu'une lecture ou une écriture de fichiers volumineux inconnue ou une lecture et une écriture de fichiers fréquentes se produisent dans le système, comment découvrir le processus source de lecture et d'écriture de fichiers ?
DeepFlow réalise une collecte et une observation complètes des événements de lecture et d'écriture des fichiers du système d'exploitation grâce à la fonctionnalité eBPF du noyau Linux et prend en charge plusieurs modes de collecte tels que la collecte complète et la collecte partielle.
Lorsqu'une application rencontre une réponse lente, DeepFlow peut récupérer en un seul clic tous les événements de lecture et d'écriture de fichiers sur le client et le serveur pendant la période problématique, et verrouiller rapidement les événements d'opération de fichiers et les processus sources dans la liste. Lorsqu'une réponse SQL lente se produit, l'administrateur de base de données peut déterminer en quelques secondes s'il existe un événement d'E/S lent associé ; lorsqu'un comportement de lecture et d'écriture de fichier est inconnu, le fonctionnement et la maintenance du système peuvent verrouiller la source d'E/S du fichier en quelques secondes :
6) Observation des performances des fonctions (profilage du CPU)
Pendant le processus de dépannage de SQL lent, lorsqu'il s'avère que le processeur est devenu le goulot d'étranglement des performances de l'entreprise, la prochaine chose à faire est d'analyser la situation de planification du processeur du composant TiDB POD, de découvrir les fonctions chaudes du composant TiDB. programme, puis recherchez le programme Le point d'entrée pour l'optimisation. DeepFlow implémente les capacités de collecte de données CPU Perf et d'observation du processus d'application via la technologie eBPF du noyau Linux. En analysant les performances du processeur du processus d'application du composant TiDB, les développeurs peuvent facilement verrouiller les fonctions du noyau, les fonctions de bibliothèque et les fonctions d'application. chaque programme de composant TiDB.
Dans la pratique de l'observabilité TiDB, nous avons utilisé DeepFlow pour analyser les performances du processeur des composants TiDB, PD et TiKV. Parmi eux, dans le graphique de flamme d'analyse des performances du processeur du processus TiDB suivant, nous pouvons clairement observer que l'instrumentation Jaeger apporte une surcharge importante en ressources CPU au processus TiDB :
05 : Récapitulatif des valeurs
De bonnes capacités de prise en charge de l'exploitation et de la maintenance sont une condition préalable au fonctionnement stable de la base de données distribuée TiDB. Dans cette pratique d'observabilité, DeepFlow utilise la technologie de collecte de données sans intrusion eBPF de pointe, la technologie de suivi de la chaîne d'appels sans instrumentation et le multi-source. la technologie d'observation unifiée des données crée une solution d'observabilité pour la pile complète, la liaison complète, le chargement à chaud à tout moment et la mise en œuvre de la production de TiDB, ce qui améliore considérablement les capacités globales d'exploitation et de maintenance de TiDB, contribue efficacement au fonctionnement stable de la base de données TiDB et aide les utilisateurs à créer un service de base de données plus fiable et plus stable.
06 : Qu'est-ce que DeepFlow
DeepFlow est un produit d'observabilité développé par Yunshan Network, visant à fournir une observabilité approfondie des infrastructures cloud complexes et des applications cloud natives. Basé sur eBPF, DeepFlow réalise la collecte sans intrusion (Zero Code) de signaux d'observation tels que les indicateurs de performances des applications, le traçage distribué et l'analyse continue des performances, et les combine avec la technologie d'étiquette intelligente (SmartEncoding) pour réaliser la corrélation Full Stack et intégration de tous les signaux d’observation. Grâce à DeepFlow, les applications cloud natives peuvent automatiquement bénéficier d'une observabilité approfondie, éliminant ainsi le lourd fardeau de l'instrumentation continue pour les développeurs et fournissant aux équipes DevOps/SRE des capacités de surveillance et de diagnostic, du code à l'infrastructure.
Adresse GitHub : https://github.com/deepflowio/deepflow
Visitez la démo DeepFlow pour découvrir une instrumentation nulle, une couverture complète et une observabilité pleinement pertinente.
J'ai décidé d'abandonner les logiciels industriels open source. OGG 1.0 est sorti, Huawei a contribué à tout le code source. Ubuntu 24.04 LTS a été officiellement publié. L'équipe de Google Python Foundation a été tuée par la "montagne de merde de code" . ". Fedora Linux 40 a été officiellement lancé. Une société de jeux bien connue a publié de nouvelles réglementations : les cadeaux de mariage des employés ne doivent pas dépasser 100 000 yuans. China Unicom lance la première version chinoise Llama3 8B au monde du modèle open source. Pinduoduo est condamné à compenser 5 millions de yuans pour concurrence déloyale Méthode de saisie dans le cloud domestique - seul Huawei n'a aucun problème de sécurité de téléchargement de données dans le cloud.