Logo Aurabase
aurabasedocuments
documents›Edge Functions›Alertes

Alertes

Comment être informé lorsque vos fonctions se comportent mal : les métriques que vous pouvez surveiller, comment les règles sont vérifiées et comment les gérer via HTTP.

5 min de lecture·Niveau intermédiaire·Révisé le 12 oct. 2026
Ce texte anglais a été généré automatiquement à partir de l’original français et n’a pas encore été relu.
Cette page a été traduite automatiquement. La version anglaise fait foi.
#
Créer

1. Créez une règle

Les règles d'alerte sont gérées via HTTP avec une clé service_role. Le SDK n'a aucune méthode pour eux.

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
}
#
Référence

2. Métriques, conditions et canaux

ChampValeurs autorisées
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
thresholdUn numéro
destinationUne adresse e-mail, ou l'URL du webhook ou du Slack hook

log_pattern surveille les journaux d'un service pour une expression régulière : log_pattern:functions:timeout. Une valeur inconnue renvoie 400 et répertorie celles acceptées. Vraie réponse pour 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>
#
Comportement

3. Comment les règles sont vérifiées

  • Le service vérifie chaque règle activée une fois par minute.
  • Les mesures numériques sont lues à partir de Prometheus ; Les règles log_pattern interrogent Loki. Chaque requête a une limite de 5 secondes. Si un projet échoue, les autres sont quand même vérifiés.
  • Lorsqu'une règle se déclenche, le service définit last_triggered_at, enregistre un événement et le publie pour diffusion sur le canal choisi.
  • Une règle que vous désactivez est conservée mais n'est pas vérifiée.
La livraison dépend de votre déploiement

Les alertes nécessitent que Prometheus et Loki soient accessibles depuis le service de fonctions, et le canal de messagerie nécessite un fournisseur de messagerie. Sur une pile de développement sans eux, une règle est stockée mais ne peut pas se déclencher.

#
Fonctionner

4. Gérer les règles et l'historique

ActionDemande
Règles de listeGET /v1/functions/alerts
Activer ou désactiverPATCH /v1/functions/alerts/{id} avec {"enabled": false}
SupprimerDELETE /v1/functions/alerts/{id}
Histoire d'une règleGET /v1/functions/alerts/{id}/events
Histoire de toutes les règlesGET /v1/functions/alerts/events

Un événement a alert_rule_id, event_type, triggered_value, message et created_at; les routes historiques acceptent limit et offset. Chaque itinéraire nécessite une clé service_role.

Dernière mise à jour · 12 oct. 2026