En 2008, j’ai décroché mon second emploi, dans l’équipe réseau d’Orange Portails¹, la division derrière les sites web et le moteur de recherche de l’opérateur télécom français Orange. Tout y fonctionnait comme sur des roulettes : un environnement technique complet, une équipe dédiée pour chaque pan de l’activité et la liberté de me concentrer sur ce que je faisais de mieux. Quelques années plus tard, plus rien n’allait : minés par une obsession du chiffre, nous n’arrivions plus à livrer les nouveaux services dans les temps.

Les premières années

À mes débuts, le département fonctionnait comme une startup. Son origine était l’entreprise française Echo. Elle avait bâti un moteur de recherche. France Télécom l’a racheté et rebaptisé Voila. C’était le moteur de recherche le plus consulté en France au début des années 2000. France Télécom a regroupé les activités de portail au sein de la division Wanadoo Portails, renommée plus tard Orange Portails.

L’environnement technique était excellent. Nous disposions de nombreux outils internes³ : un système de tickets, un outil de graphes RRD, un IPAM, un outil de reporting et un outil d’alerte basé sur SNMP⁴. Nous déployions nos serveurs Linux avec CFEngine. Nous installions les systèmes et les applications depuis des dépôts Debian internes. Nous documentions tout dans une instance MediaWiki privée. La supervision était basée sur un ancêtre de XYmon. L’architecture réseau était propre et évolutive, avec peu de dette technique. Un nouvel arrivant était opérationnel en une journée.

C’était un environnement épanouissant pour moi. J’ai développé plusieurs outils : lldpd, une implémentation de 802.1AB, Snimpy, une interface pythonique pour Net-SNMP, Wiremaps, un outil de découverte de niveau 2 doté d’une machine à remonter le temps pour savoir quel équipement est connecté où, Kitérő, un outil pour simuler des conditions réseau, QCSS-3, un contrôleur pour répartiteurs de charge, et ipoo, un service accessible via un bot Jabber et un script Greasemonkey pour exposer des informations liées aux adresses IP. J’ai ajouté le support SNMP pour Keepalived et Quagga. J’ai aussi lancé ce blog, avec des articles comme « DNS anycast », des articles sur TLS comme « Déni de service TLS : quelles solutions ? », des articles sur SNMP comme « Intégration de Net-SNMP dans une boucle d’évènements », des articles sur Linux comme « Comprendre la mise en cache des routes IPv4 sous Linux », et un article sur VXLAN bien avant que ce soit à la mode.

La chute

Quand nous avions besoin de nouveaux serveurs, l’équipe de proximité en prenait un lot dans l’inventaire, y installait notre distribution Linux, les déplaçait dans le datacenter et les câblait au réseau. Nous ouvrions un ticket décrivant les serveurs dont nous avions besoin et, une semaine plus tard, nos serveurs étaient disponibles. 💫

Orange voulait savoir si l’équipe de proximité était performante : elle a donc réclamé des KPI. Le choix s’est porté sur le nombre de tickets traités dans l’année. Orange a demandé à doubler ce nombre. Au lieu d’un seul ticket pour un nouveau service, nous en ouvrions six, un par serveur. À la fin de l’année, les KPI avaient plus que doublé.

Tout le monde y a vu une réussite du pilotage de la performance. Il a donc été demandé de récidiver l’année suivante. Cette fois, nous devions ouvrir un ticket par serveur et par étape. De nouveau, les KPI ont doublé. En coulisses, les tickets partaient à différentes personnes et n’étaient plus traités dans l’ordre. Aussi, pour l’année suivante, il a été décidé de créer des méta-tickets et de tenir des réunions pour suivre l’avancement de ces tickets. Bien sûr, toutes ces étapes supplémentaires faisaient encore grimper le KPI.

Cette méthode de pilotage de la performance s’est étendue aux autres équipes⁵. Tout est devenu plus lent. Au lieu de quelques semaines, il nous fallait six mois pour déployer un nouveau service. Nous avions bâti une usine à clous soviétique. Mais les KPI étaient bons et nous avons lâché l’affaire.

Prenons un autre exemple. Nous devions estimer l’impact de chaque opération de nuit. Nous n’étions pas mauvais : l’essentiel des opérations étaient déclarées « sans impact ». La plupart du temps, c’était le cas. Parfois, il y avait un impact de 5 secondes. On nous a demandé de faire plus d’efforts pour tenir l’impact annoncé. Qu’avons-nous fait ? Nous avons commencé à déclarer un impact attendu de 5 secondes. Un jour, nous avons eu un impact de 30 secondes et il nous a été reproché de ne pas avoir respecté l’impact annoncé. Au final, la plupart des opérations étaient déclarées avec un impact attendu de 10 minutes, et nous avons cessé de nous en préoccuper : au lieu de basculer le trafic avec soin, nous nous autorisions un impact de 5 minutes. Et nos KPI n’avaient jamais été aussi bons.

