Lab 06 — Escalar quando chega gente de verdade

# Rode ANTES de mexer em nada. A saida daqui e o numero que torna o defeito
# discutivel — e o que impede a conversa de voltar para "sobe para 8".
PROJETO=ffv-lab
RES="service/${PROJETO}/${PROJETO}-api"

# 1. A politica disparou? Esta lista e o coracao do diagnostico.
aws application-autoscaling describe-scaling-activities \
  --service-namespace ecs --resource-id "$RES" \
  --query "length(ScalingActivities)" --output text
# Na Cadencia: 0. Vinte minutos de pico, zero atividade de escala.

# 2. E a CPU, no mesmo intervalo? Se ela nunca chegou ao alvo, a politica
#    fez exatamente o que devia — e o defeito e a metrica, nao a politica.
aws cloudwatch get-metric-statistics --namespace AWS/ECS \
  --metric-name CPUUtilization \
  --dimensions Name=ClusterName,Value=$PROJETO Name=ServiceName,Value=${PROJETO}-api \
  --start-time 2025-09-05T21:55:00Z --end-time 2025-09-05T22:30:00Z \
  --period 60 --statistics Average Maximum \
  --query "sort_by(Datapoints,&Timestamp)[].[Timestamp,Average,Maximum]" --output table
# Na Cadencia: media entre 31% e 36%, maximo de 41%. O alvo era 70%.

# 3. E a dor, no mesmo intervalo? Aqui esta o contraste que faz a figura.
aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
  --metric-name TargetResponseTime \
  --dimensions Name=LoadBalancer,Value=$LBSUF Name=TargetGroup,Value=$TGSUF \
  --start-time 2025-09-05T21:55:00Z --end-time 2025-09-05T22:30:00Z \
  --period 60 --extended-statistics p99 \
  --query "sort_by(Datapoints,&Timestamp)[].[Timestamp,ExtendedStatistics.p99]" --output table
# Na Cadencia: 0,41 s antes, 9,2 s no pico. CPU plana, latencia 22x pior.

// O que `describe-scaling-activities` devolve quando a politica age. Este e o
// objeto que responde "quando ela decidiu", e a diferenca entre o inicio da
// rampa e o `StartTime` daqui e o atraso total, medido.
{
  "ActivityId": "e6c5f1a1-8d2e-4a44-9c31-7b0f2d9a4c88",
  "ServiceNamespace": "ecs",
  "ResourceId": "service/ffv-lab/ffv-lab-api",
  "ScalableDimension": "ecs:service:DesiredCount",
  "Description": "Setting desired count to 9.",
  // A causa cita o alarme, o valor observado e o LIMIAR — e e por isso que
  // ela vale mais que o painel: ela diz o que a politica enxergou.
  "Cause": "monitor alarm TargetTracking-service/ffv-lab/ffv-lab-api-AlarmHigh-... in state ALARM triggered policy ffv-lab-api-chegada",
  "StartTime": "2026-09-05T22:01:47.318Z",
  "EndTime": "2026-09-05T22:01:49.902Z",
  "StatusCode": "Successful",
  // Repare: o EndTime e dois segundos depois. A politica termina aqui, e a
  // CAPACIDADE nao chegou — faltam a partida da task e o health check. Medir
  // escala por este campo e o erro que faz a escala parecer instantanea.
  "StatusMessage": "Successfully set desired count to 9. Change successfully fulfilled by ecs."
}

// carga.js — o teste que produz o alvo, e depois o grafico do evento
//
// Roda com: k6 run -e URL=https://api.exemplo.com carga.js
// Nao e um teste de estresse ate a quebra: aquilo e o L40. Aqui o objetivo e
// outro e mais estreito — descobrir DUAS coisas com numero:
//   1. quantas requisicoes por segundo UMA task sustenta dentro do SLO;
//   2. se a metrica candidata e proporcional a capacidade.

import http from 'k6/http';
import { check } from 'k6';
import { Trend } from 'k6/metrics';

const latencia = new Trend('latencia_ms', true);

export const options = {
  scenarios: {
    // ── Fase 1: escada, com a frota TRAVADA em 1 task ─────────────────────────
    // Travar a frota e a parte que quase todo mundo esquece. Com escala ligada,
    // o teste mede o conjunto e nao a peca, e o teto por task sai errado.
    // Suspenda a escala antes:
    //   aws application-autoscaling register-scalable-target ... \
    //     --suspended-state DynamicScalingInSuspended=true,DynamicScalingOutSuspended=true
    escada: {
      executor: 'ramping-arrival-rate',
      startRate: 5, timeUnit: '1s',
      preAllocatedVUs: 200, maxVUs: 800,
      stages: [
        { target: 10, duration: '3m' },  // cada patamar dura 3 min: 1 min para
        { target: 20, duration: '3m' },  // aquecer e 2 min de leitura estavel.
        { target: 30, duration: '3m' },  // Patamar curto le transiente, nao regime.
        { target: 40, duration: '3m' },
        { target: 50, duration: '3m' },
      ],
    },
  },
  thresholds: {
    // O SLO e o criterio de teto: a task nao "cai" em 40 req/s, ela sai do SLO.
    'http_req_duration{expected_response:true}': ['p(99)<800'],
    'http_req_failed': ['rate<0.001'],
  },
};

