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:
Este conteúdo se destina para pessoas de:
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.
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.
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:
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.
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.
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.
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!
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!
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 psVoltando 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 upApó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.PostgreSQLDialectNo 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 -nltpEm seguida, incluiremos | grep 8080, sendo a porta que a aplicação está rodando.
ss -nltp | grep 8080Conseguimos 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 -dApós esse rodar esse comando, vai aparecer a seguinte mensagem:
Starting database-api-cursos ... doneIsso 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/cursosO 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!
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:
Impulsione a sua carreira com os melhores cursos e faça parte da maior comunidade tech.
1 ano de Alura
Assine o PLUS e garanta:
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
No Discord, você tem acesso a eventos exclusivos, grupos de estudos e mentorias com especialistas de diferentes áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Acelere o seu aprendizado com a IA da Alura e prepare-se para o mercado internacional.
1 ano de Alura
Todos os benefícios do PLUS e mais vantagens exclusivas:
Luri é nossa inteligência artificial que tira dúvidas, dá exemplos práticos, corrige exercícios e ajuda a mergulhar ainda mais durante as aulas. Você pode conversar com a Luri até 100 mensagens por semana.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Transforme a sua jornada com benefícios exclusivos e evolua ainda mais na sua carreira.
1 ano de Alura
Todos os benefícios do PRO e mais vantagens exclusivas:
Mensagens ilimitadas para estudar com a Luri, a IA da Alura, disponível 24hs para tirar suas dúvidas, dar exemplos práticos, corrigir exercícios e impulsionar seus estudos.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.