Loki — coleta de logs usando a abordagem Prometheus

Saudações, comunidade Habr! Com a aproximação do início de um novo ciclo do curso «Práticas e Ferramentas DevOps» preparamos para você a tradução de um material interessante.

Este artigo é uma introdução breve ao Loki. O projeto Loki é suportado pela Grafana e é voltado para a coleta centralizada de logs (de servidores ou containers).

A principal fonte de inspiração para o Loki foi Prometheus com a ideia de aplicar suas abordagens na gestão de logs:

  • uso de rótulos (labels) para armazenamento de dados
  • consumo baixo de recursos

Voltaremos aos princípios de funcionamento do Prometheus e apresentaremos alguns exemplos de sua utilização no contexto do Kubernetes.

Algumas palavras sobre o Prometheus

Para entender completamente como o Loki funciona, é importante dar um passo atrás e relembrar o Prometheus.

Uma das características distintivas do Prometheus é a extração de métricas de pontos de coleta (através de exporters) e o armazenamento delas em uma TSDB (Base de Dados de Séries Temporais) com adição de metadados na forma de rótulos.

Por que isso é necessário

Recentemente, o Prometheus se tornou o padrão de fato no mundo dos containers e Kubernetes: sua instalação é muito simples, e em um cluster Kubernetes já existe um endpoint para o Prometheus. O Prometheus também pode extrair métricas de aplicações implantadas em containers, mantendo determinados rótulos. Portanto, o monitoramento de aplicações é muito fácil de implementar.

Infelizmente, ainda não há uma solução “pronta para uso” para gestão de logs, e você deve encontrar uma solução por conta própria:

  • um serviço em nuvem gerenciado para centralização de logs (AWS, Azure ou Google)
  • um serviço de monitoramento «monitoramento como serviço» (monitoring as a service) (como o Datadog)
  • criação do seu próprio serviço de coleta de logs.

Para a terceira opção, eu tradicionalmente utilizei Elasticsearch, embora nem sempre tenha ficado satisfeito com ele (especialmente pela sua pesadez e complexidade na configuração).

O Loki foi projetado com o objetivo de simplificar a implementação de acordo com os seguintes princípios:

  • ser simples para iniciar
  • consumir poucos recursos
  • funcionar de forma independente, sem manutenção especial
  • servir como um complemento ao Prometheus para ajudar na investigação de bugs

No entanto, essa simplicidade é alcançada à custa de alguns compromissos. Um deles é não indexar o conteúdo. Portanto, a pesquisa por texto não é muito eficiente ou rica e não permite estatísticas sobre o conteúdo do texto. Mas como o Loki deseja ser o equivalente ao grep e um complemento ao Prometheus, isso não é uma desvantagem.

Investigação de incidentes

Para entender melhor por que o Loki não precisa de indexação, vamos voltar ao método de investigação de incidentes que os desenvolvedores do Loki usaram:

Loki — coleta de logs usando a abordagem Prometheus
1 Alerta → 2 Painel → 3 Consulta Adhoc → 4 Agregação de Logs → 5 Rastreamento Distribuído → 6 Correção!
(1 Alerta → 2 Painel → 3 Consulta Adhoc → 4 Agregação de Logs → 5 Rastreamento Distribuído → 6 Corrigimos!)

A ideia é que recebemos algum alerta (Notificação Slack, SMS, etc.) e depois:

  • verificamos os painéis do Grafana
  • verificamos as métricas dos serviços (por exemplo, no Prometheus)
  • verificamos os registros de logs (por exemplo, no Elasticsearch)
  • talvez olhemos para as trilhas distribuídas (Jaeger, Zipkin, etc.)
  • e, finalmente, corrigimos o problema original.

Aqui, no caso do stack Grafana + Prometheus + Elasticsearch + Zipkin, precisaríamos usar quatro ferramentas diferentes. Para economizar tempo, seria bom ter a capacidade de executar todas essas etapas usando uma única ferramenta: o Grafana. Vale ressaltar que essa abordagem de investigação foi implementada no Grafana a partir da versão 6. Assim, é possível acessar os dados do Prometheus diretamente do Grafana.

Loki — coleta de logs usando a abordagem Prometheus
A tela Explorer é dividida entre Prometheus e Loki

Nesta tela, é possível visualizar os logs no Loki relacionados às métricas do Prometheus, usando o conceito de divisão de tela. A partir da versão 6.5, o Grafana permite processar o ID de rastreamento (trace id) nas entradas de log do Loki para navegação de links para suas ferramentas de rastreamento distribuído favoritas (Jaeger).

