Open BoemmLA opened 11 months ago
Sure, adding long_query_time
to the session params is a great idea. It should be simple enough to do. Would you be up to adding this feature? You can see the params and related variables here: https://github.com/prometheus/mysqld_exporter/blob/main/collector/exporter.go#L45
In our setup we are running several databases with quite fast queries and mostly very less slow queries from the application. Thats why we setted the long_query_time for all (150) database (clusters) to 0.01 which is a fine value for our usual work load.
Unfortunately the mysqld_exporter runs queries which takes longer then 0.01 second, sometime more then 1 seconds and so we have slow logs logged for those scrape queries, sometimes the exporter queries are the only slows in the log. This is really annoying since this gives us a not really good monitoring of slow queries where we only would like to see statistics about slow queries coming from application users but not from metrics scraping.
There is the flag exporter.log_slow_filter, but this one only filters out the "non tmp disk table" queries. All queries writing tmp disk tables are still logged to the slow log.
And this tmp disk table queries are more then the non tmp disk table queries, so the existing flag has some effect, but not reaches the goal to avoid half of the queries to be logged.
Long story short, a dynamic setting for long_query_time as a exporter parameter would solve this problem. When it would be possible to set the long_query_time up to 10 seconds for the exporter sessions, this problem should be fixed.
Can you please add such a parameter to define a long_query_time value, which is then used for the mysql session the exporter uses?
The would be great!
Some code examples: Here you see a half day slow query log ... there are only scrape queries in (at least the top 4):
The 1st, 2nd and 4th are tmp disk table queries, the 3rd can be avoided when setting exporter.log_slow_filter