Partage d'expérience de traçage distribué PHP

Dans cet article, nous partageons principalement avec vous quelques expériences de traçage distribué PHP, en espérant aider tout le monde.

Depuis la mise en œuvre des microservices, nous avons rencontré de nombreux problèmes. Le plus gros problème est de savoir comment résoudre les problèmes. Les interfaces orientées services reposent généralement sur plusieurs services. La lenteur des interfaces dépendantes affectera directement la qualité de service des interfaces.

La lenteur causée par ce type de dépendance est très courante en ligne, mais il n'est pas facile de dépanner. La raison en est qu'un grand nombre de développeurs de journaux suivent en ligne via les journaux, ce qui n'est pas très intuitif. développeurs. Et certains développeurs d’entreprises ne peuvent pas voir l’état d’exécution spécifique en ligne. D'une manière générale, ces petites erreurs de probabilité en ligne représentent des dangers cachés dans le système. Lorsque le trafic augmente, ces dangers cachés s'amplifient, voire conduisent directement à des erreurs en ligne à grande échelle. Afin d'éviter des choses similaires, nous devons faire beaucoup de choses. des choses. Le plus intuitif est d’utiliser des systèmes de traçage distribués pour l’analyse statistique.

Nous voyons souvent de grands noms parler de la manière d'optimiser les performances en ligne et de la manière d'améliorer les performances. En fait, il existe un lien important qu'ils n'ont pas mentionné. Ils sont Comment trouver des défauts à faible probabilité ? Les systèmes de suivi distribués sont très courants dans les grandes sociétés Internet, mais les petites et moyennes entreprises n'ont pas la force technique nécessaire pour mettre en œuvre ce système. De notre point de vue, même si le trafic est très faible, le système reste très important pour l'entreprise et nous devons le renforcer. Ce n'est qu'en étant capables de trouver les problèmes que nous pourrons les résoudre. mis en œuvre.

La mise en œuvre spécifique du système de suivi distribué est techniquement difficile. Elle nécessite la capture des performances, l'écriture de journaux, la collecte et le tri des journaux, la transmission des journaux, le stockage des journaux et l'indexation. , l'analyse du journal en temps réel et l'affichage final de la fusion nécessitent que le système soit capable de faire face à l'impact des grands systèmes de trafic. Par exemple, si chaque interface génère 1 000 journaux pour chaque requête, alors le serveur QPS 2000 générera 2 millions de journaux. Si une requête repose sur 5 interfaces, elle générera 10 millions de journaux par seconde. Lorsque l'activité en ligne est plus complexe et que le trafic est plus important. plus le temps est long, cette valeur augmentera.

Les grandes sociétés Internet disposent de nombreux systèmes de suivi distribués, qui peuvent supporter des milliards de trafic, mais pour les petites entreprises, cette architecture est très lourde, et de nombreux liens tels que les dépendances Messagerie distribuée système, stockage distribué, informatique distribuée, ceux-ci utiliseront à eux seuls au moins 6 serveurs ou plus, ce qui n'est pas rentable pour les petites entreprises ordinaires.

Cette fois, nous avons deux types de suivi distribué open source. L'un est une version autonome pour les petites et moyennes entreprises Internet. Elle peut prendre en charge PV. Système commercial 2000w (tel que système de paiement). Il existe également un système de suivi distribué qui prend en charge des milliards de PV distribués. Actuellement, la version autonome de Fiery vient d'être ouverte (https://github.com/weiboad/fiery). Cette version est conçue pour être utilisée par les petites et moyennes entreprises. L'ensemble du projet est un package Jar qui peut le faire. Être utilisé immédiatement. Tant qu'il existe un runtime Java8, il peut être utilisé directement, bien sûr, le système doit simplement effectuer un travail d'enfouissement. La version distribuée C++ repose sur de nombreux éléments et nécessite certaines capacités pour le personnel d'exploitation et de maintenance. La version autonome sera publiée ultérieurement en fonction de la situation. Ces systèmes de trading de base, qui sont entièrement open source et contiennent des données sensibles, sont également entièrement disponibles.

Actuellement, il existe plusieurs méthodes de suivi distribué sur le marché, dont certaines sont utilisées en interne par l'entreprise, et d'autres sont gratuites à petite échelle et payantes à grande échelle. services. Le traçage distribué commun enregistre les performances de chaque bloc grâce à des méthodes statistiques. Les méthodes que nous proposons actuellement ne sont pas exactement les mêmes que celles du marché. Nous avons apporté de nombreuses simplifications grâce à des expérimentations continues, en ne conservant que les fonctions que nous pensons vraiment pratiques. Nous avons conçu le système de surveillance distribuée des systèmes clés. Tels que le système de paiement et le système de transaction.

Nous enregistrons la situation spécifique, la valeur de retour, les performances spécifiques et d'autres informations de chaque demande grâce à l'analyse des tableaux, nous pouvons découvrir rapidement les performances des interfaces dépendantes en ligne (tiers). partie ou les statistiques de performances des interfaces qui ne sont pas intégrées) et des interfaces intégrées sont également analysées de manière indépendante pour les classements de performances. En visualisant le tableau d'analyse, nous pouvons rapidement trouver l'interface la plus lente pour demander la lecture et analyser les raisons de la lenteur des performances en ligne. Grâce à la pratique, nous avons constaté que dans de nombreux cas, la lenteur des ressources de données sur lesquelles PHP s'appuie entraîne de mauvaises performances de l'interface PHP. L’accent est donc mis sur la dépendance aux ressources. Les utilisateurs peuvent ajouter d'autres informations en fonction de leurs propres besoins, ce qui peut réduire un grand nombre de journaux inutiles et les rendre plus économes.