Les KPI ne sont pas inutiles, mais ils peuvent avoir des conséquences négatives. Utilisez-les avec précaution : laissez les personnes opérationnelles participer au choix des indicateurs et reliez ces indicateurs à la qualité du service rendu, par exemple avec des objectifs de niveau de service. Sinon, même les plus consciencieux finissent par lâcher prise et détourner le système avant de partir⁶. 📊

L’IA inonde le web de contenus insipides. Les articles sur LinkedIn avec une image générée par IA, remplis d’émojis, publiés par des soi-disant experts sur un sujet auquel ils ne portent pas assez d’intérêt pour écrire eux-mêmes, sont les pires spécimens. Bien que je sois très contrarié de cette situation, je m’appuie sur des LLMs pour la grammaire, les révisions linguistiques et la traduction. Je ne trouve pas cela incohérent.

Ma langue maternelle est le français mais j’écris la plupart des articles en anglais et en français. Quand j’ai commencé à écrire ce blog en 2011, je rédigeais d’abord en français avant de traduire en anglais. J’ai fini par comprendre qu’il était préférable de le faire dans l’autre sens afin de rendre le texte plus naturel et idiomatique. J’essaie d’écrire un anglais « correct » mais cela n’a jamais été mon point fort¹. Par exemple, j’ai toujours eu des difficultés sur l’accord des temps. J’apprends les règles et je les oublie immédiatement. Je ne me vois pas non plus embaucher un éditeur pour quelque chose que je considère comme un loisir.

À titre d’exemple, j’ai gardé l’historique des modifications successives lors de l’écriture de « Scaling Akvorado BMP RIB with sharding » :

1. la première ébauche rédigée à l’aide d’un dictionnaire de synonymes² ;
2. la version modifiée par la compétence « révision linguistique » ;
3. la traduction en français générée par la compétence « traduction » ;
4. la version révisée par un humain avec quelques modifications sur la version anglaise.

Je sais que les IA peuvent dénaturer la voix de l’auteur pendant l’édition, mais les corrections apportées lors de la seconde étape sont mineures. Les instructions sont « d’appliquer de légères modifications de style » tout en demandant d’éviter les formes passives, les phrases trop longues, les verbes peu expressifs et les mots inutiles. Elles définissent également l’audience cible : technique avec un niveau d’anglais B2.

Dans l’extrait suivant, j’ai utilisé « long time » au lieu de « long-standing ». Outre le trait d’union manquant, le premier s’applique à des personnes (a long-time friend), tandis que le second concerne des situations (a long-standing agreement). J’ai mis pas mal de temps à comprendre la seconde modification : l’IA préfère cette forme grammaticale pour introduire la définition de « RIB sharding ».

As the Internet routing table contains more than 1 million routes, Akvorado needs to scale to tens of millions of routes. This has been a long time long-standing challenge, but I expect this issue is now fixed by using RIB sharding, a method to split that splits the routing database into several parts to enable concurrent updates.

Dans la modification ci-dessous, l’IA utilise le mot « device » plutôt que le mot « équipement » car ce dernier est indénombrable. Je le sais mais je tombe régulièrement dans ce piège.

When Akvorado does not find a route from a specific device, it falls back to a route sent by another equipment device.

J’encourage l’IA à utiliser des verbes descriptifs et elle s’exécute en remplaçant une périphrase par un verbe précis :

The benchmarks demonstrate it has better performance than outperforms other packages, both packages for lookups, insertions, and memory usage.

Elle corrige aussi les erreurs de grammaire. Dans le passage suivant, « list of routes » est au singulier. De plus, « stored » représente un état et il ne faut pas le faire suivre de « into » qui indique un changement.

The list of routes for each prefix are is not stored directly into in the prefix tree.

Voici un dernier exemple : le verbe « require » doit être suivi d’un nom ou d’un objet suivi d’un infinitif. Il n’est pas possible de le faire suivre directement par un infinitif.

An alternative would be to have one prefix tree for each peer but it would require to configure configuring all routers to export their routes.

Même si je lis beaucoup d’anglais³, je bute toujours sur ces règles de grammaire. Le français est une langue relativement simple une fois les bases acquises alors que l’anglais est rempli d’irrégularités.

