Observer votre application
Vous allez construire : la boucle d'observation du quotidien — suivre n'importe quel topic en direct, lire le log moteur, et mesurer le débit par agent.
Prérequis
- N'importe quelle application déployée.
1 · Suivre n'importe quel topic — le super-pouvoir
pulse events tail --topic oncall.reason.out
Chaque frontière de stage est un topic durable, donc chaque couture de votre application est observable — pas seulement les extrémités. Le debug commence généralement ici : suivez le topic juste avant l'endroit qui semble cassé.
2 · Suivre le log moteur
pulse logs -f
Déploiements, cycle de vie des stages, activité des connecteurs, erreurs avec leurs causes.
3 · Lire les constantes d'un stage
pulse metrics agent reason
Débit, lag et compteurs d'erreurs par agent — le stage suit-il le rythme de son topic d'entrée ?
4 · Diffuser les événements vers n'importe quoi d'autre
curl -N -H "Authorization: Bearer $TOKEN" \
"http://localhost:9090/api/pulse/events/stream"
Le point d'accès SSE pousse les événements dès qu'ils arrivent — le même flux que vos dashboards, scripts ou un onglet de navigateur peuvent consommer. L'obtention de $TOKEN est couverte dans Appeler votre app de n'importe où.
Ce qui vient de se passer
Ici l'observabilité n'est pas un ajout — l'architecture est l'instrumentation. Comme tout circule par des topics nommés, « que fait mon application en ce moment » a toujours une réponse en un tail, et « à quelle vitesse » en un appel de métriques. Pour le tableau complet (métriques Prometheus, tracing, flux d'audit), voir les pages observabilité sur streamflowmesh.io.
Dépannage
Le tail ne montre rien du tout
Vérifiez le nom du topic : c'est <app>.<stage>.out, exactement comme nommé dans pulse.yaml. pulse logs -f vous dit si les événements circulent mais échouent dans un stage.