Datadog: observabilidade, troubleshooting e monitoramento inteligente

Métricas: Performance e Personalização - Apresentação

Apresentando a instrutora e audiodescrevendo o cenário

Olá! Eu sou a Agnes Huescas e vou te acompanhar durante toda a nossa jornada. Eu sou instrutora da Alura e engenheira de dados. Já atuei em outras áreas, como desenvolvimento de software (programas) e DevOps (Desenvolvimento e Operações), e trabalho com temas de automação, monitoramento e dados.

Audiodescrição: Sou uma mulher branca, de cabelos castanhos, uso óculos e visto uma blusa laranja. Ao fundo, está o estúdio da Alura, com uma prateleira à minha esquerda, algumas plantas e luzes. Estou olhando diretamente para a câmera.

Definindo os objetivos do curso

Neste curso, nós vamos avançar no uso do Datadog, pensando principalmente em como transformar os dados que coletamos em informações úteis para acompanhar e investigar nossas aplicações.

Nós vamos trabalhar em um cenário de e-commerce (comércio eletrônico) e evoluir nossa estratégia de observabilidade. Vamos iniciar criando métricas personalizadas; adicionaremos tags (etiquetas) para fornecer mais contexto. Durante o processo, também iremos avançar com logs (registros).

Detalhando atividades práticas no Datadog

Nós desenvolveremos um pipeline (fluxo de dados) no Datadog, estruturaremos os dados e configuraremos facets (facetas) para facilitar buscas.

Também correlacionaremos métricas com logs, realizaremos uma investigação e evoluiremos para um troubleshooting (diagnóstico de problemas), de forma efetiva.

Estabelecendo estratégias de monitoramento e pré-requisitos

Vamos transformar nossos indicadores em monitors (monitores), utilizando thresholds (limiares), warnings (avisos), alertas e notificações. Vamos entender estratégias mais adequadas para nosso monitoramento e como diminuir o ruído dos nossos monitors (monitores).

Como este curso é uma continuidade, é importante que você já tenha conhecimentos básicos de Datadog e esteja familiarizado com os principais conceitos de monitoramento e observabilidade. Aqui, nosso foco é avançar para um cenário de análise, investigação e monitoramento estratégico.

Concluindo expectativas e convidando para começar

Ao final do curso, teremos construído uma estratégia completa com métricas, logs, alertas e recursos inteligentes que trabalham conosco para aumentar a visibilidade da nossa aplicação e apoiar a investigação de incidentes.

Temos bastante conteúdo para explorar. Vamos começar?

Métricas: Performance e Personalização - Do problema ao indicador

Apresentando o percurso do problema ao indicador

Olá.

Vamos abordar o percurso do problema ao indicador.

Definindo o problema e identificando o sinal

Antes de entrarmos no Datadog e consultarmos todas as métricas disponíveis, é fundamental entender qual problema queremos resolver. Precisamos esclarecer o que realmente desejamos monitorar. Não adianta acessarmos o Datadog, observarmos diversas métricas e construirmos um dashboard (painel) com todas elas. Antes disso, devemos definir o problema que estamos tentando resolver.

Imaginemos um cenário em que temos um e-commerce (comércio eletrônico) e queremos monitorar quando começamos a ter erros ou quando algo passa a afetar o processamento. Em vez de simplesmente coletarmos várias métricas e monitorá-las, precisamos primeiro identificar qual é o sinal desse comportamento. Um bom indicador está diretamente relacionado ao problema que pretendemos resolver.

Poderíamos, por exemplo, acompanhar o consumo de CPU (unidade central de processamento) da aplicação. Essa informação pode ser útil, mas, isoladamente, não indica necessariamente que estamos enfrentando problemas com os pedidos. Se queremos entender o processamento desses pedidos, um sinal mais adequado é a quantidade de pedidos que apresentam erro durante o processamento. Nesse caso, há uma relação clara entre o que estamos medindo e o problema que desejamos identificar.

