evaluate_alert
Évaluer des métriques par rapport à des règles d'alert sans Kapacitor.
Évaluer des métriques par rapport à des règles d'alert sans Kapacitor.
Lecture seule · Appelle des systèmes externes. Appel sûr : cet outil ne modifie pas les données.
Paramètres
| Champ | Type | Requis | Description |
|---|---|---|---|
operator | string | Oui | Slug de l'opérateur (= nom de la base InfluxDB) |
precision | string | Non | Précision temporelle de la requête (s, ms, u, ns) |
query | string | Oui | Requête InfluxQL |
rules | string | Oui | Tableau JSON de règles d'alert |
Exemple d'arguments
Arguments illustratifs qu'un agent fournit lors de l'appel de cet outil :
{
"operator": "string",
"query": "string",
"rules": "string"
}Description
Exécute une requête InfluxQL, calcule les statistiques, puis vérifie les règles. Cet outil effectue un calcul analytique LOCAL à la demande — il N'EST PAS lié aux définitions d'alert de la plateforme ni aux incidents. Pour gérer les alerts de la plateforme, utilisez list_alert_definitions et list_incidents.
IMPORTANT : Ceci est un calcul analytique LOCAL à la demande (sans état). Pour le statut des alerts de la plateforme et les incidents actifs, utilisez list_alert_definitions + list_incidents à la place.
Prérequis : exécutez query_metrics avec SHOW MEASUREMENTS et SHOW FIELD KEYS d'abord pour découvrir les champs numériques. Votre requête DOIT renvoyer des données de séries temporelles numériques (pas des commandes SHOW). Les champs "metric" des règles (par ex. "p95", "mean") réfèrent aux statistiques calculées, pas aux champs bruts InfluxDB.
8 types de règles :
- threshold : vérifier une métrique par rapport à une valeur (opérateurs : >, <, >=, <=, ==, !=)
- level_shift : détecter des changements significatifs de moyenne (filtre optionnel min_shift_pct)
- missing_data : vérifier les lacunes dans les séries temporelles (max_gaps, par défaut 0)
- flatline : détecter les valeurs bloquées (max_flatline_len, par défaut 3)
- rate_change : détecter les pics ou taux excessifs (max_spikes par défaut 0, max_abs_rate)
- outlier : vérifier le pourcentage de valeurs aberrantes (max_outlier_pct, par défaut 5.0)
- counter_reset : détecter les diminutions de compteur (max_resets, par défaut 0)
- anomaly : détecter les dépassements EWMA soutenus (sensitivity 1-5, sustained_periods par défaut 3)
Toutes les règles supportent un champ optionnel "description" pour le contexte utilisateur.
Workflow : query_metrics (explorer les données) → evaluate_alert (vérifier les règles).
Exemple de JSON de règles :
[
{"type":"threshold","metric":"p95","operator":">","value":5.0,"description":"SLA p95 < 5s"},
{"type":"missing_data","max_gaps":5},
{"type":"flatline","max_flatline_len":10},
{"type":"level_shift","min_shift_pct":20},
{"type":"anomaly","sensitivity":3,"sustained_periods":3,"detection_direction":"above"}
]
La règle anomaly supporte "detection_direction" : "above" (taux d'erreur, latence), "below" (SLA, taux de succès), ou "both" (par défaut).Associé
Et ensuite ?
Last updated on