Confiabilidade: centralizando logs com Grafana Loki

O problema da informação perdida - Apresentação

Boas-vindas ao Curso de Confiabilidade: Centralizando logs com Grafana Loki. Eu sou o Kleber Costa, instrutor na plataforma Alura.

Nesta aula de introdução, vamos entender a motivação do curso, o que agrega para a sua carreira. Primeiro, analisaremos o sumário:

Sumário

Aplicabilidade
Requisitos
Ementa do curso
O problema da Informação Perdida
Compliance - Normas e processos de SI
Decisões baseadas em dados
Diagrama com ambiente do curso
Considerações finais

Aplicabilidade

Este conteúdo se destina para pessoas de:

Desenvolvimento
DevOps
SRE
Operações de infraestrutura
QA
Segurança

Se estiver em outro estágio da sua carreira, como um Tech Lead ou PO, este curso também é relevante para você. Caso esteja ingressando no mercado e deseja entrar em alguma dessas áreas mencionadas, esse conteúdo vai agregar bastante nessa trajetória. Isso porque o conteúdo é fundamental no ramo de desenvolvimento.

Requisitos

Conceitos básicos de Java
Conceitos básicos de Maven
Conceitos básicos de Spring Boot
Conhecimentos básicos em Docker
Conhecimentos básicos em Docker Compose

Os pré-requisitos são: saber os conceitos da linguagem Java, de Maven - que está relacionado ao Java - e do Spring Boot, o que é e quais os benefícios no desenvolvimento. Conhecimentos básicos em Docker também, como executar um container. Além disso, noções básicas em Docker Compose, toda stack do curso está conteinerizada em uma stack gerenciada por essa ferramenta.

Ementa do curso

O problema da informação perdida
Centralização de logs estruturados
Trabalhando com Grafana Loki
Consultas com linguagem LogQL
Construindo alertas e tratando incidentes

Cada tópico da ementa está relacionado a uma aula, sendo o assunto tratado em determinado capítulo. Lembrando que você já deve ter noções sobre o Grafana Loki, usaremos a linguagem LogQL - sendo a linguagem nativa dessa ferramenta.

No item "O problema da informação perdida", vamos debater sobre o que ocorre com a informação e qual a sua importância para o ciclo de vida de uma aplicação e para o negócio. Também organizaremos a infraestrutura que vai executar a aplicação e fazer os ajustes para que ela seja executada dentro da stack.

No tópico de "Centralização de logs estruturados", tratamos a estruturação do log em um modelo adequado para o Grafana Loki. Realizando toda a parte de infraestrutura que torna possível a agregação do log no Grafana Loki, para subir essa stack.

Na aula "Trabalhando com Grafana Loki", vamos provisionar o Grafana Loki, entender os conceitos de utilização e tirar valor da ferramenta. Na quarta aula, em "Consultas com linguagem LogQL", aprenderemos a realizar consulta performática, para lidarmos com operadores, por exemplo. Isto é, usar a linguagem de consulta LogQL - semelhante ao PromQL.

Por fim, na parte "Construindo alertas e tratando incidentes" criaremos um cenário em que vai ocorrer um incidente. Vamos configurar um alerta para esse incidente e validar a funcionalidade do alerta.

Vamos ver um pouco sobre o assunto da primeira aula:

O problema da informação perdida

O planejamento de arquiteturas com baixo acoplamento em cenários de microsserviços conta "nativamente" com recursos de escalonamento horizontal.
Cenários complexos como estes dependem de um local padronizado para centralizar e disponibilizar informações que desapareceriam em processos de scale-out.

Atualmente, ao planejar uma arquitetura de baixo acoplamento - que usamos serviços de Cloud - analisamos em como podemos ter o melhor custo benefício. Logicamente, acabamos indo para um cenário em que vamos distribuir a aplicação e ela vai escalonar.

Ao lidarmos com microsserviços, vamos pensar em escalonamento horizontal. Isto é, replicas da sua instância computacional, do seu container que vai executar e possuir responsabilidade sobre o seu produto.

Quando nos referimos a escalonamento horizontal, já precisamos considerar que teremos um período em que vamos ter um aumento do pico, conforme ele for diminuindo e entrarmos no estado de normalidade, ocorre um scale-out no ambiente.

Com isso, entendemos que cada réplica da aplicação vai ter os próprios eventos, um consumo balanceado para ele. Consequentemente, esses eventos gerados pelo consumo, produzirão registros - logs. Se não estruturarmos esses logs em um componente centralizador, perdemos a informação.

Em suma, esse é o problema da informação perdida. Quando começamos a planejar esse ambiente, em um cenário de microsserviços, já consideramos isso. Dessa forma, podemos concluir que todos os cenários complexos dependem de um local padronizado para fazer a centralização e a disponibilização dessas informações.

