React: observabilidade, manutenção e produção em aplicações

Entendendo observabilidade - Apresentação

Apresentando o instrutor e o curso

Olá! Meu nome é Vinícius Neves e irei acompanhar vocês ao longo deste curso sobre observabilidade.

Audiodescrição: Vinícius é um homem branco, com cabelo curto castanho e barba. Ele veste uma camisa azul e está em um ambiente de escritório com uma parede clara ao fundo.

Explorando a tela do Datadog

Neste curso, vamos explorar a tela do Datadog para entender como traces (rastreamentos), logs (registros) e métricas se conectam. Aprenderemos o que são esses elementos, os pontos de atenção, e como implementá-los no Datadog.

Veremos, por exemplo, alertas em funcionamento, como receber um e-mail quando o número de logs de erro aumentar significativamente. Vamos começar a entender métricas, como as requisições, a latência, o tempo de resposta, o número de erros, entre outras formas de análise.

Focando na alarmística e tecnologias relacionadas

O ponto principal será o foco na alarmística, utilizando Datadog e Node.js. É importante que estejamos atualizados com Next.js e React, pois algumas alterações serão feitas no código dessas tecnologias, embora não estejam diretamente relacionadas ao Datadog.

No projeto base, vamos apenas adicionar observabilidade. Há muitas peculiaridades que encontraremos ao longo do caminho, tornando o processo interessante, pois se trata de um projeto real. Propositalmente, ele está mais antigo para simular situações comuns do dia a dia, como quando executamos o npm install e surgem mensagens de erro ou de aviso.

Destacando o uso do Datadog e alternativas

Nosso foco será em observabilidade, e é importante destacar que estamos utilizando o Datadog, uma das ferramentas mais populares. No entanto, também exploraremos algumas alternativas, incluindo opções open source (código aberto). Muito do conteúdo será agnóstico de plataforma, mas quando formos implementar no código, utilizaremos o Datadog.

Espero que todos estejam tão animados quanto nós. Já estamos aguardando na próxima aula e não sairemos daqui. Vamos em frente!

Entendendo observabilidade - Os 3 pilares da observabilidade

Discutindo os pilares da observabilidade

Para compreendermos a fundo o tema da observabilidade, antes de implementarmos, precisamos entender o que é e para que serve. Por isso, vamos discutir os três pilares da observabilidade. Qual é o ponto principal? A ideia de monitorar é diferente da ideia de observar. Monitorar envolve ativamente olhar para algo, mas será que conseguimos extrair dados valiosos e obter as informações necessárias no momento certo?

Vamos desmistificar e esclarecer a diferença entre monitorar e observar. Quando falamos de monitoramento, estamos verificando, por exemplo, se o servidor está funcionando. Fazemos um check para ver se o servidor está ativo, geralmente chamando esse endpoint de health check. Se o servidor está funcionando, ele responde com um código 200; caso contrário, responde de outra forma. Essa resposta binária é o monitoramento.

Explorando a diferença entre monitoramento e observabilidade

A observabilidade, por outro lado, permite identificar problemas mais complexos, como a lentidão do sistema às duas horas da tarde. Podemos investigar e entender onde está o gargalo e a causa raiz dessa lentidão. Enquanto o monitoramento nos diz que algo está quebrado, a observabilidade nos explica por que isso aconteceu. A observabilidade consiste em fazer perguntas arbitrárias sobre o sistema sem precisar saber previamente o que perguntar. Precisamos ter essa capacidade para entender, por exemplo, o que estava acontecendo no sistema às duas horas da sexta-feira 13, quando ocorreu um incidente.

Na rotina de desenvolvimento, o uso de console.log não é escalável. Funciona em nossa máquina, terminal ou navegador durante o desenvolvimento, mas em produção, com várias máquinas, para onde vão esses logs? No contexto do front-end, como acessamos os logs do navegador? Qual é o contexto, o usuário, a versão utilizada e a ação realizada? Se o log não está estruturado, como filtramos? Como sabemos se um log específico está relacionado à requisição que estamos analisando?

Exemplificando logs estruturados e não estruturados

Para ilustrar, vejamos um exemplo simples de um log não estruturado:

console.log('Erro ao criar usuario')

Esse log nos informa que houve um erro ao criar um usuário, mas não nos dá detalhes suficientes. Precisamos saber mais: qual usuário? Qual erro? Quando? Em qual servidor?

console.log('Erro ao criar usuario')
//Qual usuário? Qual erro? Quando? Em qual servidor?

Resumindo, apenas usar console.log não funciona em produção. Ele ajuda no desenvolvimento ou correção de funcionalidades, mas em produção não é eficaz. Se registramos um erro ao criar um usuário, precisamos saber qual usuário, quando, em qual momento, rotina ou servidor. Precisamos de mais dados: o que aconteceu, o timestamp, o JSON estruturado, os parâmetros utilizados na requisição. Isso auxilia no debug e na auditoria, garantindo conformidade com as regras da empresa.

Um exemplo de log estruturado seria:

{
  "timestamp": "2024-01-15T14:30:00Z",
  "level": "error",
  "message": "Failed to create user",
  "userID": "usr_123",
  "error": "duplicate email",
  "requestID": "req_abc"
}

Discutindo a importância dos logs e métricas

Devemos ter cuidado para não exagerar na quantidade de logs. Um volume excessivo de logs pode ser problemático, pois escala com a quantidade de usuários. Devemos seguir boas práticas. O log é um dos principais pilares da observabilidade, funcionando como a caixa-preta de um avião, registrando tudo o que acontece, mas é preciso saber onde procurar.

O segundo pilar são as métricas, que medem a saúde do sistema. Métricas são volumes agregados ao longo do tempo, como número de erros, sucessos, consumo de CPU, entre outros. Elas são mais leves e baratas de armazenar do que os logs. Podemos disparar alertas com base no que está acontecendo. Por exemplo, se aceitamos uma taxa de erro de até x erros por hora, e esse número for excedido, podemos emitir um alerta. No entanto, métricas não oferecem contexto individual, pois tratam de uma agregação de informações.

Explicando o conceito de trace

Diferente do log, que é específico, a métrica agrega informações. As métricas funcionam como o painel do nosso carro: vemos a velocidade média, mas não observamos o que está acontecendo no pedal. Por exemplo, alguns tipos de métricas incluem:

• http_requests_total -> Counter (só sobe)
• cpu_usage_percent -> Gauge (sobe e desce)
• request_duration_seconds -> Histogram (distribuição)

Para fechar nosso outro pilar, o trace, qual é o conceito? A ideia é rastrear uma requisição desde quando ela sai do lado do cliente até chegar ao banco de dados, por exemplo. Se estamos falando de inserir um dado no banco de dados, devemos ser capazes de acompanhar esse fluxo. Se quisermos depurar um problema em que uma pessoa usuária específica está tendo um erro ao tentar cadastrar um produto, devemos conseguir filtrar essa request para entender quais são os logs e tudo que está relacionado àquela mesma requisição. Devemos ter algo em comum para traçar, para conseguirmos fazer o próprio trace e entender o que aconteceu de ponta a ponta. Vamos filtrar todos os logs, todas as informações, tudo que está relacionado àquela requisição específica. Ela fará todo o caminho desde quando sai do cliente até chegar à ponta final, seja um banco de dados ou outro serviço. Se consumirmos múltiplos serviços, esse trace nos guiará por todo o caminho, deixando uma trilha de informações para entendermos o que está acontecendo.

Comparando a analogia do trace com o rastreamento de pedidos

Se voltarmos à nossa analogia, é como se tivéssemos um rastreamento de um pedido. Conseguimos ver cada etapa, da mesma forma que quando compramos um produto que vem de outro país. Ele será despachado, enviado, passará pela alfândega, sairá da alfândega, até chegar em trânsito e finalmente a nós. A ideia do trace é semelhante. Podemos ver que do front-end até chegar ao API Gateway está tudo certo, mas houve um atraso no serviço de autenticação. Assim, conseguimos identificar onde está o gargalo. Podemos entender e observar uma requisição de ponta a ponta, dar um passo para trás e ter uma visão macro do que está acontecendo para seguir o fluxo específico que desejamos. Assim, fechamos nosso terceiro pilar.

Integrando os três pilares da observabilidade

Ao trazer os três pilares juntos, podemos começar a ter a habilidade de responder a perguntas que nem sabemos quais são. Já discutimos isso. Qual é o nosso cenário? A API está lenta. O que faremos? Vamos olhar para as métricas. A latência aumentou. Vamos verificar os traces para entender o que está acontecendo. O gargalo está no banco de dados. A parte da requisição que está chegando ao banco de dados está demorando quase dois segundos. Vamos aos logs. Os logs indicarão qual é a query específica que está demorando tanto. Assim, os três pilares trabalham juntos. Não adianta tê-los separados para este cenário específico; devemos usá-los em conjunto.

Destacando a importância da observabilidade em incidentes

Se não tivermos observabilidade, pagamos um preço por isso. Existem alguns incidentes que podemos compartilhar. O GitLab, por exemplo, em 2017, ficou seis horas fora do ar. O GitHub Flare, em 2019, ficou 27 minutos fora do ar. O Facebook, em 2021, ficou seis horas fora do ar. Quando temos um cenário em que essas aplicações não podem parar, precisamos de observabilidade. Precisamos saber o que está acontecendo, pois o custo de downtime é quando o serviço está inativo, não respondendo. O custo médio de downtime é de 5.600 dólares por minuto, segundo informações disponíveis. É muito caro ficar parado. Precisamos de observabilidade não para se algo acontecer, mas para quando algo acontecer, podermos reagir rapidamente.

Analisando respostas específicas de cada pilar

Precisamos entender qual resposta cada pilar oferece. Vamos discutir algumas situações. Quantas requisições tivemos hoje? Métrica. Estamos agregando números. Por que a pessoa usuária X teve erro 500? Log. Vamos verificar e entender qual foi o payload enviado e o que estava acontecendo naquele momento. O checkout está lento. Trace. Precisamos olhar de ponta a ponta para identificar onde está o gargalo. Será o banco de dados? Será o gateway? Onde está o gargalo? O que mudou antes do incidente? Logs. Às vezes, queremos entender se um servidor reiniciou ou se uma nova versão foi publicada. Vamos aos logs para reconstruir os eventos passo a passo na linha do tempo. Cada pilar tem uma função muito específica.

Entendendo observabilidade - Anatomia de um Incidente

Discutindo a anatomia de um incidente

Agora podemos começar a discutir a anatomia de um incidente. Os três pilares que mencionamos até agora serão a base para nossa observabilidade. Quando algo dá errado, precisamos estar suficientemente maduros para corrigir o problema em produção.

Por exemplo, a latência da API está em 5 segundos. Recebemos uma mensagem no Slack informando que um determinado endpoint está lento. Usuários começaram a reclamar no Twitter sobre a lentidão do serviço. O gerente de produto questiona qual é o impacto, e o CTO da empresa pergunta quanto tempo levará para resolver. O que fazemos? Ainda não sabemos o que está acontecendo.

Explorando a falta de observabilidade

Se não temos observabilidade, o que faremos? Vamos acessar o servidor via terminal e usar o comando tail para tentar abrir os logs e procurar por erros. Veja como podemos fazer isso:

tail -f /var/log/app.log | grep error

No entanto, mesmo com esse comando, podemos não encontrar nada. Reiniciaremos o servidor na esperança de que o problema se resolva, mas, se resolver, não saberemos o motivo. Como fica essa situação? Gastamos duas horas para resolver, não entendemos o que ocorreu, e, por não sabermos, provavelmente acontecerá novamente. Isso gera caos. Sem observabilidade, há caos.

Demonstrando a eficácia da observabilidade

Por outro lado, se temos observabilidade, temos método. A investigação será estruturada. No mesmo cenário, com a latência aumentando às 5h30, vamos às métricas e descobrimos que a latência p99 está em 5.2 segundos desde 17:30:

Latência p99 = 5.2s
desde 17:30

Isolamos o serviço e descobrimos qual endpoint está mais lento. Por exemplo, o endpoint /api/posts está 10 vezes mais lento:

Endpoint /api/posts
está 10x mais lento

