l'article sur Badushka<\/a><\/noindex>, qui en a parl\u00e9. Mais il y a un moment. Autour de cet appel, il y avait aussi une boucle infinie, o\u00f9 une tentative continue d'ins\u00e9rer un message dans le socket se produisait. C'est cela que nous n'avons pas remarqu\u00e9. Nous avons d\u00fb r\u00e9\u00e9crire la biblioth\u00e8que. Depuis lors, elle a \u00e9t\u00e9 modifi\u00e9e plusieurs fois, mais maintenant nous avons \u00e9limin\u00e9 les blocages dans tous les sous-syst\u00e8mes. Donc, nous pouvons arr\u00eater rsyslog, et rien ne tombera.<\/p>\n<\/p>\n
Nous devons surveiller la taille des files d'attente, ce qui aide \u00e0 \u00e9viter ces pi\u00e8ges. Premi\u00e8rement, nous pouvons surveiller quand nous commen\u00e7ons \u00e0 perdre des messages. Deuxi\u00e8mement, nous pouvons surveiller si nous avons des probl\u00e8mes de livraison en g\u00e9n\u00e9ral.<\/p>\n
<\/p>\n
Et un autre point d\u00e9sagr\u00e9able \u2014 l'amplification de 10 fois dans une architecture microservices \u2014 c'est tr\u00e8s facile. Nous n'avons pas tant de demandes entrantes, mais \u00e0 cause du graphe sur lequel ces messages se d\u00e9placent, en raison des logs d'acc\u00e8s, nous augmentons r\u00e9ellement la charge des logs d'environ dix fois. Malheureusement, je n'ai pas eu le temps de calculer les chiffres exacts, mais les microservices \u2014 c'est comme \u00e7a. Il faut en tenir compte. Il s'av\u00e8re qu'actuellement, le sous-syst\u00e8me de collecte des logs est le plus sollicit\u00e9 chez Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Comment r\u00e9soudre le probl\u00e8me d'elasticsearch ? Si vous devez rapidement obtenir les logs en un seul endroit, sans courir \u00e0 travers toutes les machines, et ne pas les collecter l\u00e0-bas, utilisez un stockage de fichiers. Cela fonctionne de mani\u00e8re garantie. Cela peut se faire \u00e0 partir de n'importe quel serveur. Il suffit de brancher des disques et de mettre en place syslog. Apr\u00e8s cela, vous aurez tous les logs garantis en un seul endroit. Ensuite, vous pourrez configurer tranquillement elasticsearch, graylog ou autre chose. Mais vous aurez d\u00e9j\u00e0 tous les logs, et vous pourrez les conserver aussi longtemps que l'espace disque le permet.<\/p>\n
<\/p>\n
<\/p>\n
Au moment de ma pr\u00e9sentation, le sch\u00e9ma est devenu comme \u00e7a. Nous avons presque cess\u00e9 d'\u00e9crire dans le fichier. Maintenant, nous allons probablement d\u00e9sactiver les restes. Sur les machines locales, sur lesquelles les API sont lanc\u00e9es, nous cesserons d'\u00e9crire dans les fichiers. Premi\u00e8rement, il existe un stockage de fichiers qui fonctionne tr\u00e8s bien. Deuxi\u00e8mement, sur ces machines, l'espace finit constamment, il faut le surveiller en permanence.<\/p>\n
<\/p>\n
Cette partie avec Logstash et Graylog, elle est vraiment g\u00eanante. Donc, il faut s'en d\u00e9barrasser. Il faut choisir quelque chose d'unique.<\/p>\n
<\/p>\n
<\/p>\n
Nous avons d\u00e9cid\u00e9 de nous d\u00e9barrasser de Logstash et de Kibana. Pourquoi ? Parce que nous avons un d\u00e9partement de s\u00e9curit\u00e9. Quel rapport ? Le lien est que Kibana sans X-Pack et sans Shield ne permet pas de restreindre les droits d'acc\u00e8s aux logs. C'est pourquoi nous avons choisi Graylog. Tout cela est compris. Je n'aime pas, mais cela fonctionne. Nous avons achet\u00e9 un nouveau mat\u00e9riel, install\u00e9 une version r\u00e9cente de Graylog et transf\u00e9r\u00e9 tous les logs avec des formats stricts dans un Graylog s\u00e9par\u00e9. Nous avons r\u00e9solu le probl\u00e8me des diff\u00e9rents types de champs identiques organisationnellement.<\/p>\n
<\/p>\n
<\/p>\n
Que contient donc le nouveau Graylog ? Nous avons simplement tout enregistr\u00e9 dans Docker. Nous avons pris une multitude de serveurs, d\u00e9ploy\u00e9 trois instances de Kafka, 7 serveurs Graylog version 2.3 (car nous voulions la version 5 d'Elasticsearch). Tout cela a \u00e9t\u00e9 mis en place sur des RAID avec des HDD. Nous avons observ\u00e9 un taux d'indexation allant jusqu'\u00e0 100 000 messages par seconde. Nous avons constat\u00e9 que nous avions 140 t\u00e9raoctets de donn\u00e9es par semaine. <\/p>\n
<\/p>\n
<\/p>\n
Et encore des obstacles ! Nous avons deux ventes \u00e0 venir. Nous avons d\u00e9pass\u00e9 les 6 millions de messages. Graylog n'arrive pas \u00e0 suivre. Il faut encore survivre. <\/p>\n
<\/p>\n
<\/p>\n
Nous avons surv\u00e9cu de cette mani\u00e8re. Nous avons ajout\u00e9 un peu plus de serveurs et de SSD. Actuellement, nous vivons comme cela. Nous traitons d\u00e9j\u00e0 160 000 messages par seconde. Nous ne sommes pas encore arriv\u00e9s au plafond, donc nous ne savons pas combien nous pourrons r\u00e9ellement tirer de tout cela. <\/p>\n
<\/p>\n
<\/p>\n
Voici nos projets pour l'avenir. Parmi eux, la haute disponibilit\u00e9 est peut-\u00eatre la plus importante. Nous ne l'avons pas encore. Plusieurs machines sont configur\u00e9es de la m\u00eame mani\u00e8re, mais tout passe pour l'instant par une seule machine. Il faut prendre le temps de configurer un basculement entre elles.<\/p>\n
<\/p>\n
Collecter des m\u00e9triques avec Graylog.<\/p>\n
<\/p>\n
Mettre en place une limite de taux afin qu'une API d\u00e9faillante ne d\u00e9s\u00e9quilibre pas notre bande passante et tout le reste.<\/p>\n
<\/p>\n
Et enfin, signer un SLA avec les d\u00e9veloppeurs, stipulant que nous pouvons g\u00e9rer un certain volume. Si vous en \u00e9crivez plus, navr\u00e9.<\/p>\n
<\/p>\n
Et r\u00e9diger de la documentation.<\/p>\n
<\/p>\n
<\/p>\n
En r\u00e9sum\u00e9, voici les points cl\u00e9s de tout ce que nous avons travers\u00e9. Tout d'abord, les normes. Deuxi\u00e8mement, le syslog \u2014 c'est le meilleur. Troisi\u00e8mement, rsyslog fonctionne exactement comme indiqu\u00e9 sur la diapositive. Et passons aux questions.<\/p>\n
<\/p>\n
Questions<\/strong>.<\/p>\n<\/p>\n
Question<\/strong>: Pourquoi, en fin de compte, n'avez-vous pas d\u00e9cid\u00e9 de prendre\u2026 (filebeat ?)<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Il faut \u00e9crire dans un fichier. Je n'\u00e9tais vraiment pas en faveur. Lorsque votre API envoie des milliers de messages par seconde, m\u00eame si vous effectuez une rotation toutes les heures, ce n'est pas une option. On pourrait \u00e9crire dans un pipe. \u00c0 quoi les d\u00e9veloppeurs m'ont demand\u00e9 : \u00ab Que se passe-t-il si le processus dans lequel nous \u00e9crivons s'arr\u00eate ? \u00bb Je n'ai tout simplement pas trouv\u00e9 de r\u00e9ponse et j'ai dit : \u00ab D'accord, abandonnons cette id\u00e9e. \u00bb<\/p>\n<\/p>\n
Question<\/strong>: Pourquoi ne vous \u00e9crivez-vous pas simplement des journaux dans HDFS ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: C'est la prochaine \u00e9tape. Nous y avons pens\u00e9 au tout d\u00e9but, mais comme nous n'avons actuellement pas les ressources pour nous en occuper, cela reste une solution \u00e0 long terme.<\/p>\n<\/p>\n
Question<\/strong>: Un format en colonnes serait plus appropri\u00e9.<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Je comprends tout. Nous sommes \u00ab pour \u00bb \u00e0 deux mains. <\/p>\n<\/p>\n
Question<\/strong>: Vous \u00e9crivez dans rsyslog. Cela fonctionne avec TCP et UDP. Mais si c'est UDP, comment garantissez-vous la livraison ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Il y a deux aspects. D'abord, je dis toujours \u00e0 tout le monde que nous ne garantissons pas la livraison des journaux. Quand les d\u00e9veloppeurs arrivent et disent : \u00ab Que diriez-vous d'\u00e9crire des donn\u00e9es financi\u00e8res l\u00e0-bas, et vous les stockez pour nous au cas o\u00f9 quelque chose se produirait \u00bb, nous leur r\u00e9pondons : \u00ab Excellent ! Commencez par bloquer l'\u00e9criture dans le socket et faites-le en transactions, pour vous assurer que vous nous l'avez bien mis dans le socket et que nous l'avons re\u00e7u de l'autre c\u00f4t\u00e9. \u00bb \u00c0 ce moment-l\u00e0, tout le monde se rend compte que c'est compliqu\u00e9. Si ce n\u2019est pas n\u00e9cessaire, alors pourquoi aurait-on des questions ? Si vous ne voulez pas garantir l'\u00e9criture dans le socket, pourquoi devrions-nous garantir la livraison ? Nous faisons de notre mieux. Nous essayons r\u00e9ellement de livrer autant que possible, mais nous ne donnons pas de garantie \u00e0 100 %. Donc \u00e9vitez d'\u00e9crire des donn\u00e9es financi\u00e8res l\u00e0-dedans. Il y a des bases de donn\u00e9es pour cela, avec des transactions.<\/p>\n<\/p>\n
Question<\/strong>: Lorsque l'API g\u00e9n\u00e8re un message dans les journaux et transmet le contr\u00f4le aux microservices, avez-vous rencontr\u00e9 le probl\u00e8me que les messages de diff\u00e9rents microservices arrivent dans le d\u00e9sordre ? Cela cr\u00e9e de la confusion.<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: C'est normal qu'ils arrivent dans un ordre diff\u00e9rent. Il faut s'y pr\u00e9parer. En effet, toute livraison r\u00e9seau ne garantit pas l'ordre, ou il faut consacrer des ressources sp\u00e9cifiquement \u00e0 cela. Si nous parlons de syst\u00e8mes de fichiers, chaque API sauvegarde les journaux dans son propre fichier. En fait, rsyslog les range par r\u00e9pertoire. Chaque API a ses propres journaux, o\u00f9 l\u2019on peut aller voir, et ensuite les comparer par timestamp. S'ils vont consulter Graylog, l\u00e0 ils seront tri\u00e9s par timestamp. Tout ira bien.<\/p>\n<\/p>\n
Question<\/strong>: Le timestamp peut varier de quelques millisecondes.<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Le timestamp est g\u00e9n\u00e9r\u00e9 par l\u2019API elle-m\u00eame. C'est toute l'id\u00e9e. Nous avons un NTP. L\u2019API g\u00e9n\u00e8re le timestamp directement dans le message. Ce n'est pas rsyslog qui l'ajoute.<\/p>\n<\/p>\n
Question<\/strong>: Il n'est pas tr\u00e8s clair comment se fait l'interaction entre les centres de donn\u00e9es. Au sein d'un centre de donn\u00e9es, il est clair comment les journaux sont collect\u00e9s et trait\u00e9s. Comment se passe l'interaction entre les centres de donn\u00e9es ? Chaque centre de donn\u00e9es vit-il sa propre vie ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Presque. Chaque pays est situ\u00e9 dans un seul centre de donn\u00e9es. Actuellement, nous n'avons pas de r\u00e9partition o\u00f9 un pays serait h\u00e9berg\u00e9 dans diff\u00e9rents centres de donn\u00e9es. Donc, il n'est pas n\u00e9cessaire de les combiner. \u00c0 l'int\u00e9rieur de chaque centre, il y a un Log Relay. C'est un serveur Rsyslog. En fait, il y a deux machines de gestion. Elles sont configur\u00e9es de la m\u00eame mani\u00e8re. Mais pour l'instant, le trafic passe par l'une d'elles. Elle agr\u00e8ge tous les journaux. Elle a une file d'attente sur disque au cas o\u00f9. Elle compresse les journaux et les envoie au centre de donn\u00e9es central (de Singapour), o\u00f9 ils sont ensuite envoy\u00e9s \u00e0 Graylog. Et chaque centre de donn\u00e9es a son propre stockage de fichiers. En cas de perte de connexion, nous avons tous les journaux l\u00e0-bas. Ils y resteront. Ils seront sauvegard\u00e9s.<\/p>\n<\/p>\n
Question<\/strong>: Recevez-vous des journaux de l\u00e0 en cas de situations exceptionnelles ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: On peut y aller (dans le stockage de fichiers) et les v\u00e9rifier.<\/p>\n<\/p>\n
Question<\/strong>: Comment surveillez-vous le fait de ne pas perdre des journaux ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: En r\u00e9alit\u00e9, nous en perdons, et nous le surveillons. La surveillance a \u00e9t\u00e9 lanc\u00e9e il y a un mois. Dans la biblioth\u00e8que utilis\u00e9e par l'API Go, il y a des m\u00e9triques. Elle permet de compter combien de fois elle n'a pas pu \u00e9crire dans le socket. Actuellement, il y a une heuristique astucieuse. Il y a un tampon. Il essaie d'\u00e9crire un message dans le socket \u00e0 partir de celui-ci. Si le tampon d\u00e9borde, il commence \u00e0 les jeter. Et il compte combien il a jet\u00e9. Si les compteurs commencent \u00e0 d\u00e9border, nous en serons inform\u00e9s. Ils arrivent maintenant \u00e9galement dans Prometheus, et dans Grafana, on peut voir les graphiques. Des alertes peuvent \u00eatre configur\u00e9es. Mais pour l'instant, il n'est pas clair \u00e0 qui les envoyer.<\/p>\n<\/p>\n
Question<\/strong>: Dans Elasticsearch, vous stockez les journaux avec redondance. Combien de r\u00e9pliques avez-vous ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Une r\u00e9plique.<\/p>\n<\/p>\n
Question<\/strong>: C'est uniquement une r\u00e9plique ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: C'est un ma\u00eetre et une r\u00e9plique. Les donn\u00e9es sont stock\u00e9es en deux exemplaires.<\/p>\n<\/p>\n
Question<\/strong>: Avez-vous ajust\u00e9 la taille du tampon Rsyslog d'une mani\u00e8re ou d'une autre ? <\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Nous \u00e9crivons des datagrammes dans un socket Unix personnalis\u00e9. Cela nous impose imm\u00e9diatement une limitation de 128 Ko. Nous ne pouvons pas y \u00e9crire plus. Nous avons consign\u00e9 cela dans la norme. Ceux qui veulent acc\u00e9der aux stockages \u00e9crivent 128 Ko. Les biblioth\u00e8ques, d'ailleurs, coupent et mettent un drapeau indiquant que le message a \u00e9t\u00e9 tronqu\u00e9. Dans notre standard de message, il y a un champ sp\u00e9cial qui indique s'il a \u00e9t\u00e9 tronqu\u00e9 lors de l'\u00e9criture ou non. Ainsi, nous avons la possibilit\u00e9 de suivre ce moment.<\/p>\n<\/p>\n
Question<\/strong>: \u00c9crivez-vous des JSON corrompus ? <\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Un JSON corrompu sera rejet\u00e9 soit lors du relais, car le paquet est trop gros. Soit il sera rejet\u00e9 par Graylog, car il ne pourra pas parser le JSON. Mais il y a des nuances \u00e0 corriger, et elles sont principalement li\u00e9es \u00e0 rsyslog. J'y ai d\u00e9j\u00e0 rempli plusieurs probl\u00e8mes qui doivent encore \u00eatre trait\u00e9s.<\/p>\n<\/p>\n
Question<\/strong>: Pourquoi Kafka ? Avez-vous essay\u00e9 RabbitMQ ? Graylog ne fonctionne pas avec cette charge ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Nous avons des difficult\u00e9s avec Graylog. Mais Graylog fonctionne pour nous. Il est vraiment probl\u00e9matique. C'est une chose particuli\u00e8re. Et, en r\u00e9alit\u00e9, il n'est pas n\u00e9cessaire. Je pr\u00e9f\u00e9rerais \u00e9crire directement depuis rsyslog dans Elasticsearch et ensuite voir dans Kibana. Mais il faut r\u00e9soudre la question avec les personnes de la s\u00e9curit\u00e9. C'est une option possible pour notre d\u00e9veloppement, lorsque nous abandonnerons Graylog et utiliserons Kibana. Il n'y a pas de sens \u00e0 utiliser Logstash. Parce que, je peux faire tout cela avec rsyslog. Et il a un module pour \u00e9crire dans Elasticsearch. Avec Graylog, nous essayons de vivre d'une mani\u00e8re ou d'une autre. Nous l'avons m\u00eame un peu optimis\u00e9. Mais il y a encore de la place pour des am\u00e9liorations.<\/p>\n<\/p>\n
Concernant Kafka. Historiquement, c'\u00e9tait comme \u00e7a. Quand je suis arriv\u00e9, elle existait d\u00e9j\u00e0, et les logs y \u00e9taient d\u00e9j\u00e0 \u00e9crits. Nous avons simplement configur\u00e9 notre cluster et y avons transf\u00e9r\u00e9 les logs. Nous le g\u00e9rons, nous savons comment il fonctionne. Concernant RabbitMQ... \u00e7a ne fonctionne pas avec RabbitMQ. En revanche, RabbitMQ fonctionne bien chez nous. Il est en production et nous avons eu des probl\u00e8mes avec. Avant cette vente, il a \u00e9t\u00e9 r\u00e9gl\u00e9 et il fonctionne correctement maintenant. Mais auparavant, je n'\u00e9tais pas pr\u00eat \u00e0 le d\u00e9ployer en production. Il y a un autre point. Graylog peut lire la version AMQP 0.9, tandis que rsyslog peut \u00e9crire la version AMQP 1.0. Il n'y a pas de solution qui g\u00e8re les deux. Il faut choisir l'un ou l'autre. Donc pour le moment, c'est uniquement Kafka. Mais il y a aussi des nuances. Parce que omkafka de la version de rsyslog que nous utilisons peut perdre tout le buffer de messages r\u00e9cup\u00e9r\u00e9s de rsyslog. Pour l'instant, nous faisons avec. <\/p>\n
<\/p>\n
Question<\/strong>: Vous utilisez Kafka parce qu'elle \u00e9tait d\u00e9j\u00e0 l\u00e0 ? N'est-elle pas utilis\u00e9e \u00e0 d'autres fins ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Kafka, qui \u00e9tait l\u00e0, est utilis\u00e9e par l'\u00e9quipe Data Science. C'est un projet totalement s\u00e9par\u00e9, dont je suis d\u00e9sol\u00e9 de ne rien savoir. Je ne suis pas au courant. Elle \u00e9tait sous la gestion de l'\u00e9quipe Data Science. Lorsqu'ils ont commenc\u00e9 \u00e0 enregistrer les logs, ils ont d\u00e9cid\u00e9 de l'utiliser plut\u00f4t que d'en installer une nouvelle. Maintenant, nous avons mis \u00e0 jour Graylog et nous avons perdu la compatibilit\u00e9 car il y a une ancienne version de Kafka. Nous avons d\u00fb cr\u00e9er la n\u00f4tre. En m\u00eame temps, nous avons \u00e9limin\u00e9 ces quatre topics pour chaque API. Nous avons cr\u00e9\u00e9 un large topic pour tout le live, un autre large topic pour tout le staging et nous envoyons simplement tout l\u00e0-dedans. Graylog en extrait tout cela en parall\u00e8le.<\/p>\n<\/p>\n
Question<\/strong>: Pourquoi ce besoin de magie avec les sockets ? Avez-vous essay\u00e9 d'utiliser le log-driver syslog pour les conteneurs ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: \u00c0 l'\u00e9poque o\u00f9 nous nous posions cette question, notre relation avec Docker \u00e9tait tendue. C'\u00e9tait Docker 1.0 ou 0.9. Docker en lui-m\u00eame \u00e9tait \u00e9trange. Deuxi\u00e8mement, si nous y incluons aussi les logs... J'ai un soup\u00e7on non v\u00e9rifi\u00e9 qu'il fait passer tous les logs par lui, par le d\u00e9mon Docker. Si une API devient folle, les autres APIs se retrouvent coinc\u00e9es car elles ne peuvent pas envoyer stdout et stderr. Je ne sais pas ce que cela va entra\u00eener. J'ai un sentiment intuitif qu'il ne faut pas utiliser le driver syslog de Docker \u00e0 cet endroit. Notre d\u00e9partement de tests fonctionnels a son propre petit cluster Graylog avec des logs. Ils utilisent les drivers de logs de Docker et il semble que tout va bien de leur c\u00f4t\u00e9. Mais ils envoient directement les GELF dans Graylog. \u00c0 l'\u00e9poque o\u00f9 nous avons lanc\u00e9 tout \u00e7a, nous avions juste besoin que cela fonctionne. Peut-\u00eatre qu'un jour quelqu'un viendra nous dire qu'il fonctionne correctement depuis longtemps, et alors nous essayerons.<\/p>\n<\/p>\n
Question<\/strong>: Vous faites la livraison entre les centres de donn\u00e9es avec rsyslog. Pourquoi pas avec Kafka ?<\/p>\n<\/p>\n
R\u00e9ponse<\/strong>: Nous faisons en fait les deux. Pour deux raisons. Si le canal est vraiment d\u00e9faillant, m\u00eame nos logs compress\u00e9s ne passent pas. Kafka permet simplement de les perdre en cours de route. Avec cette m\u00e9thode, nous \u00e9vitons que ces logs ne s'accumulent. Dans ce cas, nous utilisons directement Kafka. Si notre canal est bon et que nous souhaitons le lib\u00e9rer, nous utilisons rsyslog. Mais en r\u00e9alit\u00e9, il est possible de le configurer pour qu'il supprime ce qui ne passe pas. Actuellement, nous utilisons directement rsyslog \u00e0 certains endroits, et parfois Kafka.<\/p>\nSource : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041b\u043e\u0433\u0438 \u2014 \u0432\u0430\u0436\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u043e\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 (\u043b\u0438\u0431\u043e \u043d\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u043a\u0430\u043a \u043e\u0436\u0438\u0434\u0430\u0435\u0442\u0441\u044f. \u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043b\u043e\u0433\u0430\u043c\u0438 \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u043e\u0439 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u043e\u043b\u0438\u043c\u043f\u0438\u0430\u0434\u044b. \u041d\u0443\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u0441\u0440\u0430\u0437\u0443 \u043a\u0443\u0447\u0443 \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u0432: \u043a\u0430\u043a \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438 \u0438\u0437 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f; \u043a\u0443\u0434\u0430 \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438; \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u043b\u043e\u0433\u0438 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438; \u043a\u0430\u043a \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u0438 \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438. \u041f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043d\u044b\u043d\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Lire](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n