Sempre que possível, devemos escolher sinais que nos permitam perceber mudanças com impacto mais direto e interpretá-las antes que esse impacto se torne maior.

Especificando a medição e as dimensões

Depois de escolher o sinal, precisamos definir o que será medido. Não basta afirmar que queremos monitorar erros. Precisamos especificar qual valor registraremos, com que frequência e qual será a unidade dessa informação. No exemplo, podemos acompanhar a quantidade de pedidos que apresentaram erros durante o processamento em um determinado período.

Também precisamos pensar na dimensão que pode ajudar a interpretar esse resultado.

Queremos saber em qual serviço, ambiente ou versão da aplicação esse comportamento ocorreu. Essas informações vão nos ajudar a dar contexto para nossa métrica.

Validando o indicador e resumindo o raciocínio

Existe uma pergunta muito importante para validar se escolhemos um indicador útil: se esse valor mudar, o que faremos? Se percebermos um aumento significativo na quantidade de pedidos com erro, por exemplo, sabemos que existe a necessidade de investigarmos o que está acontecendo. Esse indicador não existe apenas para gerar um gráfico; ele está relacionado a decisões que podem direcionar nossa ação.

Podemos resumir esse raciocínio da seguinte maneira: partimos de um problema, escolhemos o sinal relacionado a ele, definimos qual será a dimensão, como esse impacto será medido e verificamos se ele pode nos ajudar a tomar uma decisão efetiva.

Representando o indicador como métrica customizada

Agora que já sabemos o que queremos observar, precisamos pensar em como representar esse indicador. Uma métrica customizada pode traduzir o comportamento que é importante para nosso cenário. Para isso, precisamos de alguns elementos:

• Um nome claro, que represente e permita identificar a métrica.
• Um valor numérico que queremos registrar.
• Um timestamp (carimbo de data e hora) que indique o período em que a medição ocorreu.
• Tags (etiquetas) consistentes para adicionar contexto e permitir a análise do comportamento a partir de diferentes dimensões.

Aplicando ao exemplo e encaminhando os próximos passos

No nosso exemplo, queremos representar os erros que acontecem durante o processamento de pedidos. Já temos o plano definido e sabemos qual comportamento queremos transformar em métrica. Até aqui, partimos de um problema e chegamos ao indicador que faz sentido para nosso cenário. Esse é um passo muito importante para evitarmos que o monitoramento seja apenas uma coleção de métricas sem objetivo definido.

Agora, precisamos transformar esse indicador em algo que realmente consigamos acompanhar. No próximo vídeo, vamos entrar no Datadog e criar métricas customizadas para representar esse comportamento na prática.

Te vejo lá!

Métricas: Performance e Personalização - Criando uma métrica customizada

Apresentando o objetivo do vídeo

Olá.

No vídeo anterior, partimos de um problema e definimos um indicador que queremos acompanhar: quantos erros são gerados durante os nossos processamentos de pedidos. Agora, vamos transformar esse indicador em métricas personalizadas que serão enviadas ao Datadog. Uma métrica personalizada nos permite representar um comportamento específico da nossa aplicação ou até do nosso negócio.

Para isso, precisamos de alguns elementos: um nome claro, um valor numérico e o momento em que a medição ocorreu. Também podemos adicionar tags, mas faremos isso no próximo vídeo. Neste, vamos focar especificamente em enviar essas métricas com nome, momento de ocorrência e valor numérico.

Configurando a chave de api no datadog

Vamos ao envio na prática. Vamos abrir o Datadog. Como nossa aplicação está sendo executada fora do Datadog, precisamos permitir que ela envie os dados para a plataforma. Para isso, vamos usar uma API Key. No canto esquerdo, acessamos o menu com nosso nome e selecionamos My Organizations (Minhas organizações). Em seguida, trocamos de Personal Settings (Configurações pessoais) para Organization Settings (Configurações da organização).