J’indique dans chaque pied de page si une IA a été utilisée pour modifier le contenu. Il y a 3 niveaux :

• 🧠: pas d’IA ou pratiquement pas (par exemple, des corrections grammaticales)
• ✨: amélioré par l’IA (par exemple, des révisions linguistiques)
• 🤖: généré par IA (par exemple, traduit depuis une autre langue)

Survolez avec la souris ou tapotez sur l’icône pour révéler le nom de l’IA et son rôle dans la modification du document.

Le graphique ci-dessous représente par année les outils utilisés pour modifier chaque article. J’ai récemment demandé à une IA des corrections grammaticales sur les anciens articles, aussi bien en anglais qu’en français. Depuis 2018, les articles sont traduits en français à l’aide de DeepL puis ensuite d’une IA. Depuis 2024, je m’appuie sur une IA pour les révisions linguistiques des articles en anglais.

Si vous êtes fermement opposé à l’utilisation des LLM dans l’écriture, j’espère que vous acceptez mon point de vue plus nuancé comme une contrepartie pour des articles en français, l’IA mâchant énormément le travail de traduction. En ce qui concerne l’anglais, la littérature sur le sujet s’accorde sur l’importance de choisir le bon mot pour capturer l’attention du lecteur jusqu’à la fin.

[…] Bien écrire consiste à maîtriser un certain nombre de choses fondamentales, à savoir le vocabulaire, la grammaire et le style, et à remplir le troisième compartiment de sa boîte à outils avec les bons instruments.

― Stephen King, On Writing

Pour associer des informations de routage, telles que les chemins d’AS ou les communautés BGP, aux flux, Akvorado peut importer des routes via le BGP Monitoring Protocol (BMP). Comme la table de routage Internet contient plus d’un million de routes, Akvorado doit gérer des dizaines de millions de routes¹. C’est un défi de longue date², mais je pense que ce problème est désormais résolu grâce au sharding de la RIB, une méthode qui découpe la base de routage en plusieurs parties afin de permettre les mises à jour concurrentes.

Implémentation précédente

Akvorado associe deux éléments pour construire sa RIB :

1. un arbre de préfixes et
2. une liste de routes attachée à chaque préfixe.

Dans le diagramme ci-dessus, la RIB stocke cinq préfixes IPv4 et deux préfixes IPv6. L’un d’eux, 2001:db8:1::/48, contient trois routes :

• depuis le pair 3, via 2001:db8::3:1, AS 65402, chemin d’AS 65402, communauté 65402:31 ;
• depuis le pair 4, via 2001:db8::4:1, mêmes ASN, chemin d’AS et communauté ;
• depuis le pair 5, via 2001:db8::5:1, AS 65402, chemin d’AS 65401 65402, communauté 65402:31.

La structure rib est définie en Go de la manière suivante :

type rib struct {
    tree          *bart.Table[prefixIndex]
    routes        map[routeKey]route
    nlris         *intern.Pool[nlri]
    nextHops      *intern.Pool[nextHop]
    rtas          *intern.Pool[routeAttributes]
    nextPrefixID  prefixIndex
    freePrefixIDs []prefixIndex
}

L’arbre de préfixes s’appuie sur le paquet bart, une adaptation de l’algorithme ART de Donald Knuth. Les benchmarks montrent qu’il surpasse les autres implémentations pour les recherches, les insertions et la consommation mémoire³. De plus, l’auteur est d’une grande aide.

Stocker les routes dans une table associative

La liste des routes de chaque préfixe n’est pas stockée directement dans l’arbre de préfixes : cela mettrait trop de pression sur le ramasse-miettes en allouant un tableau par préfixe.

À la place, la RIB attribue un identifiant de 32 bits unique à chaque préfixe, soit en prenant le dernier identifiant disponible dans le tableau freePrefixIDs, soit en utilisant la valeur nextPrefixID avant de l’incrémenter. Les routes sont ensuite stockées dans la table associative routes, qui s’appuie en Go sur une structure particulièrement optimisée. Pour récupérer les routes attachées à un préfixe, nous les cherchons un par un dans la table routes via une clef de 64 bits qui combine l’index de 32 bits du préfixe avec l’index de 32 bits représentant la position de la route dans la liste. Akvorado parcourt les routes de la première à la dernière pour trouver la meilleure⁴. Il sait qu’il n’y a plus de route lorsque la clé ne renvoie aucun résultat.

type prefixIndex uint32
type routeIndex uint32
type routeKey uint64

Canonisation des routes

Une route contient un identifiant de pair BGP, un NLRI partiel⁵, le prochain saut et les attributs.

