What's next with Grafana in 2026
- Dominant language
- Python
- Stars
- 15
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
This is a follow-up issue to solve the problem behind https://github.com/kiwix/operations/issues/775 issue
Other than quick-wins already suggested by @rgaudin in https://github.com/kiwix/operations/issues/775#issuecomment-5600379522, I feel like we need to mention another way forward.
Given our strategy to reduce our dependency on US provider and the fact that Grafana Labs is a US corp, it might be a good moment to consider an alternative.
It is also important to remember that the initial reason which pushed us towards Grafana Cloud was that we missed conviction it was an appropriate strategy and paying few dollars a month to have a fully managed solution was deemed the best compromise to not invest too much in a throwaway solution. See https://github.com/kiwix/operations/issues/5#issuecomment-1713355164 in particular, but the whole thread is worth to read again as well.
Time has passed, and I feel like we are now considering Grafana must become a cornerstone of our infrastructure and application monitoring.
It is hence probably the right moment to question again our architecture.
Deploying the whole Grafana suite on-prem obviously comes with its own cost which is probably higher than the managed option. But I feel like it is more aligned with our global strategy.
And it looks like we can imagine composite architectures, either as a road towards the final architecture or as a final one. For instance, what costs us a lot ATM is metrics ingestion, and we can consider an architecture where the metrics DB (Prometheus probably, our usage is quite modest) is hosted on-premises and still queried from our Grafana Cloud instance for convenience.
Contributor guide
Assessment
This issue has not been assessed yet.