Architecture

avuru obs, c'est quelques composants, chacun avec un seul rôle. Cliquez sur un nœud pour ouvrir sa documentation.

sensor

eBPF DaemonSet · flows · traces · logs · profiles

▶

gateway

minimal OTel Collector

▶

ClickHouse

one engine · all signals

▲ SQL

UI

static SPA · own pod

▶

hub

Go API · OpAMP config plane

Flux de données

1. Chemin de la télémétrie — le sensor (eBPF + OTLP) envoie les signaux au gateway, qui les écrit dans ClickHouse.
2. Chemin des requêtes — l'ui et les clients externes appellent l'API REST du hub, qui interroge ClickHouse en SQL.
3. Chemin de la configuration — les agents et collecteurs s'enregistrent auprès du hub et reçoivent leur configuration à distance via OpAMP.

sensor DaemonSet  (eBPF : flux · traces · RED · logs · profils)
     │ OTLP
     ▼
  gateway  (collecteur OTel minimal) ──► ClickHouse  (tous les signaux)
                                           ▲ SQL
  hub  (Go : API REST/WS + OpAMP)  ◄────────┘   ◄──  UI  (SPA statique, son pod)

Composants

Composant	Chemin du repo	Stack	Responsabilité
sensor	sensor/	DaemonSet	agent eBPF + OBI + collecteur + profileur
gateway	gateway/	OCB / OTel	distribution minimale du collecteur
hub	hub/	Go	API REST/WS + plan de configuration OpAMP
ui	ui/	Next.js	SPA statique, servie depuis son propre pod
stockage	—	ClickHouse	un seul moteur pour tous les signaux

Pourquoi un seul moteur

Stocker traces, métriques, logs et profils dans le même cluster ClickHouse, c'est ce qui rend la corrélation inter-signaux peu coûteuse : trace_id et attributs de ressource partagés signifient qu'un pivot trace → logs → métriques → profil n'est qu'une requête de plus, pas un autre système.

Décisions de conception

Les décisions importantes sont consignées sous forme d' ADR (et d'Avuru Enhancement Proposals dans le repo moteur).