Prometheus 3.16.0 : fonction integral(), estimation du coût des requêtes PromQL et --web.external-url en HTTPS par défaut

Source : notes de version de Prometheus 3.16.0 (dépôt GitHub du projet) ; cycle de publication et versions LTS de Prometheus.

Le projet Prometheus a publié la version 3.16.0 de son serveur de monitoring : le tag est daté du 4 novembre 2026 et la release est sortie sur GitHub le 5 novembre, avec les images Docker. Au menu, une nouvelle fonction PromQL expérimentale, integral(), une estimation du coût des requêtes accompagnée de vraies limites d'exécution, et les sélecteurs smoothed et anchored qui passent en stable. Mais la version contient aussi six changements de comportement, dont un qui modifie les liens de vos alertes : quand TLS est activé sur Prometheus, l'URL externe calculée par défaut passe de http:// à https://.

Cet article fait le tri pour un administrateur de VPS Linux ou de serveur dédié qui surveille ses machines et ses serveurs de jeu avec Prometheus : ce qu'il faut vérifier avant de mettre à jour, ce que les nouveautés apportent concrètement, la procédure de mise à jour (binaire ou Docker) et l'alternative de la branche LTS 3.13 pour ceux qui ne veulent pas suivre chaque version mineure. Si vous n'avez pas encore de stack de supervision, notre guide installer Grafana et Prometheus sur un VPS Linux part de zéro.

Prometheus 3.16.0 en bref

• Date : tag du 4 novembre 2026, release GitHub et images prom/prometheus:v3.16.0 le 5 novembre ;
• Six changements (CHANGE) : URL externe en HTTPS si TLS est actif, exemplars à labels non uniques rejetés, métriques de métadonnées Remote Write 2.0 obsolètes retirées, batch_size plafonné à 1000 sur l'API de recherche, nouveau comptage des échantillons de sous-requêtes dans les statistiques, comptage des échantillons Remote Write 2.x reçus sans métadonnées ;
• Huit nouveautés (FEATURE), dont integral(), l'estimation du coût des requêtes PromQL, les sélecteurs smoothed et anchored stables, et metadata-wal-records en mode Agent ;
• Dix optimisations (PERF) de la base TSDB, du scrape et du parseur OpenMetrics 2.0, et une soixantaine de corrections de bugs ;
• Branche LTS : Prometheus 3.13, supportée jusqu'au 31 juillet 2027, dernière version 3.13.5 du 21 octobre 2026.

--web.external-url passe en HTTPS quand TLS est actif

Prometheus a besoin de connaître l'URL sous laquelle on l'atteint de l'extérieur : c'est l'URL externe, fixée par le flag --web.external-url. Elle sert à construire les liens de l'interface web et, surtout, le lien « source » que chaque alerte transporte jusqu'à Alertmanager (le champ generatorURL, qui renvoie vers le graphique de l'expression qui a déclenché l'alerte). Quand le flag n'est pas renseigné, Prometheus calcule une valeur par défaut à partir du nom d'hôte de la machine et du port de la première adresse d'écoute (--web.listen-address, 0.0.0.0:9090 par défaut).

Jusqu'à la 3.15, ce calcul utilisait toujours le schéma http://, même quand le fichier passé à --web.config.file activait TLS. Prometheus annonçait alors une adresse HTTP alors qu'il ne répondait plus qu'en HTTPS : les liens des alertes ne fonctionnaient pas. Depuis la 3.16 (PR #19241), la valeur déduite passe en https:// dès que ce fichier contient une section tls_server_config qui active réellement TLS, c'est-à-dire avec un certificat et une clé. Un bloc tls_server_config vide, ou qui ne règle qu'un paramètre comme min_version, laisse le schéma en http, tout comme un fichier qui ne configure que l'authentification basique. Une URL externe renseignée explicitement n'est jamais modifiée.

