You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe
We run a VictoriaMetrics cluster behind a haproxy load-balancer. I like using VMUI (also behind that load-balancer), but it fails to execute long queries due to restrictions the load balancer places on the request URI, including the query string.
VMUI sends a GET request with a request URI like .../select/0/prometheus/api/v1/query_range?query=..., which for some queries can get to 12KiB or so. At that size, haproxy returns a text/html 400 bad request and vmselect never sees the request.
Describe the solution you'd like
VictoriaMetrics supports both POST and GET to its query API for precisely this reason - the maximum length of a URI is not well defined, and it's easy to trip well-meaning limits imposed by intermediaries. I'd like VMUI to switch from making GET requests to POST requests so it works seamlessly in such an environment.
Grafana also offers the option of POST vs GET in its Prometheus datasource configuration - and defaults to POST, reserving GET for older versions of Prometheus that don't support it.
Describe alternatives you've considered
We could modify our load-balancer so it supports very long request URIs, but that would only help us, rather than everyone.
Additional information
Just a screenshot of a GET request made by VMUI:
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe
We run a VictoriaMetrics cluster behind a haproxy load-balancer. I like using VMUI (also behind that load-balancer), but it fails to execute long queries due to restrictions the load balancer places on the request URI, including the query string.
VMUI sends a GET request with a request URI like
.../select/0/prometheus/api/v1/query_range?query=...
, which for some queries can get to 12KiB or so. At that size, haproxy returns a text/html 400 bad request and vmselect never sees the request.Describe the solution you'd like
VictoriaMetrics supports both POST and GET to its query API for precisely this reason - the maximum length of a URI is not well defined, and it's easy to trip well-meaning limits imposed by intermediaries. I'd like VMUI to switch from making GET requests to POST requests so it works seamlessly in such an environment.
Grafana also offers the option of POST vs GET in its Prometheus datasource configuration - and defaults to POST, reserving GET for older versions of Prometheus that don't support it.
Describe alternatives you've considered
We could modify our load-balancer so it supports very long request URIs, but that would only help us, rather than everyone.
Additional information
Just a screenshot of a GET request made by VMUI:
The text was updated successfully, but these errors were encountered: