Observability architecture
How CosmicAC collects logs and metrics from its services and passes them to your Prometheus and Loki.
Five services publish their logs and metrics to a shared Hyperswarm topic, and cosmicac-wrk-monitor collects what arrives. Your Prometheus stores the metrics, and your Loki stores the logs. None of this affects how a job runs or how CosmicAC serves a request.
The following diagram shows which services publish to the topic, and how metrics and logs move between the monitor and the stack you run.
The monitor serves one Prometheus scrape target that covers the whole deployment, streams live logs over a WebSocket, and returns the job metrics and log history that the web interface displays. You can narrow a scrape to a single job, endpoint, or component, but the default target carries every series.
Three behaviours shape how the data moves.
- Getting data in: producers publish to the topic and never wait for a reply, so a service that stops sending goes quiet instead of failing a request.
- Getting data out: your Prometheus scrapes the monitor on its own schedule, and the monitor queries your Prometheus and your Loki to build what the web interface shows.
- What CosmicAC keeps: the monitor keeps no history of its own. It holds metrics in memory, expires a series once it stops updating, and passes log lines through to your Loki.