export default function () {
  const r = http.get(`${__ENV.URL}/api/catalogo/${__ENV.LOJA}`);
  latencia.add(r.timings.duration);
  check(r, { 'status 200': (x) => x.status === 200 });
}

// ── Fase 2: o teste de PROPORCIONALIDADE ─────────────────────────────────────
// Repita a fase 1 com desiredCount = 2, no MESMO patamar de pico da fase 1.
// A metrica candidata tem de cair pela metade. Resultado na aplicacao de exemplo:
//
//   metrica              1 task @30 req/s   2 tasks @30 req/s   proporcional?
//   CPUUtilization              34%                33%              NAO
//   MemoryUtilization           61%                60%              NAO
//   RequestCountPerTarget    1.800/min           900/min            SIM
//
// A CPU nao cai porque a task nao estava usando CPU: estava esperando o banco.
// A memoria nao cai porque o coletor de lixo do .NET mantem o heap alocado — a
// AWS recomenda explicitamente NAO escalar aplicacao .NET por memoria, por isso.
// A contagem por alvo cai pela metade por construcao: o ALB divide pelo numero
// de alvos saudaveis. Este quadro e o que decide a metrica; nao a preferencia.

// ── Fase 3: o EVENTO, com a escala religada ──────────────────────────────────
// Reproduza a rampa real da campanha — 25 para 260 req/s em 90 s — e deixe as
// politicas trabalharem. O grafico deste evento e o entregavel do laboratorio.
export const rampaDaCampanha = {
  executor: 'ramping-arrival-rate',
  startRate: 25, timeUnit: '1s',
  preAllocatedVUs: 500, maxVUs: 3000,
  stages: [
    { target: 25, duration: '3m' },   // regime, para a linha de base existir
    { target: 260, duration: '90s' }, // a rampa: e ela que testa os atrasos
    { target: 260, duration: '10m' }, // o platô: e aqui que se ve se estabilizou
    { target: 25, duration: '5m' },   // a descida: e aqui que se ve se oscila
  ],
};

# escala-alvo.tf — o alvo escalavel e o regime

# O "alvo escalavel" nao e um recurso da ECS: e um registro no Application Auto
# Scaling dizendo QUAL dimensao de QUAL recurso pode ser mexida, e entre que
# limites. Sem ele, nenhuma politica tem onde se prender.
resource "aws_appautoscaling_target" "api" {
  service_namespace  = "ecs"
  resource_id        = "service/${aws_ecs_cluster.principal.name}/${aws_ecs_service.api.name}"
  scalable_dimension = "ecs:service:DesiredCount"

  # PISO: 4 tasks, duas por AZ. Nao e o minimo para atender o regime (2 dariam);
  # e o minimo para uma falha de AZ nao cortar a capacidade pela metade no pico.
  min_capacity = 4

  # TETO: derivado do banco, nao do orcamento. 40 tasks x pool de 10 = 400
  # conexoes. Leia o max_connections EFETIVO do seu grupo de parametros antes de
  # copiar este numero — no RDS ele e derivado da memoria da instancia.
  #   aws rds describe-db-parameters --db-parameter-group-name <grupo> \
  #     --query "Parameters[?ParameterName=='max_connections']"
  max_capacity = 40
}

# ── O REGIME: target tracking na metrica de CHEGADA ───────────────────────────
resource "aws_appautoscaling_policy" "chegada" {
  name               = "${var.projeto}-api-chegada"
  policy_type        = "TargetTrackingScaling"
  service_namespace  = aws_appautoscaling_target.api.service_namespace
  resource_id        = aws_appautoscaling_target.api.resource_id
  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension

  target_tracking_scaling_policy_configuration {
    # 1.200 requisicoes por MINUTO por alvo. A unidade e por minuto: o teto
    # medido de 30 req/s da 1.800 req/min, e 0,67 disso da 1.200. Ler este valor
    # como "por segundo" erra o alvo por um fator de 60 — e a politica passa a
    # escalar para 60x a capacidade necessaria.
    target_value = 1200

    predefined_metric_specification {
      predefined_metric_type = "ALBRequestCountPerTarget"

      # O rotulo do recurso e a concatenacao dos sufixos dos dois ARNs, separados
      # por barra: app/<nome>/<id>/targetgroup/<nome>/<id>. `arn_suffix` devolve
      # exatamente essas duas partes, e e por isso que ele existe no provider.
      # Montar essa string a mao com o ARN completo e o erro numero um aqui: a
      # politica e criada, o alarme nao encontra a metrica e nada escala.
      resource_label = "${aws_lb.principal.arn_suffix}/${aws_lb_target_group.api.arn_suffix}"
    }

    # SUBIDA: 60 s em vez dos 300 s padrao para ECS. Com uma rampa de 90 s, o
    # padrao permite UMA leva de capacidade e depois cinco minutos de espera.
    scale_out_cooldown = 60

    # DESCIDA: 300 s, e de proposito mais longo que a subida. O target tracking
    # ja e conservador na descida por conta propria — ele so remove capacidade
    # quando a metrica cai bem abaixo do alvo, tipicamente mais de 10% abaixo,
    # justamente para nao oscilar. O cooldown longo reforca isso.
    scale_in_cooldown = 300

    # Deixado explicitamente em false: queremos que ele desca. Ligar
    # `disable_scale_in` faz sentido quando a descida vai ser feita por OUTRA
    # politica (step scaling na descida), e nao para "evitar risco" — nesse caso
    # o que se ganha em seguranca se paga em fatura todos os dias.
    disable_scale_in = false
  }
}

