Lab 53 — Dashboard que responde pergunta de operação

{
  "_aws": {
    "Timestamp": 1754640000000,
    "CloudWatchMetrics": [
      {
        "Namespace": "Cadencia/Negocio",
        "Dimensions": [["Servico"]],
        "Metrics": [{ "Name": "CobrancaProcessada", "Unit": "Count" }]
      }
    ]
  },
  "Servico": "Faturamento",
  "CobrancaProcessada": 1
}

// NegocioMetricas.cs — metrica de negocio publicada sem SDK de metrica nenhum
//
// A ARMADILHA deste arquivo, e o motivo de ele nao usar o mesmo logger
// estruturado (Serilog) que o resto da aplicacao: o CloudWatch exige que a
// linha de log SEJA o objeto JSON do EMF, sem nada antes nem depois. Se voce
// mandar este payload pelo Serilog, ele embrulha a string dentro do PROPRIO
// envelope JSON dele (timestamp, level, message...) — e o "_aws" deixa de
// estar na RAIZ do evento. A extracao falha em silencio: nenhum erro, nenhum
// log de aviso, so a metrica que nunca aparece no CloudWatch. A correcao e
// escrever direto em Console.Out, fora do pipeline de log da aplicacao.

using System.Text.Json;

namespace Cadencia.Observabilidade;

public static class NegocioMetricas
{
    // Um metodo por evento de negocio — nao um metodo generico "PublicarMetrica" —
    // porque o NOME da metrica e o nome do efeito, nao um parametro livre.
    // Livre demais e como "log.Info(algumaCoisa)": tecnicamente funciona,
    // pedagogicamente nao ensina nada sobre o que aconteceu.
    public static void PedidoConfirmado(string servico = "Pedidos") =>
        Emitir(nome: "PedidoConfirmado", servico);

    public static void CobrancaProcessada(string servico = "Faturamento") =>
        Emitir(nome: "CobrancaProcessada", servico);

    private static void Emitir(string nome, string servico)
    {
        // "Dimensions" e uma lista de LISTAS: cada lista interna e um
        // conjunto de dimensao que gera uma metrica propria. Uma dimensao so
        // (Servico) e suficiente aqui — NUNCA adicione PedidoId ou CobrancaId
        // como dimensao: cada valor unico vira uma metrica de CloudWatch
        // nova, e customer-id-como-dimensao e a causa mais comum de fatura
        // de metrica customizada que ninguem sabe explicar.
        var payload = new Dictionary<string, object>
        {
            ["_aws"] = new Dictionary<string, object>
            {
                ["Timestamp"] = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(),
                ["CloudWatchMetrics"] = new object[]
                {
                    new Dictionary<string, object>
                    {
                        ["Namespace"] = "Cadencia/Negocio",
                        ["Dimensions"] = new object[] { new[] { "Servico" } },
                        ["Metrics"] = new object[]
                        {
                            new Dictionary<string, object> { ["Name"] = nome, ["Unit"] = "Count" },
                        },
                    },
                },
            },
            ["Servico"] = servico,
            [nome] = 1,
        };

        // Console.Out, nao ILogger: esta linha PRECISA chegar ao driver
        // awslogs do conteiner exatamente como este JSON, sem prefixo de
        // nivel nem timestamp de outro formato na frente.
        Console.Out.WriteLine(JsonSerializer.Serialize(payload));
    }
}

// Ponto de chamada, dentro do endpoint que ja existe desde o L01/L51 — uma
// linha, no lugar exato onde o efeito de negocio se torna verdade:
//
//   await db.Pedidos.AddAsync(pedido);
//   await db.SaveChangesAsync();
//   NegocioMetricas.PedidoConfirmado();   // <- aqui, depois do commit, nao antes
//
// Antes do SaveChangesAsync a metrica mentiria sobre um pedido que pode nao
// ter sido persistido. E o mesmo raciocinio do health check de prontidao do
// L03: o sinal so vale alguma coisa se disser a verdade sobre o que JA aconteceu.