Le projet classe ce point parmi les changements et non parmi les corrections, car les liens générés changent. Concrètement, vous êtes concerné si vous cochez les trois cases : TLS activé dans le fichier de configuration web (que la documentation de la 3.16 marque toujours comme expérimental), aucun --web.external-url dans l'unité systemd ou le docker-compose.yml, et des alertes envoyées à Alertmanager. Après la mise à jour, les liens « Source » de vos notifications e-mail, Slack, Discord ou Telegram pointeront vers https://<nom-d-hote>:9090/. C'est plus juste qu'avant, mais le nom d'hôte de la machine (celui que renvoie la commande hostname) n'est pas forcément un nom public résolvable depuis l'extérieur. Pour le vérifier, interrogez l'API de votre Alertmanager pendant qu'une alerte est active :

curl -s http://localhost:9093/api/v2/alerts | jq -r '.[].generatorURL'

La bonne pratique ne change pas : fixez l'URL externe vous-même, avec le nom de domaine public du service. Derrière un reverse proxy Nginx qui termine le TLS avec un certificat Let's Encrypt, c'est même indispensable, puisque Prometheus ne voit alors que du HTTP en local et ne peut pas deviner l'adresse publique. Dans l'unité systemd :

ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.external-url=https://prometheus.example.com/

Si l'URL contient un chemin (https://example.com/prometheus/), le flag --web.route-prefix reprend ce chemin par défaut : inutile de le préciser deux fois.

Les autres changements à vérifier avant de mettre à jour

Les cinq autres changements de comportement touchent des fonctions plus pointues. Le tableau indique qui est concerné et quoi contrôler.

Exemplars : les labels en double ne passent plus

Un exemplar est un échantillon d'exemple accroché à une métrique, généralement porteur d'un identifiant de trace (trace_id) pour passer d'un pic de latence à la trace distribuée correspondante. Prometheus ne les stocke que si le flag --enable-feature=exemplar-storage est actif, dans un tampon circulaire en mémoire. Jusqu'ici, un exemplar dont deux labels portaient le même nom était enregistré tel quel, puis ressortait avec des clés JSON en double dans la réponse de /api/v1/query_exemplars, un JSON ambigu pour les clients de cette API. La TSDB les rejette désormais. Si un tableau de bord perd ses liens vers les traces après la mise à jour, c'est du côté de la bibliothèque d'instrumentation de l'application qu'il faut chercher.

Remote Write 2.0 : quatre métriques disparaissent

Les métriques prometheus_remote_storage_metadata_total, prometheus_remote_storage_metadata_failed_total, prometheus_remote_storage_metadata_retried_total et prometheus_remote_storage_metadata_bytes_total, déjà marquées obsolètes, ne sont plus exposées pour les files d'envoi en Remote Write 2.0. Une alerte qui surveillait les échecs d'envoi des métadonnées avec la première ou la deuxième restera muette sans erreur, puisqu'une série absente ne déclenche rien : repérez-les avant la mise à jour.

grep -rn 'prometheus_remote_storage_metadata' /etc/prometheus/

Nouvelle fonction PromQL integral()

La fonction integral() calcule l'intégrale d'une série temporelle sur la plage demandée, avec le temps exprimé en secondes. Elle est expérimentale et n'existe que si Prometheus est lancé avec --enable-feature=promql-experimental-functions ; le projet prévient que les fonctions de ce groupe peuvent encore changer de nom, de syntaxe ou de comportement, voire disparaître. Sa signature :

integral(v range-vector, strategy=2 scalar)

Le paramètre facultatif strategy choisit la méthode de calcul entre deux échantillons : 0 pour la méthode des rectangles à gauche, 1 pour les rectangles à droite, 2 (par défaut) pour la méthode des trapèzes, qui utilise la moyenne des deux échantillons voisins. La documentation précise que integral() ne doit être utilisée qu'avec des jauges (gauges), le plus souvent une grandeur exprimée par seconde ou par heure. Pour un compteur, increase() reste la bonne fonction.

Le cas d'usage est l'accumulation dans le temps d'une valeur instantanée. La documentation donne l'exemple d'un coût horaire transformé en coût total sur sept jours, en divisant par 3600 pour passer des secondes aux heures. Pour un serveur de jeu, une jauge du nombre de joueurs connectés, exposée par un exporter, se transforme de la même façon en « joueurs-heures » cumulées sur la journée, un indicateur de fréquentation plus parlant qu'un pic ponctuel. Une jauge de puissance en watts donne, elle, une énergie en wattheures :