# ── PISO DE SEGURANCA: utilizacao em alta resolucao ───────────────────────────
# Segunda politica de target tracking, permitida porque usa OUTRA metrica. Ela
# existe para o caso em que a chegada nao explica a carga: uma consulta que
# ficou caro por regressao de indice sobe a CPU sem subir o numero de
# requisicoes. Com duas politicas, a ECS SOBE se qualquer uma pedir e so DESCE
# se todas concordarem — a prioridade e disponibilidade, por projeto.
resource "aws_appautoscaling_policy" "utilizacao" {
  name               = "${var.projeto}-api-cpu-20s"
  policy_type        = "TargetTrackingScaling"
  service_namespace  = aws_appautoscaling_target.api.service_namespace
  resource_id        = aws_appautoscaling_target.api.resource_id
  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension

  target_tracking_scaling_policy_configuration {
    target_value = 70

    predefined_metric_specification {
      # A variante de alta resolucao avalia a metrica a cada 20 s em vez de 60.
      # Ela EXIGE que o servico tenha a configuracao de monitoramento com
      # resolutionSeconds = 20 aplicada e implantada ANTES — senao a politica e
      # criada e nao encontra pontos de metrica no periodo que espera.
      predefined_metric_type = "ECSServiceAverageCPUUtilizationHighResolution"
    }

    scale_out_cooldown = 60
    scale_in_cooldown  = 300
  }
}

# escala-degrau.tf — o degrau subito e a campanha com data

# O alarme e SEU: no step scaling voce escreve o limiar, a estatistica e o numero
# de periodos. E o oposto do target tracking, onde a politica cria e administra os
# alarmes e a documentacao pede explicitamente para voce NAO os editar.
resource "aws_cloudwatch_metric_alarm" "chegada_dobrou" {
  alarm_name  = "${var.projeto}-api-chegada-dobrou"
  namespace   = "AWS/ApplicationELB"
  metric_name = "RequestCountPerTarget"

  # A unica estatistica valida para esta metrica e Sum — e, apesar do nome, o
  # valor JA e a media por alvo: o ALB divide a contagem do grupo pelo numero de
  # alvos saudaveis. Pedir Average aqui devolve um numero sem significado, e e a
  # pegadinha mais comum desta metrica.
  statistic = "Sum"

  period             = 60
  evaluation_periods = 1 # um periodo: sensibilidade comprada com risco de ruido

  # 2.400 = o dobro do alvo do regime. Abaixo disso, o target tracking resolve
  # com proporcionalidade e sem degrau. A margem em relacao ao alvo e o que evita
  # as duas politicas brigarem pela mesma variavel.
  threshold           = 2400
  comparison_operator = "GreaterThanThreshold"

  # A metrica e sempre publicada quando ha alvos registrados, mas ausencia de
  # trafego nao e violacao — e a madrugada nao pode acordar ninguem.
  treat_missing_data = "notBreaching"

  dimensions = {
    LoadBalancer = aws_lb.principal.arn_suffix
    TargetGroup  = aws_lb_target_group.api.arn_suffix
  }

  # O alarme dispara a POLITICA, nao um topico SNS. Este e o ponto que confunde:
  # a acao de alarme aqui e o ARN da politica de escala.
  alarm_actions = [aws_appautoscaling_policy.degrau.arn]
}

