Diagnostique um Incidente com Logs e Métricas

Introdução

Pedidos válidos falham enquanto uma solicitação de inventário tem sucesso. Você comparará métricas de aplicações, rastreará uma solicitação com falha nos logs, corrigirá uma pequena falha de configuração e confirmará a recuperação sem apagar o histórico de falhas.

Conclua primeiro Encontre uma Solicitação com Falha no CloudWatch Logs e Meça a Saúde da Aplicação com Métricas do CloudWatch. Este laboratório fornece sua própria aplicação e seu próprio incidente.

Relação com as certificações

Visão geral do laboratório

Reproduza o Incidente e Compare uma Solicitação de Controle

Nesta etapa, você reproduzirá uma solicitação válida de pedido que falha inesperadamente. O serviço preparado de forma independente tem uma falha em sua configuração comum. Seus logs e métricas começam vazios, portanto as observações vêm de suas próprias solicitações.

cd /home/labex/project

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-failure-1' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-failure-2' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-control' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/inventory

Espere duas respostas HTTP 503 stock_unavailable de orders e uma resposta HTTP 200 accepted de inventory para a mesma solicitação sintética válida de apple. A solicitação de controle sugere um problema específico de orders; ela não comprova que todo o sistema está saudável.

Use uma janela recente em UTC e as dimensões Application exatas para comparar as contagens de erros do servidor. Uma métrica resume a frequência, enquanto logs individuais podem explicar uma resposta específica.

START=$(date -u -d '15 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
echo "$START"

Salve o horário final da janela de consulta em UTC:

END=$(date -u -d '1 minute' +%Y-%m-%dT%H:%M:%SZ)
echo "$END"

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=inventory \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

Espere Sum 2 de orders e Sum 0 de inventory somando os intervalos retornados. Mantenha /labex/o05-reference inalterado.

Conecte a Contagem de Erros aos Logs de Solicitações

Nesta etapa, você conectará o sintoma resumido a solicitações concretas com falha. Consulte ERROR primeiro e, depois, o ID exato da solicitação. Uma expressão entre aspas corresponde ao token request_id completo; isso evita misturar solicitações com nomes semelhantes.

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern ERROR \
  --query 'events[].{Time:timestamp,Message:message}'

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern '"request_id=o05-failure-1"' \
  --query 'events[].message'

Ambas as falhas identificam application=orders, status 503 e o motivo stock_unavailable. As métricas e os logs abrangem as mesmas solicitações na janela recente. Inspecione as configurações da aplicação para localizar a incompatibilidade com a solicitação válida de apple.

cat app.json

accepted_sku é pear para orders. Inventory usa a configuração esperada apple de forma independente. Essa é uma pequena falha de configuração; substituir o serviço ou desabilitar a observabilidade ocultaria o sintoma sem corrigi-lo.

A solicitação que falhou pediu apple, mas a configuração de orders aceita pear. Essa diferença é uma explicação verificável para stock_unavailable; a solicitação saudável a inventory ajuda a delimitar o problema. A próxima etapa testa essa explicação alterando a configuração de orders e repetindo uma solicitação válida. A recuperação exige uma resposta bem-sucedida e seu novo registro correspondente, não apenas a edição da configuração.

Corrija a Configuração e Verifique a Recuperação

Nesta etapa, você alterará o SKU aceito e comprovará que a resposta de negócio se recupera enquanto a telemetria permanece habilitada. Substitua a configuração comum pela configuração corrigida.

cat > app.json <<'JSON'
{"logging": {"enabled": true, "group": "/labex/o05-application", "stream": "requests"}, "metrics": {"enabled": true, "namespace": "LabEx/O05"}, "accepted_sku": "apple"}
JSON

curl -i -H 'Content-Type: application/json' -H 'X-Request-ID: o05-recovered' -d '{"sku":"apple","quantity":1}' http://127.0.0.1:5050/orders

aws logs filter-log-events \
  --log-group-name /labex/o05-application \
  --filter-pattern '"request_id=o05-recovered"' \
  --query 'events[].message'

Espere HTTP 200 accepted e um log INFO para o mesmo ID de solicitação recuperada. As falhas históricas permanecem na janela. Uma solicitação saudável publica Errors=0, portanto o Sum acumulado de erros permanece 2, enquanto Requests aumenta para 3.

START=$(date -u -d '15 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
echo "$START"

Salve o horário final da janela de consulta em UTC:

END=$(date -u -d '1 minute' +%Y-%m-%dT%H:%M:%SZ)
echo "$END"

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Errors \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace LabEx/O05 \
  --metric-name Requests \
  --dimensions Name=Application,Value=orders \
  --start-time "$START" \
  --end-time "$END" \
  --period 60 \
  --statistics Sum

O AWS View mostra séries reais das aplicações e logs de solicitações. Use o ID da solicitação recuperada para distinguir a nova resposta bem-sucedida do histórico de falhas mantido.

Pare a Telemetria e Remova o Grupo de Logs do Laboratório

Nesta etapa, você interromperá a instrumentação e removerá apenas o grupo de logs do incidente. As métricas existentes permanecem conforme a retenção; não existe uma API de exclusão de métricas individuais.

cat > app.json <<'JSON'
{"logging": {"enabled": false, "group": "/labex/o05-application", "stream": "requests"}, "metrics": {"enabled": false, "namespace": "LabEx/O05"}, "accepted_sku": "apple"}
JSON

aws logs delete-log-group --log-group-name /labex/o05-application

aws logs describe-log-groups --query 'logGroups[].logGroupName'

aws logs get-log-events \
  --log-group-name /labex/o05-reference \
  --log-stream-name platform \
  --query 'events[].message'

Espere apenas /labex/o05-reference e sua mensagem original INFO platform reference keep unchanged. Um inventário obtido com sucesso verifica a exclusão direcionada; consultas com falha não comprovariam a limpeza.

Resumo

Você reproduziu um incidente com uma solicitação de controle, conectou contagens de métricas a logs de solicitações, corrigiu uma configuração da aplicação, verificou uma nova resposta bem-sucedida e preservou as evidências históricas até a limpeza direcionada.

Para aprofundar o tema, consulte a documentação da AWS: Identidade de métricas, dimensões e estatísticas; Filtrar eventos de log por termos e frases exatas.