É importante diferenciar que, em Personal Settings, tínhamos a Application Key (Chave de aplicação), que é diferente de uma API Key (Chave de API). Para o envio de métricas que vamos realizar agora, precisamos utilizar uma API Key. Acessamos Access > API Keys (Acesso > Chaves de API) e criamos uma nova, com o nome “Alura Datadog eCommerce”. Copiamos o valor da chave, que será nossa credencial, e não a deixamos exposta no código nem a enviamos para nenhum repositório. Armazenamos esse valor separadamente.

Definindo variáveis de ambiente e versionamento

Em seguida, vamos para o VS Code (Visual Studio Code). Temos uma estrutura na qual criamos um arquivo .env, onde ficarão nossas variáveis da API Key. Também temos o arquivo .gitignore, no qual adicionamos o .env justamente para evitar subir acidentalmente essas variáveis para um repositório. Aqui está a nossa aplicação, que fará o envio dos nossos erros.

Para reforçar essa etapa de versionamento, no .gitignore incluímos as entradas necessárias, garantindo que o .env seja ignorado:

.env
.venv
__pycache__/

No arquivo .env, disponibilizamos as credenciais: a API Key do Datadog, que você deve colar, e o site do Datadog utilizado pela nossa organização. Esses valores ficam separados do nosso código e, como mencionado no .gitignore, já estão sendo ignorados, portanto não serão enviados para repositórios.

DD_API_KEY=YOUR_API_KEY
DD_SITE=datadoghq.com

Na aplicação, usamos load_dotenv para carregar as variáveis definidas no nosso .env. Também informamos explicitamente o caminho do arquivo, garantindo que seja carregado a partir da mesma pasta do nosso app.py.

env_path = Path(__file__).resolve().parent / ".env"
load_dotenv(dotenv_path=env_path)

Controlando cenários de erro no endpoint

Como estamos utilizando uma aplicação de demonstração, precisamos controlar quando um pedido será processado com sucesso ou com falha. Para isso, criamos a configuração hasError, que considera como erro os pedidos cujos identificadores começam com ordError. Assim, provocamos falhas de forma previsível durante os testes que precisamos realizar.

Para materializar essa lógica no endpoint, mapeamos a rota de criação de pedidos e derivamos o flag de erro a partir do order_id:

@app.post("/orders")
def process_order(order: Order):

    has_error = order.order_id.startswith("ORD-ERROR")

Criamos também a função sendError, responsável por enviar a nossa métrica.

Construindo e enviando a métrica de erro

No código, a função responsável por enviar a métrica constrói o payload com a série da métrica:

def send_error_metric():
    
    body = MetricPayload(
        series=[
            MetricSeries(
                metric="ecommerce.orders.errors",
                type=MetricIntakeType.COUNT,
                points=[
                    MetricPoint(
                        timestamp=int(datetime.now().timestamp()),
                        value=1.0,
                    )
                ],
            )
        ]
    )

Conseguimos ver que a métrica possui um identificador, que é o nome de nossa métrica: eCommerceOrdersErrors. Trata-se de um nome claro, que vamos mencionar sempre que necessário. Nesse ponto, deixamos explícito que somos um e-commerce (comércio eletrônico), estamos capturando pedidos e registramos quando há erro. Mantivemos um nome legível, como já tínhamos mencionado.

Logo abaixo, como queremos registrar ocorrências de erros, utilizamos uma métrica do tipo count. Assim, a cada falha que ocorre, registramos uma nova ocorrência. Também definimos o valor da métrica timestamp. O timestamp registra quando o evento aconteceu. Precisávamos de um nome legível e claro, e também do momento em que a ocorrência se deu. Com vários pontos de envio ao longo do tempo, conforme os eventos forem sendo enviados, conseguimos criar uma série temporal desse comportamento.

Agora, na parte do RESTERROR, conectamos a métrica diretamente ao comportamento da aplicação. Quando um pedido entra no cenário de erro, registramos o problema no log e chamamos a função sendError. Ou seja, nossa métrica nasce de um evento que realmente aconteceu no fluxo da aplicação.