Teste local do Loki

A maneira mais simples de testar o Loki localmente é usar o docker-compose. O arquivo docker-compose está no repositório do Loki. Você pode obter o repositório usando o seguinte comando git:

$ git clone https://github.com/grafana/loki.git

Em seguida, você precisa ir para o diretório de produção:

$ cd production

Depois disso, você pode obter a versão mais recente das imagens Docker:

$ docker-compose pull

Por fim, o stack Loki é iniciado com o seguinte comando:

$ docker-compose up

Arquitetura do Loki

Aqui está um pequeno diagrama com a arquitetura do Loki:

Loki — coleta de logs usando a abordagem Prometheus
Princípios da arquitetura do Loki

O cliente web executa aplicativos no servidor, o Promtail coleta logs e os envia para o Loki, o cliente web também envia metadados para o Loki. O Loki agrega tudo e envia para o Grafana.
O Loki está em execução. Para visualizar os componentes existentes, execute o seguinte comando:

$ docker ps

Em uma instalação nova do Docker, o comando deve retornar o seguinte resultado:

IMAGE               PORTS                  NAMES
grafana/promtail:                          production_promtail_1
grafana/grafana: m  0.0.0.0:3000->3000/tcp production_grafana_1
grafana/loki: late  80/tcp,0.0.0.0:3100... production_loki_1

Vemos os seguintes componentes:

  • Promtail: agente responsável pela centralização dos logs
  • Grafana: ferramenta famosa para painéis de controle
  • Loki: daemon de centralização de dados

Em uma infraestrutura clássica (por exemplo, baseada em máquinas virtuais), deve haver um agente Promtail implantado em cada máquina. O Grafana e o Loki podem ser instalados em uma única máquina.

Implantação no Kubernetes

A instalação dos componentes do Loki no Kubernetes consistirá em:

  • daemonSet para implantar o agente Promtail em cada uma das máquinas do cluster de servidores
  • implantação (Deployment) do Loki
  • e por último — a implantação do Grafana.

Felizmente, o Loki está disponível como um pacote Helm, o que facilita sua implantação.

Instalação via Heml

O Heml já deve estar instalado em seu sistema. Ele pode ser baixado do repositório do GitHub do projeto. É instalado descompactando o arquivo correspondente à sua arquitetura e adicionando helm ao $PATH.

Nota: a versão 3.0.0 do Helm foi lançada recentemente. Como houve muitas mudanças, é aconselhável ao leitor esperar um pouco antes de começar a usá-la..

Adicionando fonte para Helm

O primeiro passo é adicionar o repositório “loki” com o seguinte comando:

$ helm add loki https://grafana.github.io/loki/charts

Depois disso, você pode procurar pacotes com o nome “loki”:

$ helm search loki

Resultado:

loki/loki       0.17.2 v0.4.0 Loki: como o Prometheus, mas para logs.
loki/loki-stack 0.19.1 v0.4.0 Loki: como o Prometheus, mas para logs.
loki/fluent-bit 0.0.2  v0.0.1 Usa o plugin go fluent-bit para...
loki/promtail   0.13.1 v0.4.0 Responsável por coletar logs e...

Esses pacotes têm as seguintes funções:

  • pacote loki/loki refere-se apenas ao servidor Loki
  • pacote loki/fluent-bit permite implantar o DaemonSet, usando fluent-bit para coletar logs em vez do Promtail
  • pacote loki/promtail contém o agente de coleta de logs
  • pacote loki/loki-stack, permite implantar o Loki junto com o Promtail.

Instalação do Loki

Para implantar o Loki no Kubernetes, execute o seguinte comando no namespace “monitoring”:

$ helm upgrade --install loki loki/loki-stack --namespace monitoring

Para salvar no disco, adicione o parâmetro --set loki.persistence.enabled=true:

$ helm upgrade --install loki loki/loki-stack 
              --namespace monitoring 
              --set loki.persistence.enabled=true

Nota: se você deseja implantar o Grafana ao mesmo tempo, adicione o parâmetro --set grafana.enabled=true

Ao executar este comando, você deve obter a seguinte saída:

ÚLTIMA IMPLANTAÇÃO: Ter Nov 19 15:56:54 2019
NOME DO ESPAÇO: monitoring
STATUS: IMPLANTADO
RECURSOS:
==> v1/ClusterRole
NOME IDADE
loki-promtail-clusterrole 189d
…
NOTAS:
A pilha Loki foi implantada no seu cluster. Loki agora pode ser adicionado como uma fonte de dados no Grafana.
Veja <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> para mais detalhes.