resource "aws_appautoscaling_policy" "degrau" {
  name               = "${var.projeto}-api-degrau"
  policy_type        = "StepScaling"
  service_namespace  = aws_appautoscaling_target.api.service_namespace
  resource_id        = aws_appautoscaling_target.api.resource_id
  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension

  step_scaling_policy_configuration {
    # Percentual, nao numero absoluto: +50% em 4 tasks sao 2, e em 20 tasks sao
    # 10. Um degrau de "+6 tasks" seria exagero no regime e insuficiente no pico.
    adjustment_type = "PercentChangeInCapacity"

    # Com PercentChangeInCapacity, 50% de 4 tasks arredonda para 2. O minimo
    # explicito impede que a frota pequena receba um degrau irrelevante.
    min_adjustment_magnitude = 2

    # A agregacao e aplicada aos pontos mais recentes ANTES de comparar com os
    # limites dos degraus. Average e o padrao de fato desta escolha; Maximum
    # tornaria o degrau mais agressivo e mais suscetivel a um pico isolado.
    metric_aggregation_type = "Average"

    # Curto de proposito: o degrau existe para responder rapido. O cooldown do
    # step scaling tambem conta a capacidade recem-adicionada como parte da
    # capacidade desejada do proximo degrau, entao ele nao empilha cegamente.
    cooldown = 60

    # Os limites sao RELATIVOS ao limiar do alarme (2.400), nao absolutos. De
    # 0 a 1.200 acima (ou seja, de 2.400 a 3.600): +50%. Acima de 1.200 acima
    # (mais de 3.600 por alvo): +100%. Os intervalos nao podem se sobrepor nem
    # deixar lacuna, e exatamente um deles pode ter limite superior nulo.
    step_adjustment {
      metric_interval_lower_bound = 0
      metric_interval_upper_bound = 1200
      scaling_adjustment          = 50
    }

    step_adjustment {
      metric_interval_lower_bound = 1200
      scaling_adjustment          = 100
    }
  }
}

# ── A CAMPANHA: capacidade planejada, sem metrica no caminho ──────────────────
# A acao programada nao observa nada, e e por isso que ela nao tem atraso. Ela
# mexe nos LIMITES do alvo escalavel, nao no desiredCount: elevar o MinCapacity
# obriga o servico a subir, e as politicas reativas continuam trabalhando por
# cima desse piso novo. Acao programada tambem dispara durante um cooldown, sem
# esperar ele terminar.
resource "aws_appautoscaling_scheduled_action" "campanha_sobe" {
  name               = "${var.projeto}-api-campanha-sobe"
  service_namespace  = aws_appautoscaling_target.api.service_namespace
  resource_id        = aws_appautoscaling_target.api.resource_id
  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension

  # 15 min antes do disparo do e-mail, com folga para os quatro atrasos e para o
  # health check. O fuso e explicito: sem `timezone`, o cron e interpretado em
  # UTC, e uma campanha marcada para 19h no Brasil sairia as 16h.
  schedule = "cron(45 18 5 9 ? 2026)"
  timezone = "America/Sao_Paulo"

  scalable_target_action {
    # 14 tasks: as 13 que o teste de carga mostrou necessarias para 260 req/s,
    # mais uma de folga. Nao e chute — sai da divisao da chegada prevista pelo
    # alvo por alvo.
    min_capacity = 14
    max_capacity = 40
  }
}

resource "aws_appautoscaling_scheduled_action" "campanha_desce" {
  name               = "${var.projeto}-api-campanha-desce"
  service_namespace  = aws_appautoscaling_target.api.service_namespace
  resource_id        = aws_appautoscaling_target.api.resource_id
  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension

  # Duas horas depois. Devolver o piso NAO derruba tasks: ele apenas deixa de
  # obrigar. Quem remove capacidade e a politica reativa, quando a chegada cair —
  # e ela e conservadora nisso de proposito. Sem esta segunda acao, o piso de 14
  # tasks continua valendo para sempre, e e o erro de esquecimento mais caro
  # deste laboratorio.
  schedule = "cron(0 21 5 9 ? 2026)"
  timezone = "America/Sao_Paulo"

  scalable_target_action {
    min_capacity = 4
    max_capacity = 40
  }
}

// Program.cs — a aplicacao que nao mente sobre a propria carga

var builder = WebApplication.CreateBuilder(args);

// ── O TETO DE CONEXOES, EXPLICITO ─────────────────────────────────────────────
// O padrao do Npgsql para MaxPoolSize e generoso o suficiente para que 40 tasks
// esgotem um Postgres pequeno. Como a escala automatica multiplica o numero de
// tasks, o tamanho do pool deixa de ser detalhe de aplicacao e passa a ser um
// parametro de capacidade: max_capacity x MaxPoolSize <= max_connections do banco,
// com folga para manutencao e para a conexao de administracao.
var conexao = new NpgsqlConnectionStringBuilder(
    builder.Configuration.GetConnectionString("Padrao"))
{
    MaxPoolSize = builder.Configuration.GetValue("DB_POOL_MAX", 10),
    MinPoolSize = 2,
    // Fila interna curta: e melhor a requisicao falhar rapido e o retry com
    // backoff do L36 tratar, do que 200 requisicoes esperando pool em silencio
    // e estourando o tempo do ALB. Fila invisivel e o que faz a CPU ficar plana
    // enquanto a latencia sobe.
    Timeout = 5,
    CommandTimeout = 8,
}.ToString();

builder.Services.AddDbContextPool<AppDb>(o => o.UseNpgsql(conexao));

// ── A METRICA QUE A APLICACAO SABE E O ALB NAO ────────────────────────────────
// `ALBRequestCountPerTarget` mede a chegada, e e a metrica de regime. Ela nao
// enxerga uma coisa: requisicao que chegou e esta ESPERANDO dentro da task. Para
// um servidor limitado por concorrencia, a AWS recomenda a propria aplicacao
// publicar concorrencia como metrica personalizada, ao menos uma vez por minuto.
// Publicamos porque e o insumo do teste de carga da secao seguinte — e porque e
// o que permite decidir o teto por task com numero em vez de intuicao.
builder.Services.AddSingleton<MedidorDeConcorrencia>();
builder.Services.AddOpenTelemetry()
    .WithMetrics(m => m
        .AddMeter("Cadencia.Api")
        .AddOtlpExporter()); // coletor ADOT; o caminho e o do L08

var app = builder.Build();

// Middleware que conta requisicoes em voo. Uma unica variavel, incrementada na
// entrada e decrementada na saida — barato o suficiente para o caminho quente.
app.Use(async (ctx, next) =>
{
    var medidor = ctx.RequestServices.GetRequiredService<MedidorDeConcorrencia>();
    medidor.Entrou();
    try { await next(); }
    finally { medidor.Saiu(); }
});

// As duas rotas de saude do L03 continuam valendo, e agora carregam um segundo
// papel: durante a escala, `/health/ready` e o que decide QUANDO a task nova
// entra na conta de alvos saudaveis — e portanto quando ela passa a dividir o
// `RequestCountPerTarget`. Prontidao que mente encurta o atraso na aparencia e
// nao na pratica: a task entra na divisao antes de poder atender, o valor por
// alvo cai, a politica para de escalar, e a latencia continua subindo.
app.MapHealthChecks("/health/live", new HealthCheckOptions { Predicate = r => r.Tags.Contains("live") });
app.MapHealthChecks("/health/ready", new HealthCheckOptions { Predicate = r => r.Tags.Contains("ready") });

app.MapGet("/api/catalogo/{lojaId:guid}", async (Guid lojaId, AppDb db) =>
    // Esta e a rota da campanha, e e ela que define o perfil da aplicacao: uma
    // consulta, pouca CPU, muita espera. Por isso a CPU nao e metrica de escala
    // aqui — nao por ser "ruim", mas por nao ser proporcional a capacidade nesta
    // forma de trabalho.
    Results.Ok(await db.Produtos.Where(x => x.LojaId == lojaId).Take(50).ToListAsync()));

app.Run();

// A classe do medidor: o `ObservableGauge` e lido no momento da coleta, o que
// evita publicar um ponto por requisicao e explodir a cardinalidade.
public sealed class MedidorDeConcorrencia
{
    private static readonly Meter Meter = new("Cadencia.Api");
    private int _emVoo;

    public MedidorDeConcorrencia() =>
        Meter.CreateObservableGauge("api.requisicoes.em_voo", () => Volatile.Read(ref _emVoo));

    public void Entrou() => Interlocked.Increment(ref _emVoo);
    public void Saiu() => Interlocked.Decrement(ref _emVoo);
}

# alta-resolucao.sh — os 20 s de metrica, e a ordem que nao pode ser trocada
set -euo pipefail
PROJETO=ffv-lab; REGIAO=us-east-1

# ATENCAO A ORDEM. A politica de alta resolucao espera pontos a cada 20 s. Se
# voce a criar ANTES de o servico publicar nessa resolucao, ela e criada com
# sucesso e nao encontra dado — e o sintoma e "escala configurada que nao faz
# nada", identico ao sintoma da metrica errada.

# ── 1. Ligar a configuracao de monitoramento no servico ───────────────────────
# Isto cria uma REVISAO nova do servico e dispara uma implantacao: e um rollout,
# com os mesmos tres relogios do L03. Nao faca isto durante a campanha.
aws ecs update-service --region "$REGIAO" \
  --cluster "$PROJETO" --service "${PROJETO}-api" \
  --monitoring 'metricConfigurations=[{metricNames=[CPUUtilization,MemoryUtilization],resolutionSeconds=20}]'

aws ecs wait services-stable --cluster "$PROJETO" --services "${PROJETO}-api" --region "$REGIAO"

# ── 2. Confirmar que a configuracao esta ATIVA ────────────────────────────────
# A configuracao de monitoramento NAO volta na resposta de create-service nem de
# update-service. Ela aparece na revisao do servico, e e ali que se confere.
REV=$(aws ecs describe-services --cluster "$PROJETO" --services "${PROJETO}-api" \
        --query 'services[0].deployments[0].serviceRevisionArn' --output text)
