Loki Alert Rule Tester: Testez vos règles d’alerte Loki avant qu’elles ne se déclenchent en production.
S’exécute dans votre navigateur — rien de ce que vous collez ne quitte cette page. Comment nous le prouvons
Bac à sable AlertLint
groups:
- name: ssh-security
rules:
# Fire when more than 5 failed SSH logins occur within 5 minutes.
- alert: HighAuthFailureRate
expr: sum(count_over_time({job="sshd"} |= "Failed password" [5m])) > 5
for: 0m
labels:
severity: warning
team: platform
annotations:
summary: "High rate of failed SSH logins"
description: "{{ $value }} failed SSH logins in the last 5 minutes."
rule_files:
- ssh-security.yml
evaluation_interval: 1m
tests:
- interval: 1m
input_streams:
- stream:
job: sshd
host: bastion-1
logs:
- "1m Failed password for root from 10.0.0.9 port 52344 ssh2"
- "2m Failed password for root from 10.0.0.9 port 52345 ssh2"
- "3m Failed password for admin from 10.0.0.9 port 52346 ssh2"
- "4m Failed password for admin from 10.0.0.9 port 52347 ssh2"
- "4m Failed password for git from 10.0.0.9 port 52348 ssh2"
- "5m Failed password for git from 10.0.0.9 port 52349 ssh2"
- "5m Accepted password for deploy from 10.0.0.2 port 60001 ssh2"
alert_rule_test:
- eval_time: 5m
alertname: HighAuthFailureRate
exp_alerts:
- exp_labels:
severity: warning
team: platform
exp_annotations:
summary: "High rate of failed SSH logins"
description: "6 failed SSH logins in the last 5 minutes."
Results update as you type — press ⌘/Ctrl + Enter to run now. Press Esc to release the editor.
Passed: HighAuthFailureRate
Fired 1 alert(s) with the expected labels and annotations.
AlertLint vous permet de tester les règles d’alerte Loki avant la production — collez vos règles et vos logs synthétiques, affirmez quelles alertes devraient se déclencher, et obtenez une réussite ou un échec, le tout en ligne, sans installation ni inscription.
Le manque
Loki n’a pas de promtool, alors les alertes LogQL partent en production sans test.
Les ingénieurs Prometheus livrent des règles d’alerte testées depuis des années avec promtool test rules — des échantillons synthétiques en entrée, une réussite ou un échec en sortie. Loki a adopté le même format de règles mais n’a jamais livré l’exécuteur de tests, si bien que les alertes LogQL sont livrées sans tests : la seule manière de savoir si une règle s’était déclenchée était d’attendre le trafic de production.
La communauté réclame cela depuis des années — voir Loki issue #7655 et issue #16659. AlertLint comble ce manque dès aujourd’hui : un testeur unitaire gratuit de règles d’alerte Loki, dans le navigateur, qui utilise le fichier de test familier de style promtool et s’exécute entièrement côté client.
Nouveau dans ce format ? Rendez-vous sur les deux fichiers ou essayez le bac à sable interactif ci-dessus.
Le pipeline
Comment tester une règle d’alerte Loki dans le navigateur.
Cinq étapes déterministes s’exécutent de bout en bout à chaque appui sur Run — toutes dans votre onglet de navigateur, à chaque fois.
-
Analyser les règles.
Votre YAML de ruler Loki est analysé en groupes de règles d’alerte et d’enregistrement — exactement la forme que charge le ruler Loki.
-
Analyser le fichier de test.
Le fichier de test calqué sur promtool est lu pour ses séries de logs d’entrée, son intervalle d’évaluation et les alertes que vous attendez.
-
Construire un magasin en mémoire.
Les lignes de logs synthétiques sont chargées dans un magasin de logs éphémère, dans le navigateur, pour que les requêtes aient de quoi lire.
-
Évaluer le LogQL.
Chaque expression de règle est exécutée sur le magasin au moment d’évaluation du test, produisant les alertes qui se déclencheraient.
-
Comparer aux attentes.
Les alertes réelles sont comparées à vos exp_alerts. Tout écart constitue un cas en échec, signalé en ligne.
Formats de fichiers
Deux fichiers, tous deux familiers.
AlertLint lit exactement deux entrées : votre YAML de ruler Loki et un fichier de test calqué sur promtool. Si vous en avez déjà écrit pour Prometheus ou Loki auparavant, vous serez en terrain connu.
Le fichier de règles
YAML de ruler Loki standard — des groups de règles d’alerte et d’enregistrement, chacune avec une expr LogQL, une durée for optionnelle, et des labels / annotations. C’est exactement le fichier que votre ruler charge déjà.
groups:
- name: app-errors
rules:
- alert: HighErrorRate
expr: |
sum(count_over_time({app="checkout"} |= "error" [5m])) > 2
for: 2m
labels:
severity: page
annotations:
summary: "Checkout error rate is high" Le fichier de test
Calqué sur promtool : des input_streams de flux de logs synthétiques, un interval d’évaluation, et un alert_rule_test listant les alertes que vous attendez. Un exp_alerts: [] vide affirme qu’aucune alerte ne se déclenche.
tests:
- interval: 1m
input_streams:
- stream:
app: checkout
logs:
- "1m level=error checkout upstream timeout"
- "2m level=error checkout upstream timeout"
- "3m level=error checkout upstream timeout"
- "4m level=error checkout upstream timeout"
- "5m level=error checkout upstream timeout"
- "6m level=error checkout upstream timeout"
alert_rule_test:
- eval_time: 6m
alertname: HighErrorRate
exp_alerts:
- exp_labels:
severity: page
exp_annotations:
summary: "Checkout error rate is high"
# Negative case — empty exp_alerts asserts NO alert fires.
- interval: 1m
input_streams:
- stream:
app: checkout
logs:
- "1m level=info checkout ok"
- "2m level=info checkout ok"
alert_rule_test:
- eval_time: 6m
alertname: HighErrorRate
exp_alerts: [] Bientôt disponible
Exécutez les mêmes vérifications en CI.
Le moteur dans le navigateur n’est que la première étape. Une CLI prête à l’emploi exécutera les mêmes assertions sur un ensemble de fichiers de test dans votre pipeline, de sorte qu’une alerte cassée fasse échouer le build au lieu de vous bipper à 3 h du matin.
Une Action GitHub de première partie qui encapsule la CLI est prévue en parallèle. Les deux arrivent bientôt — le testeur dans le navigateur ci-dessus fonctionne dès aujourd’hui.
# Coming soon — the same engine as a CLI
$ alertlint test ./tests/**.yaml
✓ app-errors › HighErrorRate (fires)
✓ app-errors › HighErrorRate (no-fire on info logs)
2 passed, 0 failed Moteur en préversion
Quel LogQL l’évaluateur dans le navigateur prend en charge.
L’évaluateur couvre le LogQL dans lequel les règles d’alerte et d’enregistrement sont réellement écrites : les sélecteurs de flux avec les matchers de labels =, !=, =~ et !~, les quatre filtres de lignes (|=, !=, |~, !~), count_over_time et rate sur une plage, sum et sum by (…), et une comparaison de seuil. Tout ce qui sort de ce sous-ensemble est signalé comme une erreur plutôt que deviné, et la fenêtre for: d’une règle est respectée : l’expression est réévaluée à chaque interval du test sur toute la fenêtre d’attente et chaque évaluation doit se déclencher, si bien qu’une règle encore en Pending n’est jamais signalée comme Firing.
Une note sur la précision : il s’agit d’un moteur en préversion. Une version à parité complète qui compile le moteur de requêtes Loki en amont vers WebAssembly arrive bientôt. D’ici là, considérez une exécution au vert comme une solide confiance préliminaire plutôt qu’une rediffusion de production à l’octet près.
FAQ
Vos questions, nos réponses.
Appuyez sur une question pour afficher la réponse.
Qu’est-ce qu’AlertLint ?
AlertLint est un testeur unitaire gratuit, exécuté dans le navigateur, pour les règles d’alerte et d’enregistrement de Grafana Loki. Vous collez votre YAML de ruler Loki ainsi qu’un fichier de test calqué sur promtool contenant des flux de logs synthétiques, vous appuyez sur Run, et AlertLint évalue le LogQL puis indique si les alertes que vous attendiez se sont réellement déclenchées. C’est l’équivalent du « test rules » de promtool que Loki n’a jamais livré.
Mes données quittent-elles un jour mon navigateur ?
Non. AlertLint s’exécute à 100 % côté client. Vos règles et vos logs synthétiques sont évalués dans votre onglet de navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez l’utiliser en toute sécurité sur des définitions de règles internes ou sensibles.
En quoi est-ce différent de promtool ?
Prometheus livre promtool test rules pour tester unitairement les règles d’alerte par rapport à des échantillons synthétiques. Loki n’a aucun équivalent intégré — il n’existe pas de commande loki test. AlertLint comble ce manque pour LogQL : vous affirmez quelles alertes devraient se déclencher à partir d’un ensemble donné de lignes de logs, avant même que les règles n’atteignent la production.
Quelles fonctionnalités LogQL le moteur dans le navigateur prend-il en charge ?
L’évaluateur en préversion couvre les schémas d’alerte et d’enregistrement courants — requêtes de logs et de métriques, sélecteurs de flux, matchers de labels, filtres de lignes, agrégations rate et count_over_time, agrégations sum et comparaisons de seuils par rapport aux alertes attendues. Une parité complète avec le moteur de requêtes Loki en amont (Go compilé en WebAssembly) est prévue pour une future version.
Puis-je affirmer qu’aucune alerte ne se déclenche ?
Oui. Une liste exp_alerts vide sur un cas de test affirme que la règle ne produit aucune alerte au moment de l’évaluation — la même sémantique de cas négatif qu’utilise promtool. C’est la manière canonique de prouver qu’une règle ne se déclenchera pas sur un volume de logs anodin.
AlertLint est-il affilié à Grafana Labs ?
Non. AlertLint est un outil communautaire indépendant qui n’est ni affilié à Grafana Labs ni approuvé par lui. Loki et Grafana sont des marques de Raintank, Inc. AlertLint modélise le format de fichier de test de promtool par souci de familiarité et n’utilise les noms des éditeurs que pour décrire ce qu’il teste.
Comment tester les règles d’alerte Loki avant qu’elles n’atteignent la production ?
Avant le déploiement, vérifiez votre YAML de règles avec lokitool rules lint ou cortextool rules lint --backend=loki et testez vos requêtes à blanc dans Grafana Explore ou logcli. Pour des tests préliminaires de type assertion — l’étape que ces outils ne couvrent pas — collez vos règles ainsi que des flux de logs synthétiques dans AlertLint et affirmez quelles alertes devraient se déclencher, y compris les cas négatifs. Une exécution au vert apporte une solide confiance préliminaire, même si l’évaluateur dans le navigateur est un moteur en préversion plutôt qu’une rediffusion complète de production.
En quoi AlertLint diffère-t-il de lokitool et cortextool ?
lokitool et cortextool proposent des commandes rules lint et sync qui valident la structure des règles et poussent les règles vers un ruler Loki — mais aucun n’exécute d’assertions d’alerte sur des logs synthétiques ni ne vous indique si une règle se déclenche. AlertLint apporte à LogQL le flux de travail basé sur les assertions, de style promtool : vous fournissez des flux de logs synthétiques, vous déclarez quelles alertes vous attendez, et vous obtenez un verdict réussite ou échec, entièrement dans le navigateur et sans installation.
Comment valider du YAML de ruler Loki en ligne ?
AlertLint analyse le YAML de ruler Loki standard — des groupes de règles d’alerte et d’enregistrement, chacune avec une expr LogQL, une durée for optionnelle et des labels/annotations — et signale les problèmes structurels en ligne. Pour des vérifications plus poussées de politique d’expression par rapport aux métadonnées des règles, promruval avec --support-loki est une option en ligne de commande. AlertLint s’exécute entièrement dans le navigateur, sans inscription requise.
More free, private DevOps tools.
AlertLint est un outil parmi d’autres dans OpsCanopy — une canopée grandissante de validateurs, convertisseurs et testeurs dans le navigateur qui ne touchent jamais un serveur.
Plus dans Observabilité
42 outils gratuits, tous utilisables hors ligne — opscanopy.com fonctionne sans inscription et sans rien téléverser.
Associez-le au désormais disponible convertisseur d’ignore CVE et au validateur GitHub Actions, ou parcourez le répertoire complet des outils.
Non affilié à Grafana Labs ni approuvé par lui. Loki et Grafana sont des marques de Raintank, Inc.