# joueurs-heures sur les dernières 24 heures (jauge joueurs_connectes)
integral(joueurs_connectes[24h]) / 3600

# énergie en wattheures sur 7 jours (jauge exprimée en watts)
integral(puissance_watts[7d]) / 3600

Estimation du coût des requêtes et limites d'exécution

C'est la nouveauté la plus utile pour qui partage un Prometheus avec plusieurs personnes ou plusieurs tableaux de bord Grafana : une requête mal bornée, du type rate(http_requests_total[30d]) sans filtre de label, peut charger des millions d'échantillons et faire grimper la RAM du serveur jusqu'à l'OOM killer. Le flag expérimental --enable-feature=query-cost ajoute deux briques.

L'estimation, d'abord. Deux nouveaux endpoints, /api/v1/query_cost et /api/v1/query_range_cost, acceptent les mêmes paramètres que /api/v1/query et /api/v1/query_range et renvoient, sans exécuter la requête, le nombre estimé de séries touchées (seriesTouched) et d'échantillons lus (samplesRead). Sur les endpoints de requête classiques, le paramètre cost=true ajoute à la réponse une comparaison entre l'estimation et le coût réel. L'estimation est indicative : elle peut se tromper dans les deux sens et ne sert jamais à refuser une requête.

curl -s 'http://localhost:9090/api/v1/query_range_cost' \
  --data-urlencode 'query=rate(node_network_receive_bytes_total[5m])' \
  --data-urlencode 'start=2026-11-10T00:00:00Z' \
  --data-urlencode 'end=2026-11-11T00:00:00Z' \
  --data-urlencode 'step=60'

Les limites, ensuite. Trois nouveaux paramètres de la section global du fichier prometheus.yml, rechargeables à chaud, fixent un plafond appliqué pendant l'exécution, sur le coût réel :

global:
  scrape_interval: 15s
  query_max_series: 200000
  query_max_samples_read: 50000000
  query_max_duration: 1m

Les valeurs ci-dessus sont un exemple à adapter : les trois paramètres valent 0 par défaut, c'est-à-dire aucune limite (et pour query_max_duration, repli sur --query.timeout, 2 minutes par défaut). Une requête qui charge trop de séries ou lit trop d'échantillons est rejetée ; un dépassement de durée apparaît comme un timeout. Ces limites s'appliquent à toutes les requêtes, y compris les règles d'enregistrement et d'alerte : une règle d'alerte qui dépasse un plafond échoue comme n'importe quelle requête en erreur. Testez donc vos valeurs sur vos règles existantes avant de les serrer. Pour une requête donnée, les paramètres max_series, max_samples_read et max_query_duration permettent seulement de descendre sous ces plafonds : une valeur supérieure renvoie une erreur HTTP 400 (bad_data). Un client peut vérifier la présence de la fonction sur /api/v1/features, où elle apparaît sous le nom query_cost.

Sélecteurs smoothed et anchored : stables et actifs par défaut

Les modificateurs anchored et smoothed des sélecteurs de plage, jusqu'ici réservés au flag promql-extended-range-selectors, sont stables et toujours actifs. Le flag ne fait plus rien et peut être retiré de vos options de lancement.

• anchored prend, au début de la plage, le dernier échantillon connu (dans la limite du lookback delta), et le dernier échantillon de la plage à la fin, sans extrapolation ni interpolation. Il fonctionne avec resets, changes, rate, increase et delta. Avec increase sur des échantillons flottants, le résultat est un entier : un compteur de redémarrages ou de connexions affiche enfin un nombre rond, sans valeur extrapolée à virgule. Exemple : increase(http_requests_total[5m] anchored).
• smoothed interpole linéairement les valeurs aux bornes de la plage à partir des échantillons situés avant et après. Il fonctionne avec rate, increase et delta, et aussi sur un sélecteur instantané. Exemple : rate(http_requests_total[step()] smoothed).