aws ecs describe-service-revisions --service-revision-arns "$REV" \
  --query 'serviceRevisions[0].monitoring'
# Esperado: {"metricConfigurations":[{"metricNames":["CPUUtilization","MemoryUtilization"],
#            "resolutionSeconds":20}]}

# ── 3. Confirmar que os PONTOS existem a cada 20 s ────────────────────────────
# Esta e a prova real: periodo de 20 s tem de devolver tres pontos por minuto.
# Se devolver um, a implantacao terminou mas as tasks antigas ainda publicavam em
# 60 s — espere o rollout completar em todas.
aws cloudwatch get-metric-statistics --namespace AWS/ECS --metric-name CPUUtilization \
  --dimensions Name=ClusterName,Value="$PROJETO" Name=ServiceName,Value="${PROJETO}-api" \
  --start-time "$(date -u -v-10M +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 20 --statistics Average \
  --query 'length(Datapoints)'
# Esperado: proximo de 30 numa janela de 10 min. Se vier proximo de 10, a
# resolucao ainda e de 60 s e a politica de alta resolucao nao deve ser criada.

# ── 4. So AGORA a politica ────────────────────────────────────────────────────
terraform apply -target=aws_appautoscaling_policy.utilizacao -auto-approve

# NAO VERIFICADO NA DOCUMENTACAO: se o provider Terraform da sua versao ja expoe
# a configuracao de monitoramento como bloco em `aws_ecs_service`. Em ago/2026 o
# caminho que confirmamos e o da CLI acima; se o seu provider ja tiver o bloco,
# use-o e remova este script, porque configuracao fora do IaC volta a divergir.

# provas.sh — cinco medicoes. Nenhuma conclusao sai de "parece que escalou"
PROJETO=ffv-lab; REGIAO=us-east-1
RES="service/${PROJETO}/${PROJETO}-api"
TGSUF=$(aws elbv2 describe-target-groups --names "${PROJETO}-api" \
          --query 'TargetGroups[0].TargetGroupArn' --output text | sed 's|.*:||')
LBSUF=$(aws elbv2 describe-load-balancers --names "$PROJETO" \
          --query 'LoadBalancers[0].LoadBalancerArn' --output text | sed 's|.*:loadbalancer/||')

# ── Prova 1: a linha do tempo da escala, com carimbo de hora ──────────────────
# E a prova central. Compare o `StartTime` da primeira atividade com o instante
# em que a rampa comecou: a diferenca E o atraso total, medido, e nao estimado.
aws application-autoscaling describe-scaling-activities \
  --service-namespace ecs --resource-id "$RES" \
  --query 'ScalingActivities[].{inicio:StartTime,fim:EndTime,causa:Cause,status:StatusCode}' \
  --output table
# Esperado no desenho de producao: primeira atividade dentro de 120 s do inicio
# da rampa. Acima de 240 s, o atraso 1 ou o 2 ainda esta no padrao.
# Se a lista vier VAZIA depois de um pico inteiro, a politica nunca disparou —
# e o problema e a metrica, nao o alvo. Va para a prova 2.

# ── Prova 2: a metrica escolhida e proporcional a capacidade? ─────────────────
# Duas leituras da MESMA carga com contagens de task diferentes. Se o valor nao
# cai perto da metade, a metrica nao serve para escalar — e a AWS exige essa
# propriedade, nao e preferencia nossa.
for N in 1 2; do
  aws application-autoscaling register-scalable-target --service-namespace ecs \
    --resource-id "$RES" --scalable-dimension ecs:service:DesiredCount \
    --suspended-state DynamicScalingInSuspended=true,DynamicScalingOutSuspended=true
  aws ecs update-service --cluster "$PROJETO" --service "${PROJETO}-api" --desired-count $N
  aws ecs wait services-stable --cluster "$PROJETO" --services "${PROJETO}-api"
  echo "== $N task(s) =="; k6 run -e URL="https://$(terraform output -raw dominio)" carga.js
done
# Esperado: RequestCountPerTarget cai ~50%; CPUUtilization NAO cai. O quadro da
# fase 2 do carga.js e o resultado desta prova, e ele e o que justifica a metrica.

