Decouple from Grafana.cloud

[te4336]

Has any thought been given to decoupling this to where it can be ran with an on-prem instance of Grafana/Prometheus/Loki? I know it's a sales driver for Grafana Cloud but this would be a major step forward for those that are running On-Prem stacks.

[mem]

Just to understand the request, what would the expectation be:

• Use an on prem Grafana?
• Write to an on-prem Prometheus / Loki?
• Run all probes on prem?
• Run some probes on prem?

[te4336]

@mem Yes this would be for Prometheus/Grafana instances that are on-Prem, may or may not write to an On-Prem Loki instance (This should be irrelevant), and most probes are ran on Prem but some may be ran against services in the public cloud.

[mem]

Thanks, @te4336. We do make certain assumptions as to how the authentication proceeds (but as long as you can provide the probe with URL/username/password it should work), and in general writing to an on-prem Prometheus from a public probe would be difficult (the Prometheus instance might not be reachable from the Internet), that's why I was asking what this would entail.

Thinking...

[mem]

The more I think about this, the more convinced I become that the right way to address this is a different implementation of the API, because the assumptions related to Grafana Cloud all live there.

[paullryan]

@mem This could be done by enforcing remote write for the on prem metrics, e.g. must be against cortext or mimir and loki with exposed remotewrite.

[disfluxly]

+1 to making this available as an on-prem install. To solve some of the issues with needing a write path, perhaps couple the metrics output with an OpenTelemetry Collector, and provide the ability for users to update the Collector configuration as needed to suit their backend ingestion pipeline. This way you could default to Grafana Cloud, but provide the flexibility to fit into various prometheus backends