Observando o estado dos pods no namespace “monitoring”, veremos que tudo foi implantado:

$ kubectl -n monitoring get pods -l release=loki

Resultado:

NOME                PRONTO  STATUS    REINICIOS  IDADE
loki-0              1/1    Em execução  0         147m
loki-promtail-9zjvc  1/1    Em execução  0         3h25m
loki-promtail-f6brf  1/1    Em execução  0         11h
loki-promtail-hdcj7  1/1    Em execução  0         3h23m
loki-promtail-jbqhc  1/1    Em execução  0         11h
loki-promtail-mj642  1/1    Em execução  0         62m
loki-promtail-nm64g  1/1    Em execução  0         24m

Todos os pods estão em execução. Agora é hora de fazer alguns testes!

Conectando ao Grafana

Para se conectar ao Grafana no Kubernetes, você precisa abrir um túnel para seu pod. Veja abaixo o comando para abrir a porta 3000 para o pod Grafana:

$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80

Outro ponto importante é a necessidade de recuperar a senha do administrador do Grafana. A senha está armazenada no segredo loki-grafana no campo .data.admin-user em formato base64.

Para recuperá-la, execute o seguinte comando:

$ kubectl -n monitoring get secret loki-grafana 
 --template '{{index .data "admin-password" | base64decode}}'; echo

Use esta senha juntamente com a conta de administrador padrão (admin).

Definindo a fonte de dados Loki no Grafana

Antes de tudo, certifique-se de que a fonte de dados Loki foi criada (Configuração / Fonte de Dados).
Aqui está um exemplo:

Loki — coleta de logs usando a abordagem Prometheus
Exemplo de configuração da fonte de dados para Loki

Ao clicar em “Testar”, você pode verificar a conexão com o Loki.

Fazendo consultas ao Loki

Agora vá para o Grafana na seção “Explorar”. Ao receber logs dos contêineres, o Loki adiciona metadados do Kubernetes. Assim, é possível visualizar os logs de um contêiner específico.

Por exemplo, para selecionar os logs do contêiner promtail, você pode usar a seguinte consulta: {container_name = "promtail"}.
Aqui, não esqueça de selecionar a fonte de dados Loki.

Essa consulta retornará a atividade dos contêineres da seguinte forma:

Loki — coleta de logs usando a abordagem Prometheus
Resultado da consulta no Grafana

Adicionando ao painel

A partir do Grafana 6.4, é possível colocar informações sobre logs diretamente no painel. Depois disso, o usuário poderá alternar rapidamente entre a quantidade de consultas em seu site e os rastreamentos do aplicativo.

Abaixo está um exemplo de dashboard que implementa essa interação:

Loki — coleta de logs usando a abordagem Prometheus
Exemplo de dashboard com métricas do Prometheus e logs do Loki

O futuro do Loki

Comecei a usar o Loki em maio / junho com a versão 0.1. Hoje já foi lançada a versão 1, e até mesmo a 1.1 e 1.2.

Devo admitir que a versão 0.1 não era suficientemente estável. Mas a 0.3 já mostrou sinais reais de maturidade, e as próximas versões (0.4, então 1.0) apenas reforçaram essa impressão.

Após a versão 1.0.0, ninguém pode mais ter desculpas para não usar essa ferramenta incrível.

Melhorias futuras devem se concentrar não no Loki, mas sim na sua integração com a excelente Grafana. Na verdade, a Grafana 6.4 já trouxe uma boa integração com dashboards.

A Grafana 6.5, que foi lançada recentemente, aprimora ainda mais essa integração, reconhecendo automaticamente o conteúdo dos logs no formato JSON.

Abaixo, no vídeo, há um pequeno exemplo desse mecanismo:

Loki — coleta de logs usando a abordagem Prometheus
Uso de strings do Loki exibidas na Grafana

Torna-se possível usar um dos campos JSON, por exemplo, para:

  • link para uma ferramenta externa
  • filtragem do conteúdo dos logs

Por exemplo, você pode clicar no traceId para ir ao Zipkin ou Jaeger.

Tradicionalmente, aguardamos seus comentários e convidamos você para o webinar aberto, onde falaremos sobre como a indústria de DevOps evoluiu durante 2019 e discutiremos possíveis caminhos de desenvolvimento para 2020.

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster