{"id":93294,"date":"2020-09-05T07:42:58","date_gmt":"2020-09-05T05:42:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi"},"modified":"2020-09-05T07:42:58","modified_gmt":"2020-09-05T05:42:58","slug":"logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","title":{"rendered":"Registro de logs no Kubernetes: como coletar, armazenar, analisar e processar logs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vamos discutir os fundamentos da coleta de logs no Docker e Kubernetes, e em seguida, examinaremos duas ferramentas que podem ser utilizadas em produ\u00e7\u00e3o: Grafana Loki e o stack EFK (Elasticsearch + Fluent Bit + Kibana).<\/p>\n

<\/p>\n

O conte\u00fado deste artigo \u00e9 um resumo de uma aula aberta da escola \"Slurm\"<\/a><\/noindex>. Se houver interesse e, principalmente, necessidade de produ\u00e7\u00e3o, \u00e9 poss\u00edvel fazer um curso completo \u2014 inscreva-se no curso sobre Monitoramento e Logging de Infraestrutura no Kubernetes<\/a><\/noindex>.<\/em><\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/a><\/noindex><\/p>\n

Logging no Docker<\/h2>\n

<\/p>\n

No n\u00edvel do Kubernetes, os aplicativos s\u00e3o executados em pods, mas no n\u00edvel inferior, geralmente funcionam no Docker. Portanto, \u00e9 necess\u00e1rio configurar a coleta de logs de modo a capturar os logs dos cont\u00eaineres. Os cont\u00eaineres s\u00e3o iniciados pelo Docker \u2014 ent\u00e3o precisamos entender como a coleta de logs funciona no n\u00edvel do Docker.<\/p>\n

<\/p>\n

Espero que cada leitor saiba: os logs do aplicativo devem ser escritos em stdout\/stderr, e n\u00e3o dentro do cont\u00eainer. O Docker Daemon agrega os logs e trabalha apenas com aqueles que s\u00e3o enviados para stdout\/stderr. Al\u00e9m disso, gravar logs dentro do cont\u00eainer pode causar problemas: o cont\u00eainer incha com o log crescente (j\u00e1 que provavelmente n\u00e3o h\u00e1 nenhum Logrotate dentro do cont\u00eainer), e o Docker Daemon n\u00e3o est\u00e1 ciente desse log.<\/p>\n

<\/p>\n

O Docker possui v\u00e1rios drivers de log ou plugins para coleta de logs de cont\u00eaineres. Na vers\u00e3o gratuita Docker Community Edition (CE), h\u00e1 menos drivers de log do que na vers\u00e3o comercial Docker Enterprise Edition (EE).<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Nunca utilizei o Docker EE na pr\u00e1tica: na Southbridge, nos esfor\u00e7amos para aderir a solu\u00e7\u00f5es Open Source, e para a maioria dos clientes, as funcionalidades adicionais do Docker EE n\u00e3o s\u00e3o necess\u00e1rias. <\/p>\n

<\/p>\n

Drivers de log no Docker CE:<\/p>\n

<\/p>\n

local<\/strong> \u2014 grava\u00e7\u00e3o de logs em arquivos internos do Docker Daemon;
\njson-file<\/strong> \u2014 cria\u00e7\u00e3o de json-log na pasta de cada cont\u00eainer;
\njournald<\/strong> \u2014 envio de logs para o journald.<\/p>\n

<\/p>\n

As configura\u00e7\u00f5es de logging no Docker est\u00e3o no arquivo daemon.json. <\/p>\n

<\/p>\n

No campo \"log-driver\", especifica-se o plugin, e no campo \"log-opts\" \u2014 suas configura\u00e7\u00f5es. No exemplo acima, o plugin \"json-file\" \u00e9 especificado, com o limite de tamanho do log \u2014 \"max-size\": \"10m\"; limite de arquivos (configura\u00e7\u00f5es de rota\u00e7\u00e3o) \u2014 \"max-file\": \"3\"; assim como os valores que ser\u00e3o anexados aos logs.<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Algumas configura\u00e7\u00f5es do driver de log podem ser definidas atrav\u00e9s da ferramenta de linha de comando. Isso \u00e9 conveniente se um cont\u00eainer espec\u00edfico precisa ser iniciado com um driver de log diferente. <\/p>\n

<\/p>\n

Assim \u00e9 como o esquema de logging no Docker se apresenta:<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Como o esquema funciona: o driver de log, por exemplo o json-file, cria arquivos. Os coletores de logs (Rsyslog, Fluentd, Logagent e outros) re\u00fanem esses arquivos e os enviam para armazenamento no Elastic, Sematext ou outros reposit\u00f3rios.<\/p>\n

<\/p>\n

Caracter\u00edsticas da coleta de logs no Kubernetes<\/h2>\n

<\/p>\n

Simplificadamente, o esquema de coleta de logs no Kubernetes parece assim: h\u00e1 um pod, dentro do qual um cont\u00eainer est\u00e1 rodando, e o cont\u00eainer envia logs para stdout\/stderr. Em seguida, o Docker cria um arquivo e grava os logs, que podem ser rotacionados depois.<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Vamos considerar as caracter\u00edsticas da coleta de logs no Kubernetes.<\/p>\n

<\/p>\n

Manter logs entre implanta\u00e7\u00f5es<\/strong>. Esta \u00e9 uma condi\u00e7\u00e3o obrigat\u00f3ria para a configura\u00e7\u00e3o correta do registro. Se n\u00e3o houver a preserva\u00e7\u00e3o dos logs entre os deployments, ao lan\u00e7ar uma nova vers\u00e3o do aplicativo, os logs anteriores ser\u00e3o sobrescritos, e a reinicializa\u00e7\u00e3o do cont\u00eainer tamb\u00e9m pode resultar na perda dos logs. O Kubernetes possui a chave —previous, que permite visualizar os logs do aplicativo antes da \u00faltima reinicializa\u00e7\u00e3o do Pod, mas n\u00e3o mais profundo.<\/p>\n

<\/p>\n

Agregar logs de todas as inst\u00e2ncias<\/strong>. Se os microsservi\u00e7os est\u00e3o hospedados em nuvens, o provedor de nuvem \u00e9 respons\u00e1vel pelo controle do sistema. Se os microsservi\u00e7os est\u00e3o no seu pr\u00f3prio hardware, al\u00e9m dos logs dos cont\u00eaineres, \u00e9 necess\u00e1rio coletar tamb\u00e9m os logs do sistema.<\/p>\n

<\/p>\n

Antes, n\u00e3o havia ferramentas convenientes para coletar logs tanto do sistema quanto dos microsservi\u00e7os. Normalmente, uma ferramenta coletava logs do sistema (por exemplo, Rsyslog), enquanto outra coletava logs do Docker (por exemplo, journal-bit com a configura\u00e7\u00e3o do driver de log do Docker no journald). Tentaram usar o journal-bit para coletar logs tanto dos cont\u00eaineres (indicando no driver de log do Docker que os logs deveriam ser gravados no journald) quanto do sistema (no CentOS 7 j\u00e1 existem systemd e journald). A solu\u00e7\u00e3o funciona, mas n\u00e3o \u00e9 ideal. Se houver muitos logs, o journal-bit come\u00e7a a apresentar lentid\u00e3o e as mensagens se perdem.<\/p>\n

<\/p>\n

As experi\u00eancias continuaram \u2014 e uma outra solu\u00e7\u00e3o foi encontrada. No CentOS 7, os principais logs do sistema (messages, audit, secure) s\u00e3o duplicados no var-log na forma de arquivos. No Docker, tamb\u00e9m \u00e9 poss\u00edvel configurar a grava\u00e7\u00e3o de logs em arquivos json. Portanto, esses arquivos do CentOS 7 e do Docker podem ser coletados juntos.<\/p>\n

<\/p>\n

Com o tempo, a solu\u00e7\u00e3o ELK Stack se tornou popular. \u00c9 uma combina\u00e7\u00e3o de v\u00e1rias ferramentas: Elasticsearch, Logstash e Kibana.<\/p>\n

<\/p>\n

O Elasticsearch armazena os logs dos cont\u00eaineres, o Logstash coleta logs das inst\u00e2ncias, e o Kibana permite processar os logs recebidos e construir gr\u00e1ficos a partir deles. Durante algum tempo, o ELK Stack foi amplamente utilizado, mas, na minha opini\u00e3o, seu tempo est\u00e1 passando. Mais adiante explicarei por qu\u00ea.<\/p>\n

<\/p>\n

Adicionar metadados<\/strong>. Pods, aplicativos e cont\u00eaineres podem ser executados em qualquer lugar. Al\u00e9m disso, um \u00fanico aplicativo pode ter v\u00e1rias inst\u00e2ncias. Os logs s\u00e3o registrados em um formato \u00fanico, e precisamos entender qual r\u00e9plica espec\u00edfica est\u00e1 registrando, qual Pod isso est\u00e1 escrevendo e em qual namespace est\u00e1 localizado. \u00c9 por isso que os logs devem incluir metadados.<\/p>\n

<\/p>\n

Analisar logs<\/strong>. Curiosamente, os custos de manuten\u00e7\u00e3o de um sistema de logging e monitoramento podem superar os custos do aplicativo principal. Quando voc\u00ea tem dezenas ou at\u00e9 centenas de milhares de logs por segundo, isso parece l\u00f3gico, mas ainda assim \u00e9 importante saber onde est\u00e1 o limite. Uma das formas de encontrar esse limite \u00e9 atrav\u00e9s da an\u00e1lise de logs. <\/p>\n

<\/p>\n

Normalmente, voc\u00ea n\u00e3o precisa coletar e armazenar todos os logs; deve enviar para armazenamento apenas uma parte \u2014 por exemplo, logs com status 'warning' ou 'error'. No caso de logs de nginx ou de controladores de ingress, \u00e9 poss\u00edvel enviar para armazenamento apenas aqueles cujo status \u00e9 diferente de 200. Mas essa n\u00e3o \u00e9 uma orienta\u00e7\u00e3o universal: se voc\u00ea estiver construindo algum tipo de an\u00e1lise de logs do Nginx, est\u00e1 claro que deve colet\u00e1-los. <\/p>\n

<\/p>\n

N\u00e3o \u00e9 recomend\u00e1vel filtrar os logs sem pensar, pois os dados filtrados podem ser insuficientes para uma an\u00e1lise adequada. Por outro lado, talvez seja melhor conduzir a an\u00e1lise n\u00e3o no n\u00edvel de logging, mas sim no n\u00edvel de coleta de m\u00e9tricas. Assim, voc\u00ea n\u00e3o ter\u00e1 que armazenar centenas de milhares de linhas com o c\u00f3digo 200. Uma das abordagens \u00e9 obter informa\u00e7\u00f5es sobre o tr\u00e1fego e os erros a partir das m\u00e9tricas dos controladores de ingress. <\/p>\n

<\/p>\n

No geral, \u00e9 necess\u00e1rio refletir bem sobre o que voc\u00ea deseja armazenar e por quanto tempo, pois, caso contr\u00e1rio, voc\u00ea poder\u00e1 enfrentar uma situa\u00e7\u00e3o em que o sistema de logging consome mais recursos do que o projeto principal.<\/p>\n

<\/p>\n

Ainda n\u00e3o h\u00e1 uma solu\u00e7\u00e3o padr\u00e3o para logging<\/strong>. Ao contr\u00e1rio do monitoramento, onde existe uma solu\u00e7\u00e3o predominante, o Prometheus, no logging n\u00e3o h\u00e1 um padr\u00e3o estabelecido. <\/p>\n

<\/p>\n

Neste semin\u00e1rio, vamos abordar duas ferramentas: uma popular e a outra em ascens\u00e3o. Existem outras, mas n\u00e3o vamos cobri-las neste artigo.<\/p>\n

<\/p>\n

Considerando todas as caracter\u00edsticas discutidas anteriormente, o logging no Kubernetes agora pode ser representado no seguinte diagrama:<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Resta o log do cont\u00eainer, a rota\u00e7\u00e3o, mas surge um agente-coletor que recolhe os logs e os envia para armazenamento (no diagrama \u2014 para o Logging Backend). O agente opera em cada n\u00f3 e, geralmente, \u00e9 executado no Kubernetes.<\/p>\n

<\/p>\n

Agora vamos discutir as ferramentas de log.<\/p>\n

<\/p>\n

Grafana Loki<\/h2>\n

<\/p>\n

Grafana Loki<\/a><\/noindex> apareceu recentemente, mas j\u00e1 se tornou bastante conhecido. Suas vantagens: instala\u00e7\u00e3o f\u00e1cil, baixo consumo de recursos, n\u00e3o requer a instala\u00e7\u00e3o do Elasticsearch, pois armazena os dados em TSDB (banco de dados de s\u00e9ries temporais). No artigo anterior, mencionei que o Prometheus armazena dados em tal banco, e essa \u00e9 uma das muitas semelhan\u00e7as entre os dois produtos. Os desenvolvedores afirmam at\u00e9 que o Loki \u00e9 o \"Prometheus para o mundo da l\u00f3gica\".<\/p>\n

<\/p>\n

Uma breve digress\u00e3o sobre TSDB para aqueles que n\u00e3o leram artigo anterior<\/a><\/noindex>: TSDB lida muito bem com o armazenamento de grandes quantidades de dados de s\u00e9ries temporais, mas n\u00e3o \u00e9 feita para armazenamento prolongado. Se por algum motivo voc\u00ea precisar armazenar logs por mais de duas semanas, \u00e9 melhor configurar a transmiss\u00e3o deles para outro banco de dados.<\/p>\n

<\/p>\n

Outra vantagem do Loki \u00e9 que a visualiza\u00e7\u00e3o dos dados \u00e9 feita atrav\u00e9s do Grafana. \u00c9 muito conveniente: no Grafana, visualizamos os dados de monitoramento e l\u00e1 mesmo, conectando o Loki, visualizamos os logs. Gr\u00e1ficos podem ser constru\u00eddos com base nos logs.<\/p>\n

<\/p>\n

A arquitetura do Loki parece aproximadamente assim: <\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Usando DaemonSet, um agente \u2014 Promtail ou Fluent Bit \u2014 \u00e9 implantado em todos os servidores do cluster. O agente coleta os logs. O Loki os busca e armazena em sua TSDB. Metadados s\u00e3o imediatamente adicionados aos logs, o que \u00e9 conveniente: \u00e9 poss\u00edvel filtrar por Pods, namespaces, nomes de cont\u00eaineres e at\u00e9 mesmo r\u00f3tulos.<\/p>\n

<\/p>\n

Instru\u00e7\u00f5es para a instala\u00e7\u00e3o do Loki<\/a><\/noindex><\/p>\n

<\/p>\n

O Loki funciona na interface familiar do Grafana. O Loki at\u00e9 tem sua pr\u00f3pria linguagem de consultas, chamada LogQL \u2014 que, pelo nome e pela sintaxe, lembra o PromQL do Prometheus. Na interface do Loki, h\u00e1 sugest\u00f5es de consultas, portanto, n\u00e3o \u00e9 necess\u00e1rio memoriz\u00e1-las.<\/p>\n

<\/p>\n

Documenta\u00e7\u00e3o para a linguagem LogQL<\/a><\/noindex><\/p>\n

<\/p>\n

\"Registro
\nLoki na interface do Grafana<\/em><\/p>\n

<\/p>\n

Usando filtros, \u00e9 poss\u00edvel encontrar c\u00f3digos no Loki (\"400\", \"404\" e qualquer outro); verificar logs de todo o n\u00f3; filtrar todos os logs que cont\u00eam a palavra \"error\". Se voc\u00ea clicar em um log, uma ficha com todas as informa\u00e7\u00f5es do evento ser\u00e1 revelada.<\/p>\n

<\/p>\n

O Loki possui ferramentas suficientes para permitir a extra\u00e7\u00e3o dos logs necess\u00e1rios, embora, sinceramente, tecnicamente poderiam haver mais. Atualmente, o Loki est\u00e1 em desenvolvimento ativo e ganhando popularidade. <\/p>\n

<\/p>\n

Elastic + Fluent Bit + Kibana (Stack EFK)<\/h2>\n

<\/p>\n

O stack EFK \u00e9 uma ferramenta de log mais cl\u00e1ssica e, ao mesmo tempo, n\u00e3o menos popular. <\/p>\n

<\/p>\n

No in\u00edcio do artigo, mencionamos o ELK (Elasticsearch + Logstash + Kibana), mas esse stack se tornou obsoleto devido ao Logstash, que consome muitos recursos e \u00e9 pouco eficiente. Em vez disso, come\u00e7aram a usar o mais leve e eficiente Fluentd, e depois de um tempo, ele recebeu a ajuda de Fluent Bit<\/a><\/noindex> \u2014 um agente de coleta ainda mais leve e ainda mais eficiente. <\/p>\n

<\/p>\n

Se os desenvolvedores estiverem certos, o Fluent Bit \u00e9 mais de 100 vezes mais eficiente do que o Fluentd: \"onde o Fluentd consome 20 MB de RAM, o Fluent Bit consome 150 KB\" \u2014 cita\u00e7\u00e3o direta da documenta\u00e7\u00e3o. Olhando para isso, o Fluent Bit passou a ser usado com mais frequ\u00eancia.<\/p>\n

<\/p>\n

O Fluent Bit tem menos funcionalidades do que o Fluentd, mas atende \u00e0s necessidades b\u00e1sicas, por isso usamos principalmente o Fluent Bit.<\/p>\n

<\/p>\n

O esquema de trabalho do stack EFK: o agente coleta logs de todos os pods (geralmente, \u00e9 um DaemonSet executado em todos os servidores do cluster) e os envia para o armazenamento (Elasticsearch, PostgreSQL ou Kafka). O Kibana se conecta ao armazenamento e extrai todas as informa\u00e7\u00f5es necess\u00e1rias.<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> Ele apresenta as informa\u00e7\u00f5es em uma interface web conveniente. H\u00e1 gr\u00e1ficos, filtros e muito mais.<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

Com os logs, \u00e9 poss\u00edvel criar pain\u00e9is completos.<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

As funcionalidades do Fluent Bit<\/h2>\n

<\/p>\n

Como o Fluent Bit, em geral, \u00e9 menos conhecido do que o Logstash, vamos analis\u00e1-lo com um pouco mais de detalhe. O Fluent Bit pode ser logicamente dividido em 6 m\u00f3dulos, e alguns desses m\u00f3dulos podem ter plugins que ampliam suas capacidades.<\/p>\n

<\/p>\n

\"Registro<\/p>\n

<\/p>\n

M\u00f3dulo Input<\/strong> coleta logs de arquivos, servi\u00e7os systemd e at\u00e9 mesmo de tcp-socket (basta indicar o endpoint, e o Fluent Bit come\u00e7ar\u00e1 a acess\u00e1-lo). Essas capacidades s\u00e3o suficientes para coletar logs tanto do sistema quanto dos cont\u00eaineres.<\/p>\n

<\/p>\n

Em produ\u00e7\u00e3o, usamos com mais frequ\u00eancia os plugins tail<\/a><\/noindex> (pode ser direcionado para uma pasta de logs) e systemd<\/a><\/noindex> (pode-se especificar de quais servi\u00e7os coletar logs).<\/p>\n

<\/p>\n

M\u00f3dulo Parser<\/strong> normaliza os logs. Por padr\u00e3o, os logs do Nginx s\u00e3o representados como uma linha. Com um plugin, \u00e9 poss\u00edvel transformar essa linha em JSON: definir campos e seus valores. Trabalhar com JSON \u00e9 muito mais f\u00e1cil do que com logs em formato de string, pois oferece op\u00e7\u00f5es de ordena\u00e7\u00e3o mais flex\u00edveis.<\/p>\n

<\/p>\n

M\u00f3dulo Filter<\/strong>. Nesse n\u00edvel, logs desnecess\u00e1rios s\u00e3o filtrados. Por exemplo, apenas logs com o valor \"warning\" ou com certos r\u00f3tulos s\u00e3o enviados para armazenamento. Os logs filtrados v\u00e3o para o buffer.<\/p>\n

<\/p>\n

M\u00f3dulo Buffer<\/strong>. O Fluent Bit possui dois tipos de buffer: buffer de mem\u00f3ria e buffer em disco. O buffer \u00e9 um armazenamento tempor\u00e1rio de logs, necess\u00e1rio em caso de erros ou falhas. Todos querem economizar em RAM, portanto, normalmente optam pelo buffer em disco. Mas \u00e9 preciso considerar que, antes de ir para o disco, os logs ainda s\u00e3o descarregados na mem\u00f3ria.<\/p>\n

<\/p>\n

M\u00f3dulo Routing\/Output<\/strong> cont\u00e9m regras e endere\u00e7os para o envio de logs. Como j\u00e1 foi mencionado, os logs podem ser enviados para Elasticsearch, PostgreSQL ou, por exemplo, Kafka. <\/p>\n

<\/p>\n

Curiosamente, os logs do Fluent Bit podem ser enviados para o Fluentd. Como o primeiro \u00e9 mais leve e menos funcional, \u00e9 poss\u00edvel coletar logs e envi\u00e1-los para Fluentd, onde, com a ajuda de plugins adicionais, podem ser processados e enviados para armazenamento.<\/p>\n

<\/p>\n

Se voc\u00ea planeja usar Elasticsearch\u2026<\/p>\n

Por fim, duas dicas para aqueles que pretendem usar Elasticsearch como armazenamento de logs em produ\u00e7\u00e3o. <\/p>\n

    \n
  1. Configure alertas usando ElastAlert<\/a><\/noindex>. Este programa extrai mensagens importantes do fluxo geral de logs e gera alertas por email ou em outro canal. No entanto, recentemente saiu uma not\u00edcia triste de que o projeto pode em breve deixar de existir.<\/a><\/noindex><\/em>.<\/li>\n
  2. Gire logs usando o aplicativo Curator<\/a><\/noindex> ou chamando a API do Elasticsearch. O pr\u00f3prio Elastic, na verdade, est\u00e1 tomando medidas significativas para gerenciar o ciclo de vida dos \u00edndices sem precisar de ferramentas de terceiros. No geral, n\u00e3o faz sentido manter logs por muito tempo: \u00e9 pouco prov\u00e1vel que algum log seja necess\u00e1rio ap\u00f3s duas semanas \u2014 se for realmente cr\u00edtico, em duas semanas ter\u00e1 sido resolvido. Como \u00faltimo recurso, logs antigos podem ser arquivados e enviados para um armazenamento de longo prazo. Ouvi falar de logs espec\u00edficos que, por lei, devem ser mantidos por at\u00e9 5 anos. Pessoalmente, nunca me deparei com isso, mas eu n\u00e3o classificaria essas informa\u00e7\u00f5es como logs comuns e, possivelmente, at\u00e9 os armazenaria separadamente.<\/li>\n<\/ol>\n

    \n<\/p><\/blockquote>\n

    Continua\u2026<\/p>\n

    <\/p>\n

    Autor: Marcel Ibraev, administrador Kubernetes certificado, engenheiro pr\u00e1tico na empresa Southbridge<\/a><\/noindex>, palestrante e desenvolvedor de cursos Slurm<\/a><\/noindex>.<\/em><\/p>\n

    Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana). \u041c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u0432\u044b\u0436\u0438\u043c\u043a\u0430 \u0438\u0437 \u043e\u0442\u043a\u0440\u044b\u0442\u043e\u0439 \u043b\u0435\u043a\u0446\u0438\u0438 \u0448\u043a\u043e\u043b\u044b \u00ab\u0421\u043b\u0451\u0440\u043c\u00bb. \u0415\u0441\u043b\u0438 \u0435\u0441\u0442\u044c \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u0438 \u0442\u0435\u043c \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u044c \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u043e\u043b\u043d\u043e\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u2014 \u0437\u0430\u043f\u0438\u0441\u044b\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043d\u0430 \u043a\u0443\u0440\u0441 \u043f\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93295,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Loga\u00e7\u00e3o em Kubernetes: como coletar, armazenar, analisar e processar logs | ProHoster","description":"Vamos abordar os fundamentos da loga\u00e7\u00e3o em Docker e Kubernetes, e depois analisaremos duas ferramentas que podem ser usadas com seguran\u00e7a em produ\u00e7\u00e3o: Grafana Loki e a pilha EFK (Elasticsearch + Fluent Bit + Kibana)..","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043a\u0430\u043a \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c, \u0445\u0440\u0430\u043d\u0438\u0442\u044c, \u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u043b\u043e\u0433\u0438 | ProHoster","og:description":"\u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana)..","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-05T05:42:58+00:00","article:modified_time":"2020-09-05T05:42:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"93294","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:50:29","updated":"2022-09-27 18:43:48","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/93294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=93294"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/93294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/93295"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=93294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=93294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=93294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}