Lab 08 — Enxergar o que quebrou

# Rode ANTES de instrumentar nada. Os numeros daqui sao a linha de base.
GRUPO=/ecs/ffv-lab-api

# 1. Quantos eventos por dia, e quantos GB. Da a escala do problema.
aws logs describe-log-groups --log-group-name-prefix "$GRUPO" \
  --query "logGroups[].{grupo:logGroupName,bytes:storedBytes,ret:retentionInDays}" \
  --output table
# Na Cadencia: 3,4 GB/dia e retentionInDays NULO — guardando para sempre.

# 2. Qual fracao dos eventos e JSON valido, ou seja, consultavel por campo.
#    Com log de texto a resposta e zero, e o zero e o argumento deste modulo.
aws logs start-query --log-group-name "$GRUPO" \
  --start-time $(( $(date +%s) - 3600 )) --end-time $(date +%s) \
  --query-string 'fields @message
    | filter ispresent(TraceId)
    | stats count() as com_campo' --query queryId --output text
# Na Cadencia: 0 de 87.412 eventos na ultima hora.

# 3. Cronometre a busca de UMA requisicao conhecida. Faca voce mesmo, com
#    relogio, partindo so de "erro por volta das 14h22".
#    Na Cadencia: 3 dias, e a conclusao foi o adverbio "provavelmente".

// Os tres identificadores que atravessam UMA requisicao, e por que sao tres.

// ── 1. O que o cliente ve na resposta ────────────────────────────────────────
HTTP/1.1 500 Internal Server Error
X-Amz-Cf-Id: SLxU6dEQ4o8-Xz1kA9wV3rN7pQ==   // identificador da requisicao de borda
X-Correlation-Id: 4bf92f3577b34da6a3ce929d0e0e4736  // devolvido pelo nosso middleware

// ── 2. O que o ALB coloca a caminho do alvo ─────────────────────────────────
// Cabecalho AUSENTE na entrada: o balanceador cria um campo Root.
X-Amzn-Trace-Id: Root=1-67891233-abcdef012345678912345678
//               ^versao 1  ^epoca em 8 digitos hex  ^id em 24 digitos hex

// Cabecalho PRESENTE com Root: o balanceador INSERE Self na frente e preserva
// o resto, inclusive campos que a sua aplicacao tenha acrescentado.
X-Amzn-Trace-Id: Self=1-67891233-12456789abcdef012345678;Root=1-67891233-abcdef012345678912345678;CalledFrom=app

// Ja com Sampled e Parent, quando vem de um servico instrumentado:
X-Amzn-Trace-Id: Root=1-5759e988-bd862e3fe1be46a994272793;Parent=53995c3f42cd8ad8;Sampled=1

// ── 3. O que um cliente moderno ou outro servico instrumentado manda ─────────
// Formato W3C. Repare que ele NAO tem tempo embutido: e 32 hex aleatorios.
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
//           ^versao ^trace-id (32 hex)          ^span-id (16 hex) ^flags: 01 = amostrado

// A diferenca de formato tem consequencia pratica: o id do X-Ray carrega a epoca
// nos seus 8 primeiros digitos hexadecimais e o do W3C nao carrega nada. E por
// isso que existe um gerador de id "no formato X-Ray" nas extensoes AWS do
// OpenTelemetry, e por isso que aceitar id em formato W3C foi uma capacidade que
// precisou ser acrescentada ao lado do X-Ray, nao algo que ja vinha de graca.

{
  "_aws": {
    "Timestamp": 1786000951418,
    "CloudWatchMetrics": [
      {
        "Namespace": "ApiPedidos",
        "Dimensions": [ [ "http.route", "http.status_code" ] ],
        "Metrics": [
          { "Name": "http.server.request.duration", "Unit": "Milliseconds" },
          { "Name": "db.query.duration",            "Unit": "Milliseconds" }
        ]
      }
    ]
  },

  "http.route": "/api/pedidos/{id}",
  "http.status_code": "500",

  "http.server.request.duration": 4213,
  "db.query.duration": 4098,

  "TraceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "PedidoId": "8f3a1c22-0d41-4d9e-9c17-0b2f4a6e5d10",
  "AwsCloudFrontRequestId": "SLxU6dEQ4o8-Xz1kA9wV3rN7pQ=="
}