O primeiro ponto é: precisamos agrupar os logs em um ambiente centralizado. Todo registro é importante. Não podemos, também, ter dificuldade em acessar essas informações. Como, por exemplo, precisar acessar o ambiente de produção para verificar um comportamento anômalo. Isso enquanto o cliente está consumindo o produto.

Esse é o primeiro problema que trataremos na primeira aula.

Compliance - Normas e processos de SI

Informação centralizada
Acesso à informação sem acesso à produção
Controle de acesso
Mascaramento de dados sensíveis
Processos auditáveis
Security Information and Event Management (SIEM)

Além do benefício de um ambiente centralizado com as informações, acabamos ficando de acordo com algumas normas e processos de segurança da informação - Compliance.

Isso porque temos a informação centralizada, temos acesso ao dado sem precisar entrar no ambiente de produção. Às vezes para acessar o ambiente de produção é necessário ter permissão, por estar sobre uma governança. Ou seja, não é apenas rodar um comando para entrar nesse ambiente.

Assim, não temos esse problema e colocamos os registros em um local centralizado. Esse local, não está competindo com a sua produção, você pode acessá-lo sem solicitar permissão. Isso acontece, consequentemente, ao ter um controle de acesso.

Logo, quem administra a ferramenta de centralização de logs, possui um controle de acesso e ele permite que a pessoa visualize uma informação. É possível definir quem pode visualizar e qual dado.

Além disso, nesse cenário, sabemos que teremos uma plataforma que vai disponibilizar o acesso facilitado aos registros dos eventos que ocorreram para o log. Por isso, precisamos considerar, por padrão, no mascaramento de dados sensíveis. Porque esses dados estarão expostos na plataforma.

Mesmo que o indivíduo tenha permissão para visualizar determinado dado, não possui para informações pessoais. É um ponto interessante, dado que somos forçados a resolver esse problema no começo.

Dessa forma, facilita os processos de auditoria. Quando temos uma auditoria já consegue exibir como a informação é tratada e qual o período de retenção, provando que possui os registros - logs.

Assim, se adequa para o uso de ferramentas, como o SIEM - Security Information and Event Management (em português, “Informações de segurança e gerenciamento de eventos”). Este trabalha com uma correlação de dados, para detectar anomalias comportamentais por problemas de segurança no sistema.

Agora vamos para outra vantagem.

Decisões baseadas em dados

A centralização de logs permite também o benefício de análise e tomada de decisões baseadas em dados. Estes processos são possíveis através de agregação e correlação de informações geradas por eventos registrados, como logs e métricas.

A partir do momento em que fazemos a agregação da informação, é possível usar recursos que possuem uma inteligência própria. Trabalham com a correlação desses dados, podendo gerar informações úteis para o negócio na parte de estratégia.

A centralização de logs, vai nos dar esse benefício de trabalhar com dados. Isso porque já temos a agregação de eventos da aplicação. É interessante, porque nessa parte, conseguimos obter para a área de negócios informações baseadas no comportamento do usuário.

Diagrama com ambiente do curso

Vamos mencionar agora o diagrama do ambiente do curso, entender como é a infraestrutura que suporta este curso.

Temos uma API construída em Spring, que usa como Back-end um Postgres. Tanto que a API do início do curso, ainda faremos alterações nela e vamos conteinerizá-la.

O Postgres já está conteinerizado, ao longo do curso vamos provisionar um cliente sintético - sendo um container - que vai consumir a API como se fosse um usuário. Ou seja, vai cometer erros de autenticação e consulta e vai conseguir realizar algumas ações também.

No decorrer do curso também subiremos o Grafana, ele que já consegue coletar métricas por padrão, nesta aplicação. Porque essa ferramenta já possui o micrometer e o actuator, portanto já exibe as métricas de consumo e o Grafana possui acesso a esses dados.

Já temos um Dashboard que tem um template que será importado, isso já dá uma melhor visibilidade para a aplicação. Porém, ainda teremos o trabalho de subir o Grafana Loki e o Alertmanager e realizar o processo de centralização de logs.

Isso visualizando os eventos, entendendo como utilizamos a linguagem LogQL, trabalhando com os alertas - na camada do Alertmanager - e comunicando com o cliente externo. Esse é o diagrama do curso, toda essa stack sobe em Docker.

Por isso, é importante você já ter conhecimentos básicos de Docker e Docker Compose. Principalmente se utilizar o sistema macOS, existem algumas mudanças na composição do Docker Compose, que difere do sistema Linux. Além disso, é preciso ter uma IDE de desenvolvimento, recomendo o Eclipse.

Faremos pequenas alterações na aplicação, mas nada que atrapalhe. Mesmo se não entender sobre Java, não tem problema, visto que mexeremos em arquivos de configuração em .xml.