type route struct {
    peer       uint32
    nlri       intern.Reference[nlri]
    nextHop    intern.Reference[nextHop]
    attributes intern.Reference[routeAttributes]
    prefixLen  uint8
}

type nlri struct {
    family bgp.Family
    path   uint32
    rd     RD
}
type nextHop netip.Addr
type routeAttributes struct {
    asn              uint32
    asPath           []uint32
    communities      []uint32
    largeCommunities []bgp.LargeCommunity
}

Pour économiser la mémoire et les allocations, les NLRI, les prochains sauts et les attributs de route sont canonisés : un entier de 32 bits remplace la valeur réelle. Ce mécanisme est antérieur au paquet unique introduit dans Go 1.23. Nous le conservons car ses compromis sont différents :

• il utilise un comptage de références explicite plutôt que des pointeurs faibles ;
• il fonctionne avec des valeurs non comparables implémentant les méthodes Hash() et Equal()⁶ ;
• il utilise des instances explicites pour la canonisation, ce qui se révèlera utile pour le sharding ;
• il offre de meilleures performances. Voir par exemple ce benchmark ;
• il consomme deux fois moins de mémoire grâce à des références 32 bits plutôt que des pointeurs ;
• mais il n’est pas utilisable de manière concurrente.

Qu’est-ce qui pose problème ?

Le verrou global en lecture/écriture est le goulot d’étranglement de cette implémentation. Mais pourquoi ? Plusieurs composants utilisent la RIB, chacun avec ses propres contraintes :

• Les consommateurs Kafka consultent la RIB pour enrichir les flux avec des informations de routage. Leur nombre est bornée par la somme des partitions Kafka⁸. Akvorado ajuste également ce nombre afin de garantir un export groupé efficace des flux vers ClickHouse. Sur notre installation, la quantité de consommateurs oscille entre 8 et 16. Comme nous voulons observer les données récentes le plus tôt possible, nous ne pouvons pas nous permettre que les consommateurs Kafka prennent trop de retard.

• Les routeurs surveillés envoient leurs routes via le protocole BMP. À la connexion, ils peuvent envoyer des millions de routes⁹. Après la synchronisation initiale, les mises à jour arrivent en continu et peuvent connaître des pics ponctuels. Le routeur détecte une station BMP bloquée lorsque sa fenêtre TCP est pleine. Dans ce cas, il réinitialise la session. Bien qu’Akvorado dispose d’un important tampon en entrée, il doit appliquer les routes reçues suffisamment vite pour ne pas être considéré comme bloqué.

• Quand un pair BGP distant tombe, Akvorado purge les routes associées en parcourant la RIB. Quand un routeur surveillé tombe, Akvorado patiente un peu, mais finit par purger toutes les routes associées.

En résumé : sur une installation chargée, la contention sur le verrou est forte autant pour les lecteurs que pour les écrivains, et aucun des deux ne peut prendre trop de retard.

Sharding de la RIB

Première étape

Pour supprimer le verrou global, la RIB est découpée en plusieurs « shards », chacun gérant un sous-ensemble des préfixes :

L’arbre de préfixes reste global et protégé par un unique verrou. Chaque partition dispose de son propre verrou en lecture/écriture, de sa table de routes et de ses blocs de canonisation pour stocker les NLRI, les prochains sauts et les attributs de route, ce qui n’aurait pas été possible avec le paquet unique de Go. Les index de préfixes sont eux aussi partitionnés : les 8 bits de poids fort correspondent à l’index de la partition et les 24 bits de poids faible à l’index local du préfixe.

Gerhard a confirmé que suite à ce changement à l’aveugle, le composant BMP a commencé à ronronner. 🎉

J’ai ensuite écrit un benchmark portant sur un demi-million de routes synthétiques mais plausibles¹⁰, réparties entre 0 et 8 écrivains qui modifient les routes aussi vite que possible, tandis que 1 à 16 lecteurs consultent en boucle un ensemble de 10 000 routes. J’ignore si ce benchmark est réaliste, mais il confirme les améliorations à la fois sur les latences en lecture et en écriture :

Il montre également qu’un grand nombre d’écrivains dégrade la latence en lecture.

Deuxième étape

L’unique verrou en lecture/écriture protégeant l’arbre de préfixes constitue la cible suivante. Le paquet bart propose des méthodes alternatives pour les mutations. Elles renvoient un arbre mis à jour via une copie partielle. Les lecteurs n’ont plus besoin du verrou global, qui ne sert plus qu’à synchroniser les écrivains. L’arbre de préfixes est encapsulé dans un pointeur atomique.