# dashboard.tf — um widget por pergunta, layout por urgência

# O corpo do dashboard e uma string JSON. O grid tem 24 unidades de largura —
# e e por isso que os dois widgets do topo, com width = 12 cada, ocupam a
# largura inteira lado a lado: a pergunta mais urgente nao compete por espaco
# com nenhuma outra.
resource "aws_cloudwatch_dashboard" "operacao" {
  dashboard_name = "${var.projeto}-6-perguntas"

  dashboard_body = jsonencode({
    widgets = [
      # ── Pergunta 1, y=0: o sistema esta disponivel? ─────────────────────
      # Topo, esquerda, largura total dividida com a pergunta 2 — as duas
      # mais urgentes as 3h da manha.
      {
        type = "metric", x = 0, y = 0, width = 12, height = 6
        properties = {
          title  = "1. Esta disponivel? (5xx do alvo, por servico)"
          view   = "timeSeries"
          region = var.regiao
          period = 60
          stat   = "Sum"
          metrics = [
            ["AWS/ApplicationELB", "HTTPCode_Target_5XX_Count", "TargetGroup", aws_lb_target_group.pedidos.arn_suffix, "LoadBalancer", aws_lb.principal.arn_suffix, { label = "Pedidos" }],
            ["AWS/ApplicationELB", "HTTPCode_Target_5XX_Count", "TargetGroup", aws_lb_target_group.faturamento.arn_suffix, "LoadBalancer", aws_lb.principal.arn_suffix, { label = "Faturamento" }],
          ]
        }
      },
      # ── Pergunta 2, y=0: esta lento? ──────────────────────────────────
      {
        type = "metric", x = 12, y = 0, width = 12, height = 6
        properties = {
          title  = "2. Esta lento? (p99 de resposta do alvo, por servico)"
          view   = "timeSeries"
          region = var.regiao
          period = 60
          stat   = "p99"
          metrics = [
            ["AWS/ApplicationELB", "TargetResponseTime", "TargetGroup", aws_lb_target_group.pedidos.arn_suffix, "LoadBalancer", aws_lb.principal.arn_suffix, { label = "Pedidos" }],
            ["AWS/ApplicationELB", "TargetResponseTime", "TargetGroup", aws_lb_target_group.faturamento.arn_suffix, "LoadBalancer", aws_lb.principal.arn_suffix, { label = "Faturamento" }],
          ]
        }
      },
      # ── Pergunta 3, y=6: ha mensagens acumuladas? ─────────────────────
      # Metrica gerenciada pela AWS sobre a fila do L22 — nenhum codigo novo.
      {
        type = "metric", x = 0, y = 6, width = 8, height = 6
        properties = {
          title  = "3. Ha mensagens acumuladas? (fila de pedidos, L22)"
          view   = "timeSeries"
          region = var.regiao
          period = 60
          stat   = "Maximum"
          metrics = [
            ["AWS/SQS", "ApproximateNumberOfMessagesVisible", "QueueName", aws_sqs_queue.pedidos.name],
            ["AWS/SQS", "ApproximateAgeOfOldestMessage", "QueueName", aws_sqs_queue.pedidos.name, { yAxis = "right" }],
          ]
        }
      },
      # ── Pergunta 4, y=6: quantas operacoes de negocio foram concluidas? ─
      # Metrica de EMF: o mesmo namespace onde o app publica PedidoConfirmado
      # e CobrancaProcessada — ver NegocioMetricas.cs.
      {
        type = "metric", x = 8, y = 6, width = 8, height = 6
        properties = {
          title  = "4. Quantas operacoes de negocio concluiram? (EMF)"
          view   = "timeSeries"
          region = var.regiao
          period = 300
          stat   = "Sum"
          metrics = [
            ["Cadencia/Negocio", "PedidoConfirmado", "Servico", "Pedidos"],
            ["Cadencia/Negocio", "CobrancaProcessada", "Servico", "Faturamento"],
          ]
        }
      },
      # ── Pergunta 5, y=6: houve aumento inesperado de custo? ────────────
      # AWS/Billing SO existe na regiao us-east-1, MESMO que este dashboard
      # e todo o resto da infraestrutura estejam em outra regiao — por isso
      # o "region" deste widget e fixo, nao var.regiao. E a unica pergunta
      # cuja resposta nao e proxima de tempo real: atualiza poucas vezes ao dia.
      {
        type = "metric", x = 16, y = 6, width = 8, height = 6
        properties = {
          title  = "5. Custo inesperado? (atualiza poucas vezes/dia, nao e tempo real)"
          view   = "timeSeries"
          region = "us-east-1"
          period = 21600 # 6 h — o mesmo periodo recomendado para alarme de billing
          stat   = "Maximum"
          metrics = [
            ["AWS/Billing", "EstimatedCharges", "Currency", "USD"],
          ]
        }
      },
      # ── Pergunta 6, y=12: qual componente esta falhando? ───────────────
      # Onde metrica pre-agregada nao alcanca: widget do tipo "log", que
      # executa uma consulta salva de Logs Insights sobre o log correlacionado
      # do L51. E o unico widget que NAO e "metric" neste dashboard.
      {
        type = "log", x = 0, y = 12, width = 24, height = 8
        properties = {
          title  = "6. Qual componente esta falhando? (Logs Insights, log correlacionado do L51)"
          region = var.regiao
          view   = "table"
          query  = "SOURCE '/ecs/${var.projeto}-pedidos' | SOURCE '/ecs/${var.projeto}-faturamento'\n| filter nivel = \"ERROR\"\n| stats count(*) as erros by servico\n| sort erros desc"
        }
      },
    ]
  })
}