Ce Fiery open source comprend principalement trois parties : une bibliothèque de points intrusifs PHP, un module push rationalisé de surveillance des journaux et un serveur. Ces trois-là réalisent un suivi distribué pour un site Web avec une PV inférieure à 2000w.

La bibliothèque de points enterrés générera un Traceid (UUID) à l'entrée. Ce Traceid masque l'adresse IP du serveur d'entrée et l'heure de la demande. Tous les journaux suivants seront marqués avec cet UUID. Après la collecte des journaux, tous les journaux pertinents seront stockés selon cet UUID. La bibliothèque de points enterrés sera chargée de recevoir le Traceid envoyé par d'autres requêtes et d'envoyer et de maintenir le RPCID pendant l'exécution. Le RPCID est un compteur hiérarchique grâce auquel nous pouvons directement restaurer l'ordre et la hiérarchie de la relation appelante et l'afficher au développeur. . De plus, si une exception se produit pendant le fonctionnement de PHP, elle sera capturée et enregistrée par la bibliothèque de points enterrés pour que le serveur puisse effectuer des statistiques de déduplication. Enfin, ces journaux seront enregistrés sur le disque local du serveur. Pour certaines raisons, lorsque plusieurs processus PHP écrivent un fichier en même temps, l'ordre peut occasionnellement se produire. Nous enregistrons désormais les journaux en fonction de l'ID du processus plus le. nom du projet comme nom de fichier.

Nous avons implémenté une version simple de capture et de transmission des journaux Fiery afin de simplifier le travail du personnel d'exploitation et de maintenance. Il existe en effet de nombreuses sources ouvertes qui fournissent des fonctions similaires. Cependant, il doit s'appuyer sur d'autres environnements, ce qui impose une certaine charge en termes d'exploitation et de maintenance. Nous disposons également d'un service expérimental de capture et de transmission des journaux PHP, mais il s'agit toujours d'une fonction expérimentale. Il est prévu que les utilisateurs puissent participer au débogage et à l'amélioration.

Nous avons effectué beaucoup de travail côté serveur de Fiery et avons intégré Lucene et Rocksdb pour indexer et stocker les demandes respectivement. Nous avons également effectué des travaux sur les statistiques de mémoire.À l'heure actuelle, nos dimensions statistiques sont fixes.Nous ne comptons que les réponses des interfaces locales, des interfaces dépendantes, de Mysql et de Curl.Nous fournissons également des statistiques de lecture des relations d'appel et de déduplication des alertes du journal des erreurs. Grâce à ces fonctions, les défauts de performances et les anomalies du système aux points clés de la ligne peuvent être rapidement découverts. Actuellement, il ne s'agit que d'une version autonome, et je peux l'étendre davantage vers un mode distribué plus simple si nécessaire à l'avenir.

Les services ci-dessus ne sont pas uniquement destinés aux services en ligne. Nous les avons également utilisés en interne pour effectuer de nombreuses tentatives intéressantes, telles que l'accès à un environnement de test d'assurance qualité et les tests une fois terminés. Le Traceid généré par l'interface défectueuse est envoyé directement au développement. Le développement peut utiliser le Traceid pour connaître tous les processus d'appel, les paramètres, les conditions de retour et les performances de cette requête, qui peuvent également être visualisés pour une analyse facile. être effectué pour les tests unitaires avant de passer en ligne. Il y a quelque temps, lorsque j'ai posté sur Weibo pour promouvoir Fiery, quelqu'un a mentionné qu'il pourrait être utilisé comme pot de miel pour visualiser le processus de piratage et des détails spécifiques. Les fonctions de suivi doivent encore être explorées et améliorées par tous. Ce système est conçu pour combler les lacunes de l'écosystème PHP.

Recommandations associées :

Comment implémenter Session avec Redis dans la distribution PHP

Problèmes liés à la distribution PHP et au traitement des données à grande échelle

Partage de mémoire interne distribué PHP (Memcache)

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!