# ── Prova 3: o grafico do evento — o entregavel, como arquivo ────────────────
# `get-metric-widget-image` devolve PNG. Tres series no mesmo eixo: chegada por
# alvo (a demanda), alvos saudaveis (a capacidade que de fato serve) e p99 (a dor).
cat > widget.json <<'JSON'
{ "width": 1200, "height": 500, "start": "-PT45M", "end": "PT0H",
  "title": "Campanha: chegada por alvo x capacidade saudavel x p99",
  "yAxis": { "left": { "label": "req/min por alvo" }, "right": { "label": "alvos / ms" } },
  "metrics": [
    [ "AWS/ApplicationELB", "RequestCountPerTarget", "TargetGroup", "TGSUF", { "stat": "Sum", "period": 60 } ],
    [ "AWS/ApplicationELB", "HealthyHostCount", "TargetGroup", "TGSUF", "LoadBalancer", "LBSUF",
      { "stat": "Minimum", "period": 60, "yAxis": "right" } ],
    [ "AWS/ApplicationELB", "TargetResponseTime", "TargetGroup", "TGSUF", "LoadBalancer", "LBSUF",
      { "stat": "p99", "period": 60, "yAxis": "right" } ]
  ],
  "annotations": { "horizontal": [ { "value": 1200, "label": "alvo da politica" } ] } }
JSON
sed -i '' "s/TGSUF/$TGSUF/g; s|LBSUF|$LBSUF|g" widget.json
aws cloudwatch get-metric-widget-image --metric-widget file://widget.json \
  --output-format png --output text --query MetricWidgetImage | base64 --decode > evento.png
# Esperado: a chegada por alvo sobe, cruza a linha de 1.200, os alvos saudaveis
# sobem ATRAS dela, e o p99 tem um corcova que termina quando as curvas se
# reencontram. A AREA dessa corcova e a fatia de pico que o cliente engoliu, e e
# o numero que se leva para a reuniao. Usamos HealthyHostCount e nao
# RunningTaskCount de proposito: o segundo exige Container Insights, que cobra
# como metrica personalizada, e o primeiro ja diz o que interessa — quantos
# alvos de fato estavam servindo.

# ── Prova 4: o teto de conexoes nao foi estourado ────────────────────────────
# Escalar a camada de task sem esta prova troca 504 por conexao recusada, e o
# segundo erro e pior: ele atinge tambem quem nao estava no pico.
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value="${PROJETO}-db" \
  --start-time "$(date -u -v-45M +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 60 --statistics Maximum --query 'max_by(Datapoints,&Maximum).Maximum'
# Esperado: abaixo de 70% do max_connections efetivo do seu grupo de parametros.
# Compare com o valor real, nao com um numero decorado:
aws rds describe-db-parameters --db-parameter-group-name "${PROJETO}-pg" \
  --query "Parameters[?ParameterName=='max_connections'].[ParameterValue]" --output text

# ── Prova 5: a acao programada elevou o piso, e devolveu depois ──────────────
# A que mais se esquece de conferir. Um piso que subiu e nao voltou e capacidade
# paga por mes inteiro por causa de uma campanha de vinte minutos.
aws application-autoscaling describe-scalable-targets --service-namespace ecs \
  --resource-ids "$RES" \
  --query 'ScalableTargets[].{min:MinCapacity,max:MaxCapacity}' --output table
aws application-autoscaling describe-scheduled-actions --service-namespace ecs \
  --resource-id "$RES" \
  --query 'ScheduledActions[].{nome:ScheduledActionName,quando:Schedule,fuso:Timezone,acao:ScalableTargetAction}' \
  --output table
# Esperado: min de volta em 4 depois da janela, e DUAS acoes programadas — a que
# sobe e a que desce. Uma so e o defeito.