# A consulta acima tambem existe SALVA — para nao depender de ninguem lembrar
# a sintaxe as 3h. Aparece no console em "Consultas salvas", com o mesmo texto.
resource "aws_cloudwatch_query_definition" "qual_componente" {
  name = "${var.projeto}/6-perguntas/qual-componente-esta-falhando"

  log_group_names = [
    aws_cloudwatch_log_group.pedidos.name,
    aws_cloudwatch_log_group.faturamento.name,
  ]

  query_string = <<-QUERY
    filter nivel = "ERROR"
    | stats count(*) as erros by servico
    | sort erros desc
  QUERY
}

# Segunda consulta salva: reconstroi a jornada de UM trace especifico quando o
# widget 6 apontou um servico, mas nao qual requisicao. Parametrizada por
# trace_id, informado na hora de rodar — nao um valor fixo no Terraform.
resource "aws_cloudwatch_query_definition" "jornada_por_trace" {
  name = "${var.projeto}/6-perguntas/jornada-de-um-trace"

  log_group_names = [
    aws_cloudwatch_log_group.pedidos.name,
    aws_cloudwatch_log_group.faturamento.name,
  ]

  query_string = <<-QUERY
    filter trace_id = "$traceId"
    | sort @timestamp asc
    | fields @timestamp, servico, nivel, mensagem
  QUERY
}

# provas.sh — cinco medições; nenhuma conclusão vem de "o painel parece certo"

PROJETO=ffv-lab; REGIAO=us-east-1

# ── Prova 1: o dashboard existe e tem os seis widgets ────────────────────────
aws cloudwatch get-dashboard --dashboard-name "${PROJETO}-6-perguntas" \
  --query 'DashboardBody' --output text | jq '.widgets | length'
# Esperado: 6. Se vier menos, algum widget falhou silenciosamente no apply —
# jsonencode() nao valida o SCHEMA do dashboard, so a sintaxe JSON.

# ── Prova 2: a consulta "qual componente" devolve número, não suposição ──────
QUERY_ID=$(aws logs start-query \
  --log-group-names "/ecs/${PROJETO}-pedidos" "/ecs/${PROJETO}-faturamento" \
  --start-time "$(date -u -d '15 minutes ago' +%s)" --end-time "$(date -u +%s)" \
  --query-string 'filter nivel = "ERROR" | stats count(*) as erros by servico | sort erros desc' \
  --query 'queryId' --output text)
