Aura Logo
aurabasedocumentos
documentos›Edge Functions›Alertas

Alertas

Como ser informado quando suas funções se comportam mal: as métricas que você pode observar, como as regras são verificadas e como gerenciá-las por HTTP.

5 min lido·Nível intermediário·Revisado em 12 de out. de 2026
Este texto em inglês foi gerado automaticamente a partir do original em francês e ainda não foi revisado.
Esta página foi traduzida automaticamente. A versão em inglês é oficial.
#
Criar

1. Crie uma regra

As regras de alerta são gerenciadas por HTTP com uma chave service_role. O SDK não possui método para eles.

terminalbash
curl -X POST "$AURA_URL/v1/functions/alerts" \
  -H "apikey: $AURA_SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High error rate",
    "metric": "error_rate",
    "condition": "gt",
    "threshold": 5,
    "channel": "email",
    "destination": "oncall@example.com"
  }'
responsejson
{
  "data": {
    "id": "3356d54a-ed32-49df-84bf-94ee64790c78",
    "name": "High error rate",
    "metric": "error_rate",
    "condition": "gt",
    "threshold": 5.0,
    "channel": "email",
    "destination": "oncall@example.com",
    "enabled": true,
    "last_triggered_at": null,
    "created_at": "2026-10-12T15:42:34.721256Z"
  },
  "meta": null
}
#
Referência

2. Métricas, condições e canais

CampoValores permitidos
metricerror_rate, latency_p95, job_failures, low_disk, ai_quota, anomaly_detection ou log_pattern:<service>:<regex>
conditiongt, lt, eq, match, auto
channelemail, webhook, slack
thresholdUm número
destinationUm endereço de e-mail ou o URL do webhook ou gancho do Slack

log_pattern observa os logs de um serviço em busca de uma expressão regular: log_pattern:functions:timeout. Um valor desconhecido retorna 400 e lista os aceitos. Resposta real para metric: "cpu":

errortext
Requête invalide : Métrique inconnue: 'cpu'. Valeurs: error_rate, latency_p95, job_failures, low_disk, ai_quota, anomaly_detection, log_pattern:<service>:<regex>
#
Comportamento

3. Como as regras são verificadas

  • O serviço verifica cada regra habilitada uma vez por minuto.
  • As métricas numéricas são lidas no Prometheus; log_pattern regras consultam Loki. Cada consulta tem um limite de 5 segundos. Se um projeto falhar, os outros ainda serão verificados.
  • Quando uma regra é acionada, o serviço define last_triggered_at, registra um evento e o publica para entrega no canal escolhido.
  • Uma regra desativada é mantida, mas não verificada.
A entrega depende da sua implantação

Os alertas precisam que o Prometheus e o Loki sejam acessíveis a partir do serviço de funções, e o canal de e-mail precisa de um provedor de e-mail. Em uma pilha de desenvolvimento sem eles, uma regra é armazenada, mas não pode ser acionada.

#
Operar

4. Gerencie regras e histórico

AçãoSolicitação
Listar regrasGET /v1/functions/alerts
Habilitar ou desabilitarPATCH /v1/functions/alerts/{id} com {"enabled": false}
ExcluirDELETE /v1/functions/alerts/{id}
História de uma regraGET /v1/functions/alerts/{id}/events
História de todas as regrasGET /v1/functions/alerts/events

Um evento possui alert_rule_id, event_type, triggered_value, message e created_at; as rotas do histórico aceitam limit e offset. Cada rota precisa de uma chave service_role.

Última atualização · 12 de out. de 2026