Sans verrou, un lecteur peut désormais récupérer un index de préfixe périmé en parcourant sa copie de l’arbre, lorsqu’un écrivain concurrent supprime la dernière route attachée à cet index et le recycle pour un autre préfixe. Pour éviter ce problème, nous combinons l’index de préfixe avec un numéro de génération que nous stockons dans l’arbre :

type generation uint32
type prefixRef struct {
    idx prefixIndex
    gen generation
}
type rib struct {
    mu     sync.Mutex
    tree   atomic.Pointer[bart.Table[prefixRef]]
    shards []*ribShard
}

Chaque partition stocke le numéro de génération de chaque index de préfixe local. Ce numéro est incrémenté quand l’index de préfixe associé est libéré. Lors de la recherche des routes attachées à un index de préfixe, le lecteur vérifie que le numéro de génération correspond. Sinon, il considère que l’index a été recyclé et que la liste de routes est vide¹¹. Le schéma précédent illustre ce cas pour l’index de préfixe 5, stocké avec un numéro de génération de 3, alors que la valeur actuelle dans le tableau []generations est 4. Le numéro de génération peut boucler, mais ce n’est pas un problème car les recherches sont rapides.

L’exécution du benchmark sur cette nouvelle implémentation montre les améliorations sur la latence en lecture ainsi qu’en écriture dès que le coût de la copie partielle de l’arbre de préfixes est amorti.

Parmi les nombreuses tentatives d’optimisation du composant BMP, le sharding de la RIB est l’une des plus satisfaisantes. Akvorado 2.2 implémente la première étape. La PR #2433, rédigée pendant l’écriture de ce billet, implémente la seconde et est sortie avec Akvorado 2.4. 🪓

Le rythme vertical structure les lignes selon un espacement régulier de haut en bas. Il permet de guider l’œil de manière fluide et prévisible. Grâce à l’unité CSS rlh, ce rythme est simple à mettre en place pour le texte¹. Mais les illustrations et les tableaux peuvent perturber la mise en page. Le typographe amateur en moi aspire à suivre la sagesse de Bringhurst :

Les titres, intertitres, citations, notes de bas de page, illustrations, légendes et autres intrusions dans le texte créent des syncopes et des variations par rapport au rythme de base d’un interlignage régulier. Ces variations peuvent et doivent animer la page, mais le texte principal doit également reprendre, après chaque variation, précisément la mesure et la phase.

― Robert Bringhurst, The Elements of Typographic Style

Pour le texte

Trois facteurs régissent le rythme vertical : la taille de police, la hauteur de ligne et la marge ou le remplissage. Posons la base avec une police de 18 pixels et une hauteur de ligne de 1,5 :

html {
  font-size: 112.5%;
  line-height: 1.5;
}
h1, h2, h3, h4 {
  font-size: 100%;
}
html, body,
h1, h2, h3, h4,
p, blockquote,
dl, dt, dd, ol, ul, li {
  margin: 0;
  padding: 0;
}

Le CSS Values and Units Module Level 4 définit l’unité rlh, égale à la hauteur de ligne de l’élément racine. Tous les navigateurs la gèrent depuis 2023². Utilisez-la pour insérer des espaces verticaux ou corriger la hauteur de ligne quand la taille de police change³ :

h1, h2, h3, h4 {
  margin-top: 2rlh;
  margin-bottom: 1rlh;
}
h1 {
  font-size: 2.5rem;
  line-height: 2rlh;
}
h2 {
  font-size: 1.5rem;
  line-height: 1rlh;
}
h3 {
  font-size: 1.25rem;
  line-height: 1rlh;
}
p, blockquote, pre {
  margin-top: 1rlh;
}
aside {
  font-size: 0.875rem;
  line-height: 1rlh;
}

Vérifions le résultat en superposant une grille⁴ au-dessus du texte :

Si un sous-élément utilise une police aux métriques intrinsèques plus hautes, il peut étirer la boîte de la ligne au-delà de la hauteur configurée⁵. Une astuce consiste à ramener la hauteur de ligne à 1. Les glyphes débordent mais ne poussent pas la ligne plus haut.

code, kbd {
  line-height: 1;
}

Pour les images adaptatives

Les images adaptatives, dont la taille s’ajuste à la largeur de l’affichage, sont difficiles à aligner sur la grille car leur hauteur nous est inconnue. Le CSS Rhythmic Sizing Module Level 1 introduit la propriété block-step pour ajuster la hauteur d’un élément à un multiple d’une unité de pas. Cependant, la plupart des navigateurs ne la gèrent pas encore.