// Program.cs — a configuração real do log estruturado com escopo de requisição.
// Não é "use Serilog": é a fábrica de log do proprio .NET anexando o contexto do
// Activity corrente a TODA mensagem escrita dentro da requisicao.

using System.Diagnostics;
using OpenTelemetry.Trace;
using OpenTelemetry.Metrics;
using OpenTelemetry.Resources;

var builder = WebApplication.CreateBuilder(args);

// ── 1. O elo que quase todo mundo esquece ────────────────────────────────────
// ActivityTrackingOptions faz a fabrica de log ler o Activity.Current e anexar
// TraceId e SpanId como ESCOPO de cada mensagem. Sem esta linha voce tem trace
// bonito no X-Ray e log sem trace id nenhum — o pior dos dois mundos, porque
// cada metade responde a uma pergunta e nenhuma responde a sua.
builder.Logging.Configure(o =>
    o.ActivityTrackingOptions = ActivityTrackingOptions.TraceId
                              | ActivityTrackingOptions.SpanId
                              | ActivityTrackingOptions.ParentId);

// ── 2. Uma linha de JSON por evento, e por que UMA linha ─────────────────────
// O driver awslogs quebra a saida por salto de linha: um JSON identado viraria
// N eventos invalidos no CloudWatch, cada um com um fragmento do objeto. Indented
// = false nao e estetica, e requisito do transporte.
builder.Logging.ClearProviders();
builder.Logging.AddJsonConsole(o =>
{
    o.IncludeScopes = true;   // sem isto, TraceId fica no escopo e nao no evento
    o.UseUtcTimestamp = true; // fuso local em log distribuido e fonte de erro de leitura
    o.JsonWriterOptions = new System.Text.Json.JsonWriterOptions { Indented = false };
});

// ── 3. Propagador COMPOSTO: aceita os dois formatos que chegam ───────────────
// O ALB fala X-Amzn-Trace-Id; um cliente moderno ou outro servico instrumentado
// fala traceparent (W3C). Instalar so um dos dois propagadores e a causa numero
// um de "trace quebrado em dois": o contexto que chegou nao e reconhecido, um id
// novo e criado, e o mapa perde a aresta.
//
// INCERTEZA DECLARADA: o pacote NuGet que traz o propagador da AWS e o gerador de
// id no formato do X-Ray mudou de nome entre versoes (ja se chamou
// OpenTelemetry.Contrib.Extensions.AWSXRay). Confira o nome atual no NuGet antes
// de copiar o `using` — o MECANISMO abaixo nao muda, o pacote sim.
builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r
        .AddService(serviceName: "api-pedidos",
                    serviceVersion: builder.Configuration["SHA_DA_IMAGEM"] ?? "dev")
        // O SHA como versao do recurso e o que permite perguntar "esta latencia
        // apareceu com qual deploy?" — liga observabilidade a entrega (L03).
        .AddAttributes(new Dictionary<string, object>
        {
            ["deployment.environment"] = builder.Environment.EnvironmentName,
        }))
    .WithTracing(t => t
        .AddAspNetCoreInstrumentation(o =>
        {
            // Health check gera trace inutil em volume alto: e a maior fonte de
            // span sem valor numa API atras de ALB verificando a cada 5 s.
            o.Filter = ctx => !ctx.Request.Path.StartsWithSegments("/health");
            // Enriquecer o span com o que o cliente tem na mao. Sem isto, nao ha
            // como partir do ticket e chegar no trace.
            o.EnrichWithHttpRequest = (activity, req) =>
            {
                var borda = req.Headers["X-Amz-Cf-Id"].ToString();
                if (!string.IsNullOrEmpty(borda))
                    activity.SetTag("aws.cloudfront.request_id", borda);
            };
        })
        .AddHttpClientInstrumentation()
        .AddNpgsql()                       // subsegmento por consulta, com duracao
        .AddOtlpExporter())                // destino vem de OTEL_EXPORTER_OTLP_ENDPOINT
    .WithMetrics(m => m
        .AddAspNetCoreInstrumentation()
        .AddRuntimeInstrumentation()
        .AddOtlpExporter());

