-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metricbeat PostgreSQL Dashboard creates significant load and long running queries #22085
Comments
Pinging @elastic/integrations-services (Team:Services) |
If this is helpful in this case, I think this kind of filters could be helpful in the dashboards of many other modules. We might consider adding filters like these ones to all dashboards. With agent/fleet and data streams we could even query directly to I don't think this is related to this issue, #20321 is about the contents of a filebeat dashboard, not its performance. |
TBH I'm surprised we don't have this kind of filter already in the dashboards. I think in most cases we should filter by With the data stream naming scheme we currently filter on |
I have checked now and this is actually done in several dashboards, but not in many of them. I think it may worth to add it to the ones missing it, even if it is solved in agent with the use of data streams. |
Adding filters in PostgreSQL dashboards in #24607. |
Opening the Metricbeat PostgreSQL dashboard for longer time spans (e.g. 7 days) creates significant CPU usage. Specifying an additional filter (
event.module: postgresql
) on the dashboard level reduces the loading time from minutes to seconds. This effect is also visible after waiting some time and manually clearing the caches.First try opening the dashboard ~13:13 without the filter and second try ~13:16 with the filter:
Hot node monitoring:
Warm Node monitoring:
The text was updated successfully, but these errors were encountered: