Observability architecture

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.

cosmicac-wrk-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 properties explain how the data gets in, how it gets out, and what CosmicAC keeps:

• Producers publish to the topic and never wait for a reply, so a service that stops sending goes quiet instead of failing a request.
• Your Prometheus scrapes cosmicac-wrk-monitor on its own schedule. cosmicac-wrk-monitor queries your Prometheus and your Loki to build what the web interface shows.
• cosmicac-wrk-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.

For more information, see Connect CosmicAC to your Prometheus and Loki.

Next steps

• Connect CosmicAC to your Prometheus and Loki
• Observability settings API
• Architecture for the components and how CosmicAC reaches your cluster