var app = builder.Build();

// ── 4. Devolver o identificador ao cliente ───────────────────────────────────
// E a peca que transforma "deu erro no seu site" em "deu erro, o codigo e este".
// Sem ela, o ticket chega com um horario aproximado e a investigacao comeca por
// adivinhacao. Devolver trace id NAO e vazamento: ele nao contem dado do usuario.
app.Use(async (ctx, next) =>
{
    var trace = Activity.Current?.TraceId.ToString();
    if (trace is not null)
        ctx.Response.Headers["X-Correlation-Id"] = trace;
    await next();
});

app.MapGet("/api/pedidos/{id:guid}", async (
    Guid id, AppDb db, ILogger<Program> log) =>
{
    // Repare no que NAO esta aqui: nenhum trace id passado a mao. O escopo
    // ambiental do Activity ja garante que este evento sai com TraceId e SpanId.
    // Repare tambem no formato: {PedidoId} e um NOME DE CAMPO, nao interpolacao.
    // `$"pedido {id}"` produziria uma cadeia de caracteres opaca, e a consulta
    // por pedido voltaria a ser substring.
    log.LogInformation("Consultando pedido {PedidoId}", id);

    var pedido = await db.Pedidos.FindAsync(id);
    if (pedido is null)
    {
        // 404 e resultado esperado, nao falha: registrar como erro polui a taxa
        // de erro e faz o alarme perder credibilidade.
        log.LogInformation("Pedido {PedidoId} inexistente", id);
        return Results.NotFound();
    }

    // Atributo de negocio no span: e o que permite filtrar traces por cliente
    // sem criar uma metrica por cliente. Atributo de span e barato; dimensao de
    // metrica com a mesma cardinalidade seria ruinosa.
    Activity.Current?.SetTag("pedido.id", id.ToString());
    Activity.Current?.SetTag("pedido.loja", pedido.LojaId.ToString());

    return Results.Ok(pedido);
});

app.MapHealthChecks("/health/ready");
app.Run();

// O MESMO evento, nos dois formatos. A diferenca nao e estetica.

// ── Antes: uma cadeia de caracteres. Legivel, inconsultavel. ─────────────────
// 2026-08-07 14:22:31 ERRO ao processar pedido 8f3a-... para loja 42: timeout
//
// Para achar isto voce precisa saber a substring exata. Para contar quantos
// aconteceram por loja, precisa de expressao regular sobre texto livre. Para
// ligar a outra linha da mesma requisicao, precisa do horario e de sorte.

// ── Depois: um objeto com campos. Um evento, N perguntas. ───────────────────
{
  "Timestamp": "2026-08-07T14:22:31.4180000Z",
  "LogLevel": "Error",
  "Category": "Api.Pedidos",
  "Message": "Falha ao consultar pedido",
  "State": {
    "PedidoId": "8f3a1c22-0d41-4d9e-9c17-0b2f4a6e5d10",
    "LojaId": 42
  },
  // Injetados pelo ActivityTrackingOptions: nao aparecem no codigo da rota.
  "Scopes": [
    { "TraceId": "4bf92f3577b34da6a3ce929d0e0e4736",
      "SpanId":  "00f067aa0ba902b7",
      "ParentId": "0000000000000000" }
  ],
  // O que o cliente tem na mao, gravado como campo — e a porta de entrada da
  // investigacao quando o ticket nao traz horario preciso.
  "AwsCloudFrontRequestId": "SLxU6dEQ4o8-Xz1kA9wV",
  "http.route": "/api/pedidos/{id}",
  "http.status_code": 500
}

