Logotipo de Aurabase
aurabasedocumentos
documentos›Edge Functions›Alertas

Alertas

Cómo saber cuándo sus funciones se comportan mal: las métricas que puede observar, cómo se verifican las reglas y cómo administrarlas a través de HTTP.

5 min leer·Nivel intermedio·Revisado el 12 oct 2026
Este texto en inglés se generó automáticamente a partir del original en francés y aún no ha sido revisado.
Esta página fue traducida automáticamente. La versión en inglés es autorizada.
#
crear

1. Crea una regla

Las reglas de alerta se administran a través de HTTP con una clave service_role. El SDK no tiene ningún método para ellos.

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
}
#
Referencia

2. Métricas, condiciones y canales

campoValores permitidos
metricerror_rate, latency_p95, job_failures, low_disk, ai_quota, anomaly_detection o log_pattern:<service>:<regex>
conditiongt, lt, eq, match, auto
channelemail, webhook, slack
thresholdun numero
destinationUna dirección de correo electrónico o la URL del webhook o del gancho de Slack

log_pattern observa los registros de un servicio en busca de una expresión regular: log_pattern:functions:timeout. Un valor desconocido devuelve 400 y enumera los aceptados. Respuesta 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>
#
Comportamiento

3. Cómo se verifican las reglas

  • El servicio verifica cada regla habilitada una vez por minuto.
  • Las métricas numéricas se leen desde Prometheus; log_pattern consulta de reglas a Loki. Cada consulta tiene un límite de 5 segundos. Si un proyecto falla, los demás aún se revisan.
  • Cuando se activa una regla, el servicio configura last_triggered_at, registra un evento y lo publica para su entrega en el canal elegido.
  • Una regla que deshabilites se mantiene pero no se verifica.
La entrega depende de su implementación

Las alertas necesitan que Prometheus y Loki sean accesibles desde el servicio de funciones, y el canal de correo electrónico necesita un proveedor de correo electrónico. En una pila de desarrollo sin ellos, una regla se almacena pero no se puede activar.

#
Operar

4. Gestionar las reglas y el historial.

acciónSolicitar
Lista de reglasGET /v1/functions/alerts
Activar o desactivarPATCH /v1/functions/alerts/{id} con {"enabled": false}
EliminarDELETE /v1/functions/alerts/{id}
Historia de una reglaGET /v1/functions/alerts/{id}/events
Historia de todas las reglas.GET /v1/functions/alerts/events

Un evento tiene alert_rule_id, event_type, triggered_value, message y created_at; las rutas del historial aceptan limit y offset. Cada ruta necesita una clave service_role.

Última actualización · 12 oct 2026