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 that you run.
The monitor serves one Prometheus scrape target that covers the whole deployment, and streams live logs over a WebSocket. It also returns the job metrics, log history, and log downloads that the web interface uses. You can narrow a scrape to a single job, endpoint, or component, but the default target carries every series.
The following behaviors shape how the data moves.
- 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.
- 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.
- Retention: the monitor keeps no history of its own. It holds metrics in memory, expires a series after it stops updating, and passes log lines through to your Loki.
- Configuration: you enter the Prometheus and Loki URLs in Settings > Observability. cosmicac-app-node sends them to the monitor, which stores them and reuses them after a restart. Until you set a Loki URL, the monitor doesn't send log lines to Loki, but live logs still work.