Cameron Kerr tracks down dashboard problems:
Is your Prometheus performance causing your Grafana experience to suffer? Could you explain which of your tens of Grafana dashboards or users are causing performance problems in Prometheus? Let me show you how we unlocked insight into the performance of Grafana and Prometheus, allowing us to answer import service management questions such as:
- Which dashboards are actually being used?
- Who is actually using the dashboards?
- Who has been issuing poorly-performing queries?
- And which dashboard activity is causing my Prometheus instance(s) to perform poorly?
- Is it slow because someone has a dashboard showing a year’s worth of data that auto-refreshes every 30 seconds?
Click through for a thorough article on finding performance bottlenecks in a platform which typically helps you find performance bottlenecks in other platforms.
“a platform which typically helps you find performance bottlenecks in other platforms.”
Care to elaborate?
A few sample links of what I mean:
– https://github.com/development-plate/lab-monitoring-sqlserver-telegraf-influxdb-grafana
– https://techcommunity.microsoft.com/t5/sql-server-blog/near-real-time-monitoring-of-sql-server-linux-containers-using/ba-p/2620050
– https://techcommunity.microsoft.com/t5/azure-sql-blog/monitoring-azure-sql-database-with-telegraf/ba-p/882790
– https://grafana.com/grafana/dashboards/1883-telegraf-sql-server-monitoring/
Prometheus is a time series data collection service and Grafana a visualization engine which sits on top of it. Most often, we use that combination of tools (or InfluxDB and Grafana) to send metrics on other systems and diagnose issues like high CPU, changes in memory utilization, or blocking in close-enough-to-real-time.