Essa jornada é uma sequência do curso anterior de instrumentação de logs, em que faremos algumas adequações para pensar no processo de produção. Como tratamos esse log se levássemos para a produção: quais as alterações necessárias e qual a melhor forma de agregar valor usando o Grafana Loki como a solução de centralização e agregação de logs.

Neste vídeo era isso que queria passar para você, obrigado por ter me acompanhado. Até a próxima aula!

O problema da informação perdida - Importando o projeto

Bem-vindos(as) ao curso de Centralizando logs com Grafana Loki, nesta aula vamos configurar o ambiente. Após você baixar os arquivos .zip da aula, chamado de grafana-loki.zip, já vai ter toda a infraestrutura necessária. Ao realizar o download do pacote, descompactar e clicar na pasta grafana-loki, você vai ter os diretórios: logs, postgres e docker-compose.yml.

O diretório logs é o que possui a aplicação Spring. O postgres, que clicando nele, temos a pasta db, com um arquivo .sh dentro de inicialização. Podemos clicar e analisar o código, só não vamos alterar nada. Esse script é executado quando o container sobe para realizar as configurações no banco de dados.

Voltando para a pasta grafana-loki, clicaremos no arquivo docker-compose.yml. Nele temos as configurações necessárias para subirmos o banco de dados. Este banco de dados realiza um bind na porta 5432 TCP da sua máquina.

Se você tiver alguma configuração de segurança, que impossibilite a conexão nessa porta, é preciso ajustar esse detalhe. O container vai rodar na porta 5432. Porém, vai espelhar essa comunicação na 5432 da sua máquina hospedeira. Em suma, esse script é basicamente um container rodando um banco de dados PostgreSQL.

Entendendo a composição deste pacote, você deve importar o projeto para a IDE que está usando. No meu caso, é o Eclipse, você pode usar uma de sua preferência. Porém, é necessário que você saiba importar um projeto nela e lidar com as dependências da IDE.

No Eclipse, o processo de import é simples. No canto superior esquerdo, clicaremos em "File", vai abrir um menu e nele selecionamos "Import". Na tela que vai ser exibida de import, vamos expandir a pasta "Maven" e selecionar a opção "Existing Maven Projects" (em português, "Projetos Maven existentes").

Em seguida, clicaremos no botão azul "Next", na parte inferior central da tela. Na próxima tela, com o título "Import Maven Projects", selecionamos o botão "Browse" do lado direito superior. Na tela de Browse, clicaremos duas vezes com o botão esquerdo no mouse no diretório grafana-loki e depois, no logs.

Clicando em logs, em que há um arquivo que vai ser categorizado pelo Eclipse como arquivo de projeto Maven. Selecionaremos o botão azul "Open", do lado direito superior da tela. Vai retornar para a página "Import Maven Projects", note que em "Projects" ele identifica através do pom.xml, vamos selecionar essa opção e clicar no botão "Next".

Após realizar esse passo a passo, o projeto vai estar no Eclipse do lado esquerdo da tela em "Package Explorer". Com isso, já temos a infraestrutura necessária para seguirmos com o curso.

Obrigado por me acompanhar nesta aula. Até mais!

O problema da informação perdida - Subindo a API

Nesta aula vamos começar a trabalhar na aplicação. No Eclipse, do lado esquerdo da tela em "Package Explorer", clicaremos na pasta logs do projeto, para expandir. Em seguida, selecionaremos a pasta src/main/java, depois a br.com.alura.logs. Nesta vai ter um arquivo chamado de CursoApplication.java, clicaremos nele.

O arquivo CursoApplication.java é a classe principal da aplicação, vamos validar para subi-la. Para isso, abriremos o terminal para executar o comando docker container ps, isso para analisarmos se temos o container da aplicação rodando. Não está, podemos prosseguir. Esse container é o do banco de dados e não da aplicação.

docker container ps

Voltando para o Eclipse, selecionaremos o botão "▶" no menu na parte superior da tela, para subir. Assim, vamos nos deparar com o primeiro problema dessa aplicação. Na aba na parte inferior, em "Console", note que retornou um erro: "Error creating bean name 'entityManagerFactory' defined in class path resource...".

Isso significa que a aplicação já possui um log formatado em JSON. O log está sendo exibido no Stand Out Put, no stdout. Lembrando que esse projeto foi tratado no curso anterior, foi instrumentado e teve a camada de logs configuradas.

Porém, chegou neste curso com alguns problemas propositais. A primeira dificuldade é que a aplicação não sobe sem o banco de dados. Isso é um problema, visto que em um momento de indisponibilidade do banco de dados, a aplicação vai parar completamente.

Vamos supor que tentamos executar o comando deploy em algum momento em que o banco de dados está indisponível, por algum motivo. O comando simplesmente não será executado. Esse é o primeiro ponto que precisamos corrigir.