// A consulta que o segundo formato permite e o primeiro nao, no Logs Insights:
//
//   fields @timestamp, Message, State.PedidoId
//   | filter Scopes.0.TraceId = "4bf92f3577b34da6a3ce929d0e0e4736"
//   | sort @timestamp asc
//
// Devolve a requisicao INTEIRA, em ordem, sem depender de horario. E o mesmo
// dado de antes; o que mudou e que agora ele tem nome.

# coletor.yaml — configuracao do ADOT collector rodando como sidecar da task.
# Ele existe para que amostragem, lote e repeticao de envio NAO rodem no processo
# que atende o cliente.

receivers:
  otlp:
    protocols:
      grpc:
        # 127.0.0.1 e nao 0.0.0.0: em modo awsvpc os dois conteineres da task
        # compartilham a interface de rede, entao localhost basta — e expor em
        # 0.0.0.0 abriria o receptor para qualquer coisa na sub-rede.
        endpoint: 127.0.0.1:4317
      http:
        endpoint: 127.0.0.1:4318

processors:
  # Lote existe para trocar N chamadas pequenas por uma maior. Timeout curto
  # mantem a telemetria util em incidente; lote grande economiza chamada.
  batch/traces:
    timeout: 5s
    send_batch_size: 128

  # Amostragem por CAUDA: decide DEPOIS de o trace terminar, entao pode usar o
  # resultado na decisao. E a diferenca central em relacao a amostragem por
  # cabeca, que decide na primeira requisicao e nao sabe ainda se houve erro.
  tailsampling:
    decision_wait: 10s
    policies:
      # 1. Tudo o que falhou: 100%. E a regra que garante que o trace da
      #    requisicao reclamada pelo cliente EXISTE.
      - name: erros-sempre
        type: status_code
        status_code: { status_codes: [ERROR] }
      # 2. Tudo o que passou de 2 s: 100%. Lentidao e o segundo motivo de ticket.
      - name: lentas-sempre
        type: latency
        latency: { threshold_ms: 2000 }
      # 3. O resto: 5%. E a linha de base do comportamento normal — suficiente
      #    para p99 e para o mapa de servicos, e e onde o custo mora.
      - name: resto-amostrado
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

  resourcedetection:
    detectors: [env, ecs]   # preenche cluster, servico e task sem codigo

exporters:
  awsxray:
    indexed_annotations: [pedido.loja, deployment.environment]
    # Anotacao e indexada e serve de filtro; atributo comum vira metadado e nao
    # e pesquisavel. Indexar `pedido.id` seria tentador e errado: o limite e de
    # 50 anotacoes por trace, e id unico nao agrupa nada.

  awsemf:
    namespace: ApiPedidos
    log_group_name: /ecs/api-pedidos/emf
    dimension_rollup_option: NoDimensionRollup
    metric_declarations:
      # A escolha de dimensao E a decisao de custo deste arquivo. Rota x status
      # sao dezenas de series. Trocar por id de cliente seriam milhares; por id
      # de requisicao, uma serie por requisicao — a documentacao do formato
      # embutido avisa exatamente isso.
      - dimensions: [[http.route, http.status_code]]
        metric_name_selectors: ['http.server.request.duration']

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resourcedetection, tailsampling, batch/traces]
      exporters: [awsxray]
    metrics:
      receivers: [otlp]
      processors: [resourcedetection]
      exporters: [awsemf]

# observabilidade.tf — a task com dois conteineres, e o IAM que cada um precisa

# ── Grupos de logs SEPARADOS, com retencoes diferentes ───────────────────────
# Um grupo por proposito, porque retencao e uma decisao por proposito. Grupo
# criado sem retention_in_days guarda PARA SEMPRE, e e a linha esquecida mais
# comum da fatura de CloudWatch.
resource "aws_cloudwatch_log_group" "app" {
  name              = "/ecs/${var.projeto}-api"
  retention_in_days = 14 # log de aplicacao raramente serve depois de 2 semanas
  kms_key_id        = aws_kms_key.logs.arn
}