sleep 5
aws logs get-query-results --query-id "$QUERY_ID" --query 'results' --output table
# Esperado: uma linha por serviço com erro, ordenada. Tabela vazia significa
# "sem erro nos últimos 15 min" — resultado legítimo, não falha da prova.

# ── Prova 3: a métrica de negócio tem dado, e não é zero por engano ──────────
aws cloudwatch get-metric-statistics --namespace "Cadencia/Negocio" \
  --metric-name PedidoConfirmado --dimensions Name=Servico,Value=Pedidos \
  --start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%S)" --period 300 --statistics Sum \
  --query 'Datapoints[].Sum' --output text
# Esperado: soma > 0 se houve pedido na última hora. Zero persistente com
# tráfego real na aplicação indica o erro de pipeline descrito no callout
# sobre o Serilog — confira se a linha chegou ao log group como JSON puro.

# ── Prova 4: o sinal de fila se move quando o consumidor para ────────────────
# Publica 20 mensagens de teste SEM rodar o consumidor (pare a função do L22
# antes, e suba de novo depois).
for i in $(seq 1 20); do
  aws sqs send-message --queue-url "$(terraform output -raw fila_pedidos_url)" \
    --message-body "{\"teste\": $i}" >/dev/null
done
sleep 30
aws sqs get-queue-attributes --queue-url "$(terraform output -raw fila_pedidos_url)" \
  --attribute-names ApproximateNumberOfMessagesVisible ApproximateAgeOfOldestMessage \
  --query 'Attributes'
# Esperado: ApproximateNumberOfMessagesVisible perto de 20 e a idade da mais
# antiga subindo — é exatamente o sintoma que a arquitetura mínima não via.

# ── Prova 5: a métrica de billing existe, na região certa ────────────────────
aws cloudwatch list-metrics --namespace "AWS/Billing" --region us-east-1 \
  --metric-name EstimatedCharges --query 'Metrics[].Dimensions' --output table
# Esperado: ao menos uma linha, com dimensão Currency=USD. Lista vazia quase
# sempre significa que "Receive Billing Alerts" não foi habilitado na conta
# — é passo de console, e leva cerca de 15 min para aparecer depois de habilitado.

# limpar.sh — o que este laboratório acrescenta, e o que sobrevive ao destroy

# 1. O que o Terraform administra: dashboard, consultas salvas, alarme de
#    billing se você o criou. Nada aqui tem custo por hora ligada.
terraform destroy -auto-approve

# 2. CONSULTAS SALVAS: seguem o ciclo do Terraform e saem no destroy. Confira,
#    porque consulta salva "órfã" (criada à mão no console) NÃO aparece no
#    estado e continua contando para a cota de 100 concorrentes por conta.
aws logs describe-query-definitions \
  --query-definition-name-prefix "ffv-lab/6-perguntas" --query 'queryDefinitions'

# 3. A MÉTRICA DE NEGÓCIO (EMF) não é um recurso: é dado extraído de log já
#    existente. Ela não sobrevive à exclusão do grupo de logs, mas SOBREVIVE
#    ao destroy do dashboard — o histórico de datapoints fica retido pelo
#    prazo padrão de métrica customizada, e volta a aparecer se você recriar
#    o dashboard apontando para o mesmo namespace.

# 4. O ALARME DE BILLING, se criado: billing alarm mora sempre em us-east-1,
#    independentemente da região do resto da infraestrutura — confira lá.
aws cloudwatch describe-alarms --region us-east-1 \
  --alarm-name-prefix "ffv-lab" --query 'MetricAlarms[].AlarmName'

# 5. O QUE JÁ VINHA DO L01/L22/L51 E CONTINUA COBRANDO: ALB, NAT Gateway,
#    fila SQS, RDS. Este laboratório não cria nenhum deles — se você não vai
#    seguir para o L59, rode a limpeza desses laboratórios também.

# 6. Prova final: nada com o nome do projeto de pé.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab \
  --query "ResourceTagMappingList[].ResourceARN" --output table