Résumé
Ce générateur regex transforme une liste d’hôtes, de chemins, de versions, de domaines d’e-mail ou de codes HTTP en motif échappé pour les règles de ciblage de déploiement, les matchers Prometheus et les filtres de logs. Vous choisissez entre la sémantique de correspondance partielle (JavaScript, Go, grep) et de correspondance complète (Prometheus, Alertmanager, Envoy), puis vous testez des lignes dans le navigateur. Rien ne quitte votre machine.
Générateur regex pour ciblage de rollout et filtres de logs
Collez les hôtes, chemins, versions ou codes HTTP à cibler. Obtenez un motif échappé pour votre moteur regex, puis testez-le sur de vraies lignes avant qu’il n’atteigne la production.

Ce que le générateur fait de vos valeurs
Échappe chaque littéral
Les points, barres obliques, crochets et plus de vos valeurs sont échappés : api.internal.example.com ne peut donc pas correspondre à api-internal-example-com. Les listes blanches écrites à la main échouent ici plus que partout ailleurs.
Écrit pour le moteur que vous utilisez
Les moteurs de recherche ont besoin de ^ et de $ pour verrouiller une correspondance. Prometheus, Alertmanager et Envoy comparent la chaîne entière et demandent .* pour les règles de préfixe et de suffixe. Vous choisissez le moteur, le générateur adapte le motif.
Teste avant la mise en production
Chaque ligne de test reçoit un badge « correspond » ou « ne correspond pas » selon le motif que vous allez copier. Ajoutez volontairement les faux proches : checkout-v22 à côté de checkout-v2, example.com.evil.io à côté de example.com.
La regex qui a passé la revue et a quand même réveillé quelqu’un
La plupart des incidents liés aux regex dans la configuration des déploiements et des alertes ne sont pas exotiques. Une règle de ciblage censée couvrir trois hôtes internes couvrait aussi un hôte au nom presque identique. Un matcher d’alerte écrit avec des ancres que Prometheus n’attend pas a discrètement fait disparaître un service. Un filtre de logs qui correspondait sur une sous-chaîne masquait les erreurs qu’il devait compter. Le motif est rarement trop subtil. Il est presque toujours trop large, ou n’a été testé que sur des lignes censées correspondre. Une règle qui conditionne un déploiement doit d’abord être testée sur les lignes qui ne doivent pas correspondre.
- Échapper les points dans chaque nom d’hôte
- Savoir si votre moteur ancre à votre place
- Tester les faux proches, pas seulement les correspondances
- Préférer une liste littérale à une regex quand l’ensemble est petit et stable
D’une liste de valeurs à un motif sur lequel vous pouvez compter
-
1
Choisissez le type de correspondance
Valeurs exactes pour les listes blanches d’hôtes et de clés de flags, préfixe pour les groupes de routes, codes HTTP pour les règles d’alerte, familles de versions pour le ciblage de déploiement par version d’application.
-
2
Choisissez le moteur
Utilisez la correspondance partielle pour le code et grep. Utilisez la correspondance complète pour les matchers Prometheus, les routes Alertmanager et Envoy. Ce seul choix supprime l’erreur d’ancrage la plus courante.
-
3
Collez les faux proches dans la zone de test
Ajoutez un hôte qui lui ressemble, une version voisine et un code HTTP juste hors de la plage. Si l’un d’eux affiche « correspond », resserrez les valeurs avant de copier le motif.
Questions fréquentes
Ce générateur regex est-il gratuit, et envoie-t-il mes valeurs quelque part ?
Quel moteur regex le motif généré vise-t-il ?
Pourquoi Prometheus ignore-t-il mes ancres ^ et $ ?
Le motif évite-t-il le retour arrière catastrophique ?
Comment sont traités les caractères spéciaux ?
Puis-je utiliser le motif dans une règle de ciblage de feature flag ?
Que ne fait-il pas ?
Conditionnez le déploiement au SLO, pas à l’intuition
Les règles de ciblage décident qui reçoit un changement. L’AI Pilot d’upstreamapi décide s’il doit continuer, et revient en arrière seul lorsque le taux d’erreur dépasse votre seuil de SLO.