Feuille de route
Où va avuru obs. Ceci est indicatif, pas un engagement — la portée et l'ordre
évoluent au fil de nos apprentissages. Le détail technique de référence vit dans
le ROADMAP.md
du dépôt moteur ; cette page en est le résumé lisible. Pour ce qui fonctionne
aujourd'hui, voir l'État des fonctionnalités ; pour ce qui a été
livré, le Changelog.
Étoile polaire
:::tip Le coin Un cluster Kubernetes neuf → carte des services en direct en moins de cinq minutes, zéro changement applicatif. Chaque jalon est jugé à cette aune, et c'est vérifié par une porte d'intégration continue. :::
v0.1 — le coin (publiée le 15 juillet 2026)
Les niveaux de signaux livrés pour 0.1 :
| Niveau | Signal | État |
|---|---|---|
| Complet | Carte des services + métriques RED ; explorateur de traces (waterfall, recherche) | Livré |
| Basique | Logs (collecte, recherche plein texte, corrélation trace_id) | Livré |
| Léger | Profilage continu (flame graphs CPU par service) | Livré |
| Support | Métriques d'infra (CPU/mémoire/réseau des nœuds/pods) | Livré |
Plus la promesse forte : un remplaçant OTLP « drop-in » — les applications déjà instrumentées migrent en changeant seulement l'endpoint d'export, sans changement de SDK ni de code.
Jalons vers v0.1
Stack locale & ingestion
Livré- Stack
make dev(ClickHouse + collecteur + app de démo) - Ingestion OTLP de bout en bout ; premier test e2e « drop-in »
- Explorateur de traces, logs, carte des services & État du système en direct
Backend OTLP déployable
Livré- Installation Helm ; gateway → ClickHouse → hub dans le cluster — en direct
- DaemonSet sensor : traces + RED eBPF zéro-code (OBI), logs zéro-config — en direct
- UI d'inventaire des services (RED par service) — en direct
Profondeur & corrélation des signaux
Livré- Métriques d'infra & tableaux santé nœuds/pods — en direct
- Tableau de bord des métriques RED — en direct
Profondeur de l'UI
Livré- Waterfall + flamegraph, table des spans, statistiques, graphe — en direct
- Comparaison de traces (diff structurel) — en direct
- UI de profilage continu (flame graphs par service) — en direct
Build gateway & porte TTV
Livré- Distribution collecteur minimale construite via OCB — en direct
- Porte « time-to-value » sur kind imposant le coin des moins de 5 min — en direct
v0.2 — profondeur et contrôle (publiée le 28 juillet 2026)
Tout ce qui visait la v0.2 est livré dans la v0.2.0 : l'authentification sécurisée par défaut avec rôles par projet et SSO OIDC, le cadre de modules (choisissez vos signaux), le suivi des erreurs avec une voie d'ingestion navigateur, la santé des services par groupes avec niveaux de criticité, les webhooks d'alerte, la santé réseau sur les liaisons de la carte des services, le module énergie & carbone, et un capteur « qu'on peut laisser activé » prouvé par la CI. Le projet est sous licence AGPL-3.0 à partir de cette version. Le détail complet est sur la page état des fonctionnalités et dans le changelog.
v0.3 — une multi-tenance digne de confiance (publiée le 31 juillet 2026)
La v0.2 avait sécurisé la lecture ; la v0.3.0 verrouille
l'écriture. Les projets deviennent quelque chose que vous administrez —
création, renommage et suppression depuis l'interface — et les clés
d'ingestion par projet font qu'un émetteur ne se contente plus de déclarer
un tenant : en mode enforce, c'est la clé qui décide où atterrit sa
télémétrie. Autour de cela : une démo en lecture seule en un clic, le
module green sur les VM cloud dépourvues de RAPL, les fondations du plan de
contrôle de la collecte à chaud, et le renommage de la couche de déploiement de
avuruops vers avuruobs (rupture — voir le
guide de mise à jour). Le détail complet est sur la
page état des fonctionnalités et dans le
changelog.
v0.4 — des comptes que vous administrez (publiée le 7 août 2026)
La v0.4.0 termine le cycle de vie des comptes entamé en
v0.2 : la gestion des utilisateurs depuis l'interface — modifier le nom et
les rôles, réinitialiser un mot de passe, supprimer un compte selon la règle
« désactiver d'abord » — et le changement de mot de passe en libre-service
dans Paramètres → Compte, ces opérations restant refusées aux utilisateurs SSO
dont l'identifiant appartient au fournisseur d'identité. La revue de cette
surface a refermé trois portes d'entrée : un mot de passe local que l'on
pouvait créer sur un compte purement SSO, un verrouillage des connexions que la
rotation d'adresses IP contournait, et une connexion SSO capable de s'approprier
l'e-mail d'un compte local. Côté exploitation : une installation dont la
migration de schéma n'a jamais tourné se répare d'elle-même et publie l'état
du schéma dans Paramètres → État ; green ne fait plus tomber la sonde sur les
nœuds sans RAPL ; et la connexion fonctionne derrière un reverse proxy qui
réécrit Host. Le détail complet est sur la page
état des fonctionnalités et dans le
changelog.
v0.5 — piloter depuis l'interface (publiée le 16/08/2026)
Presque tout ce que l'on administrait exigeait de modifier les valeurs puis de redéployer ; v0.5.0 le fait entrer dans l'application. La collecte pilotable à chaud est livrée au complet : chaque signal s'active ou se coupe depuis Paramètres → Collecte et le capteur suit en quelques secondes, toujours désactivée par défaut derrière un rôle étroitement délimité. Les groupes de services s'écrivent dans l'application, les groupes déclarés dans le chart restant en lecture seule et l'emportant en cas de collision de nom. Paramètres → Stockage et Accès montrent où vivent les données et qui peut toucher à quoi ; le mapping SSO groupe→rôle s'édite à côté des règles du chart ; et les jetons d'API personnels donnent aux scripts et aux futurs clients une accréditation qui suit les permissions vivantes de son propriétaire. Le Tableau de bord répond en un écran à « comment se porte le parc ? », la carte des services porte de vrais anneaux de santé, une latence par arête côté appelant et des filtres partageables, et l'écran Nœuds se trie et se filtre. OpAMP reste la destination pour le contrôle de la collecte : d'abord la remontée d'état, puis la configuration à distance quand l'amont fournira un client. Le détail complet est sur la page état des fonctionnalités et dans le changelog.
v0.6 et au-delà (indicatif)
- Compatibilité d'ingestion élargie : des récepteurs pour les protocoles courants de traces/métriques/logs en plus d'OTLP, plus des exporteurs de transfert pour écrire en double pendant une migration.
- Plus de clients : l'API du hub est le contrat agnostique ; la SPA n'en est qu'un client léger. Une source de données Grafana et une CLI sont prévues, toutes deux portées par les jetons d'API personnels livrés en v0.5.
- Projets multi-clusters : des projets membres agrégeant plusieurs clusters, la rétention et l'état système par projet, et des interrupteurs de composants du chart pour qu'un cluster secondaire n'installe que la passerelle (et le capteur) sur un ClickHouse partagé. Le CRUD des projets et les clés d'ingestion sont livrés en v0.3.
- Étiquetage automatique plus riche : faire des labels/annotations Kubernetes des étiquettes métier, filtrables sur tous les signaux.
- Réévaluation du stockage : ClickHouse reste derrière l'interface
storage.Store; GreptimeDB sera réévalué mi-2027 sans changer le code du hub.
Comment cette feuille de route change
Ouvrez une issue ou une discussion pour proposer un changement de cap ; les éléments plus importants passent par une Avuru Enhancement Proposal avant implémentation. Les modifications passent par une pull request classique.