undefined
@Viss I was under the impression the bridge was entirely third party?
What's the concern in this scenario, about them "just fucking changing their mind" (which they absolutely do) considering this?
EDIT: In case this comes across as the shitty "concern" kind of post, that's absolutely not my goal, I'm genuinely trying to assert the risk for my instance
@Viss @viq Yeah, or rather, you add the VictoriaMetrics server as a data source in grafana and it will read the timeseries from it. You can setup the data source __twice__ as prometheus AND victoriametrics (via the plug in) if you want, which lets you both do graphql and also just straight up use generic prometheus dashboards.
@Viss For reference also, it was all supremely trivial to configure. I put up a nuc-style PC with a N95 and 8gb of ram to hold the `graphs and shit` role in my homelab of like ~30 hosts, and it turns out that was WILDLY overspecced for the task. I don't know what kind of black magic VictoriaMetrics does in terms of storage and memory usage, but it's shockingly low.
@Viss I had similar concerns when I threw out netdata for Having Become Terrible(tm).
I didn't want to setup an elasticsearch cluster just to hold metrics.
It turns out grafana itself is fairly lightweight, and you can swap out prometheus server with something like VictoriaMetrics + vmagent, which lets you do push instead of pull depending on context, and also just normal endpoint scraping.
The datasource itself can either be transparently added as a prometheus one, or as a victoriametrics one (which nets you a few query language bonuses).
It's supremely low resource usage and does not consume much disk space either, to much of my surprise. None of it require a k8s cluster just to collect metrics either.
It's worth exploring, I think.