Les journaux sont une partie importante du système, vous permettant de comprendre que cela fonctionne (ou ne fonctionne pas) comme prévu. Dans les conditions de l'architecture des microservices, travailler avec les journaux devient une discipline distincte de l'Olympiade spéciale. Il y a beaucoup de problèmes à régler :
- comment écrire des journaux à partir de l'application ;
- où écrire les journaux ;
- comment livrer les journaux pour le stockage et le traitement ;
- comment traiter et stocker les journaux.
L'utilisation des technologies de conteneurisation actuellement populaires ajoute du sable au-dessus du râteau dans le domaine des options de résolution de problèmes.
À peu près ceci est la transcription du rapport de Yuri Bushmelev "Carte d'un râteau dans le domaine de la collecte et de la livraison de grumes"
Qui s'en soucie, s'il vous plaît sous le chat.
Je m'appelle Yuri Bushmelev. Je travaille pour Lazada. Aujourd'hui, je vais parler de la façon dont nous avons fabriqué nos journaux, comment nous les avons collectés et ce que nous y écrivons.
D'où est-ce que nous venons? Qui sommes nous? Lazada est le détaillant en ligne n°1 dans six pays d'Asie du Sud-Est. Tous ces pays sont répartis entre les centres de données. Il y a maintenant 4 centres de données au total, pourquoi est-ce important ? Parce que certaines décisions étaient dues au fait qu'il y a un lien très faible entre les centres. Nous avons une architecture de microservice. J'ai été surpris de constater que nous avons déjà 80 microservices. Lorsque j'ai commencé la tâche avec les journaux, il n'y en avait que 20. De plus, il y a un assez gros morceau d'héritage PHP, avec lequel je dois aussi vivre et supporter. Tout cela génère pour nous en ce moment plus de 6 millions de messages par minute pour l'ensemble du système. De plus, je montrerai comment nous essayons de vivre avec cela, et pourquoi il en est ainsi.
Vous devez vivre avec ces 6 millions de messages d'une manière ou d'une autre. Que devons-nous faire avec eux? 6 millions de messages nécessaires :
- envoyer depuis l'application
- accepter pour la livraison
- livrer pour analyse et stockage.
- analyser
- stocker en quelque sorte.
Quand il y avait trois millions de messages, j'avais à peu près le même look. Parce que nous avons commencé avec quelques sous. Il est clair que les journaux d'application y sont écrits. Par exemple, ne pouvait pas se connecter à la base de données, pouvait se connecter à la base de données, mais ne pouvait pas lire quelque chose. Mais en plus de cela, chacun de nos microservices écrit également un journal d'accès. Chaque demande qui arrive au microservice tombe dans le journal. Pourquoi fait-on ça? Les développeurs veulent pouvoir tracer. Chaque journal d'accès contient le champ traceid, selon lequel une interface spéciale déroule ensuite toute la chaîne et affiche magnifiquement la trace. La trace montre comment la demande s'est déroulée, ce qui aide nos développeurs à traiter plus rapidement les déchets inconnus.
Comment vivre avec ? Je vais maintenant décrire brièvement le champ des options - comment ce problème est généralement résolu. Comment résoudre le problème de la collecte, du transfert et du stockage des journaux.
Comment écrire depuis l'application ? Il est clair qu'il existe différentes manières. En particulier, il y a les meilleures pratiques, comme nous le disent des camarades à la mode. Il y a deux types de vieille école, comme disaient les grands-pères. Il existe d'autres moyens.
Avec la collecte de journaux, la situation est à peu près la même. Il n'y a pas tellement d'options pour résoudre cette partie particulière. Il y en a plus, mais pas encore autant.
Mais avec la livraison et l'analyse ultérieure, le nombre de variations commence à exploser. Je ne décrirai pas chaque option maintenant. Je pense que les principales options sont bien connues de tous ceux qui s'intéressent au sujet.
Je vais vous montrer comment nous l'avons fait à Lazada et comment tout a commencé.
Il y a un an, je suis venu à Lazada et j'ai été envoyé au projet de journalisation. C'était comme ça là-bas. Le journal de l'application a été écrit dans stdout et stderr. Tout a été fait de manière à la mode. Mais ensuite, les développeurs l'ont jeté hors des flux standard, puis les spécialistes de l'infrastructure le découvriront d'une manière ou d'une autre. Entre les spécialistes de l'infrastructure et les développeurs, il y a aussi les releasers qui ont dit : "euh... eh bien, enveloppons-les simplement dans un fichier avec un shell, et c'est tout." Et puisque tout cela est dans un conteneur, ils l'ont enveloppé directement dans le conteneur lui-même, ont mappé le répertoire à l'intérieur et l'ont mis là. Je pense que c'est assez évident pour tout le monde ce qui s'est passé.
Regardons un peu plus loin. Comment nous avons livré ces journaux. Quelqu'un a choisi td-agent, qui parle couramment mais pas tout à fait. Je ne comprends toujours pas la relation de ces deux projets, mais ils semblent être à peu près la même chose. Et ce fluentd, écrit en Ruby, a lu les fichiers journaux, les a analysés en JSON en utilisant une sorte d'expressions régulières. Ensuite, ils ont été envoyés à Kafka. De plus, dans Kafka, nous avions 4 sujets distincts pour chaque API. Pourquoi 4 ? Parce qu'il y a du live, il y a de la mise en scène, et parce qu'il y a stdout et stderr. Les développeurs les produisent et les travailleurs de l'infrastructure doivent les créer dans Kafka. De plus, Kafka était contrôlé par un autre département. Il fallait donc créer un ticket pour qu'ils y créent 4 sujets pour chaque api. Tout le monde l'a oublié. En général, c'était des ordures et des déchets.
Qu'avons-nous fait ensuite avec ? Nous l'avons envoyé à Kafka. Plus loin de Kafka, la moitié des bûches ont volé vers Logstash. L'autre moitié des journaux a été partagée. Certains ont volé vers un Graylog, d'autres vers un autre Graylog. En conséquence, tout cela s'est envolé dans un seul cluster Elasticsearch. C'est-à-dire que tout ce gâchis est tombé à la fin là. Vous n'avez pas à faire ça !
Voici à quoi cela ressemble vu d'en haut. Vous n'avez pas à faire ça ! Ici, les zones problématiques sont immédiatement marquées de chiffres. Il y en a en fait plus, mais 6 sont vraiment problématiques, avec lesquels il faut faire quelque chose. Je vais en parler séparément maintenant.
Ici (1,2,3) nous écrivons des fichiers et, par conséquent, il y a trois râteaux ici à la fois.
La première (1) est que nous devons les écrire quelque part. Il n'est pas toujours souhaitable de donner à une API la possibilité d'écrire directement dans un fichier. Il est souhaitable que l'API soit isolée dans un conteneur, et encore mieux, qu'elle soit en lecture seule. Je suis un administrateur système, j'ai donc une vision légèrement différente de ces choses.
Le deuxième point (2,3) est que nous recevons beaucoup de requêtes vers l'API. L'API écrit beaucoup de données dans un fichier. Les dossiers s'agrandissent. Nous devons les faire tourner. Sinon, vous ne pourrez pas y enregistrer de disques. Les faire pivoter est mauvais car ils sont redirigés via le shell vers un répertoire. Il n'y a aucun moyen de le faire pivoter. Vous ne pouvez pas dire à l'application de rouvrir les poignées. Car les développeurs vont vous regarder comme un imbécile : « Quels descripteurs ? Nous écrivons généralement sur stdout. Les frameworks ont fait de copytruncate en logrotate, ce qui fait juste une copie du fichier et troncs l'original. En conséquence, entre ces processus de copie, l'espace disque s'épuise généralement.
(4) Nous avions différents formats dans différentes API. Ils étaient légèrement différents, mais l'expression régulière devait être écrite différemment. Comme tout était géré par Puppet, il y avait un grand nombre de classes avec leurs propres cafards. De plus, l'agent td pouvait la plupart du temps manger de la mémoire, être stupide, il pouvait juste prétendre qu'il travaillait et ne rien faire. Extérieurement, il était impossible de comprendre qu'il ne faisait rien. Au mieux, il tombera, et quelqu'un viendra le chercher plus tard. Plus précisément, une alerte arrivera, et quelqu'un ira la lever avec ses mains.
(6) Et le plus de déchets et de déchets - c'était elasticsearch. Parce que c'était une ancienne version. Parce que nous n'avions pas de maîtres dédiés à l'époque. Nous avions des journaux hétérogènes dont les champs pouvaient se chevaucher. Différents journaux d'applications différentes peuvent être écrits avec les mêmes noms de champ, mais en même temps, il peut y avoir des données différentes à l'intérieur. C'est-à-dire qu'un journal est fourni avec un entier dans un champ, par exemple level. Un autre journal est fourni avec une chaîne dans le champ de niveau. En l'absence de cartographie statique, une telle chose merveilleuse s'avère. Si, après la rotation de l'index, un message avec une chaîne est arrivé en premier dans elasticsearch, alors nous vivons normalement. Et si le premier est arrivé avec Integer, tous les messages suivants arrivés avec String sont simplement ignorés. Parce que le type de champ ne correspond pas.
Nous avons commencé à nous poser ces questions. Nous avons décidé de ne pas chercher les coupables.
Mais il faut faire quelque chose ! Ce qui est évident, c'est qu'il faut établir des normes. Nous avions déjà des normes. Certains nous avons apporté un peu plus tard. Heureusement, un format de journal unique pour toutes les API était déjà approuvé à l'époque. Elle est inscrite directement dans les normes d'interaction des services. En conséquence, ceux qui souhaitent recevoir les journaux doivent les écrire dans ce format. Si quelqu'un n'écrit pas de journaux dans ce format, nous ne garantissons rien.
De plus, j'aimerais avoir une norme unique pour les méthodes d'enregistrement, de livraison et de collecte des journaux. En fait, où les écrire et comment les livrer. La situation idéale est lorsque les projets utilisent la même bibliothèque. Il existe une bibliothèque de journalisation distincte pour Go, il existe une bibliothèque distincte pour PHP. Tout le monde que nous avons, tout le monde devrait les utiliser. Pour le moment, je dirais que nous réussissons à 80 %. Mais certains continuent à manger des cactus.
Et là (sur la diapositive) le « SLA pour la livraison des journaux » commence à peine à apparaître. Ce n'est pas encore là, mais nous y travaillons. Car c'est très pratique quand infra dit que si vous écrivez dans tel ou tel format à tel ou tel endroit et pas plus de N messages par seconde, alors on le livrera très probablement là-bas. Cela enlève beaucoup de maux de tête. S'il y a un SLA, alors c'est tout simplement génial !
Comment avons-nous commencé à résoudre le problème ? Le râteau principal était avec td-agent. Il n'était pas clair où vont nos journaux. Sont-ils livrés ? Vont-ils? Où sont-ils de toute façon ? Par conséquent, il a été décidé de remplacer td-agent par le premier élément. Options pour le remplacer par, j'ai brièvement décrit ici.
Courant. Tout d'abord, je l'ai rencontré lors d'un précédent travail et il y tombait aussi périodiquement. Deuxièmement, c'est la même chose, seulement de profil.
battement de fichier. Comment était-ce bon pour nous? Le fait qu'il soit en Go, et nous avons une grande expertise en Go. En conséquence, si quelque chose, nous pourrions en quelque sorte l'ajouter à nous-mêmes. C'est pourquoi nous ne l'avons pas pris. Pour qu'il n'y ait même pas la tentation de commencer à le réécrire pour vous-même.
La solution évidente pour le sysadmin est toutes sortes de syslogs dans cette quantité (syslog-ng/rsyslog/nxlog).
Ou écrivez quelque chose de votre côté, mais nous l'avons jeté, ainsi que filebeat. Si vous écrivez quelque chose, il est préférable d'écrire quelque chose d'utile pour les affaires. Pour livrer des bûches, il vaut mieux prendre quelque chose de prêt à l'emploi.
Par conséquent, le choix se résumait en fait à un choix entre syslog-ng et rsyslog. Je me suis penché vers rsyslog simplement parce que nous avions déjà des classes pour rsyslog dans Puppet, et je n'ai pas trouvé de différence évidente entre elles. Qu'est-ce que syslog, qu'est-ce que syslog. Oui, certaines documentations sont pires, d'autres meilleures. Il sait de cette façon, et il le fait différemment.
Et un peu sur rsyslog. Tout d'abord, c'est cool parce qu'il a beaucoup de modules. Il a un RainerScript lisible par l'homme (langage de configuration moderne). Un bonus impressionnant est que nous avons pu émuler le comportement de td-agent avec ses outils standard, et rien n'a changé pour les applications. Autrement dit, nous changeons td-agent en rsyslog et ne touchons pas encore à tout le reste. Et immédiatement nous obtenons une livraison de travail. Ensuite, mmnormalize est la chose intéressante à propos de rsyslog. Il vous permet d'analyser les journaux, mais pas avec Grok et regexp. Il crée un arbre syntaxique abstrait. Il analyse les journaux de la même manière qu'un compilateur analyse le code source. Cela vous permet de travailler très vite, de consommer peu de CPU et, en général, c'est juste une chose très cool. Il y a plein d'autres bonus. Je ne m'attarderai pas sur eux.
rsyslog a beaucoup plus d'inconvénients. Ils sont à peu près les mêmes que les bonus. Les principaux problèmes sont que vous devez pouvoir le cuisiner et que vous devez sélectionner une version.
Nous avons décidé d'écrire les logs dans un socket unix. Et pas dans /dev/log, parce que là nous avons un gâchis de journaux système, il y a journald dans ce pipeline. Écrivons donc dans un socket personnalisé. Nous l'attacherons à un ensemble de règles séparé. N'interférons avec rien. Tout sera transparent et compréhensible. Donc nous l'avons fait. Le répertoire avec ces sockets est standardisé et transmis à tous les conteneurs. Les conteneurs peuvent voir le socket dont ils ont besoin, l'ouvrir et y écrire.
Pourquoi pas un dossier ? Parce que tout le monde a lu , qui a essayé de transférer le fichier vers docker et a constaté qu'après le redémarrage de rsyslog, le descripteur de fichier change et que docker perd ce fichier. Il garde ouvert quelque chose d'autre, mais pas la même douille où ils écrivent. Nous avons décidé de contourner ce problème et, en même temps, de contourner le problème de blocage.
Rsyslog effectue les actions indiquées sur la diapositive et envoie les journaux au relais ou à Kafka. Kafka suit l'ancienne voie. Rayleigh - J'ai essayé d'utiliser rsyslog pur pour fournir des journaux. Sans Message Queue, à l'aide des outils rsyslog standard. En gros, ça marche.
Mais il y a des nuances dans la façon de les insérer plus tard dans cette partie (Logstash/Graylog/ES). Cette partie (rsyslog-rsyslog) est utilisée entre les centres de données. Voici un lien tcp compressé, qui vous permet d'économiser de la bande passante et, par conséquent, d'augmenter en quelque sorte la probabilité que nous recevions des journaux d'un autre centre de données lorsque le canal est plein. Parce que nous avons l'Indonésie, où tout va mal. C'est là que réside le problème constant.
Nous avons réfléchi à la manière dont nous surveillons réellement, avec quelle probabilité les journaux que nous avons enregistrés à partir de l'application atteignent-ils cette fin ? Nous avons décidé de commencer les métriques. Rsyslog a son propre module de collecte de statistiques, qui a une sorte de compteurs. Par exemple, il peut vous indiquer la taille de la file d'attente, ou le nombre de messages arrivés pour telle ou telle action. Vous pouvez déjà leur prendre quelque chose. De plus, il a des compteurs personnalisés que vous pouvez configurer, et il vous montrera, par exemple, le nombre de messages que certaines API ont enregistrés. Ensuite, j'ai écrit rsyslog_exporter en Python, et nous avons tout envoyé à Prometheus et tracé. Nous voulions vraiment des métriques Graylog, mais jusqu'à présent nous n'avons pas eu le temps de les mettre en place.
Quels sont les problèmes? Le problème est survenu avec le fait que nous avons découvert (SOUDAINS !) Que nos API Live écrivaient 50 12 messages par seconde. Il s'agit uniquement de l'API Live sans mise en scène. Et Graylog ne nous montre que XNUMX XNUMX messages par seconde. Et une question raisonnable s'est posée, où sont les restes? D'où nous avons conclu que Graylog ne peut tout simplement pas faire face. Nous avons cherché, et, effectivement, Graylog avec Elasticsearch ne maîtrisait pas ce flux.
Ensuite, d'autres découvertes que nous avons faites en cours de route.
Les écritures sur le socket sont bloquées. Comment est-ce arrivé? Lorsque j'ai utilisé rsyslog pour la livraison, à un moment donné, nous avons rompu le canal entre les centres de données. La livraison s'est levée à un endroit, la livraison s'est levée à un autre endroit. Tout cela se résume à une machine avec des API qui écrivent sur le socket rsyslog. Il y avait une file d'attente. Ensuite, la file d'attente d'écriture sur le socket unix s'est remplie, qui est par défaut de 128 paquets. Et le prochain write() dans les blocs d'application. Lorsque nous avons examiné la bibliothèque que nous utilisons dans les applications Go, il y était écrit que l'écriture sur le socket se produit en mode non bloquant. Nous étions sûrs que rien n'était bloqué. Parce que nous avons lu qui a écrit à ce sujet. Mais il y a un moment. Il y avait aussi une boucle infinie autour de cet appel, dans laquelle il y avait une tentative constante de pousser un message dans le socket. Nous ne l'avons pas remarqué. J'ai dû réécrire la bibliothèque. Depuis lors, cela a changé plusieurs fois, mais maintenant nous nous sommes débarrassés des verrous dans tous les sous-systèmes. Par conséquent, vous pouvez arrêter rsyslog et rien ne tombera.
Il faut surveiller la taille des files d'attente, ce qui aide à ne pas marcher sur ce râteau. Tout d'abord, nous pouvons surveiller quand nous commençons à perdre des messages. Deuxièmement, nous pouvons vérifier que nous avons essentiellement des problèmes de livraison.
Et un autre moment désagréable - l'amplification par 10 fois dans une architecture de microservice est très facile. Nous n'avons pas autant de requêtes entrantes, mais à cause du graphique le long duquel ces messages s'exécutent plus loin, à cause des journaux d'accès, nous augmentons en fait la charge sur les journaux d'environ dix fois. Malheureusement, je n'ai pas eu le temps de calculer les chiffres exacts, mais les microservices sont ce qu'ils sont. Ceci doit être gardé à l'esprit. Il s'avère qu'à l'heure actuelle, le sous-système de collecte de journaux est le plus chargé de Lazada.
Comment résoudre le problème d'elasticsearch ? Si vous avez besoin d'obtenir rapidement des journaux en un seul endroit, afin de ne pas courir sur toutes les machines et de ne pas les collecter là-bas, utilisez le stockage de fichiers. Ceci est garanti pour fonctionner. Cela se fait depuis n'importe quel serveur. Il vous suffit d'y coller des disques et de mettre syslog. Après cela, vous êtes assuré d'avoir tous les journaux au même endroit. Ensuite, il sera possible de configurer lentement elasticsearch, graylog ou autre chose. Mais vous aurez déjà tous les journaux et, de plus, vous pourrez les stocker, dans la mesure où il y a suffisamment de baies de disques.
Au moment de mon rapport, le régime a commencé à ressembler à ceci. Nous avons pratiquement cessé d'écrire dans le fichier. Maintenant, très probablement, nous allons éteindre les restes. Sur les machines locales exécutant l'API, nous arrêterons d'écrire dans les fichiers. Premièrement, il y a le stockage de fichiers, qui fonctionne très bien. Deuxièmement, ces machines manquent constamment d'espace, vous devez le surveiller en permanence.
Cette partie avec Logstash et Graylog, ça monte vraiment en flèche. Par conséquent, vous devez vous en débarrasser. Vous devez en choisir un.
Nous avons décidé d'abandonner Logstash et Kibana. Parce que nous avons un service de sécurité. Quel est le rapport? Le lien est que Kibana sans X-Pack et sans Shield ne permet pas de différencier les droits d'accès aux logs. Par conséquent, ils ont pris Graylog. Il a tout. Je n'aime pas ça, mais ça marche. Nous avons acheté du nouveau matériel, y avons installé un nouveau Graylog et déplacé tous les journaux avec des formats stricts vers un Graylog séparé. Nous avons résolu le problème avec différents types des mêmes champs sur le plan organisationnel.
Qu'est-ce qui est exactement inclus dans le nouveau Graylog. Nous venons d'écrire tout dans le docker. Nous avons pris un tas de serveurs, déployé trois instances Kafka, 7 serveurs Graylog version 2.3 (car je voulais Elasticsearch version 5). Tout cela a été soulevé lors de raids du disque dur. Nous avons vu un taux d'indexation allant jusqu'à 100 140 messages par seconde. Nous avons vu le chiffre de XNUMX téraoctets de données par semaine.
Et encore un râteau ! Nous avons deux ventes à venir. Nous avons dépassé les 6 millions de publications. Nous Graylog n'a pas le temps de mâcher. D'une manière ou d'une autre, vous devez à nouveau survivre.
C'est ainsi que nous avons survécu. Ajout de quelques serveurs et SSD supplémentaires. En ce moment, nous vivons comme ça. Maintenant, nous mâchons déjà 160 XNUMX messages par seconde. Nous n'avons pas encore atteint la limite, il n'est donc pas clair combien nous pouvons en tirer de manière réaliste.
Ce sont nos plans pour l'avenir. Parmi ceux-ci, le plus important est probablement la haute disponibilité. Nous ne l'avons pas encore. Plusieurs voitures sont configurées de la même manière, mais jusqu'à présent, tout passe par une seule voiture. Il faut passer du temps à mettre en place un basculement entre eux.
Collectez les métriques de Graylog.
Fixez une limite de débit pour que nous ayons une API folle qui ne nous tue pas la bande passante et tout le reste.
Et enfin, signez une sorte de SLA avec les développeurs afin que nous puissions servir autant. Si vous écrivez plus, alors désolé.
Et rédiger une documentation.
En bref, les résultats de tout ce que nous avons vécu. Premièrement, les normes. Deuxièmement, syslog est un gâteau. Troisièmement, rsyslog fonctionne exactement comme il est écrit sur la diapositive. Et passons aux questions.
des questions.
question: Pourquoi ont-ils décidé de ne pas prendre ... (filebeat?)
réponse: Besoin d'écrire dans un fichier. Je ne voulais vraiment pas. Lorsque votre API écrit des milliers de messages par seconde, même si vous effectuez une rotation une fois par heure, ce n'est toujours pas une option. Vous pouvez écrire dans pipe. A quoi les développeurs m'ont demandé : « Que se passera-t-il si le processus dans lequel nous écrivons échoue » ? Je n'ai tout simplement pas trouvé quoi leur répondre, et j'ai dit: "Bon, ok, ne faisons pas ça."
question : Pourquoi n'écrivez-vous pas simplement des journaux sur HDFS ?
réponseR : C'est la prochaine étape. Nous y avons pensé au tout début, mais comme il n'y a pas de ressources pour y faire face pour le moment, cela dépend de notre solution à long terme.
question: Un format colonne serait plus approprié.
réponse: Je comprends. Nous sommes "pour" des deux mains.
question: Vous écrivez à rsyslog. TCP et UDP y sont disponibles. Mais si UDP, comment garantissez-vous la livraison ?
réponseR : Il y a deux points. Premièrement, je dis immédiatement à tout le monde que nous ne garantissons pas la livraison des journaux. Parce que quand les développeurs viennent nous dire : « Commençons à y écrire des données financières, et vous nous les mettrez quelque part au cas où il se passerait quelque chose », nous leur répondons : « Génial ! Commençons par bloquer l'écriture sur le socket, et faisons-le dans les transactions, afin que vous soyez assuré de le mettre dans le socket pour nous et de vous assurer que nous l'avons reçu de l'autre côté. Et à ce moment, tout le monde devient immédiatement inutile. Et sinon, quelles questions avons-nous? Si vous ne voulez pas garantir une écriture sur le socket, pourquoi garantirions-nous la livraison ? Nous faisons de notre mieux. Nous essayons vraiment de livrer le plus possible et le mieux possible, mais nous ne donnons pas de garantie à 100 %. Par conséquent, vous n'avez pas besoin d'y écrire des données financières. Il existe des bases de données transactionnelles pour cela.
question : Lorsque l'API génère un message dans le journal et transfère le contrôle aux microservices, avez-vous rencontré le problème que les messages de différents microservices arrivent dans le mauvais ordre ? De ce fait, la confusion s'installe.
réponseR : Il est normal qu'ils viennent dans un ordre différent. Vous devez être prêt pour cela. Parce que toute livraison sur le réseau ne vous garantit pas la commande, ou vous devez dépenser des ressources spéciales pour cela. Si nous prenons des stockages de fichiers, chaque API enregistre les journaux dans son propre fichier. Au lieu de cela, rsyslog les décompose en répertoires. Chaque API a ses propres journaux là-bas, où vous pouvez aller et regarder, puis vous pouvez les comparer en utilisant l'horodatage dans ce journal. S'ils vont chercher dans Graylog, ils y seront triés par horodatage. Tout ira bien là-bas.
question : L'horodatage peut varier de quelques millisecondes.
réponse: L'horodatage est généré par l'API elle-même. C'est en fait tout l'intérêt. Nous avons NTP. L'API génère un horodatage déjà dans le message lui-même. Il n'est pas ajouté par rsyslog.
question: L'interaction entre les centres de données n'est pas très claire. Dans le cadre du centre de données, il est clair comment les logs ont été collectés et traités. Comment se passe l'interaction entre les centres de données ? Ou chaque centre de données vit-il sa propre vie ?
réponse: Presque. Nous avons chaque pays situé dans un centre de données. Nous n'avons pas actuellement de diffusion, de sorte qu'un pays est placé dans différents centres de données. Il n'est donc pas nécessaire de les combiner. A l'intérieur de chaque centre se trouve un Log Relay. Il s'agit d'un serveur Rsyslog. En fait, deux machines de gestion. Ils sont configurés de la même manière. Mais pour l'instant, le trafic ne passe que par l'un d'eux. Elle enregistre tous les agrégats. Il a une file d'attente de disque juste au cas où. Elle presse les journaux et les envoie au centre de données central (Singapour), où ils sont déjà empoisonnés dans Graylog. Et chaque centre de données possède son propre stockage de fichiers. Au cas où nous perdrions la connexion, nous avons tous les journaux là-bas. Ils y resteront. Ils y seront stockés.
question : Recevez-vous des journaux à partir de là lors de situations anormales ?
réponse: Vous pouvez y aller (au stockage de fichiers) et regarder.
question: Comment surveillez-vous que vous ne perdez pas de journaux ?
réponse: Nous les perdons en fait, et nous le surveillons. La surveillance a commencé il y a un mois. La bibliothèque utilisée par les API Go contient des métriques. Elle peut compter combien de fois elle n'a pas réussi à écrire sur socket. Là, en ce moment, il y a une heuristique délicate. Il y a un tampon là-bas. Il essaie d'écrire un message de celui-ci au socket. Si le tampon déborde, il commence à les supprimer. Et il compte combien il les a fait tomber. Si les compteurs commencent à y déborder, nous le saurons. Ils viennent maintenant également sur Prometheus, et vous pouvez voir les graphiques dans Grafana. Vous pouvez configurer des alertes. Mais on ne sait pas encore à qui les envoyer.
question: Dans elasticsearch, vous stockez les journaux avec redondance. Combien de répliques as-tu ?
réponse: Une réplique.
question: Est-ce juste une ligne ?
réponse: Il s'agit du maître et de la réplique. Les données sont stockées en double.
question: Avez-vous modifié la taille du tampon rsyslog d'une manière ou d'une autre ?
réponse: Nous écrivons des datagrammes dans un socket Unix personnalisé. Cela nous impose immédiatement une limitation de 128 kilo-octets. Nous ne pouvons pas écrire plus dedans. Nous avons écrit cela dans la norme. Qui veut entrer dans le stockage, ils écrivent 128 kilo-octets. Les bibliothèques, d'ailleurs, coupent, et mettent un drapeau que le message est coupé. Nous avons un champ spécial dans la norme du message lui-même, qui indique s'il a été coupé lors de l'enregistrement ou non. Nous avons donc la possibilité de suivre ce moment.
Question: Écrivez-vous du JSON cassé ?
réponse: Le JSON brisé sera rejeté pendant le relais car le paquet est trop volumineux. Ou Graylog sera supprimé, car il ne pourra pas analyser JSON. Mais il y a des nuances ici qui doivent être corrigées, et elles sont principalement liées à rsyslog. J'ai déjà rempli quelques questions là-bas, qui doivent encore être travaillées.
Question: Pourquoi Kafka ? Avez-vous essayé RabbitMQ ? Graylog ne s'additionne pas sous de telles charges ?
réponse: Ça ne marche pas avec Graylog. Et Graylog prend forme. C'est vraiment problématique pour lui. Il est une sorte de chose. Et, en fait, ce n'est pas nécessaire. Je préfère écrire de rsyslog directement à elasticsearch, puis regarder Kibana. Mais nous devons régler le problème avec les agents de sécurité. Il s'agit d'une variante possible de notre développement lorsque nous lançons Graylog et utilisons Kibana. Logstash n'aura aucun sens. Parce que je peux faire la même chose avec rsyslog. Et il a un module pour écrire dans elasticsearch. Avec Graylog, nous essayons de vivre en quelque sorte. Nous l'avons même un peu modifié. Mais il y a encore place à l'amélioration.
À propos de Kafka. C'est comme ça que ça s'est passé historiquement. Quand je suis arrivé, il était déjà là et des journaux y étaient déjà écrits. Nous venons d'élever notre cluster et d'y déplacer des journaux. Nous le gérons, nous savons ce qu'il ressent. Quant à RabbitMQ... nous avons des problèmes avec RabbitMQ. Et RabbitMQ se développe pour nous. Nous l'avons en production, et il y avait des problèmes avec. Maintenant, avant la vente, il serait chamanisé, et il commencerait à travailler normalement. Mais avant cela, je n'étais pas prêt à le sortir en production. Il y a encore un point. Graylog peut lire la version AMQP 0.9 et rsyslog peut écrire la version AMQP 1.0. Et il n'y a pas une seule solution qui puisse faire les deux au milieu. Il y a soit l'un soit l'autre. Donc pour l'instant uniquement Kafka. Mais il y a aussi des nuances. Parce que omkafka de la version de rsyslog que nous utilisons peut perdre tout le tampon de messages qu'il a récupéré de rsyslog. Tant qu'on le supporte.
Question: Utilisez-vous Kafka parce que vous l'aviez ? Pas utilisé à d'autres fins ?
réponse: Kafka, qui a été utilisé par l'équipe Data Science. Il s'agit d'un projet complètement distinct, dont je ne peux malheureusement rien dire. Je ne sais pas. Elle était dirigée par l'équipe Data Science. Lorsque les journaux ont commencé, ils ont décidé de l'utiliser, afin de ne pas mettre les leurs. Maintenant, nous avons mis à jour Graylog et nous avons perdu la compatibilité, car il existe une ancienne version de Kafka. Nous avons dû fabriquer le nôtre. En même temps, nous nous sommes débarrassés de ces quatre sujets pour chaque API. Nous avons fait un haut large pour tous les live, un large haut large pour toutes les mises en scène et nous tournons tout là-bas. Graylog ratisse tout cela en parallèle.
Question: Pourquoi a-t-on besoin de ce chamanisme à douilles ? Avez-vous essayé d'utiliser le pilote de journal syslog pour les conteneurs.
réponse: Au moment où nous avons posé cette question, nous avions des relations tendues avec le docker. C'était docker 1.0 ou 0.9. Docker lui-même était bizarre. Deuxièmement, si vous y insérez également des journaux ... J'ai un soupçon non vérifié qu'il passe tous les journaux par lui-même, via le démon docker. Si nous avons une API qui devient folle, alors le reste des API se heurtera au fait qu'elles ne peuvent pas envoyer stdout et stderr. Je ne sais pas où cela mènera. J'ai un soupçon au niveau du sentiment qu'il n'est pas nécessaire d'utiliser le pilote docker syslog à cet endroit. Notre département de tests fonctionnels possède son propre cluster Graylog avec des logs. Ils utilisent des pilotes de journal Docker et tout semble bien se passer. Mais ils écrivent immédiatement GELF à Graylog. Au moment où nous avons commencé tout cela, nous en avions besoin pour fonctionner. Peut-être que plus tard, quand quelqu'un viendra nous dire que cela fonctionne normalement depuis cent ans, nous essaierons.
Question: Vous livrez entre les centres de données en utilisant rsyslog. Pourquoi pas sur Kafka ?
réponse: Nous faisons cela, et c'est vraiment comme ça. Pour deux raisons. Si le canal est complètement mort, tous nos journaux, même sous forme compressée, ne le traverseront pas. Et kafka leur permet simplement de perdre dans le processus. De cette façon, on se débarrasse du collage de ces bûches. Nous utilisons simplement Kafka dans ce cas directement. Si nous avons un bon canal et que nous voulons le libérer, nous utilisons leur rsyslog. Mais en fait, vous pouvez le configurer pour qu'il laisse tomber ce qu'il n'a pas traversé. Pour le moment, nous utilisons simplement la livraison rsyslog directement quelque part, quelque part Kafka.
Source: habr.com