Tipos de Condição de Alerta

Detalhes técnicos de no_data, byte_threshold, rate_drop e lag_high com exemplos de uso.

Tipos de Condição

A v1 suporta 4 tipos de condição. Cada um avalia um aspecto diferente da ingestão.

no_data — Ausência de dados

Match se now - last_ingest_at > threshold_seconds para o escopo da regra.

Quando usar: detectar integração quebrada, fonte parou de enviar, ClickPipes pausado.

Campos:

Campo	Tipo	Obrigatório
threshold_seconds	int > 0	Sim

Exemplo:

{
  "name": "Bet placed parou",
  "domain": "sportsbook",
  "event": "bet_placed",
  "condition_type": "no_data",
  "threshold_seconds": 300,
  "severity": "critical"
}

Caso especial: se o heartbeat para a chave não existe (a fonte nunca enviou dados), a regra dispara — assume integração broken.

lag_high — Atraso entre evento e ingestão

Match se last_ingest_at - last_event_at > threshold_seconds.

Quando usar: detectar Kafka backlog, ClickPipes lento, DLQ acumulando.

Diferença de no_data: o evento está chegando, mas com atraso (timestamp do evento muito mais antigo que ingest).

Exemplo:

{
  "name": "Lag de ingestão > 2min",
  "domain": "transaction",
  "condition_type": "lag_high",
  "threshold_seconds": 120,
  "severity": "warning"
}

byte_threshold — Volume acima de limite

Match se sum(bytes_uncompressed) na janela > threshold_bytes.

Quando usar: alerta de quota de plano, detecção de spike anômalo (ex: 10× volume normal indica bug no operador).

Campos:

Campo	Tipo	Default
threshold_bytes	int64	obrigatório
window_seconds	int	300

Exemplo:

{
  "name": "Spike de bytes > 100MB/min",
  "condition_type": "byte_threshold",
  "threshold_bytes": 104857600,
  "window_seconds": 60,
  "severity": "warning"
}

rate_drop — Queda vs baseline

Compara rows_count na janela atual com a média de janelas equivalentes nos últimos baseline_window_days dias.

Match se (1 - current/baseline) * 100 >= threshold_percent.

Quando usar: detectar degradação parcial sem que a fonte fique 100% silenciosa (no_data não pegaria).

Campos:

Campo	Tipo	Default
threshold_percent	float (0-100)	obrigatório
window_seconds	int	300
baseline_window_days	int	7

Exemplo:

{
  "name": "Queda > 50% vs baseline 7d",
  "domain": "sportsbook",
  "condition_type": "rate_drop",
  "threshold_percent": 50,
  "window_seconds": 600,
  "baseline_window_days": 7,
  "severity": "warning"
}

Caso especial: se a fonte é nova (sem baseline >= 1 dia de histórico), a regra não dispara (metric_payload.note = "insufficient_baseline").

Comparação

Detecta	no_data	lag_high	byte_threshold	rate_drop
Fonte 100% parada	✓	✗	✗	✓ (após queda total)
Lag de pipeline	✗	✓	✗	✗
Spike anômalo	✗	✗	✓	✗
Degradação parcial	✗	✗	✗	✓
Quota / cobrança	✗	✗	✓	✗

Recomendação: combine no_data (5 min) + rate_drop (50% queda em 10 min) para cobrir tanto silêncio total quanto degradação.

Avaliação

Tudo roda no alert_runner, worker em goroutine no backend (Go). Tick de 30s:

1. Lista regras enabled (1 query PG)
2. Avalia em batch via AlertEvaluator (1 query CH por strategy)
3. Para cada match em estado ok|resolved + cooldown ok: cria alert_event, dispara canais, marca firing
4. Para cada não-match em estado firing: cria alert_event, dispara resolve, marca resolved

Falhas de despacho (Slack down, etc) são gravadas em alert_events.delivery_status mas não bloqueiam outros canais nem a transição de estado.