Deux précautions tirées de la documentation : smoothed a besoin d'un échantillon postérieur à l'intervalle évalué, il a donc tendance à sous-estimer le résultat dans les règles d'alerte et d'enregistrement, où il faut obligatoirement ajouter un query_offset au groupe de règles ; et ces sélecteurs étendus ne sont pas pris en charge dans les sous-requêtes.

Mode Agent, timestamps de départ et autres nouveautés

• metadata-wal-records en mode Agent : ce flag conserve les métadonnées des séries (type, unité, aide) en mémoire et enregistre leurs changements dans le WAL. Il est nécessaire pour envoyer les métadonnées en Remote Write 2.0, et fonctionne désormais aussi avec --agent, le mode léger qui collecte et transmet sans stocker localement ni évaluer de requêtes. Utile pour un petit VPS qui envoie ses métriques vers un Prometheus central.
• Timestamps de départ : l'en-tête HTTP X-Prometheus-Use-Start-Timestamps active ou désactive, requête par requête, l'usage des timestamps de départ dans PromQL. Derrière le flag use-start-timestamps, ils servent aussi à détecter les remises à zéro des compteurs avec anchored et smoothed.
• Noms Unicode sans guillemets : derrière --enable-feature=promql-unquoted-utf8-names, les lettres Unicode et les points sont acceptés, après le premier caractère, dans les noms de métriques et de labels écrits sans guillemets.
• promtool affiche le nom du fichier de test pendant les tests unitaires de règles, ce qui facilite la lecture des logs d'une CI.
• Remote Write : un paramètre expérimental convert_nhcb_to_classic convertit les histogrammes natifs à buckets personnalisés (NHCB) en histogrammes classiques pour les bases distantes qui ne les gèrent pas.

Gains de performance : TSDB, scrape et parseur OpenMetrics

La 3.16 apporte dix optimisations. Celles qui comptent sur un VPS aux ressources limitées :