Avec JavaScript, nous pouvons ajouter un remplissage autour de l’image pour qu’elle ne perturbe pas le rythme vertical :

const targets = document.querySelectorAll(".lf-media-outer");
const adjust = (el, height) => {
  const rlh = parseFloat(getComputedStyle(document.documentElement).lineHeight);
  const padding = Math.ceil(height / rlh) * rlh - height;
  el.style.padding = `${padding / 2}px 0`;
};

targets.forEach((el) => adjust(el, el.clientHeight));

Comme l’image est adaptative, sa hauteur peut varier. Il faut appeler la fonction adjust() dans un observateur :

const ro = new ResizeObserver((entries) => {
  for (const entry of entries) {
    const height = entry.contentBoxSize[0].blockSize;
    adjust(entry.target, height);
  }
});
for (const target of targets) {
  ro.observe(target);
}

Pour les tableaux

Les cellules d’un tableau pourraient fixer leur hauteur à 1rlh mais paraîtraient à l’étroit. Passer à 2rlh gaspille trop d’espace. À la place, nous utilisons l’interligne incrémental : une ligne sur cinq est alignée sur la grille.

table {
  border-spacing: 2px 0;
  border-collapse: separate;
  th {
    padding: 0.4rlh 1em;
  }
  td {
    padding: 0.2rlh 0.5em;
  }
}

Pour aligner les éléments après le tableau, il faut ajouter un peu de remplissage. Nous pouvons soit réutiliser le code JavaScript des images, soit utiliser quelques lignes de CSS qui comptent les lignes régulières et calculent le remplissage vertical manquant :

table:has(tbody tr:nth-child(5n):last-child)   { padding-bottom: 0.2rlh; }
table:has(tbody tr:nth-child(5n+1):last-child) { padding-bottom: 0.8rlh; }
table:has(tbody tr:nth-child(5n+2):last-child) { padding-bottom: 0.4rlh; }
table:has(tbody tr:nth-child(5n+3):last-child) { padding-bottom: 0 }
table:has(tbody tr:nth-child(5n+4):last-child) { padding-bottom: 0.6rlh; }

Une cellule d’en-tête a deux fois le remplissage d’une cellule régulière. Avec deux lignes régulières, le remplissage total vaut 2×2×0,2+2×0,4=1,6. Il faut ajouter 0.4rlh pour atteindre 2rlh de remplissage vertical supplémentaire autour du tableau.

Rien de tout cela n’est indispensable, mais une fois l’œil entraîné, il devient difficile de ne plus le remarquer. En attendant que les navigateurs implémentent le CSS Rhythmic Sizing, un mélange de de bidouilles CSS et d’un peu de JavaScript suffit. Le texte principal reprend désormais après chaque intrusion « précisément la mesure et la phase ». 🎼

J’ai souvent besoin d’un calcul rapide ou de convertir une unité en une autre. Plutôt que de recourir à un outil séparé, quelques lignes de configuration Zsh transforment = en calculatrice. En tapant = 660km / (2/3)c * 2 -> ms, j’obtiens 6.60457 ms¹ sans quitter mon terminal, grâce à l’éditeur de ligne de Zsh.

L’alias =

L’idée de base est simple : définir = comme alias vers une calculatrice en ligne de commande. Je préfère Numbat, une calculatrice scientifique gérant les conversions d’unités. Qalculate est une autre option². Si aucun des deux n’est disponible, nous nous rabattons sur le module zcalc intégré à Zsh.

Comme la commande alias utilise = comme séparateur entre nom et valeur, nous modifions directement le tableau associatif aliases :

if (( $+commands[numbat] )); then
  aliases[=]='numbat -e'
elif (( $+commands[qalc] )); then
  aliases[=]='qalc'
else
  autoload -Uz zcalc
  aliases[=]='zcalc -f -e'
fi

Ainsi, = 847/11 devient numbat -e 847/11.

Le problème des caractères spéciaux

Le premier problème apparaît vite. Taper = 5 * 3 échoue : Zsh interprète * comme un motif pour fichiers avant de le transmettre à la calculatrice. Le même souci se pose avec d’autres caractères spéciaux pour Zsh, comme > ou |. Il faut protéger l’expression :

$ = '5 * 3'
15

Nous corrigeons cela en nous appuyant sur l’éditeur de ligne de Zsh pour placer l’expression entre guillemets avant son exécution.

Protéger l’expression automatiquement avec ZLE

Zsh appelle le widget line-finish avant de valider une commande. Nous y attachons une fonction qui détecte le préfixe = et protège l’expression :

