o artigo sobre Badushka<\/a><\/noindex>, que escreveu sobre isso. Mas h\u00e1 um detalhe. Ao redor dessa chamada havia um ciclo infinito, onde havia constantes tentativas de empurrar a mensagem para o socket. Isso n\u00e3o notamos. Foi necess\u00e1rio reescrever a biblioteca. Desde ent\u00e3o, ela mudou v\u00e1rias vezes, mas agora nos livramos de bloqueios em todos os subsistemas. Portanto, podemos parar o rsyslog, e nada vai cair.<\/p>\n<\/p>\n
\u00c9 preciso monitorar o tamanho das filas, o que ajuda a evitar esses erros. Primeiro, podemos monitorar quando come\u00e7amos a perder mensagens. Em segundo lugar, podemos monitorar se estamos tendo problemas na entrega.<\/p>\n
<\/p>\n
E mais um ponto desagrad\u00e1vel \u2014 a amplifica\u00e7\u00e3o em 10 vezes na arquitetura de microsservi\u00e7os \u2014 isso \u00e9 muito f\u00e1cil. N\u00e3o temos tantas requisi\u00e7\u00f5es de entrada, mas devido ao grafo pelo qual as mensagens se movem, por causa dos logs de acesso, realmente aumentamos a carga dos logs em cerca de dez vezes. Infelizmente, n\u00e3o consegui contar os n\u00fameros exatos, mas os microsservi\u00e7os s\u00e3o assim. \u00c9 algo a se ter em mente. Atualmente, o subsistema de coleta de logs \u00e9 o mais sobrecarregado na Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Como resolver o problema do elasticsearch? Se voc\u00ea precisa rapidamente obter logs em um s\u00f3 lugar, para n\u00e3o ter que correr por todas as m\u00e1quinas e colet\u00e1-los, use um armazenamento de arquivos. Isso funciona garantidamente. Pode ser feito a partir de qualquer servidor. Basta instalar discos l\u00e1 e configurar o syslog. Depois disso, todos os logs estar\u00e3o garantidamente em um s\u00f3 lugar. A partir da\u00ed, voc\u00ea pode configurar o elasticsearch, graylog ou outra coisa no seu pr\u00f3prio ritmo. Mas voc\u00ea j\u00e1 ter\u00e1 todos os logs e, al\u00e9m disso, poder\u00e1 armazen\u00e1-los conforme a capacidade dos arrays de discos.<\/p>\n
<\/p>\n
<\/p>\n
No momento da minha apresenta\u00e7\u00e3o, o esquema ficou assim. Praticamente paramos de escrever em arquivos. Agora, provavelmente, desligaremos os restos. Em m\u00e1quinas locais, onde as APIs est\u00e3o em execu\u00e7\u00e3o, n\u00e3o escreveremos mais em arquivos. Primeiro, h\u00e1 um armazenamento de arquivos que funciona muito bem. Em segundo lugar, nessas m\u00e1quinas, o espa\u00e7o acaba constantemente, \u00e9 preciso monitor\u00e1-lo incessantemente.<\/p>\n
<\/p>\n
Essa parte com Logstash e Graylog realmente est\u00e1 dando dor de cabe\u00e7a. Portanto, precisamos nos livrar dela. \u00c9 necess\u00e1rio escolher uma das duas.<\/p>\n
<\/p>\n
<\/p>\n
Decidimos descartar o Logstash e o Kibana. Porque temos um departamento de seguran\u00e7a. Qual \u00e9 a rela\u00e7\u00e3o? A rela\u00e7\u00e3o \u00e9 que o Kibana sem X-Pack e sem Shield n\u00e3o permite delimitar os direitos de acesso aos logs. Portanto, optamos pelo Graylog. Ele n\u00e3o me agrada, mas funciona. Compramos novo hardware, instalamos o Graylog l\u00e1 e transferimos todos os logs com formatos r\u00edgidos para um Graylog separado. Resolvemos o problema com diferentes tipos de campos iguais de maneira organizacional.<\/p>\n
<\/p>\n
<\/p>\n
O que na verdade est\u00e1 inclu\u00eddo no novo Graylog. Simplesmente gravamos tudo no Docker. Pegamos um monte de servidores, implantamos tr\u00eas inst\u00e2ncias do Kafka, 7 servidores Graylog vers\u00e3o 2.3 (porque quer\u00edamos a vers\u00e3o 5 do Elasticsearch). Tudo isso foi levantado em RAID com HDDs. Vimos uma taxa de indexa\u00e7\u00e3o de at\u00e9 100 mil mensagens por segundo. Vimos o n\u00famero que 140 terabytes de dados por semana. <\/p>\n
<\/p>\n
<\/p>\n
E mais uma vez, desafios! Temos duas vendas se aproximando. N\u00f3s transferimos 6 milh\u00f5es de mensagens. Nosso Graylog n\u00e3o d\u00e1 conta. De alguma forma, precisamos sobreviver novamente. <\/p>\n
<\/p>\n
<\/p>\n
Sobrevivemos assim. Adicionamos mais alguns servidores e SSDs. No momento, estamos operando dessa maneira. Agora estamos processando 160 mil mensagens por segundo. Ainda n\u00e3o atingimos o limite, ent\u00e3o ainda n\u00e3o est\u00e1 claro quanto realmente conseguiremos puxar disso. <\/p>\n
<\/p>\n
<\/p>\n
Aqui est\u00e3o nossos planos para o futuro. Desses, o mais importante, provavelmente, \u00e9 a alta disponibilidade. Neste momento, n\u00e3o a temos. V\u00e1rias m\u00e1quinas configuradas da mesma forma, mas tudo ainda passa por uma s\u00f3 m\u00e1quina. Precisamos gastar tempo para configurar o failover entre elas.<\/p>\n
<\/p>\n
Coletar m\u00e9tricas do Graylog.<\/p>\n
<\/p>\n
Fazer um rate limit para que uma API, enlouquecida, n\u00e3o consuma nossa largura de banda e outras coisas.<\/p>\n
<\/p>\n
E finalmente, assinar algum tipo de SLA com os desenvolvedores, informando que podemos suportar essa quantidade. Se voc\u00eas enviam mais, desculpem.<\/p>\n
<\/p>\n
E escrever documenta\u00e7\u00e3o.<\/p>\n
<\/p>\n
<\/p>\n
Resumindo, os resultados de tudo o que passamos. Primeiro, padr\u00f5es. Em segundo lugar, syslog \u2013 \u00e9 um prazer. Em terceiro lugar, o rsyslog funciona exatamente como est\u00e1 escrito no slide. E vamos para as perguntas.<\/p>\n
<\/p>\n
Perguntas<\/strong>.<\/p>\n<\/p>\n
Pergunta<\/strong>: Por que decidiram n\u00e3o usar\u2026 (filebeat?)<\/p>\n<\/p>\n
Resposta<\/strong>: Precisamos gravar em um arquivo. N\u00e3o queria fazer isso. Quando sua API grava milhares de mensagens por segundo, mesmo que voc\u00ea rotacione uma vez por hora, ainda assim n\u00e3o \u00e9 uma op\u00e7\u00e3o. Pode-se gravar em pipe. Ao que os desenvolvedores me perguntaram: \"E se o processo em que estamos gravando falhar\"? Eu simplesmente n\u00e3o consegui encontrar o que responder e disse: \"Bem, ok, vamos n\u00e3o fazer assim\".<\/p>\n<\/p>\n
Pergunta<\/strong>: Por que voc\u00ea n\u00e3o escreve logs apenas no HDFS?<\/p>\n<\/p>\n
Resposta<\/strong>: Este \u00e9 o pr\u00f3ximo passo. Pensamos sobre isso no in\u00edcio, mas, como no momento n\u00e3o temos recursos para trabalhar nisso, permanece como uma solu\u00e7\u00e3o a longo prazo.<\/p>\n<\/p>\n
Pergunta<\/strong>: O formato em coluna seria mais adequado.<\/p>\n<\/p>\n
Resposta<\/strong>: Eu entendo tudo. Estamos \"a favor\" com ambas as m\u00e3os. <\/p>\n<\/p>\n
Pergunta<\/strong>: Voc\u00ea escreve no rsyslog. \u00c9 poss\u00edvel usar tanto TCP quanto UDP. Mas se for UDP, como voc\u00ea garante a entrega?<\/p>\n<\/p>\n
Resposta<\/strong>: Existem dois pontos. Primeiro, eu sempre digo a todos que n\u00e3o garantimos a entrega dos logs. Porque quando os desenvolvedores v\u00eam e dizem: 'Vamos come\u00e7ar a escrever dados financeiros l\u00e1, e voc\u00ea os armazenar\u00e1 caso algo aconte\u00e7a', n\u00f3s respondemos: '\u00d3timo! Vamos fazer com que voc\u00ea comece a bloquear a grava\u00e7\u00e3o no socket e a fazer isso em transa\u00e7\u00f5es, para garantir que voc\u00ea nos coloque no socket e verifique se recebemos do outro lado.' E nesse momento, a maioria das pessoas logo perde o interesse. E se n\u00e3o h\u00e1 interesse, que perguntas temos? Se voc\u00ea n\u00e3o quer garantir a grava\u00e7\u00e3o no socket, por que n\u00f3s dever\u00edamos garantir a entrega? N\u00f3s fazemos o melhor que podemos. Realmente tentamos entregar o m\u00e1ximo poss\u00edvel e da melhor forma, mas n\u00e3o damos 100% de garantia. Portanto, n\u00e3o escreva dados financeiros l\u00e1. Para isso, temos bancos de dados com transa\u00e7\u00f5es.<\/p>\n<\/p>\n
Pergunta<\/strong>: Quando a API gera uma mensagem no log e passa o controle para os microsservi\u00e7os, voc\u00ea j\u00e1 encontrou o problema de que mensagens de diferentes microsservi\u00e7os chegam na ordem errada? Isso causa confus\u00e3o.<\/p>\n<\/p>\n
Resposta<\/strong>: \u00c9 normal que elas cheguem em ordens diferentes. Voc\u00ea precisa estar preparado para isso. Porque qualquer entrega em rede n\u00e3o garante a ordem, ou voc\u00ea precisa gastar recursos especificamente para isso. Se pegarmos sistemas de armazenamento de arquivos, cada API salva logs em seu pr\u00f3prio arquivo. Na verdade, o rsyslog os organiza em diret\u00f3rios. Cada API tem seus pr\u00f3prios logs, onde voc\u00ea pode ir e verificar, e depois, pelo timestamp nesse log, pode correlacion\u00e1-los. Se eles olharem no Graylog, l\u00e1 eles estar\u00e3o ordenados por timestamp. Tudo ser\u00e1 bom.<\/p>\n<\/p>\n
Pergunta<\/strong>: O timestamp pode diferir em milissegundos.<\/p>\n<\/p>\n
Resposta<\/strong>: O timestamp \u00e9 gerado pela pr\u00f3pria API. Essa \u00e9, na verdade, toda a quest\u00e3o. Temos NTP. A API gera o timestamp j\u00e1 na pr\u00f3pria mensagem. N\u00e3o \u00e9 o rsyslog que o adiciona.<\/p>\n<\/p>\n
Pergunta<\/strong>: N\u00e3o est\u00e1 muito claro como ocorre a intera\u00e7\u00e3o entre os data centers. No contexto de um data center, \u00e9 compreens\u00edvel como os logs foram coletados e processados. Como se d\u00e1 a intera\u00e7\u00e3o entre os data centers? Ou cada data center vive sua pr\u00f3pria vida?<\/p>\n<\/p>\n
Resposta<\/strong>: Quase. Cada pa\u00eds est\u00e1 localizado em um \u00fanico data center. No momento, n\u00e3o temos uma configura\u00e7\u00e3o distribu\u00edda onde um pa\u00eds esteja alocado em diferentes data centers. Portanto, n\u00e3o \u00e9 necess\u00e1rio integr\u00e1-los. Dentro de cada centro, existe um Log Relay. \u00c9 um servidor Rsyslog. Na verdade, s\u00e3o duas m\u00e1quinas de gerenciamento. Elas est\u00e3o configuradas da mesma forma. Mas, por enquanto, o tr\u00e1fego est\u00e1 passando por apenas uma delas. Ela agrega todos os logs. Possui uma fila em disco para precau\u00e7\u00f5es. Ela comprime os logs e os envia para o data center central (em Singapura), de onde s\u00e3o enviados para o Graylog. E em cada data center h\u00e1 seu pr\u00f3prio armazenamento de arquivos. Caso ocorra uma perda de conex\u00e3o, ainda temos todos os logs l\u00e1. Eles permanecer\u00e3o l\u00e1. Eles ser\u00e3o salvos.<\/p>\n<\/p>\n
Pergunta<\/strong>: Em situa\u00e7\u00f5es incomuns, voc\u00ea recebe logs de l\u00e1?<\/p>\n<\/p>\n
Resposta<\/strong>: \u00c9 poss\u00edvel ir at\u00e9 l\u00e1 (no armazenamento de arquivos) e verificar.<\/p>\n<\/p>\n
Pergunta<\/strong>: Como voc\u00eas monitoram para garantir que n\u00e3o est\u00e3o perdendo logs?<\/p>\n<\/p>\n
Resposta<\/strong>: Na verdade, n\u00f3s os perdemos, e estamos monitorando isso. Iniciamos o monitoramento h\u00e1 um m\u00eas. Na biblioteca utilizada pelo Go API, h\u00e1 m\u00e9tricas. Ela consegue contar quantas vezes n\u00e3o conseguiu gravar no socket. Atualmente, existe uma heur\u00edstica inteligente. H\u00e1 um buffer. Ele tenta gravar a mensagem no socket a partir dele. Se o buffer ficar cheio, ele come\u00e7a a descartar mensagens. E conta quantas ele descartou. Se os contadores come\u00e7arem a se encher, ficamos sabendo. Os dados chegam tamb\u00e9m ao Prometheus, e os gr\u00e1ficos podem ser visualizados no Grafana. \u00c9 poss\u00edvel configurar alertas. Mas, por enquanto, n\u00e3o est\u00e1 claro para quem envi\u00e1-los.<\/p>\n<\/p>\n
Pergunta<\/strong>: No Elasticsearch, voc\u00eas armazenam logs com redund\u00e2ncia. Quantas r\u00e9plicas voc\u00eas t\u00eam?<\/p>\n<\/p>\n
Resposta<\/strong>: Uma r\u00e9plica.<\/p>\n<\/p>\n
Pergunta<\/strong>: Isso \u00e9 apenas uma r\u00e9plica?<\/p>\n<\/p>\n
Resposta<\/strong>: \u00c9 um mestre e uma r\u00e9plica. Os dados s\u00e3o armazenados em duas inst\u00e2ncias.<\/p>\n<\/p>\n
Pergunta<\/strong>: Voc\u00ea fez algum ajuste no tamanho do buffer do rsyslog? <\/p>\n<\/p>\n
Resposta<\/strong>: Escrevemos datagramas em um socket unix personalizado. Isso imediatamente nos imp\u00f5e um limite de 128 kilobytes. N\u00e3o podemos escrever mais do que isso. Estipulamos isso no padr\u00e3o. Quem quiser entrar nos storages deve escrever 128 kilobytes. As bibliotecas, por sua vez, truncam e marcam a mensagem como truncada. Nosso padr\u00e3o de mensagem possui um campo especial que indica se foi truncada durante a grava\u00e7\u00e3o ou n\u00e3o. Assim, temos a oportunidade de rastrear esse aspecto.<\/p>\n<\/p>\n
Pergunta<\/strong>: Voc\u00ea est\u00e1 escrevendo JSON corrompido? <\/p>\n<\/p>\n
Resposta<\/strong>: JSON corrompido ser\u00e1 descartado durante o relay, porque \u00e9 um pacote muito grande. Ou ser\u00e1 descartado pelo Graylog, pois n\u00e3o poder\u00e1 fazer o parsing do JSON. Mas existem nuances que precisam ser corrigidas, e a maior parte delas est\u00e1 relacionada ao rsyslog. J\u00e1 abri algumas issues l\u00e1 que ainda precisam de trabalho.<\/p>\n<\/p>\n
Pergunta<\/strong>: Por que Kafka? Voc\u00ea j\u00e1 experimentou o RabbitMQ? O Graylog n\u00e3o se ajusta a essas cargas?<\/p>\n<\/p>\n
Resposta<\/strong>: N\u00e3o conseguimos nos conectar com o Graylog. Mas o Graylog funciona para n\u00f3s. \u00c9 realmente problem\u00e1tico. \u00c9 uma coisa peculiar. E, na verdade, n\u00e3o \u00e9 necess\u00e1rio. Eu preferiria escrever diretamente do rsyslog para o Elasticsearch e depois visualizar no Kibana. Mas precisamos resolver essa quest\u00e3o com os seguran\u00e7as. Essa \u00e9 uma poss\u00edvel dire\u00e7\u00e3o para nosso desenvolvimento, quando descartaremos o Graylog e utilizaremos o Kibana. N\u00e3o faria sentido usar o Logstash. Porque eu posso fazer tudo isso com o rsyslog. E ele possui um m\u00f3dulo para grava\u00e7\u00e3o no Elasticsearch. Estamos tentando conviver com o Graylog. At\u00e9 fizemos algumas melhorias. Mas ainda h\u00e1 espa\u00e7o para melhorias.<\/p>\n<\/p>\n
Sobre o Kafka. Assim aconteceu historicamente. Quando cheguei, j\u00e1 existia e j\u00e1 eram registrados logs nele. N\u00f3s apenas configuramos nosso cluster e transferimos os logs para l\u00e1. N\u00f3s o gerenciamos, sabemos como ele est\u00e1. Sobre o RabbitMQ... n\u00e3o estamos indo bem com o RabbitMQ. Mas temos o RabbitMQ funcionando. Ele est\u00e1 em produ\u00e7\u00e3o e tivemos problemas com ele. Agora, antes da liquida\u00e7\u00e3o, ele foi ajustado e come\u00e7ou a funcionar bem. Mas antes disso, eu n\u00e3o estava pronto para coloc\u00e1-lo em produ\u00e7\u00e3o. H\u00e1 ainda outro ponto. O Graylog consegue ler a vers\u00e3o AMQP 0.9, enquanto o rsyslog consegue escrever na vers\u00e3o AMQP 1.0. E n\u00e3o h\u00e1 uma \u00fanica solu\u00e7\u00e3o que consiga fazer as duas coisas. H\u00e1 ou uma coisa ou outra. Portanto, por enquanto, fica somente com Kafka. Mas isso tamb\u00e9m tem suas nuances. Porque o omkafka, na vers\u00e3o do rsyslog que estamos usando, pode perder todo o buffer de mensagens que ele retirou do rsyslog. Por enquanto, estamos lidando com isso. <\/p>\n
<\/p>\n
Pergunta<\/strong>: Voc\u00ea usa o Kafka porque ele j\u00e1 estava a\u00ed? N\u00e3o \u00e9 usado para mais nada?<\/p>\n<\/p>\n
Resposta<\/strong>: O Kafka que existia \u00e9 usado pela equipe de Data Science. \u00c9 um projeto completamente separado, sobre o qual, infelizmente, n\u00e3o posso dizer nada. N\u00e3o estou a par. Ele estava sob a responsabilidade da equipe de Data Science. Quando foram registrados os logs, decidiram utiliz\u00e1-lo para n\u00e3o precisar instalar o seu pr\u00f3prio. Agora, atualizamos o Graylog e perdemos a compatibilidade, porque h\u00e1 uma vers\u00e3o antiga do Kafka. Precisamos configurar o nosso pr\u00f3prio. De quebra, nos livramos desses quatro t\u00f3picos por cada API. Fizemos um t\u00f3pico amplo para todos os ambientes de produ\u00e7\u00e3o, um outro t\u00f3pico amplo para todos os ambientes de testes e apenas jogamos tudo l\u00e1. O Graylog extrai tudo isso em paralelo.<\/p>\n<\/p>\n
Pergunta<\/strong>: Por que essa malandragem com os sockets? Voc\u00eas tentaram usar o driver de log syslog para cont\u00eaineres?<\/p>\n<\/p>\n
Resposta<\/strong>: Na \u00e9poca em que est\u00e1vamos lidando com essa quest\u00e3o, nosso relacionamento com o Docker era tenso. Era o Docker 1.0 ou 0.9. O Docker em si era peculiar. Em segundo lugar, se voc\u00ea ainda tentar inserir logs nele... Tenho uma suspeita n\u00e3o confirmada de que ele passa todos os logs por ele mesmo, atrav\u00e9s do daemon do Docker. Se uma API entra em pane, as outras APIs ficam travadas porque n\u00e3o conseguem enviar stdout e stderr. N\u00e3o sei a que isso levar\u00e1. Tenho uma suspeita intuitiva de que n\u00e3o devemos usar o driver syslog do Docker neste ponto. Nosso departamento de testes funcionais tem seu pr\u00f3prio cluster Graylog com logs. Eles usam os drivers de log do Docker e parece que est\u00e1 tudo funcionando bem. Mas eles escrevem diretamente em Graylog usando GELF. Quando come\u00e7amos tudo isso, precis\u00e1vamos que funcionasse. Pode ser que mais tarde, quando algu\u00e9m disser que j\u00e1 est\u00e1 funcionando bem h\u00e1 muito tempo, possamos tentar de novo.<\/p>\n<\/p>\n
Pergunta<\/strong>: Voc\u00eas fazem a entrega entre data centers usando rsyslog. Por que n\u00e3o usar Kafka?<\/p>\n<\/p>\n
Resposta<\/strong>: Estamos fazendo os dois, na verdade, por duas raz\u00f5es. Se a conex\u00e3o estiver completamente ruim, todos os nossos logs, mesmo compactados, n\u00e3o conseguem passar. E o Kafka permite que eles sejam simplesmente descartados durante o processo. Dessa forma, evitemos o entupimento desses logs. Usamos o Kafka diretamente nesse caso. Se nossa conex\u00e3o estiver boa e quisermos liber\u00e1-la, usamos o rsyslog. Mas na verdade podemos configur\u00e1-lo para que ele mesmo descarte o que n\u00e3o passou. Neste momento, usamos a entrega do rsyslog diretamente em alguns lugares e o Kafka em outros.<\/p>\nFonte: 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
![\"Por](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n