Tester, déployer et superviser ses règles

6. Tester ses règles avec promtool #

Vérification et tests unitaires, avant de déployer.

Des tests unitaires, sans serveur #

promtool check rules vérifie la syntaxe. promtool test rules va plus loin : il injecte des séries fictives, évalue les règles et compare le résultat. Le test ci-dessous couvre les deux cas du piège précédent :

rule_files:
  - rules.yml
evaluation_interval: 1m

tests:
  - name: 10 % d'erreurs
    interval: 1m
    input_series:
      - series: 'prometheus_http_requests_total{job="api",handler="/a",code="200"}'
        values: '0+54x10'
      - series: 'prometheus_http_requests_total{job="api",handler="/a",code="500"}'
        values: '0+6x10'
    promql_expr_test:
      - expr: job:prometheus_http_requests:rate5m
        eval_time: 10m
        exp_samples:
          - labels: 'job:prometheus_http_requests:rate5m{job="api"}'
            value: 1
      - expr: job:prometheus_http_requests_errors:ratio_rate5m
        eval_time: 10m
        exp_samples:
          - labels: 'job:prometheus_http_requests_errors:ratio_rate5m{job="api"}'
            value: 0.1

  - name: aucune erreur, le ratio vaut 0 et non vide
    interval: 1m
    input_series:
      - series: 'prometheus_http_requests_total{job="api",handler="/a",code="200"}'
        values: '0+60x10'
    promql_expr_test:
      - expr: job:prometheus_http_requests_errors:ratio_rate5m
        eval_time: 10m
        exp_samples:
          - labels: 'job:prometheus_http_requests_errors:ratio_rate5m{job="api"}'
            value: 0

Comment lire values: '0+54x10' : la série part de 0 et augmente de 54 à chacun des 10 pas d'une minute, soit 0,9 requête par seconde. Avec 0,1 requête en erreur, le ratio attendu est bien 0,1.

7. Déployer #

Recharger la configuration, Kubernetes.

Recharger sans redémarrer #

Après modification, envoyez un signal SIGHUP au processus, ou appelez POST /-/reload si Prometheus a été lancé avec --web.enable-lifecycle. Une erreur dans le fichier laisse l'ancienne configuration en place : vérifiez donc le résultat dans Status > Rule health ou avec /api/v1/rules.

--web.enable-lifecycle permet à quiconque atteint le port de recharger ou d'arrêter Prometheus. Protégez cet accès en production.

Sur Kubernetes #

Avec le Prometheus Operator, les règles sont déclarées par une ressource PrometheusRule. Son étiquette doit correspondre au ruleSelector de votre Prometheus, sinon elle est ignorée sans message.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: http-recording-rules
  namespace: monitoring
  labels:
    release: kube-prometheus-stack   # doit correspondre au ruleSelector de votre Prometheus
spec:
  groups:
    - name: http
      rules:
        - record: job:http_requests:rate5m
          expr: sum by (job) (rate(http_requests_total[5m]))

8. Superviser ses règles #

Détecter un groupe trop lent ou une règle en échec.

Les métriques à suivre #

Si un groupe met plus de temps à s'évaluer que son intervalle, des évaluations sont sautées et des trous apparaissent. Prometheus expose tout ce qu'il faut pour le détecter :

# Une évaluation dépasse-t-elle son intervalle ? (à surveiller en priorité)
rate(prometheus_rule_group_iterations_missed_total[5m]) > 0

# Part de l'intervalle consommée par chaque groupe
prometheus_rule_group_last_duration_seconds / prometheus_rule_group_interval_seconds

# Règles en échec
rate(prometheus_rule_evaluation_failures_total[5m]) > 0

Bonne pratique : alertez sur prometheus_rule_group_iterations_missed_total. Si un groupe devient trop lent, découpez-le : les groupes s'exécutent en parallèle.

9. Recalculer le passé #

Le backfill avec promtool.

Créer l'historique d'une nouvelle règle #

promtool tsdb create-blocks-from rules interroge l'API d'un Prometheus et écrit des blocs TSDB dans le dossier data/ (option --output-dir). Il faut ensuite les déplacer dans le répertoire de données (storage.tsdb.path) : ils fusionnent avec les blocs existants au prochain compactage.

Limites documentées : une règle qui dépend d'une autre règle en cours de recalcul n'est pas prise en charge : recalculez d'abord les règles de base, déplacez leurs blocs, puis relancez pour les règles dépendantes. Les alertes du fichier sont ignorées. Relancer sur une période qui se chevauche crée à chaque fois des blocs contenant les mêmes données.

Commandes à connaître #

# Vérifier la syntaxe et compter les règles
promtool check rules rules.yml

# Lancer les tests unitaires
promtool test rules tests.yml

# Recharger sans redémarrer (avec --web.enable-lifecycle)
curl -X POST http://localhost:9090/-/reload

# Lister les règles, leur santé et leur durée
curl -s http://localhost:9090/api/v1/rules | jq '.data.groups[] | {name, evaluationTime, rules: [.rules[] | {name, health}]}'

# Mesurer le coût d'une requête
curl -s --get --data-urlencode 'query=job:prometheus_http_requests:rate5m' --data-urlencode 'stats=all' \
  http://localhost:9090/api/v1/query | jq .data.stats.samples.totalQueryableSamples

# Recalculer le passé (création de blocs TSDB)
promtool tsdb create-blocks-from rules --start 2026-11-01T00:00:00Z --end 2026-11-02T00:00:00Z \
  --url http://localhost:9090 --eval-interval 60s rules.yml

Sources officielles #

• Prometheus : defining recording rules
• Prometheus : recording rules best practices
• Prometheus : unit testing for rules
• Prometheus : storage et backfilling