Prometheus Rule Builder
DevOps & SRE Telemetry Automation

Générateur de Règles d'Alerte et d'Enregistrement Prometheus (PromQL) - Guide Développeur

Créez et validez visuellement des règles d'alerte et d'enregistrement PromQL, des seuils, des étiquettes et des annotations de runbook.

Prometheus 2.x • K8s Operator CRD • Promtool
Préréglages :
Configuration de la règle et PromQL
Interactive PromQL Builder Assistant
Label Matchers (e.g. {mode="idle"}):
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85Live Assistant
Tier: Range Rate Window
Wait before firing
Prometheus 2.42+ anti-flapping
Warning (P2)
:
:
:
# Prometheus Alerting & Recording Rules Specification
# Generated by ToolsAA (100% Client-Side Engine)
groups:
  - name: infrastructure_node_alerts
    interval: 30s
    rules:
      - alert: HostHighCpuLoad
        expr: 100 - (avg by (instance, job) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        keep_firing_for: 2m
        labels:
          severity: warning
          tier: "infra"
          team: "sre-platform"
        annotations:
          summary: "Host CPU utilization exceeds 85% on {{ $labels.instance }}"
          description: "Node {{ $labels.instance }} (job: {{ $labels.job }}) has had CPU utilization above 85% for 5m. Current load is {{ $value | printf \"%.2f\" }}%."
          runbook_url: "https://runbooks.prometheus-operator.dev/runbooks/general/cpu-high-load/"
          dashboard_url: "https://grafana.internal.net/d/node-exporter-full?var-instance={{ $labels.instance }}"
          action_required: "Investigate noisy-neighbor processes via htop or check autoscaling capacity."
Architecture de règlealert
HostHighCpuLoad

Group: infrastructure_node_alerts | For: 5m

Analyse PromQLValid
Rate Counter

Range: Windowed | Annotations: 3 vars

Compatibilité des outils100% Native
Prometheus 2.x & K8s

kube-prometheus-stack • Alertmanager • promtool

AST PromQL et synthèse d'expressions

Construisez visuellement des expressions PromQL robustes avec des sélecteurs de métriques, des fenêtres temporelles, des fonctions d'agrégation et des seuils de comparaison.

Confidentialité 100% dans le navigateur

Aucune communication serveur ni télémétrie. Vos noms de métriques internes, topologies de cluster et URL de runbook restent confidentiels dans votre navigateur.

Natif pour Promtool et Operator

Génère des fichiers de règles standard Prometheus 2.x, des CRD PrometheusRule pour kube-prometheus-stack et des spécifications de tests unitaires promtool.

Référence technique et guide d'architecture

Générateur de Règles d'Alerte et d'Enregistrement Prometheus (PromQL) - Guide Développeur — Guide de référence

Créez et validez visuellement des règles d'alerte et d'enregistrement PromQL, des seuils, des étiquettes et des annotations de runbook.

Paramètres clés et contrôles

Type de règle et identifiantstring (alert: / record:)

Définit si le bloc YAML spécifie une règle d'alerte déclenchée par dépassement de seuil (`alert: Name`) ou une règle d'enregistrement précalculée (`record: metric:name`).

Par défaut : HighCpuUsage
Expression PromQL (`expr`)string (syntaxe PromQL)

La requête PromQL évaluée à chaque cycle d'évaluation pour déclencher l'alerte ou calculer la nouvelle série temporelle enregistrée.

Par défaut : 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
Durée d'attente (`for`)chaîne de durée (ex. 5m, 10m, 1h)

La durée pendant laquelle la condition doit être continuellement vraie avant de passer de l'état `Pending` à `Firing`, évitant ainsi les alertes intempestives dues aux pics transitoires.

Par défaut : 5m
Étiquettes (`labels`)carte clé-valeur

Paires clé-valeur de métadonnées attachées à l'alerte pour le routage dans Alertmanager, le regroupement des notifications, le masquage et la criticité.

Par défaut : severity: warning, team: sre
Annotations (`annotations`)carte clé-valeur (support des modèles Go)

Informations lisibles par l'humain telles que le résumé, la description et l'URL du runbook, prenant en charge les variables de modèle Go comme `{{ $labels.instance }}` et `{{ $value }}`.

Par défaut : summary: "High CPU load on {{ $labels.instance }}"

Conseils de pro et bonnes practices

Précalculez les requêtes lourdes avec des Règles d'Enregistrement (Recording Rules)

Calculez à l'avance les agrégations coûteuses ou les taux sur de longues fenêtres (ex. `rate(http_requests_total[1h])`) à l'aide de règles d'enregistrement nommées selon la convention `level:metric:operations` afin d'accélérer les tableaux de bord et d'alléger l'évaluation.

Mettez en forme les valeurs numériques dans les annotations avec les filtres Go

Évitez d'afficher des nombres à virgule flottante illisibles comme 0.85231999999 dans vos alertes. Utilisez des filtres tels que `{{ $value | humanizePercentage }}` ou `{{ $value | printf "%.2f" }}` pour des messages clairs et opérationnels.

Évitez le battement d'alertes (Flapping) grâce à une durée `for` bien calibrée

Définissez une durée `for: 5m` à `15m` pour les métriques fluctuantes (charge CPU, disques, pauses GC), tout en conservant des fenêtres courtes comme `for: 1m` pour les sondes synthétiques de disponibilité (Blackbox exporter).

Automatisez la validation des règles avec `promtool` en CI/CD

Exécutez `promtool check rules rules.yml` dans votre pipeline d'intégration continue afin de détecter les erreurs de syntaxe YAML, les requêtes PromQL invalides et les variables de modèle non déclarées avant le déploiement en production.

Pièges courants et dépannage

L'alerte reste indéfiniment à l'état `Pending` sans jamais passer à `Firing`

Vérifiez si la métrique repasse ponctuellement sous le seuil pendant la fenêtre d'évaluation. Si l'expression s'avère fausse même pour un seul cycle d'évaluation, le compteur de durée est remis à zéro. Assurez-vous également que `evaluation_interval` est inférieur à la durée `for`.

Erreur lors du rendu de l'alerte : "template: rule: function not defined"

Les annotations Prometheus ne supportent qu'un ensemble restreint de fonctions intégrées Go (comme `humanize`, `humanize1024`, `humanizeDuration`, `humanizePercentage`, `title`, `toUpper`, `toLower`). Retirez toute fonction personnalisée et référencez vos variables via `$labels.key` ou `$value`.

Aucune alerte ne se déclenche lorsqu'un service surveillé tombe complètement en panne

Les requêtes de comparaison standard comme `http_requests_total > 100` renvoient un vecteur vide lorsque la cible s'arrête d'émettre des métriques. Pour détecter les arrêts complets, configurez des alertes spécifiques basées sur `absent(up{job="api"}) == 1` ou surveillant `up{job="api"} == 0`.

Foire aux questions (FAQ)

Quelle est la différence fondamentale entre une règle d'alerte et une règle d'enregistrement ?▼

Une règle d'alerte évalue une expression PromQL et envoie des événements de notification à Alertmanager lorsque la condition est satisfaite pendant la durée spécifiée. Une règle d'enregistrement précalcule périodiquement une requête PromQL lourde et enregistre le résultat sous forme d'une nouvelle série temporelle dans la TSDB.

Comment les étiquettes définies dans la règle interagissent-elles avec celles de la métrique ?▼

Les étiquettes du bloc `labels` de la règle fusionnent avec celles issues de la métrique évaluée. En cas de conflit sur une même clé d'étiquette, la valeur déclarée dans la règle d'alerte prévaut et écrase celle de la métrique.

Peut-on utiliser des sous-requêtes PromQL au sein d'expressions de règles d'alerte ?▼

Oui, les sous-requêtes comme `rate(http_requests_total[5m])[30m:1m]` sont valides au niveau syntaxique, mais elles imposent une lourde charge CPU et mémoire lors des cycles d'évaluation. La bonne pratique consiste à calculer d'abord le taux interne via une règle d'enregistrement.

Comment concevoir des tests unitaires automatisés pour les règles Prometheus ?▼

Utilisez l'outil officiel `promtool test rules test.yml`. Vous pouvez y définir des séries temporelles simulées avec des horodatages précis et vérifier si l'alerte passe bien aux états `pending` ou `firing` aux moments prévus.

Quelle est la convention recommandée pour organiser les groupes de règles (Rule Groups) ?▼

Organisez les règles par service, équipe ou domaine de défaillance (par exemple, `groups: - name: node_exporter_alerts`). Chaque groupe peut posséder son propre intervalle d'évaluation (`interval`) selon le niveau de criticité requis.

Outils et utilitaires connexes

Tous les outils →
Guide Développeur : Générateur de Types de Résolveurs TypeScript depuis GraphQL SDLdeveloper

Générez des interfaces de résolveurs TypeScript strictement typées, des arguments de requêtes/mutations et des types de contexte depuis vos schémas GraphQL SDL.

Ouvrir l'outil→
Guide de développement : Convertisseur cURL vers C# (.NET HttpClient, RestSharp et Flurl)developer

Convertissez vos requêtes cURL en code C# idiomatique pour .NET HttpClient, RestSharp ou Flurl.Http avec les meilleures pratiques de programmation asynchrone et de pool de connexions.

Ouvrir l'outil→
Guide développeur du convertisseur cURL vers Java (Java 11+ HttpClient, OkHttp & Spring WebClient)developer

Convertissez vos commandes cURL en requêtes HTTP Java prêtes pour la production avec java.net.http.HttpClient natif, OkHttp3 ou Spring WebClient.

Ouvrir l'outil→
Guide Développeur : Générateur de Définition JSON vers XML Schema (XSD)developer

Inférence de schémas XML (XSD), structures de types complexes, attributs et règles de cardinalité minOccurs/maxOccurs à partir d'échantillons JSON.

Ouvrir l'outil→
Générateur Interactif de Fichier .gitignore (Node, Python, Go, Rust, Java) Guide Développeurdeveloper

Générez des modèles .gitignore complets en combinant les règles pour systèmes d'exploitation, éditeurs et plus de 50 langages de programmation.

Ouvrir l'outil→
Syntaxe Crontab & Expressions Quartz Cheat Sheetdeveloper

Référence exhaustive de la syntaxe cron POSIX à 5 champs et Quartz à 6 champs. Raccourcis macros, calcul des cycles et prévention des chevauchements de tâches.

Ouvrir l'outil→