No trecho do endpoint que trata o caso de erro, fazemos o log e disparamos o envio da métrica:

    if has_error:
        logging.error(
            f"Erro ao processar pedido "
            f"order_id={order.order_id} - "
            f"customer_id={customer.customer_id}"
        )

        send_error_metric()

Testando a aplicação via swagger

Vamos iniciar a aplicação e testar esse comportamento. Executamos o comando no terminal e iniciamos a aplicação. Ela conseguiu capturar a API key (chave de API). Colocamos um printf justamente para sabermos que estava tudo correto.

python -m uvicorn app:app --reload

Em seguida, acessamos o Swagger para visualizar e testar. O contrato exibe ORDER ID (string) e CUSTOMER. Utilizamos primeiro um caso de sucesso. Queremos gerar um sucesso, então executamos: SUCCESS ORDER 1001. Perfeito. Como o identificador não tem o prefixo que definimos para simular erro, foi processado normalmente.

Para o caso de sucesso, o corpo de exemplo enviado foi:

{
  "order_id": "1001",
  "amount": 150.5,
  "customer_id": "CUST_01",
  "payment_method": "credit_card"
}

Agora, alteramos o identificador para o prefixo ORDER ERROR para gerar um erro. Nesse caso, além de registrarmos o erro da aplicação, também executamos o envio da métrica para o Datadog. Executamos e verificamos: comportamento esperado. Temos ORDER ID com ORDER ERROR 1002, e o status foi ERROR, dentro do nó esperado.

Para simular o erro, enviamos um pedido cujo order_id começa com o prefixo configurado:

{
  "order_id": "ORD-ERROR-1002",
  "amount": 150.5,
  "customer_id": "CUST_01",
  "payment_method": "credit_card"
}

Verificando a métrica no datadog

Abrimos o Datadog e acessamos as métricas. Para revisar, entramos em Explorer (Explorador) e buscamos pela métrica que criamos de erros, eCommerceOrdersErrors. Pode levar alguns segundos para aparecer. Após alguns segundos, pesquisamos novamente e visualizamos nosso primeiro erro — o nosso primeiro case (caso) acontecendo. O funcionamento está correto; verificamos que realmente funcionou.

Nas métricas, pesquisamos e conseguimos visualizar o dado enviado pela nossa aplicação. A partir daqui, conforme novos erros acontecerem, novos pontos serão enviados e conseguiremos observar esse comportamento ao longo do tempo.

Refletindo sobre indicadores e próximos passos

Há um ponto importante nesse processo. Não começamos simplesmente escolhendo uma métrica disponível. Primeiro, identificamos o problema e definimos qual era o indicador que queríamos. Depois, transformamos esse indicador em uma métrica que conseguimos acompanhar no Datadog.

Ainda existe uma limitação: se essa métrica começar a indicar um aumento de erros, saberemos que existe um problema, mas ainda não saberemos exatamente onde ele está acontecendo. Ocorreu em produção? Está relacionado a algum serviço específico? Aconteceu após uma determinada versão? Para responder a essas perguntas, precisamos adicionar algumas tags para dar mais contexto à nossa métrica.

Isso é o que vamos ver no próximo vídeo. Eu te vejo lá.

Sobre o curso Datadog: observabilidade, troubleshooting e monitoramento inteligente

O curso Datadog: observabilidade, troubleshooting e monitoramento inteligente possui 239 minutos de vídeos, em um total de 63 atividades. Gostou? Conheça nossos outros cursos de Engenharias e Arquiteturas de Dados em Dados, ou leia nossos artigos de Dados.

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

• Métricas: Performance e Personalização
• Logs: Estruturação e Visibilidade
• Investigação: O Poder da Correlação
• Alertas Estratégicos e Notificações
• Monitoramento Inteligente com IA