resource "aws_cloudwatch_log_group" "emf" {
  name              = "/ecs/${var.projeto}-api/emf"
  retention_in_days = 3 # o valor virou metrica; o log fonte nao precisa durar
  kms_key_id        = aws_kms_key.logs.arn
}

resource "aws_ecs_task_definition" "api" {
  family                   = "${var.projeto}-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 1024 # +256 em relacao ao L01: o sidecar consome
  memory                   = 2048
  execution_role_arn       = aws_iam_role.execucao.arn
  task_role_arn            = aws_iam_role.task.arn

  container_definitions = jsonencode([
    {
      name      = "api"
      image     = "${var.repositorio}:${var.sha_da_imagem}"
      essential = true
      portMappings = [{ containerPort = 8080, protocol = "tcp" }]

      environment = [
        { name = "ASPNETCORE_URLS", value = "http://+:8080" },
        # localhost porque, em awsvpc, os dois conteineres da task compartilham
        # a interface de rede. Nao ha salto de rede entre eles.
        { name = "OTEL_EXPORTER_OTLP_ENDPOINT", value = "http://127.0.0.1:4317" },
        # Propagador COMPOSTO. Manter so um dos dois e a causa numero um de
        # trace partido: o contexto que chega nao e reconhecido e um id novo
        # nasce no meio do caminho.
        { name = "OTEL_PROPAGATORS", value = "tracecontext,baggage,xray" },
        { name = "OTEL_SERVICE_NAME", value = "${var.projeto}-api" },
        # O SHA entra na telemetria: e o que liga latencia a deploy (L03).
        { name = "SHA_DA_IMAGEM", value = var.sha_da_imagem },
      ]

      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = aws_cloudwatch_log_group.app.name
          "awslogs-region"        = var.regiao
          "awslogs-stream-prefix" = "api"
        }
      }

      # A API nao sobe antes do coletor. Sem isto, os primeiros segundos de
      # telemetria sao perdidos com recusa de conexao — e e justamente a partida
      # que voce quer ver quando algo quebra no deploy.
      dependsOn = [{ containerName = "coletor", condition = "START" }]
    },
    {
      name = "coletor"
      # Fixe a versao em vez de :latest, pelo mesmo motivo do L03: telemetria
      # que muda de comportamento sozinha e pior que telemetria ausente.
      image = "public.ecr.aws/aws-observability/aws-otel-collector:v0.43.0"

      # essential = false E A DECISAO CENTRAL DESTE BLOCO. Com true, uma falha do
      # coletor mata a task inteira e voce troca um incidente de observabilidade
      # por um incidente de disponibilidade. Telemetria nao pode ser mais critica
      # que o servico que ela observa.
      essential = false

      cpu    = 256
      memory = 512

      secrets = [{
        # A configuracao vem por referencia de ARN, nunca em environment.
        name      = "AOT_CONFIG_CONTENT"
        valueFrom = aws_ssm_parameter.coletor.arn
      }]

      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = aws_cloudwatch_log_group.app.name
          "awslogs-region"        = var.regiao
          "awslogs-stream-prefix" = "coletor"
        }
      }
    },
  ])
}

# ── IAM: quem escreve telemetria e a APLICACAO, nao o agente do ECS ──────────
data "aws_iam_policy_document" "telemetria" {
  statement {
    sid    = "EnviarTraceParaXRay"
    effect = "Allow"
    actions = [
      "xray:PutTraceSegments",
      "xray:PutTelemetryRecords",
      "xray:GetSamplingRules",
      "xray:GetSamplingTargets",
      "xray:GetSamplingStatisticSummaries",
    ]
    # Nenhuma destas cinco acoes aceita recurso especifico: o X-Ray nao tem ARN
    # de segmento nem de regra de amostragem a que se restringir. Escrever um ARN
    # aqui nao estreitaria nada — nao autorizaria nada. E `*` por natureza da
    # API, e esta frase e o que separa decisao de preguica.
    resources = ["*"]
  }

  statement {
    sid    = "EscreverLogEEmf"
    effect = "Allow"
    actions = [
      "logs:CreateLogStream",
      "logs:PutLogEvents",
      "logs:DescribeLogStreams",
    ]
    # Aqui SIM ha recurso: os dois grupos, e nada mais. O exportador de metrica
    # embutida escreve num deles, e nao tem por que alcancar outro grupo da conta.
    resources = [
      "${aws_cloudwatch_log_group.app.arn}:*",
      "${aws_cloudwatch_log_group.emf.arn}:*",
    ]
  }
}