_vbe_calc_quote() {
  case $BUFFER in
    "="*)
      typeset -g _vbe_calc_expr=$BUFFER # not used yet
      BUFFER="= ${(q-)${${BUFFER#=}# }}"
      ;;
  esac
}
add-zle-hook-widget line-finish _vbe_calc_quote

Quand on tape = 5 * 3 puis ↲, _vbe_calc_quote protège l’expression avec le drapeau (q-) et réécrit la ligne en = '5 * 3' avant que Zsh ne valide la commande. En bonus, vous pouvez économiser quelques caractères avec =5*3 ! 🚀

Nous pouvons désormais effectuer des calculs et des conversions d’unités directement depuis le shell. Zsh protège automatiquement les expressions :

$ = '1 + 2'
3
$ = 'pi/3 + pi |> cos'
-0.5
$ = '17 USD -> EUR'
14.7122 €
$ = '180*500mg -> g'
90 g
$ = '5 gigabytes / (2 minutes + 17 seconds) -> megabits/s'
291.971 Mbit/s
$ = 'now() -> tz("Asia/Tokyo")'
2026-03-22 22:00:03 JST (UTC +09), Asia/Tokyo
$ = '1 / (40 rods / hogshead) -> L / 100km'
118548 × 0.01 l/km

Conserver l’expression originale dans l’historique

En l’état, Zsh enregistre l’expression protégée dans l’historique. Il faut la déprotéger avant de la soumettre à nouveau, sinon ZLE la protège une seconde fois. Bart Schaefer m’a fourni une solution pour stocker la version originale :

_vbe_calc_history() {
  return ${+_vbe_calc_expr}
}
add-zsh-hook zshaddhistory _vbe_calc_history

_vbe_calc_preexec() {
  (( ${+_vbe_calc_expr} )) && print -s $_vbe_calc_expr
  unset _vbe_calc_expr
  return 0
}
add-zsh-hook preexec _vbe_calc_preexec

Le hook zshaddhistory renvoie 1 quand une expression est en cours d’évaluation, indiquant à Zsh de ne pas enregistrer la commande. Le hook preexec ajoute ensuite la commande originale, non protégée, avec print -s.

Le code complet est disponible dans mon zshrc. Une alternative courante est le modificateur noglob. En utilisant to au lieu de -> pour les conversions d’unités, il couvre 90 % des cas. Pour une astuce similaire avec l’éditeur de ligne de Zsh, voyez comment j’utilise les expansions automatiques des alias pour corriger les fautes de frappe courantes.

Akvorado, un collecteur de flux réseau, s’appuie sur Traefik, un proxy HTTP, pour exposer les services HTTP d’un environnement Docker Compose. Des labels Docker attachés à chaque service définissent les règles de routage. Traefik les prend en compte automatiquement au démarrage d’un conteneur. Plutôt que de maintenir un fichier de configuration statique pour collecter les métriques Prometheus, la même approche s’applique avec Grafana Alloy, simplifiant sa configuration.

Traefik & Docker

Traefik écoute les événements sur la socket Docker. Chaque service annonce sa configuration via des labels. Par exemple, voici le service Loki dans Akvorado :

services:
  loki:
    # …
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix(`/loki`)

Dès que le conteneur est opérationnel, Traefik crée un routeur qui redirige les requêtes correspondant à /loki vers le premier port exposé. Placer la configuration Traefik au sein même de la définition du service est attirant. Comment obtenir la même chose pour les métriques Prometheus ?

Découverte de métriques avec Alloy

Grafana Alloy, un collecteur de métriques capable de collecter des métriques Prometheus, inclut un composant discovery.docker. Tout comme Traefik, il se connecte à la socket Docker¹. Avec quelques règles de réétiquetage, on peut lui apprendre à utiliser les labels Docker pour localiser et collecter les métriques.

On définit trois labels sur chaque service :

• metrics.enable active la collecte de métriques,
• metrics.port indique le port exposant les métriques Prometheus,
• metrics.path indique le chemin vers les métriques.

Si le service expose plus d’un port, metrics.port est obligatoire, sinon il prend par défaut la valeur de l’unique port exposé. La valeur par défaut de metrics.path est /metrics. Le service Loki devient :

services:
  loki:
    # …
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix(`/loki`)
      - metrics.enable=true
      - metrics.path=/loki/metrics

La configuration d’Alloy se divise en quatre parties :

1. découvrir les conteneurs via la socket Docker,
2. filtrer et réétiqueter les cibles à l’aide des labels Docker,
3. collecter les métriques,
4. transmettre les métriques à Prometheus.

Découverte des conteneurs Docker

Le premier bloc découvre les conteneurs en cours d’exécution :

