Métricas por conector e o que é NÃO MEDIDO

Selo de estado: Preview (teto atual do produto) · Curso ACD-230 — Operação: orquestração, falhas e recuperação · Aula 6 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai ler as métricas de saúde de um conector e explicar por que a certificação operacional de 30 dias é um gate humano ainda pendente.

Vídeo#

Identificador no manifesto: acd-230-06-observabilidade-por-conector · duração-alvo 5 min · tela do produto: /dags.

Roteiro (4 capítulos):

Conteúdo#

O conceito: saúde de conector é agregação de eventos

Cada operação de extração emite uma linha de telemetria (linhas, bytes, milissegundos, sucesso ou erro). A telemetria nunca derruba a extração — se ela falhar, a carga continua. Sobre esse acervo, o produto agrega quatro coisas por conector: número de execuções, taxa de erro, percentis de latência (p50/p95) e freshness (há quanto tempo o conector rodou pela última vez, e quando foi a última execução bem-sucedida).

Os limiares são fixos e públicos, e produzem três estados:

O limiar de 26 horas existe porque o caso típico é carga diária: 26 h dá folga para atraso de fila sem acusar um conector sadio. Já 72 h significa que algo travou — não é oscilação.

Onde você lê isso, nas telas reais

Hoje o operador lê saúde de conector pelo rastro da execução, não por um painel de observabilidade self-service:

• Em Orquestração → Execuções (DAGs) (/dags): a separação entre Falha na última execução e Falhas no período é, na prática, uma leitura de taxa de erro; a coluna de Duração mostra a latência de cada rodada; e o horário de Início com fuso explícito mostra o freshness.
• Na página da fonte (/sources/[id]): o painel de ingestão mostra o histórico daquela origem, a última carga e o estado da agenda.
• No catálogo de conectores (/docs/data/conectores): o estado público de cada conector — Disponível, Acesso limitado ou Planejado — e a maturidade. O catálogo é a verdade; um item Planejado não é uma conexão utilizável.

Seja honesto sobre o que o produto ainda não oferece: não há, hoje, uma tela de "saúde por conector" com os percentis prontos; os limiares acima são a regra que o produto aplica, e a sua leitura no console é indireta.

A certificação de 30 dias: o que a máquina prova e o que só uma pessoa declara

A certificação de um conector roda sondas vivas contra o adaptador real (com transporte injetado, sem rede) e prova, automaticamente:

E há itens que nenhum teste pode declarar: 30 dias de operação com credencial real, reconciliação contra os relatórios do próprio provedor, rotação de token no mundo real e quotas sob tráfego real. Esses são gate humano — e por isso a prontidão para disponibilidade geral é sempre false até alguém assinar. O protocolo prevê conferência em D7, D14, D21 e D30, zero incidentes graves, taxa de execuções agendadas bem-sucedidas acima de 99,5% — e a regra mais importante: nenhum conector é promovido pelo verificador automático, só por decisão humana registrada.

Exemplo: a Comércio Aurora

O conector de vendas da Aurora rodou 30 vezes no mês, com 2 falhas (6,7% — abaixo dos 20%), p95 de 12 s (abaixo de 30 s) e última execução há 4 h. Pelos limiares, saudável. Na semana seguinte, a origem fica instável: 8 falhas em 30 execuções (26,7%) e o conector passa a degradado — ainda carrega, mas o número de erro já cruzou o limiar e pede atenção antes que vire DLQ (aula 3).

Em paralelo, João é perguntado pela diretoria se "o conector do ERP já está pronto para produção". A resposta honesta não é "sim" nem "não": o adaptador passa toda a bateria automática, mas o conector está em Acesso limitado (maturidade Preview) porque os 30 dias com credencial real ainda não foram cumpridos e assinados. O que ele pode prometer: que o produto recusa configurar o que não dá para usar hoje, em vez de deixar o usuário descobrir na execução.

Erros comuns

Estado do produto

A capacidade C09.6 — certificação operacional dos conectores — tem o painel de certificação pronto e coberto por testes, mas a janela de 30 dias reais é gate humano pendente; o claim público permitido é exatamente esse. O teto da plataforma é Preview: sem SLA, sem certificação de nuvem, métricas de nuvem NÃO MEDIDO. Consultar histórico e métricas custa R$ 0.

Faça você mesmo#

Esta é uma aula de conhecimento (kind: conhecer): não há exercício operacional no console. Os passos abaixo são de leitura e observação — nada aqui executa carga nem muda configuração.

1. Em /dags, observe um pipeline da Aurora Varejo e conte, no histórico visível, quantas execuções falharam e quantas concluíram. Estime a taxa de erro e compare com o limiar de 20%.
2. Na mesma lista, olhe a coluna de Duração de várias execuções: a mais lenta ficaria acima ou abaixo dos 30 s de p95?
3. Confira o horário de Início da última execução. Quantas horas atrás? Isso é saudável (< 26 h), degradado (> 26 h) ou parado (> 72 h)?
4. Abra /sources/[id] e localize, no painel de ingestão, a última carga daquela origem — o mesmo sinal de freshness, visto do lado da fonte.
5. Leia o catálogo de conectores e localize o estado público do conector que você usou: Disponível, Acesso limitado ou Planejado.
6. Releia, acima, a tabela "a máquina prova / só uma pessoa declara" e escreva para você mesmo, em uma frase, por que a prontidão para disponibilidade geral é sempre false hoje.

Você terminou quando conseguir classificar um conector em saudável / degradado / parado usando só os limiares, e explicar — sem olhar a aula — a diferença entre "o adaptador passou na bateria automática" e "o conector está certificado para produção".

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• data/agendamento-retry-dlq
• data/conectores

Capacidades ensinadas#

C09.6 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".