Identificando e corrigindo a causa raiz

Sabendo qual é o endpoint problemático, vamos entender em qual momento isso ocorre. Realizamos o trace e descobrimos que há uma query que está consumindo quase 5 segundos:

Span prisma query = 
4.8s

O problema está no banco de dados. Vamos verificar qual é a query que está rodando. Descobrimos que há um SELECT sem o WHERE, causando um problema de N+1:

SELECT * FROM
posts sem WHERE -
N+1

Teremos mais momentos para discutir esse N+1. No final, desenvolvemos a correção, publicamos e validamos nas métricas se o problema foi resolvido. Levamos 20 minutos para resolver, e a causa raiz era uma query com problema de N+1, após um deploy realizado às 5h15. Realizar deploy às 5h15, é algo a se considerar.

Comparando caos e método na resolução de incidentes

Perceba que, enquanto há caos sem observabilidade, com ações aleatórias para entender o que está acontecendo, com observabilidade, temos um método e uma investigação estruturada. Sabemos onde e por que olhar. É um cenário muito mais controlado.

Explicando siglas e conceitos relacionados a incidentes

Quando um incidente acontece, há uma série de siglas relacionadas que queremos compartilhar. A primeira é MTTD, que significa Mean Time To Detect (Tempo Médio para Detectar), ou seja, quanto tempo levamos para perceber que o problema existe.

O MTTR, que é o Mean Time To Recovery (Tempo Médio para Recuperação), envolve dois aspectos principais: o tempo que levamos para perceber o problema e o tempo que levamos para resolvê-lo. O Blaze Radius refere-se a quantos usuários ou funcionalidades foram impactados. A Severity (Gravidade) indica o quão grave foi o problema, sendo classificada em níveis: nível 1, nível 2 e nível 3. No final, temos o Post Mortem, que ocorre após a detecção e resolução do problema. Nesse momento, paramos para analisar a causa do problema. O objetivo do Post Mortem não é apontar culpados, mas sim aprender para evitar que o problema ocorra novamente.

Discutindo SLI, SLO e Orçamento de Erro

Além disso, temos os conceitos de SLI, SLO e Orçamento de Erro. O SLI (Service Level Indicator) é a métrica que medimos, por exemplo, a porcentagem de requisições com latência menor que 500 milissegundos. Temos um valor fixo que aceitamos como aceitável, e se ultrapassarmos esse valor, temos um problema. O SLO (Service Level Objective) é o objetivo que queremos atingir em relação a essa métrica, como 99,9% das requisições com latência menor que 500 milissegundos. O Orçamento de Erro define quanto podemos falhar sem comprometer o SLO. Por exemplo, se temos um uptime de 99,9%, isso significa que temos 8,7 horas de downtime permitidas ao longo do ano. Esse é um compromisso para operações críticas, e precisamos nos comprometer com o que conseguimos entregar.

Implementando melhorias após um incidente

Para alcançar esse nível de excelência, precisamos trabalhar para isso e ter um processo de mitigação de erros bem configurado. O Post Mortem é uma cerimônia para aprender com o que aconteceu, não para procurar culpados. Queremos entender como o problema ocorreu, não quem errou. Após essa análise, documentamos o ocorrido, montamos a linha do tempo, identificamos a causa raiz e definimos ações para evitar que o problema se repita. Compartilhamos essas informações com as equipes e criamos tarefas para implementar melhorias.

Exemplificando um incidente e suas resoluções

Vamos trazer um exemplo: um incidente de API lenta ocorrido em 15 de janeiro de 2024. Identificamos o impacto, a consulta que causou o problema e as ações para evitar que isso aconteça novamente. No final, definimos ações como adicionar um índice na tabela de postagens, criar um alerta e documentar o padrão de recarregamento. Também definimos responsáveis por essas ações para garantir que sejam realizadas.

Sobre o curso React: observabilidade, manutenção e produção em aplicações

O curso React: observabilidade, manutenção e produção em aplicações possui 187 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de React em Front-end, ou leia nossos artigos de Front-end.

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

• Entendendo observabilidade
• Logs e boas práticas
• Dominando instrumentação
• Conhecendo tracing
• Simulando um incidente