#961·coroot

Issues with using Coroot on GCP with Monarch as the data source

Author: facchini-miguelCreated Aug 13, 2026Updated Aug 13, 2026

Hello, good morning, I’ve started testing the Coroot tool in my company's work environment.

Since I’ve used Prometheus, Grafana, etc., in the past, the implementation went smoothly. I managed to get Coroot running with Prometheus and the node-agent.

However, I need to run it differently, and I’m running into some trouble.

I work with GCP and use Monarch for data storage; Coroot returns connection errors with Monarch, so I haven't been able to use it that way. I believe it’s a JSON-related issue—the PromQL format differs from the Monarch metric format.

I have GCE instances and several GKE clusters to monitor. For the test, I only included a few GCE instances because I had to deploy Prometheus, whereas my entire network uses Monarch as the metrics backend.

I’m not sure if this is the best approach, but I implemented it on a dedicated monitoring machine (a GCE instance) isolated from the production environments, with all tools—including Coroot—running in Docker. I hope to monitor the GKE clusters this way. However, since I couldn't connect to Monarch, I installed a local Prometheus instance in Docker.

Regarding a solution: it would be great if Coroot could read Monarch directly, without me having to deploy the Coroot agent across the entire network (since I already have Google agents sending data to Monarch). If the Coroot daemon could convert the data directly by reading Monarch as the data source, that would be perfect.

I also noticed something else: one of the machines where I installed the Coroot agent has a large 50TB disk, but this external drive doesn't show up in the cost breakdown; Coroot ignores it. From what I can see, it only accounts for memory and CPU cores.

Another question: is Coroot optimized for analyzing GCP costs within the interface? Can I trust the data shown in the "Costs" tab?

I can provide more information if needed.

Looking forward to your reply. Thanks, Miguel Facchini