Portanto, a aplicação acabou não subindo devido a esse erro. Para reparar esse problema, vamos à pasta src/main/resources, nela clicaremos no arquivo application.properties, sendo a pasta que possui as propriedades da aplicação.

Analisando o arquivo de propriedades, percebemos que ele possui as configurações de DSN, de conexão com o Postgres. Para validarmos que o problema é o container, no terminal, estou um nível acima do nosso projeto e executaremos o comando ls. Note que temos um arquivo chamado de docker-compose.yml.

Em docker-compose.yml temos a configuração para subir o container, para isso vamos rodar o comando docker-compose up. Pode demorar um pouco, dado que ele precisa baixar todas as dependências, para subir o Postgres.

Isto é, vai construir o container ainda, por ter algumas customizações. Vai adicionar um layer (camada) a mais.

docker-compose up

Após aguardar um pouco, ao subir já está disponível para conexões. Com isso, podemos voltar para o Eclipse para rodar a aplicação novamente, dentro do arquivo CursoApplication.java, clicando no botão "▶" na parte superior da tela. No console, conseguimos observar que a aplicação subiu.

Dessa forma, está comprovado que temos uma dependência sobre o container. Podemos clicar no botão "🟥", na parte superior esquerda do console, para parar a aplicação. Em seguida, no botão com dois xis ("X"), a terceira opção no menu superior do console também, para limpar os logs. No terminal, podemos parar o container também.

Se tentarmos subir novamente, clicando no botão "▶", vai gerar o mesmo erro que tivemos anteriormente. Em suma, não é possível rodar a aplicação.

Voltando para o arquivo application.properties, temos as configurações que possuem uma propriedade dispensável na linha 7, que podemos remover: spring.jpa.hibernate.ddl - auto-update. Essa propriedade realiza uma atualização na base de dados ao subir a aplicação. Agora, vamos incluir a seguinte propriedade:

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

No terminal, com o container derrubado, executaremos o comando docker container ps. Isso para analisarmos se não temos nenhum container rodando, note que não temos. Porém, fizemos essa inclusão na aplicação e vamos subi-la novamente, clicando no botão "▶". Isso sem um container rodando, isto é, com o banco de dados indisponível.

No console do Eclipse, conseguimos visualizar que a aplicação subiu. Constam os campos: timestamp, o level como "INFO", o thread, o logger, o message e o context. Deste modo, solucionamos o primeiro problema.

No terminal, rodaremos o comando ss -nltp, para procurarmos pela porta. O ss é um comando que verifica a relação de processos, portas, etc que esteja aberto na sua máquina. Isso para o sistema Linux, no Windows é outro comando.

O n é para trazer somente dados que não tenham resolução de nomes, o l é para portas em estado listen, o t é o protocolo TCP e o p, o número do processo.

ss -nltp

Em seguida, incluiremos | grep 8080, sendo a porta que a aplicação está rodando.

ss -nltp | grep 8080

Conseguimos visualizar a porta no arquivo application.properties, na primeira linha, em server.port=8080. Com a aplicação rodando, vamos pará-la clicando no botão "🟥" na parte superior no console. Em seguida, no terminal, subiremos o banco de dados com o comando docker-compose up -d.

docker-compose up -d

Após esse rodar esse comando, vai aparecer a seguinte mensagem:

Starting database-api-cursos ... done

Isso significa que o container foi startado. Se procurarmos pela porta do serviço, executando novamente o comando ss -nltp | grep 8080, ele não está disponível. Voltando para o Eclipse, subiremos de novo a aplicação, clicando no botão "▶".

No console, após aguardar alguns minutos, conseguimos subir a aplicação e no terminal, vamos rodar mais uma vez o comando ss -nltp | grep 8080. É exibida a porta 8080, na cor vermelha, no estado listen, com a aplicação disponível.

Como validamos que a aplicação está, de fato, rodando? No browse, no campo da URL digitaremos "localhost:8080/cursos".

localhost:8080/cursos

O seu retorno pode conter informações que diferem do meu. Você não vai ter os IDs, mais para frente criaremos um cliente sintético que vai realizar essas inserções.

Assim, finalizamos essa aula, concluímos o primeiro passo de configurações do ambiente. Te espero na próxima aula, até mais!

Sobre o curso Confiabilidade: centralizando logs com Grafana Loki

O curso Confiabilidade: centralizando logs com Grafana Loki possui 267 minutos de vídeos, em um total de 46 atividades. Gostou? Conheça nossos outros cursos de Confiabilidade em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

O problema da informação perdida
Subindo a stack de logs
Configurando o Grafana Loki
Centralização de Logs
Aprofundando na linguagem LogQL
Integração de dashboard e alertas com Grafana