# Repare no que NAO esta na politica: cloudwatch:PutMetricData. A metrica deste
# desenho nasce do log, entao a permissao de publicar metrica e desnecessaria.
# Se um dia for preciso, ela tambem nao aceita recurso — mas aceita a chave de
# condicao cloudwatch:namespace, que e como se estreita esse caso.

resource "aws_iam_role_policy" "telemetria" {
  role   = aws_iam_role.task.id
  policy = data.aws_iam_policy_document.telemetria.json
}

# ── Alarme sobre a metrica DERIVADA do log ───────────────────────────────────
# O namespace e o nome vem do exportador de metrica embutida do coletor. Se o
# alarme ficar em INSUFFICIENT_DATA para sempre, a causa quase certa e o par
# namespace/dimensao nao casar com o que o coletor declarou.
resource "aws_cloudwatch_metric_alarm" "p99_rota_pedidos" {
  alarm_name          = "${var.projeto}-p99-pedidos"
  namespace           = "ApiPedidos"
  metric_name         = "http.server.request.duration"
  extended_statistic  = "p99"
  period              = 60
  evaluation_periods  = 3
  threshold           = 2000
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "notBreaching"

  dimensions = {
    "http.route"       = "/api/pedidos/{id}"
    "http.status_code" = "200"
  }

  # O corpo do aviso tem de trazer a consulta pronta. Alarme que diz "erro em
  # producao" transfere ao plantao o trabalho de descobrir por onde comecar.
  alarm_description = "p99 da rota de pedidos acima de 2 s. Investigue com: fields @timestamp, Message | filter http.route = '/api/pedidos/{id}' | filter http.status_code >= 500 | sort @timestamp desc"
  alarm_actions     = [aws_sns_topic.alertas.arn]
}

# Filtro de metrica: o OUTRO jeito de derivar metrica de log, e ele serve para o
# caso em que voce NAO controla o formato — log de terceiro, de biblioteca, de
# agente. Aqui cabe porque a excecao nao passa pelo coletor.
resource "aws_cloudwatch_log_metric_filter" "excecao_nao_tratada" {
  name           = "${var.projeto}-excecao-nao-tratada"
  log_group_name = aws_cloudwatch_log_group.app.name
  # Padrao de JSON: consulta por CAMPO, nao por substring. Com log de texto este
  # filtro so poderia casar cadeia de caracteres, e mudanca de redacao da
  # mensagem o quebraria em silencio.
  pattern = "{ $.LogLevel = \"Critical\" }"

  metric_transformation {
    name          = "ExcecaoNaoTratada"
    namespace     = "ApiPedidos"
    value         = "1"
    default_value = "0" # sem isto, ausencia de erro vira ausencia de dado
  }
}

# provas.sh — cinco medicoes. Nenhuma conclusao vem de "parece que funcionou".

PROJETO=ffv-lab; REGIAO=us-east-1
GRUPO="/ecs/${PROJETO}-api"
URL="https://$(terraform output -raw dominio)/api/pedidos/8f3a1c22-0d41-4d9e-9c17-0b2f4a6e5d10"