// politica-de-quem-configura-escala.json
// Esta e a permissao de quem APLICA o Terraform — nao a de quem escala em tempo
// de execucao. Quem escala e a funcao vinculada ao servico do Application Auto
// Scaling (AWSServiceRoleForApplicationAutoScaling_ECSService), que a AWS cria e
// administra. Confundir as duas e o erro classico: pessoas acrescentam
// `application-autoscaling:*` a task role da aplicacao, onde ela nao faz nada.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ConfigurarEscala",
      "Effect": "Allow",
      "Action": [
        "application-autoscaling:RegisterScalableTarget",
        "application-autoscaling:DeregisterScalableTarget",
        "application-autoscaling:PutScalingPolicy",
        "application-autoscaling:DeleteScalingPolicy",
        "application-autoscaling:PutScheduledAction",
        "application-autoscaling:DeleteScheduledAction",
        "application-autoscaling:Describe*"
      ],
      // As acoes do Application Auto Scaling nao suportam permissao em nivel de
      // recurso: nao existe ARN de alvo escalavel para colocar aqui. O escopo
      // real vem da condicao abaixo, que limita ao namespace da ECS, e das
      // permissoes de ECS deste mesmo documento. Sem esta frase o `*` seria
      // preguica; com ela, e limite do servico.
      "Resource": "*",
      "Condition": {
        "StringEquals": { "application-autoscaling:service-namespace": "ecs" }
      }
    },
    {
      "Sid": "AlarmesQueEuMesmoEscrevo",
      "Effect": "Allow",
      // Apenas o alarme do degrau: os alarmes do target tracking sao criados e
      // apagados pela propria politica, e a documentacao pede explicitamente
      // para nao edita-los. Restringimos por ARN de alarme, com prefixo do
      // projeto — o que o `Describe` nao aceita, porque ele nao suporta recurso.
      "Action": ["cloudwatch:PutMetricAlarm", "cloudwatch:DeleteAlarms"],
      "Resource": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:ffv-lab-api-*"
    },
    {
      "Sid": "LerAlarmeNaoAceitaRecurso",
      "Effect": "Allow",
      // `DescribeAlarms` e operacao de listagem e nao suporta recurso especifico.
      // E a segunda ocorrencia legitima de `*` neste documento, e tambem vem com
      // a frase que a justifica.
      "Action": ["cloudwatch:DescribeAlarms", "cloudwatch:GetMetricData"],
      "Resource": "*"
    },
    {
      "Sid": "MexerNoServicoAlvo",
      "Effect": "Allow",
      "Action": ["ecs:UpdateService", "ecs:DescribeServices"],
      // Aqui o recurso EXISTE e e estreito: um servico, num cluster. Escrever
      // `*` neste bloco autorizaria mexer em qualquer servico da conta.
      "Resource": "arn:aws:ecs:us-east-1:111122223333:service/ffv-lab/ffv-lab-api"
    },
    {
      "Sid": "CriarAFuncaoVinculadaUmaVez",
      "Effect": "Allow",
      "Action": "iam:CreateServiceLinkedRole",
      "Resource": "*",
      // A condicao e o que impede esta linha de ser um caminho para criar
      // funcao vinculada de QUALQUER servico. Sem ela, `CreateServiceLinkedRole`
      // e uma escalada de privilegio de aparencia inocente.
      "Condition": {
        "StringEquals": {
          "iam:AWSServiceName": "ecs.application-autoscaling.amazonaws.com"
        }
      }
    }
  ]
}

# limpar.sh — a ordem importa, e o que sobra aqui cobra por hora
set -euo pipefail
PROJETO=ffv-lab
RES="service/${PROJETO}/${PROJETO}-api"

# 1. PRIMEIRO devolva o piso. Se voce apagar a acao programada que DESCE antes de
#    ela rodar, o piso elevado da campanha fica valendo — e 14 tasks ligadas por
#    um mes e a fatura surpresa mais comum deste laboratorio.
aws application-autoscaling register-scalable-target --service-namespace ecs \
  --resource-id "$RES" --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 1 --max-capacity 2

# 2. Depois o Terraform. Ele remove politicas, acoes programadas, alarmes e o
#    registro do alvo escalavel.
terraform destroy -auto-approve

# 3. ALVO ESCALAVEL ORFAO: se o destroy foi interrompido, o registro pode
#    sobreviver. Ele nao cobra nada por si, mas mantem politicas ativas mexendo
#    num servico que voce acha que abandonou.
aws application-autoscaling describe-scalable-targets --service-namespace ecs \
  --query 'ScalableTargets[].ResourceId' --output table
aws application-autoscaling deregister-scalable-target --service-namespace ecs \
  --resource-id "$RES" --scalable-dimension ecs:service:DesiredCount 2>/dev/null || true

# 4. ALARMES DO TARGET TRACKING: sao criados pela politica, nao pelo Terraform, e
#    a remocao da politica costuma leva-los. "Costuma" nao e "sempre" quando
#    houve interrupcao — confira por prefixo e apague o que sobrou.
aws cloudwatch describe-alarms --alarm-name-prefix TargetTracking \
  --query 'MetricAlarms[].AlarmName' --output table
aws cloudwatch describe-alarms --alarm-name-prefix "${PROJETO}-api" \
  --query 'MetricAlarms[].AlarmName' --output table

# 5. A CONFIGURACAO DE MONITORAMENTO DE 20 s continua no servico e continua
#    cobrando metrica de alta resolucao enquanto o servico existir. Ela NAO sai
#    com a politica de escala: sao objetos diferentes.
aws ecs update-service --cluster "$PROJETO" --service "${PROJETO}-api" \
  --monitoring 'metricConfigurations=[]' 2>/dev/null || true

# 6. E o que veio do L01 e cobra por hora, ligado ou nao: ALB, RDS, NAT Gateway e
#    o Elastic IP dele. O Elastic IP cobra justamente por NAO estar associado.
aws ec2 describe-addresses --query "Addresses[?AssociationId==null].PublicIp" --output table

# 7. Prova final: se o serviço ainda existe, ele tem de estar no desiredCount
#    minimo — e nenhuma politica pode estar de pe para mudar isso.
aws ecs describe-services --cluster "$PROJETO" --services "${PROJETO}-api" \
  --query 'services[0].{desejado:desiredCount,rodando:runningCount}' --output table
aws application-autoscaling describe-scaling-policies --service-namespace ecs \
  --query 'length(ScalingPolicies)' --output text   # esperado: 0