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.4rem;
  line-height: 2rlh;
}
h2 {
  font-size: 1.5rem;
  line-height: 1rlh;
}
h3 {
  font-size: 1.2rem;
  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. 🩺

J’ai exhumé quelques vieux articles tapés, adolescent, entre 1996 et 1998. Sans éclat à leur époque, ces pages composent, trois décennies plus tard, la chronique d’un temps disparu.

Le mot « blog » n’existe pas encore. Wikipédia reste à venir. Google n’a pas vu le jour. AltaVista règne sur les recherches, tout en peinant déjà à embrasser l’immensité naissante du web¹. Pour se rencontrer, il faut s’accorder au préalable et préparer son chemin sur des cartes en papier. 🗺️

Le web s’élance. La spécification CSS vient à peine d’éclore, les tables HTML servent encore à la mise en page. Les cookies et les bandeaux publicitaires pointent leur nez. Les pages s’ornent de musiques et de vidéos, contraignant les navigateurs à s’armer de plugins. Netscape Navigator trône sur 86% du territoire, mais Windows 95 glisse désormais Internet Explorer dans sa besace pour combler son retard. Face à cette offensive, Netscape ouvre les sources de son navigateur.

La France accumule les retards. En dehors des universités, l’accès à Internet demeure onéreux et laborieux. Le Minitel règne encore, offrant annuaire, billets de train, achats à distance. Cela n’était pas encore possible avec Internet : acheter un CD en ligne relève de la chimère. Le chiffrement subit une réglementation de fer : l’algorithme DES est bridé à 40 bits et décrypté en quelques secondes.

Ces pages portent la trace de l’adolescence du web. Trente années sont passées. Les mêmes guerres se poursuivent : vente de données, publicité, monopoles.

Les solutions RAID classiques gaspillent de l’espace lorsque les disques sont de tailles différentes. Le RAID logiciel Linux avec LVM exploite la capacité totale de chaque disque et permet d’étendre le stockage en remplaçant un ou deux disques à la fois.¹

Nous partons de quatre disques de taille identique :

$ lsblk -Mo NAME,TYPE,SIZE
NAME TYPE  SIZE
vda  disk  101M
vdb  disk  101M
vdc  disk  101M
vdd  disk  101M

Nous créons une partition sur chacun d’eux :

$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vda
$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vdb
$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vdc
$ sgdisk --zap-all --new=0:0:0 -t 0:fd00 /dev/vdd
$ lsblk -Mo NAME,TYPE,SIZE
NAME   TYPE  SIZE
vda    disk  101M
└─vda1 part  100M
vdb    disk  101M
└─vdb1 part  100M
vdc    disk  101M
└─vdc1 part  100M
vdd    disk  101M
└─vdd1 part  100M

Nous assemblons les quatre partitions pour former un volume RAID 5² :

$ mdadm --create /dev/md0 --level=raid5 --bitmap=internal --raid-devices=4 \
>   /dev/vda1 /dev/vdb1 /dev/vdc1 /dev/vdd1
$ lsblk -Mo NAME,TYPE,SIZE
    NAME          TYPE    SIZE
    vda           disk    101M
┌┈▶ └─vda1        part    100M
┆   vdb           disk    101M
├┈▶ └─vdb1        part    100M
┆   vdc           disk    101M
├┈▶ └─vdc1        part    100M
┆   vdd           disk    101M
└┬▶ └─vdd1        part    100M
 └┈┈md0           raid5 292.5M
$ cat /proc/mdstat
md0 : active raid5 vdd1[4] vdc1[2] vdb1[1] vda1[0]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous utilisons LVM pour créer des volumes logiques au-dessus du volume RAID.

$ pvcreate /dev/md0
  Physical volume "/dev/md0" successfully created.
$ vgcreate data /dev/md0
  Volume group "data" successfully created
$ lvcreate -L 100m -n bits data
  Logical volume "bits" created.
$ lvcreate -L 100m -n pieces data
  Logical volume "pieces" created.
$ mkfs.ext4 -q /dev/data/bits
$ mkfs.ext4 -q /dev/data/pieces
$ lsblk -Mo NAME,TYPE,SIZE
    NAME          TYPE    SIZE
    vda           disk    101M
┌┈▶ └─vda1        part    100M
┆   vdb           disk    101M
├┈▶ └─vdb1        part    100M
┆   vdc           disk    101M
├┈▶ └─vdc1        part    100M
┆   vdd           disk    101M
└┬▶ └─vdd1        part    100M
 └┈┈md0           raid5 292.5M
    ├─data-bits   lvm     100M
    └─data-pieces lvm     100M
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   1   2   0 wz--n- 288.00m 88.00m

Nous obtenons la configuration suivante :

Nous remplaçons /dev/vda par un disque plus grand. Nous le réintégrons dans la grappe RAID 5 après avoir copié les partitions de /dev/vdb :

$ cat /proc/mdstat
md0 : active (auto-read-only) raid5 vdb1[1] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vda /dev/vdb
$ sgdisk --randomize-guids /dev/vda
$ mdadm --manage /dev/md0 --add /dev/vda1
$ cat /proc/mdstat
md0 : active raid5 vda1[5] vdb1[1] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous n’utilisons pas la capacité supplémentaire : cette configuration ne survivrerait pas à la perte de /dev/vda car nous ne disposons d’aucune capacité de réserve. Nous devons remplacer un second disque, tel que /dev/vdb :

$ cat /proc/mdstat
md0 : active (auto-read-only) raid5 vda1[5] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [U_UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vdb /dev/vdc
$ sgdisk --randomize-guids /dev/vdb
$ mdadm --manage /dev/md0 --add /dev/vdb1
$ cat /proc/mdstat
md0 : active raid5 vdb1[6] vda1[5] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous créons un nouveau volume RAID 1 en utilisant l’espace libre sur /dev/vda et /dev/vdb :

$ sgdisk --new=0:0:0 -t 0:fd00 /dev/vda
$ sgdisk --new=0:0:0 -t 0:fd00 /dev/vdb
$ mdadm --create /dev/md1 --level=raid1 --bitmap=internal --raid-devices=2 \
>   /dev/vda2 /dev/vdb2
$ cat /proc/mdstat
md1 : active raid1 vdb2[1] vda2[0]
      101312 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid5 vdb1[6] vda1[5] vdd1[4] vdc1[2]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Nous ajoutons /dev/md1 au groupe de volumes :

$ pvcreate /dev/md1
  Physical volume "/dev/md1" successfully created.
$ vgextend data /dev/md1
  Volume group "data" successfully extended
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   2   2   0 wz--n- 384.00m 184.00m
$  lsblk -Mo NAME,TYPE,SIZE
       NAME          TYPE    SIZE
       vda           disk    201M
   ┌┈▶ ├─vda1        part    100M
┌┈▶┆   └─vda2        part    100M
┆  ┆   vdb           disk    201M
┆  ├┈▶ ├─vdb1        part    100M
└┬▶┆   └─vdb2        part    100M
 └┈┆┈┈┈md1           raid1  98.9M
   ┆   vdc           disk    101M
   ├┈▶ └─vdc1        part    100M
   ┆   vdd           disk    101M
   └┬▶ └─vdd1        part    100M
    └┈┈md0           raid5 292.5M
       ├─data-bits   lvm     100M
       └─data-pieces lvm     100M

Nous obtenons la configuration suivante³ :

Étendons encore notre capacité en remplaçant /dev/vdc :

$ cat /proc/mdstat
md1 : active (auto-read-only) raid1 vda2[0] vdb2[1]
      101312 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active (auto-read-only) raid5 vda1[5] vdd1[4] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UU_U]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vdc /dev/vdb
$ sgdisk --randomize-guids /dev/vdc
$ mdadm --manage /dev/md0 --add /dev/vdc1
$ cat /proc/mdstat
md1 : active (auto-read-only) raid1 vda2[0] vdb2[1]
      101312 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid5 vdc1[7] vda1[5] vdd1[4] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Convertissons /dev/md1 d’un RAID 1 vers un RAID 5 :

$ mdadm --grow /dev/md1 --level=5 --raid-devices=3 --add /dev/vdc2
mdadm: level of /dev/md1 changed to raid5
mdadm: added /dev/vdc2
$ cat /proc/mdstat
md1 : active raid5 vdc2[2] vda2[0] vdb2[1]
      202624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid5 vdc1[7] vda1[5] vdd1[4] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ pvresize /dev/md1
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   2   2   0 wz--n- 482.00m 282.00m

Nous obtenons la disposition suivante :

Nous étendons encore davantage notre capacité en remplaçant /dev/vdd :

$ cat /proc/mdstat
md0 : active (auto-read-only) raid5 vda1[5] vdc1[7] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active (auto-read-only) raid5 vda2[0] vdc2[2] vdb2[1]
      202624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ sgdisk --replicate=/dev/vdd /dev/vdc
$ sgdisk --randomize-guids /dev/vdd
$ mdadm --manage /dev/md0 --add /dev/vdd1
$ cat /proc/mdstat
md0 : active raid5 vdd1[4] vda1[5] vdc1[7] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active (auto-read-only) raid5 vda2[0] vdc2[2] vdb2[1]
      202624 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

Agrandissons le second volume RAID 5 :

$ mdadm --grow /dev/md1 --raid-devices=4 --add /dev/vdd2
mdadm: added /dev/vdd2
$ cat /proc/mdstat
md0 : active raid5 vdd1[4] vda1[5] vdc1[7] vdb1[6]
      299520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid5 vdd2[3] vda2[0] vdc2[2] vdb2[1]
      303936 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 0/1 pages [0KB], 65536KB chunk
$ pvresize /dev/md1
$ vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   2   2   0 wz--n- 580.00m 380.00m
$ lsblk -Mo NAME,TYPE,SIZE
       NAME          TYPE    SIZE
       vda           disk    201M
   ┌┈▶ ├─vda1        part    100M
┌┈▶┆   └─vda2        part    100M
┆  ┆   vdb           disk    201M
┆  ├┈▶ ├─vdb1        part    100M
├┈▶┆   └─vdb2        part    100M
┆  ┆   vdc           disk    201M
┆  ├┈▶ ├─vdc1        part    100M
├┈▶┆   └─vdc2        part    100M
┆  ┆   vdd           disk    301M
┆  └┬▶ ├─vdd1        part    100M
└┬▶ ┆  └─vdd2        part    100M
 ┆  └┈┈md0           raid5 292.5M
 ┆     ├─data-bits   lvm     100M
 ┆     └─data-pieces lvm     100M
 └┈┈┈┈┈md1           raid5 296.8M

Ce processus peut se poursuivre indéfiniment en remplaçant chaque disque un par un en s’appuyant sur les mêmes étapes. ♾️

Akvorado collecte des flux sFlow et IPFIX via UDP. Comme UDP ne retransmet pas les paquets perdus, il faut les traiter rapidement. Akvorado exécute plusieurs routines écoutant sur le même port. Le noyau devrait répartir équitablement les paquets reçus entre ces routines. Cependant, cela ne fonctionne pas comme prévu. Quelques routines présentent une perte de paquets importante :

$ curl -s 127.0.0.1:8080/api/v0/inlet/metrics \
> | sed -n s/akvorado_inlet_flow_input_udp_in_dropped//p
packets_total{listener="0.0.0.0:2055",worker="0"} 0
packets_total{listener="0.0.0.0:2055",worker="1"} 0
packets_total{listener="0.0.0.0:2055",worker="2"} 0
packets_total{listener="0.0.0.0:2055",worker="3"} 1.614933572278264e+15
packets_total{listener="0.0.0.0:2055",worker="4"} 0
packets_total{listener="0.0.0.0:2055",worker="5"} 0
packets_total{listener="0.0.0.0:2055",worker="6"} 9.59964121598348e+14
packets_total{listener="0.0.0.0:2055",worker="7"} 0

eBPF peut aider en implémentant un algorithme de répartition alternatif. 🐝

Options pour la répartition de charge

Il existe trois méthodes pour répartir les paquets UDP entre des routines :

1. Une routine reçoit les paquets et les distribue aux autres routines.
2. Toutes les routines partagent la même chaussette.
3. Chaque routine a sa propre chaussette, liée au même port, avec l’option SO_REUSEPORT.

Option SO_REUSEPORT

Tom Hebert a ajouté l’option SO_REUSEPORT dans Linux 3.9. La présentation de sa série de patchs explique pourquoi cette nouvelle option est meilleure que les deux existantes du point de vue des performances :

SO_REUSEPORT permet à plusieurs chaussettes d’être liées au même port. […] Les paquets reçus sont distribués aux multiples chaussettes liées au même port en utilisant un hachage du quadruplet de connexion.

Le cas d’usage pour SO_RESUSEPORT en TCP serait quelque chose comme un serveur web écoutant sur le port 80 fonctionnant avec plusieurs routines, où chaque routine pourrait avoir sa propre chaussette d’écoute. Cela pourrait être une alternative à d’autres modèles :

1. avoir une routine d’écoute qui distribue les connexions aux autres routines ;
2. accepter sur une seule chaussette depuis plusieurs routines.

Dans le premier cas, la routine d’écoute peut facilement devenir un goulot d’étranglement. Dans le second cas, la proportion de connexions acceptées par routine a tendance à être inégale sous une charge élevée. […] Nous avons vu la disproportion atteindre un ratio de 3:1 entre la routine acceptant le plus de connexions et celle qui en accepte le moins. Avec SO_REUSEPORT, la distribution est uniforme.

Le cas d’usage pour SO_REUSEPORT en UDP serait quelque chose comme un serveur DNS. Une alternative serait de recevoir sur la même chaussette depuis plusieurs routines. Comme dans le cas de TCP, la charge entre ces routines a tendance à être disproportionnée et nous observons également beaucoup de contention sur le verrou de la chaussette.

Akvorado utilise l’option SO_REUSEPORT pour distribuer les paquets entre les routines. Comme la distribution utilise un hachage du quadruplet de connexion, une seule routine gère tous les flux provenant d’un exporteur.

Option SO_ATTACH_REUSEPORT_EBPF

Dans Linux 4.5, Craig Gallek a ajouté l’option SO_ATTACH_REUSEPORT_EBPF pour permettre à un programme eBPF de sélectionner la chaussette UDP cible. Dans Linux 4.6, il l’a étendue pour prendre en charge TCP. La page de manuel socket(7) documente ce mécanisme¹ :

Le programme BPF doit renvoyer un index entre 0 et N-1 représentant la chaussette qui devrait recevoir le paquet (où N est le nombre de chaussettes dans le groupe). Si le programme BPF renvoie un index invalide, la sélection de chaussette se rabattra sur le mécanisme SO_REUSEPORT standard.

Dans Linux 4.19, Martin KaFai Lau a ajouté le type de programme BPF_PROG_TYPE_SK_REUSEPORT. Un tel programme eBPF sélectionne la chaussette à partir d’un tableau associatif. Cette nouvelle approche est plus flexible et permet par exemple un redémarrage sans impact en insérant les chaussettes d’une nouvelle instance.

Répartition de charge avec eBPF et Go

Modifier l’algorithme de répartition de charge pour un groupe de chaussettes nécessite deux étapes :

1. écrire et compiler un programme eBPF en C² ;
2. le charger et l’attacher en Go.

Programme eBPF en C

Un algorithme de répartition de charge simple consiste à choisir aléatoirement la chaussette de destination. Le noyau expose la fonction bpf_get_prandom_u32() pour obtenir un nombre pseudo-aléatoire.

volatile const __u32 num_sockets; // ❶

struct {
    __uint(type, BPF_MAP_TYPE_REUSEPORT_SOCKARRAY);
    __type(key, __u32);
    __type(value, __u64);
    __uint(max_entries, 256);
} socket_map SEC(".maps"); // ❷

SEC("sk_reuseport")
int reuseport_balance_prog(struct sk_reuseport_md *reuse_md)
{
    __u32 index = bpf_get_prandom_u32() % num_sockets; // ❸
    bpf_sk_select_reuseport(reuse_md, &socket_map, &index, 0); // ❹
    return SK_PASS; // ❺
}

char _license[] SEC("license") = "GPL";

En ❶, nous déclarons une constante volatile pour le nombre de chaussettes dans le groupe. Nous initialiserons cette constante avant de charger le programme eBPF dans le noyau. En ❷, nous définissons le tableau associatif de chaussettes. Nous le remplirons par la suite avec les descripteurs de fichiers. En ❸, nous sélectionnons aléatoirement l’index de la chaussette cible³. En ❹, nous invoquons la fonction bpf_sk_select_reuseport() pour enregistrer notre décision. Enfin, en ❺, nous acceptons le paquet.

Fichiers d’en-tête

Si vous compilez le source C avec clang, vous obtenez des erreurs dues à des entêtes manquantes. La méthode conseillée pour résoudre ce problème consiste à générer un fichier vmlinux.h avec bpftool :

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

Ensuite, incluez les entêtes suivantes⁴ :

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

Pour mon noyau 6.17, le fichier vmlinux.h généré est assez volumineux : 2,7 Mio. De plus, bpf/bpf_helpers.h est fourni avec libbpf. Cela ajoute une autre dépendance. Comme le programme eBPF est assez petit, je préfère mettre le strict minimum dans vmlinux.h en sélectionnant les définitions dont j’ai besoin.

Compilation

La bibliothèque eBPF pour Go fournit bpf2go, un outil pour compiler les programmes eBPF et générer un squelette de code. Nous créons un fichier gen.go avec le contenu suivant :

package main

//go:generate go tool bpf2go -tags linux reuseport reuseport_kern.c

Après avoir exécuté go generate ./..., nous pouvons inspecter les objets résultants avec readelf et llvm-objdump :

$ readelf -S reuseport_bpfeb.o
There are 14 section headers, starting at offset 0x840:
  [Nr] Name              Type             Address           Offset
[…]
  [ 3] sk_reuseport      PROGBITS         0000000000000000  00000040
  [ 6] .maps             PROGBITS         0000000000000000  000000c8
  [ 7] license           PROGBITS         0000000000000000  000000e8
[…]
$ llvm-objdump -S reuseport_bpfeb.o
reuseport_bpfeb.o:  file format elf64-bpf
Disassembly of section sk_reuseport:
0000000000000000 <reuseport_balance_prog>:
; {
       0:   bf 61 00 00 00 00 00 00     r6 = r1
;     __u32 index = bpf_get_prandom_u32() % num_sockets;
       1:   85 00 00 00 00 00 00 07     call 0x7
[…]

Utilisation depuis Go

Configurons 10 routines écoutant sur le même port⁵. Chaque chaussette active l’option SO_REUSEPORT avant de se mettre en écoute⁶ :

var (
    err error
    fds []uintptr
    conns []*net.UDPConn
)
workers := 10
listenAddr := "127.0.0.1:0"
listenConfig := net.ListenConfig{
    Control: func(_, _ string, c syscall.RawConn) error {
        c.Control(func(fd uintptr) {
            err = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
            fds = append(fds, fd)
        })
        return err
    },
}
for range workers {
    pconn, err := listenConfig.ListenPacket(t.Context(), "udp", listenAddr)
    if err != nil {
        t.Fatalf("ListenPacket() error:\n%+v", err)
    }
    udpConn := pconn.(*net.UDPConn)
    listenAddr = udpConn.LocalAddr().String()
    conns = append(conns, udpConn)
}

La deuxième étape consiste à charger le programme eBPF, initialiser la variable num_sockets, remplir le tableau de chaussettes et attacher le programme à la première chaussette⁷.

// Charge la collection eBPF.
spec, err := loadReuseport()
if err != nil {
    t.Fatalf("loadVariables() error:\n%+v", err)
}

// Initialise la variable globale "num_sockets" avec le nombre de descripteurs de fichiers.
if err := spec.Variables["num_sockets"].Set(uint32(len(fds))); err != nil {
    t.Fatalf("NumSockets.Set() error:\n%+v", err)
}

// Charge le programme et le tableau dans le noyau.
var objs reuseportObjects
if err := spec.LoadAndAssign(&objs, nil); err != nil {
    t.Fatalf("loadReuseportObjects() error:\n%+v", err)
}
t.Cleanup(func() { objs.Close() })

// Renseigne les descripteurs de fichiers dans le tableau de chaussettes.
for worker, fd := range fds {
    if err := objs.reuseportMaps.SocketMap.Put(uint32(worker), uint64(fd)); err != nil {
        t.Fatalf("SocketMap.Put() error:\n%+v", err)
    }
}

// Attache le programme eBPF à la première chaussette.
socketFD := int(fds[0])
progFD := objs.reuseportPrograms.ReuseportBalanceProg.FD()
if err := unix.SetsockoptInt(socketFD, unix.SOL_SOCKET, unix.SO_ATTACH_REUSEPORT_EBPF, progFD); err != nil {
    t.Fatalf("SetsockoptInt() error:\n%+v", err)
}

Nous sommes maintenant prêts à traiter les paquets. Chaque routine Go incrémente un compteur pour chaque paquet reçu⁸ :

var wg sync.WaitGroup
receivedPackets := make([]int, workers)
for worker := range workers {
    conn := conns[worker]
    packets := &receivedPackets[worker]
    wg.Go(func() {
        payload := make([]byte, 9000)
        for {
            if _, err := conn.Read(payload); err != nil {
                if errors.Is(err, net.ErrClosed) {
                    return
                }
                t.Logf("Read() error:\n%+v", err)
            }
            *packets++
        }
    })
}

Envoyons 1000 paquets :

sentPackets := 1000
conn, err := net.Dial("udp", conns[0].LocalAddr().String())
if err != nil {
    t.Fatalf("Dial() error:\n%+v", err)
}
defer conn.Close()
for range sentPackets {
    if _, err := conn.Write([]byte("hello world!")); err != nil {
        t.Fatalf("Write() error:\n%+v", err)
    }
}

Si nous affichons le contenu du tableau receivedPackets, nous pouvons vérifier que la répartition fonctionne comme prévu, chaque routine recevant environ 100 paquets :

=== RUN   TestUDPWorkerBalancing
    balancing_test.go:84: receivedPackets[0] = 107
    balancing_test.go:84: receivedPackets[1] = 92
    balancing_test.go:84: receivedPackets[2] = 99
    balancing_test.go:84: receivedPackets[3] = 105
    balancing_test.go:84: receivedPackets[4] = 107
    balancing_test.go:84: receivedPackets[5] = 96
    balancing_test.go:84: receivedPackets[6] = 102
    balancing_test.go:84: receivedPackets[7] = 105
    balancing_test.go:84: receivedPackets[8] = 99
    balancing_test.go:84: receivedPackets[9] = 88

    balancing_test.go:91: receivedPackets = 1000
    balancing_test.go:92: sentPackets     = 1000

Déploiement sans impact

Nous pouvons également utiliser SO_ATTACH_REUSEPORT_EBPF pour redémarrer une application sans impact. Une nouvelle instance de l’application prépare sa propre version du tableau de chaussettes et attache le programme eBPF à la première d’entre elles. Le noyau dirige alors les paquets entrants vers cette nouvelle instance. L’ancienne instance doit traiter les paquets déjà reçus avant de s’arrêter.

Pour vérifier que nous ne perdons aucun paquet, nous créons une routine Go pour envoyer autant de paquets que possible :

sentPackets := 0
notSentPackets := 0
done := make(chan bool)
conn, err := net.Dial("udp", conns1[0].LocalAddr().String())
if err != nil {
    t.Fatalf("Dial() error:\n%+v", err)
}
defer conn.Close()
go func() {
    for {
        if _, err := conn.Write([]byte("hello world!")); err != nil {
            notSentPackets++
        } else {
            sentPackets++
        }
        select {
        case <-done:
            return
        default:
        }
    }
}()

Ensuite, pendant que cette routine Go s’exécute, nous démarrons le deuxième ensemble de routines. Une fois configurées, elles commencent à recevoir des paquets. Si nous arrêtons proprement l’ensemble initial de routines, nous ne perdons aucun paquet⁹ !

=== RUN   TestGracefulRestart
    graceful_test.go:135: receivedPackets1[0] = 165
    graceful_test.go:135: receivedPackets1[1] = 195
    graceful_test.go:135: receivedPackets1[2] = 194
    graceful_test.go:135: receivedPackets1[3] = 190
    graceful_test.go:135: receivedPackets1[4] = 213
    graceful_test.go:135: receivedPackets1[5] = 187
    graceful_test.go:135: receivedPackets1[6] = 170
    graceful_test.go:135: receivedPackets1[7] = 190
    graceful_test.go:135: receivedPackets1[8] = 194
    graceful_test.go:135: receivedPackets1[9] = 155

    graceful_test.go:139: receivedPackets2[0] = 1631
    graceful_test.go:139: receivedPackets2[1] = 1582
    graceful_test.go:139: receivedPackets2[2] = 1594
    graceful_test.go:139: receivedPackets2[3] = 1611
    graceful_test.go:139: receivedPackets2[4] = 1571
    graceful_test.go:139: receivedPackets2[5] = 1660
    graceful_test.go:139: receivedPackets2[6] = 1587
    graceful_test.go:139: receivedPackets2[7] = 1605
    graceful_test.go:139: receivedPackets2[8] = 1631
    graceful_test.go:139: receivedPackets2[9] = 1689

    graceful_test.go:147: receivedPackets = 18014
    graceful_test.go:148: sentPackets     = 18014

Malheureusement, arrêter correctement une chaussette UDP n’est pas trivial en Go¹⁰. Auparavant, nous terminions les routines en fermant leurs chaussettes. Cependant, si nous les fermons trop tôt, l’application perd les paquets qui leur ont été attribués mais qui n’ont pas encore été traités. Avant de s’arrêter, une routine doit appeler conn.Read() jusqu’à ce qu’il n’y ait plus de paquets. Une solution consiste à définir une échéance pour conn.Read() et vérifier si nous devons arrêter la routine Go lorsque l’échéance est écoulée :

payload := make([]byte, 9000)
for {
    conn.SetReadDeadline(time.Now().Add(50 * time.Millisecond))
    if _, err := conn.Read(payload); err != nil {
        if errors.Is(err, os.ErrDeadlineExceeded) {
            select {
            case <-done:
                return
            default:
                continue
            }
        }
        t.Logf("Read() error:\n%+v", err)
    }
    *packets++
}

Avec TCP, cet aspect est plus simple : après avoir activé le paramètre noyau net.ipv4.tcp_migrate_req, le noyau migre automatiquement les connexions en attentes vers une chaussette aléatoire du même groupe. Alternativement, eBPF peut également contrôler cette migration. Les deux fonctionnalités sont disponibles depuis Linux 5.14.

Addendum

Après avoir implémenté cette stratégie dans Akvorado, toutes les routines perdent désormais des paquets ! 😱

$ curl -s 127.0.0.1:8080/api/v0/inlet/metrics \
> | sed -n s/akvorado_inlet_flow_input_udp_in_dropped//p
packets_total{listener="0.0.0.0:2055",worker="0"} 838673
packets_total{listener="0.0.0.0:2055",worker="1"} 843675
packets_total{listener="0.0.0.0:2055",worker="2"} 837922
packets_total{listener="0.0.0.0:2055",worker="3"} 841443
packets_total{listener="0.0.0.0:2055",worker="4"} 840668
packets_total{listener="0.0.0.0:2055",worker="5"} 850274
packets_total{listener="0.0.0.0:2055",worker="6"} 835488
packets_total{listener="0.0.0.0:2055",worker="7"} 834479

La raison majeure est que le module Kafka limite par défaut les lots à 32 messages. Cette limite est trop basse car les brokers ont une charge importante lors du traitement de chaque lot : ils doivent s’assurer de leur bonne persistance avant d’accuser réception. Augmenter la limite à 4096 messages corrige ce problème.

Bien que la répartition des flux entrants avec eBPF reste utile, elle n’a pas résolu le problème principal. Au moins, la distribution uniforme des paquets perdus a aidé à identifier le véritable goulot d’étranglement. 😅