• TSDB : moins de mémoire pour écrire et relire les enregistrements de métadonnées des checkpoints du WAL, et métadonnées des séries dédupliquées en mémoire ;
• Encodage XOR2 : compression et ajout d'échantillons plus rapides. XOR2 est un encodage de chunks stable mais pas activé par défaut ; il se choisit avec le champ chunk_encoding.floats de la configuration TSDB, le flag xor2-encoding étant marqué obsolète ;
• Scrape : moins de copies du corps des réponses des cibles ;
• Parseur OpenMetrics 2.0 : réutilisation des tampons d'un scrape à l'autre, construction paresseuse des labels (moins d'allocations et de CPU) et conversion directe des histogrammes classiques en NHCB. Ce parseur reste expérimental et n'est actif qu'avec --enable-feature=openmetrics2 ;
• PromQL : timestamp(), start_timestamp() et absent() ne décodent plus que la somme et le nombre des histogrammes, pas leurs buckets, et les sous-requêtes avec modificateur @ ne lisent que leur fenêtre fixe.

Côté corrections, aucune des entrées de la 3.16 n'est présentée comme un correctif de sécurité, mais la soixantaine de bugs réglés en touche plusieurs qui se voient en production : la perte d'échantillons hors ordre (out-of-order) quand un checkpoint du WAL supprime l'enregistrement d'une série, des chunks en double après un redémarrage, une panique de la découverte de services Azure sur un tag de VM à valeur nulle, la restauration après redémarrage des alertes actives dont la durée for est plus courte que --rules.alert.for-grace-period, et une négociation HTTP/2 qui retombait silencieusement en HTTP/1.1 quand TLS est activé avec http2: true.

Mettre à jour Prometheus sur un VPS : installation par binaire

Avant tout, sachez quelle version tourne. Les paquets des distributions sont loin derrière : au 11 novembre 2026, le paquet prometheus est en 2.42 dans Debian 12, en 2.53 dans Debian 13, en 2.45 dans Ubuntu 24.04 et en 2.53 dans Ubuntu 26.04 LTS. La 3.16 concerne donc ceux qui ont installé le binaire officiel ou l'image Docker. Pour connaître la version en cours :

prometheus --version
curl -s http://localhost:9090/api/v1/status/buildinfo

La procédure suivante reprend l'installation de notre guide Grafana et Prometheus : binaires dans /usr/local/bin, configuration dans /etc/prometheus, service systemd nommé prometheus. Téléchargez l'archive et le fichier de sommes de contrôle, vérifiez l'intégrité, puis validez votre configuration avec le promtool de la nouvelle version :

cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v3.16.0/prometheus-3.16.0.linux-amd64.tar.gz
wget https://github.com/prometheus/prometheus/releases/download/v3.16.0/sha256sums.txt
sha256sum -c --ignore-missing sha256sums.txt
tar xzf prometheus-3.16.0.linux-amd64.tar.gz
./prometheus-3.16.0.linux-amd64/promtool check config /etc/prometheus/prometheus.yml

Sur un serveur ARM, remplacez linux-amd64 par linux-arm64. Gardez une copie de l'ancien binaire pour pouvoir revenir en arrière, puis remplacez les deux exécutables et redémarrez le service :

sudo cp /usr/local/bin/prometheus /usr/local/bin/prometheus.old
sudo cp /usr/local/bin/promtool /usr/local/bin/promtool.old
sudo systemctl stop prometheus
sudo install -m 0755 prometheus-3.16.0.linux-amd64/prometheus prometheus-3.16.0.linux-amd64/promtool /usr/local/bin/
sudo systemctl start prometheus
journalctl -u prometheus -n 50 --no-pager
prometheus --version

Au redémarrage, Prometheus relit son WAL avant d'être prêt : sur une base volumineuse, cela peut prendre un moment. Contrôlez ensuite l'état des cibles sur la page /targets de l'interface, puis vos alertes. La release publie aussi des archives pour Windows (windows-amd64.zip) si votre Prometheus tourne sur un VPS Windows.

Mettre à jour Prometheus avec Docker

Les images officielles sont publiées sous prom/prometheus sur Docker Hub (et sous quay.io/prometheus/prometheus). Sur Docker Hub, la 3.16 existe en trois variantes : v3.16.0, v3.16.0-busybox et v3.16.0-distroless. Attention aux tags flottants : latest et v3 pointent sur la 3.16.0 depuis le 5 novembre. Un conteneur déclaré avec image: prom/prometheus sans tag passera donc en 3.16 au prochain docker compose pull, ou tout seul si un outil de mise à jour automatique des conteneurs tourne sur le serveur. Épinglez une version précise dans le docker-compose.yml :

services:
  prometheus:
    image: prom/prometheus:v3.16.0
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --web.external-url=https://prometheus.example.com/
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    restart: unless-stopped

volumes:
  prometheus-data:

Validez la configuration avec le promtool de la nouvelle image, puis recréez le conteneur :

docker run --rm --entrypoint promtool -v "$PWD/prometheus.yml:/etc/prometheus/prometheus.yml:ro" prom/prometheus:v3.16.0 check config /etc/prometheus/prometheus.yml
docker compose pull prometheus
docker compose up -d prometheus
docker compose logs --tail 50 prometheus

Les données restent dans le volume nommé et survivent à la recréation du conteneur. Pour revenir en arrière, remettez l'ancien tag (v3.15.1) et relancez docker compose up -d. Une fois la nouvelle version validée, l'ancienne image se supprime avec docker image prune (voir nettoyer Docker avec prune). Si Docker n'est pas encore installé, commencez par installer Docker sur un VPS et Docker Compose sur VPS Linux.

Rester sur la branche LTS 3.13

Prometheus sort une version mineure toutes les six semaines, et une mineure ne reçoit en général plus de corrections une fois la suivante publiée. Pour un serveur de monitoring qu'on ne veut pas toucher tous les mois et demi, le projet désigne des versions LTS (Long Term Support), maintenues un an. La LTS en cours est Prometheus 3.13, sortie le 1er juillet 2026 et supportée jusqu'au 31 juillet 2027. La prochaine LTS est annoncée pour juin 2027, avec un chevauchement d'au moins un mois pour migrer sans précipitation.

Une LTS ne reçoit pas tout : uniquement une sélection de correctifs de gravité élevée (CVSS 7.0 ou plus), quelques corrections de bugs et de documentation, et une chaîne de compilation tenue à jour. Les fonctions expérimentales et instables en sont exclues. La 3.13.5 du 21 octobre en est un bon exemple : elle n'apporte aucune nouveauté, mais une compilation avec Go 1.26.10 pour corriger des failles de net/http, crypto/tls et html/template, une mise à jour de golang.org/x/net contre des failles HTTP/2, et le retrait de deux autorités de certification des images Docker. Pour rester sur cette branche, épinglez prom/prometheus:v3.13.5 ou téléchargez prometheus-3.13.5.linux-amd64.tar.gz, et surveillez les versions 3.13.x suivantes. Notez que integral() et les limites de requêtes, apparues dans la 3.16, n'existent pas dans cette branche.

Faut-il passer à la 3.16 maintenant ?

Si vous êtes en 3.14 ou 3.15, rien ne presse côté sécurité : les notes de version de la 3.16 ne signalent aucune faille corrigée. Mais une mineure ne reçoit en principe plus de corrections une fois la suivante sortie : planifiez la mise à jour, après avoir vérifié les trois points du tableau qui vous concernent le plus souvent (URL externe, métriques Remote Write, exemplars). Si votre Prometheus tourne en Docker sur le tag latest, la décision est peut-être déjà prise : vérifiez la version réellement en service avec l'API buildinfo. Si vous préférez la stabilité, la 3.13 LTS vous laisse jusqu'à l'été 2027. Dans tous les cas, gardez Prometheus et ses exporters derrière le pare-feu (voir ouvrir et fermer les ports avec UFW) et n'exposez que Grafana, en HTTPS.

Lexique Prometheus

• PromQL : langage de requête de Prometheus, utilisé dans l'interface web, dans Grafana et dans les règles d'alerte.
• TSDB : base de données de séries temporelles intégrée à Prometheus, qui stocke les échantillons sur le disque local par blocs.
• WAL (Write-Ahead Log) : journal où Prometheus écrit les échantillons récents avant de les compacter en blocs ; il est relu à chaque démarrage.
• Exemplar : échantillon d'exemple attaché à une métrique, souvent avec un identifiant de trace, pour passer d'une métrique à une trace distribuée.
• Remote Write : protocole d'envoi des échantillons vers une base distante (un autre Prometheus, Mimir, Thanos, VictoriaMetrics) ; la version 2.0 transporte aussi les métadonnées.
• Mode Agent : mode allégé lancé avec --agent, qui scrape et transmet en Remote Write sans stockage local ni moteur de requêtes.
• Feature flag : fonction optionnelle activée avec --enable-feature=nom, souvent expérimentale et susceptible de changer d'une version à l'autre.
• LTS : version maintenue un an avec une sélection de correctifs, pour ceux qui ne suivent pas chaque mineure.

En résumé

Prometheus 3.16.0, publiée les 4 et 5 novembre 2026, ajoute integral() et l'estimation du coût des requêtes PromQL (deux fonctions expérimentales derrière des feature flags), rend stables les sélecteurs smoothed et anchored, ouvre metadata-wal-records au mode Agent et allège la TSDB. Avant de mettre à jour, vérifiez les liens de vos alertes si TLS est actif sans --web.external-url, vos règles qui lisent les métriques de métadonnées Remote Write 2.0 retirées et vos exemplars. La mise à jour tient en quelques commandes, par binaire ou par Docker, et la branche LTS 3.13 reste une alternative jusqu'au 31 juillet 2027. Pour aller plus loin sur les alertes, voir notre guide alertes de monitoring sur un VPS Linux. Pour héberger votre stack de supervision, un VPS Linux suffit pour quelques serveurs ; au-delà, un serveur dédié offre la RAM et le stockage nécessaires à une longue rétention.