Logo Aurabase
aurabazadokumenty
dokumenty›Edge Functions›Alerty

Alerty

Jak dowiedzieć się, kiedy funkcje działają nieprawidłowo: jakie metryki możesz obserwować, w jaki sposób sprawdzane są reguły i jak nimi zarządzać za pośrednictwem protokołu HTTP.

5 min przeczytane·Poziom mediator·Zmieniono 12 paź 2026
Ten tekst w języku angielskim został wygenerowany automatycznie na podstawie francuskiego oryginału i nie był jeszcze recenzowany.
Ta strona została przetłumaczona automatycznie. Wersja angielska jest miarodajna.
#
Tworzyć

1. Utwórz regułę

Reguły alertów są zarządzane przez protokół HTTP za pomocą klucza service_role. SDK nie ma dla nich żadnej metody.

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

2. Metryki, warunki i kanały

PoleDozwolone wartości
metricerror_rate, latency_p95, job_failures, low_disk, ai_quota, anomaly_detection lub log_pattern:<service>:<regex>
conditiongt, lt, eq, match, auto
channelemail, webhook, slack
thresholdKilka
destinationAdres e-mail lub adres URL webhooka lub haka Slack

log_pattern obserwuje logi jednej usługi pod kątem wyrażenia regularnego: log_pattern:functions:timeout. Nieznana wartość zwraca 400 i wyświetla listę zaakceptowanych. Prawdziwa odpowiedź na 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>
#
Zachowanie

3. Jak sprawdzane są reguły

  • Usługa sprawdza każdą włączoną regułę raz na minutę.
  • Metryki numeryczne są odczytywane z Prometeusza; Reguły log_pattern wysyłają zapytanie do Lokiego. Każde zapytanie ma limit 5 sekund. Jeśli jeden projekt zakończy się niepowodzeniem, pozostałe są nadal sprawdzane.
  • Po uruchomieniu reguły usługa ustawia last_triggered_at, rejestruje zdarzenie i publikuje je w celu dostarczenia na wybranym kanale.
  • Reguła, którą wyłączysz, zostanie zachowana, ale nie zaznaczona.
Dostawa zależy od wdrożenia

Alerty wymagają dostępności Prometheusa i Lokiego z usługi funkcji, a kanał e-mail wymaga dostawcy poczty e-mail. Na stosie programistycznym bez nich reguła jest przechowywana, ale nie może zostać uruchomiona.

#
Działać

4. Zarządzaj regułami i historią

DziałanieWniosek
Zasady listyGET /v1/functions/alerts
Włącz lub wyłączPATCH /v1/functions/alerts/{id} z {"enabled": false}
UsuwaćDELETE /v1/functions/alerts/{id}
Historia jednej regułyGET /v1/functions/alerts/{id}/events
Historia wszystkich zasadGET /v1/functions/alerts/events

Zdarzenie ma alert_rule_id, event_type, triggered_value, message i created_at; trasy historii akceptują limit i offset. Każda trasa wymaga klucza service_role.

Ostatnia aktualizacja · 12 paź 2026