Montées de version
Versions épinglées
| Service | Version | Remarque |
|---|---|---|
| OpenObserve | v0.14.4 | épinglée |
| Collecteur OTel | 0.137.0 | épinglée |
| Umami | postgresql-v2.19.0 | épinglée |
| Matomo | 5.3-apache | tag mineur, suit les correctifs |
| MariaDB | 11.4 | tag mineur |
| PostgreSQL | 16.4-alpine (Umami), 17.4-alpine (Rybbit) | versions imposées par l'amont |
| ClickHouse | 25.4.2-alpine | épinglée |
| Redis | 8.6.4-alpine | épinglée |
| Rybbit | latest | à corriger avant tout usage distant |
latest pour Rybbit est une dette assumée du POC : l'amont ne publie pas de tag de version stable
évident. Un déploiement distant doit épingler une empreinte (@sha256:…).
Côté applicatif, @opentelemetry/sdk-node est en 0.300.x : les versions 0.x de l'écosystème
OpenTelemetry cassent régulièrement leurs API. Deux exemples déjà rencontrés dans ce POC :
la classe Resource remplacée par resourceFromAttributes, et BatchLogRecordProcessor dont la
signature est passée d'un exportateur à un objet d'options. Toute montée demande de relire le
journal des changements, pas seulement de lancer les tests.
Marche à suivre
- Sauvegarder, et vérifier la sauvegarde.
- Monter un service à la fois, jamais la pile entière.
- Relancer
pnpm telemetry:testaprès chaque montée : il interroge les données, donc il détecte une régression d'ingestion qu'un contrôle de santé laisserait passer. - Vérifier le journal du service pour les migrations de schéma.
Retour arrière
Possible pour les conteneurs applicatifs, pas pour les schémas de base de données. Une montée de Matomo, d'Umami ou de Rybbit qui migre le schéma n'est pas réversible : seul le retour à la sauvegarde l'est.
Mises à jour automatiques
Renovate peut proposer les montées. Il ne doit pas les appliquer sans contrôle sur l'infrastructure d'analytics : une migration de schéma déclenchée automatiquement n'est pas rattrapable.