discovery.docker "docker" {
  host             = "unix:///var/run/docker.sock"
  refresh_interval = "30s"
  filter {
    name   = "label"
    values = ["com.docker.compose.project=akvorado"]
  }
}

Alloy se connecte à la socket Docker et liste les conteneurs toutes les 30 secondes². Le bloc filter restreint la découverte aux conteneurs du projet akvorado, évitant toute interférence avec d’autres conteneurs sur le même hôte. Pour chaque conteneur découvert, Alloy produit une cible avec des labels tels que __meta_docker_container_label_metrics_port pour le label Docker metrics.port.

Réétiquetage des cibles

L’étape de réétiquetage filtre et transforme les cibles brutes issues de la découverte Docker en cibles exploitables. La première étape ne conserve que les cibles dont metrics.enable vaut true :

discovery.relabel "prometheus" {
  targets = discovery.docker.docker.targets

  // Keep only targets with metrics.enable=true
  rule {
    source_labels = ["__meta_docker_container_label_metrics_enable"]
    regex         = `true`
    action        = "keep"
  }

  // …
}

La deuxième étape remplace le port découvert lorsque metrics.port est défini :

// When metrics.port is set, override __address__.
rule {
  source_labels = ["__address__", "__meta_docker_container_label_metrics_port"]
  regex         = `(.+):\d+;(.+)`
  target_label  = "__address__"
  replacement   = "$1:$2"
}

Ensuite, on gère les conteneurs en mode réseau host. Quand __meta_docker_network_name vaut host, l’adresse est réécrite en host.docker.internal au lieu de localhost³ :

// When host networking, override __address__ to host.docker.internal.
rule {
  source_labels = ["__meta_docker_container_label_metrics_port", "__meta_docker_network_name"]
  regex         = `(.+);host`
  target_label  = "__address__"
  replacement   = "host.docker.internal:$1"
}

L’étape suivante dérive le label job à partir du nom du service, en supprimant tout suffixe numéroté. Le label instance est l’adresse sans le port :

rule {
  source_labels = ["__meta_docker_container_label_com_docker_compose_service"]
  regex         = `(.+)(?:-\d+)?`
  target_label  = "job"
}
rule {
  source_labels = ["__address__"]
  regex         = `(.+):\d+`
  target_label  = "instance"
}

Si un conteneur définit metrics.path, Alloy l’utilise comme chemin. Sinon, la valeur par défaut est /metrics :

rule {
  source_labels = ["__meta_docker_container_label_metrics_path"]
  regex         = `(.+)`
  target_label  = "__metrics_path__"
}
rule {
  source_labels = ["__metrics_path__"]
  regex         = ""
  target_label  = "__metrics_path__"
  replacement   = "/metrics"
}

Collecte et transmission

Une fois les cibles correctement réétiquetées, la collecte et la transmission sont sommaires :

prometheus.scrape "docker" {
  targets         = discovery.relabel.prometheus.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

prometheus.remote_write "default" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

prometheus.scrape récupère périodiquement les métriques des cibles découvertes. prometheus.remote_write les transmet à Prometheus.

Exporteurs intégrés

Certains services n’exposent pas de point d’accès Prometheus. Redis et Kafka en sont des exemples courants. Alloy embarque des exporteurs Prometheus capables d’interroger ces services et d’exposer les métriques à leur place.

prometheus.exporter.redis "docker" {
  redis_addr = "redis:6379"
}
discovery.relabel "redis" {
  targets = prometheus.exporter.redis.docker.targets
  rule {
    target_label = "job"
    replacement  = "redis"
  }
}
prometheus.scrape "redis" {
  targets         = discovery.relabel.redis.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

Le même schéma s’applique à Kafka :

prometheus.exporter.kafka "docker" {
  kafka_uris = ["kafka:9092"]
}
discovery.relabel "kafka" {
  targets = prometheus.exporter.kafka.docker.targets
  rule {
    target_label = "job"
    replacement  = "kafka"
  }
}
prometheus.scrape "kafka" {
  targets         = discovery.relabel.kafka.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
}

Chaque exporteur est un composant distinct avec sa propre configuration de réétiquetage et de collecte. Le label job est défini explicitement.

Avec cette configuration, ajouter des métriques à un nouveau service disposant d’un point d’accès Prometheus se résume à quelques labels dans docker-compose.yml, tout comme l’ajout d’une route Traefik. Alloy s’en charge automatiquement. Une approche similaire est possible avec d’autres méthodes de découverte, comme discovery.kubernetes, discovery.scaleway ou discovery.http. 🩺