Architecture interne

3. Architecture interne #

Les composants, les services et le graphe de dépendances (DAG).

Le composant, brique de base #

Tout repose sur le composant. Il reçoit des arguments (ce que vous écrivez), s'exécute en continu et publie des exports, que d'autres composants lisent. Il a aussi un état de santé, visible dans l'interface et par l'API.

Le graphe (DAG) #

Au chargement, le contrôleur construit un graphe orienté acyclique (DAG) à partir des références. Il évalue d'abord les composants sans dépendance, puis remonte. Ensuite, quand un composant publie un nouvel export, seuls ses dépendants sont réévalués. Un nouveau pod découvert ne perturbe donc pas l'envoi des logs.

Le graphe impose des règles, contrôlées au chargement. Voici les messages réels d'Alloy 1.21 :

cycle detected: prometheus.relabel.a, prometheus.relabel.b
block prometheus.remote_write.a already declared at du.alloy:1:1
component "prometheus.remote_write.absent.receiver" does not exist or is out of scope

Où sont les données ? #

Certains composants écrivent sur disque, dans le dossier --storage.path (par défaut data-alloy). Nous y avons trouvé par exemple le WAL de prometheus.remote_write et les positions de loki.source.file. Rendez ce dossier persistant : sans lui, un redémarrage relit les fichiers ou perd les métriques en attente.

Recharger sans s'interrompre #

Un POST /-/reload recharge la configuration. Nous avons vérifié deux cas :

• Configuration valide : réponse config reloaded.
• Configuration invalide : réponse 400, et les composants en cours continuent de tourner avec l'ancienne configuration.

Bonne pratique : alloy run accepte un dossier, et charge tous ses fichiers .alloy. Séparez par domaine : 10-collecte.alloy, 20-envoi.alloy. Nous l'avons testé : les références fonctionnent d'un fichier à l'autre.