# ── Prova 1: o identificador chega ao cliente e existe nos DOIS planos ───────
# E o entregavel do laboratorio. Partimos so do que um reclamante teria na mao.
CORR=$(curl -s -D - -o /dev/null "$URL" | awk -F': ' '/^[Xx]-[Cc]orrelation-[Ii]d/{print $2}' | tr -d '\r')
echo "identificador devolvido ao cliente: $CORR"
# Esperado: 32 caracteres hexadecimais. Se vier vazio, o middleware nao rodou ou
# nao ha Activity corrente — a instrumentacao do ASP.NET Core nao esta ativa.
[ "${#CORR}" -eq 32 ] || echo "FALHA DA PROVA 1: esperado 32 chars, veio ${#CORR}"

# ── Prova 2: TODA linha de log tem o identificador. A meta e 0 sem. ──────────
# Esta e a prova que separa "instrumentei" de "correlacionei". Um unico evento
# sem TraceId e um ponto cego permanente naquela requisicao.
CONSULTA_ID=$(aws logs start-query --log-group-name "$GRUPO" \
  --start-time "$(($(date +%s) - 900))" --end-time "$(date +%s)" \
  --query-string 'fields @message
    | filter ispresent(Scopes.0.TraceId) = 0
    | stats count() as sem_trace' \
  --query queryId --output text)
sleep 8
aws logs get-query-results --query-id "$CONSULTA_ID" --output table
# Esperado: sem_trace = 0 num total de centenas. Qualquer valor > 0 aponta log
# escrito FORA do escopo da requisicao — tipicamente na partida ou num
# BackgroundService, e nesses casos e legitimo: confira a categoria antes.

# ── Prova 3: a amostragem faz aritmeticamente o que ela diz ─────────────────
# 600 requisicoes em ~60 s, das quais 60 forcadas a erro. Com a regra por cauda
# do coletor (100% de erro, 5% do resto), a conta esperada e:
#   60 (erros) + 0,05 x 540 (~27) = ~87 traces, nao 600.
for i in $(seq 1 540); do curl -s -o /dev/null "$URL"; done &
for i in $(seq 1 60);  do curl -s -o /dev/null "${URL}?forcar_erro=1"; done
wait
aws xray get-trace-summaries --region "$REGIAO" \
  --start-time "$(($(date +%s) - 300))" --end-time "$(date +%s)" \
  --query 'length(TraceSummaries)' --output text
# Esperado: da ordem de 87, com tolerancia — a amostragem e estatistica, nao
# cota. O que REPROVA e sair ~600 (amostragem nao aplicada, e a fatura vem
# junto) ou sair ~30 (a regra de erro nao casou, e o trace que interessa nao
# existe). Confira tambem que 100% dos 60 erros aparecem:
aws xray get-trace-summaries --region "$REGIAO" \
  --start-time "$(($(date +%s) - 300))" --end-time "$(date +%s)" \
  --filter-expression 'error = true OR fault = true' \
  --query 'length(TraceSummaries)' --output text
# Esperado: 60. Menos que isso significa que a decisao por cauda expirou antes
# de o trace fechar — aumente decision_wait.

# ── Prova 4: a metrica derivada casa com a contagem no log ──────────────────
# Duas fontes, um numero. Divergencia acima de 1% indica que o exportador de
# metrica embutida esta descartando evento — quase sempre por dimensao ausente
# no registro, que invalida o documento inteiro em silencio.
aws cloudwatch get-metric-statistics --namespace ApiPedidos \
  --metric-name 'http.server.request.duration' --statistics SampleCount \
  --start-time "$(date -u -v-15M +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '15 min ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --period 900 \
  --dimensions Name=http.route,Value='/api/pedidos/{id}' Name=http.status_code,Value=200 \
  --query 'Datapoints[0].SampleCount' --output text
# Compare com o count() do mesmo intervalo no grupo de logs. Diferenca < 1%.
# Confira tambem se houve documento recusado: o CloudWatch publica falha de
# extracao no namespace AWS/Logs.

# ── Prova 5: do ticket ao span, em duas consultas e menos de 2 minutos ──────
# A prova de que o LABORATORIO cumpriu o objetivo. Cronometre de verdade.
inicio=$(date +%s)
aws logs start-query --log-group-name "$GRUPO" \
  --start-time "$(($(date +%s) - 3600))" --end-time "$(date +%s)" \
  --query-string "fields @timestamp, Message, State.PedidoId, http.status_code
    | filter Scopes.0.TraceId = '${CORR}'
    | sort @timestamp asc" --query queryId --output text
aws xray batch-get-traces --trace-ids "$(aws xray get-trace-summaries \
    --start-time "$(($(date +%s) - 3600))" --end-time "$(date +%s)" \
    --query 'TraceSummaries[0].Id' --output text)" \
  --query 'Traces[0].Segments[].Document' --output text | head -5
echo "segundos do ticket ao span: $(( $(date +%s) - inicio ))"
# Esperado: abaixo de 120 s, e nenhuma das duas consultas usa horario como
# filtro principal. Se voce precisou adivinhar a janela, a correlacao nao esta
# no lugar — esta na sua cabeca.

# limpar.sh — a ordem importa, e tres coisas aqui cobram depois do destroy.

# 1. O que o Terraform administra.
terraform destroy -auto-approve

# 2. GRUPOS DE LOGS: sobrevivem se skip_destroy estiver ligado, e sobrevivem
#    sempre se voce os criou implicitamente (o driver awslogs cria o grupo
#    quando ele nao existe, e esse nao entra no estado do Terraform).
for g in /ecs/ffv-lab-api /ecs/ffv-lab-api/emf; do
  aws logs describe-log-groups --log-group-name-prefix "$g" \
    --query 'logGroups[].{nome:logGroupName,bytes:storedBytes,ret:retentionInDays}' \
    --output table
  aws logs delete-log-group --log-group-name "$g" 2>/dev/null || true
done

# 3. GRUPO DE SPANS: se voce habilitou o Transaction Search, os spans vao para um
#    grupo gerenciado chamado aws/spans, e ele NAO pertence ao seu Terraform.
#    Desabilitar a busca por transacao e a acao que para a ingestao; apagar o
#    grupo sem desabilitar apenas o recria.
aws logs describe-log-groups --log-group-name-prefix "aws/spans" \
  --query 'logGroups[].{nome:logGroupName,bytes:storedBytes}' --output table

# 4. METRICAS CUSTOMIZADAS nao se apagam. Elas expiram por desuso (15 meses de
#    retencao de serie no CloudWatch). Se voce criou serie de alta cardinalidade
#    por engano, o custo do mes ja foi — a correcao e parar de produzir, e a
#    licao e a secao de custo deste modulo.
aws cloudwatch list-metrics --namespace ApiPedidos \
  --query 'length(Metrics)' --output text
# Se este numero for da ordem do numero de requisicoes do teste, voce reproduziu
# a explosao de cardinalidade. E didatico uma vez; e caro duas.

# 5. ALARMES e filtro de metrica, se criados fora do Terraform.
aws cloudwatch delete-alarms --alarm-names ffv-lab-p99-pedidos 2>/dev/null || true
aws logs delete-metric-filter --log-group-name /ecs/ffv-lab-api \
  --filter-name ffv-lab-excecao-nao-tratada 2>/dev/null || true

# 6. REGRAS DE AMOSTRAGEM do X-Ray criadas a mao permanecem na conta. Nao cobram,
#    mas se aplicam ao proximo servico que voce subir — e isso surpreende.
aws xray get-sampling-rules \
  --query 'SamplingRuleRecords[].SamplingRule.RuleName' --output table

# 7. O que veio do L01 e cobra POR HORA, ligado ou nao: ALB, RDS, NAT Gateway e o
#    Elastic IP dele, e endpoint de interface de VPC. Se voce nao vai seguir para
#    o L09, rode a limpeza do L01 tambem.
aws ec2 describe-addresses --query "Addresses[?AssociationId==null].PublicIp" --output table

# 8. Prova final: nada com a etiqueta do projeto de pe.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab \
  --query "ResourceTagMappingList[].ResourceARN" --output table