-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Confusing timeout behaviour #259
Comments
The timeout is a maximum, and we use a default of 10 as that's the default over in Prometheus - that header wasn't always sent. Did you try using the debug output for this particular issue? |
No - I'd used log-level=debug for the server process but didn't run with |
Would you like to send a PR to clarify that? |
I also find the timeout behaviour puzzling. The following code effectively enforces a maximum timeout of 10s for the module timeout if not specified by the Prometheus scrape_interval: if timeoutSeconds == 0 {
timeoutSeconds = 10
}
if module.Timeout.Seconds() < timeoutSeconds && module.Timeout.Seconds() > 0 {
timeoutSeconds = module.Timeout.Seconds()
} However, just a few lines before that, the This makes it somewhat of a hassle to test very slow probes (> 10s) via the blackbox web UI, since one would have to coerce the browser into setting the all-powerful |
The current default of 10s is problematic when testing slower probes from a browser. Cancellation will still work as a fallback, including for older Prometheus servers that don't send the timeout header, so there shouldn't be a big buildup of ongoing probes. Fixes #259 Signed-off-by: Brian Brazil <[email protected]>
The current default of 10s is problematic when testing slower probes from a browser. Cancellation will still work as a fallback, including for older Prometheus servers that don't send the timeout header, so there shouldn't be a big buildup of ongoing probes. Fixes #259 Signed-off-by: Brian Brazil <[email protected]>
The current default of 10s is problematic when testing slower probes from a browser. Cancellation will still work as a fallback, including for older Prometheus servers that don't send the timeout header, so there shouldn't be a big buildup of ongoing probes. Fixes #259 Signed-off-by: Brian Brazil <[email protected]>
I was surprised by the behaviour of timeouts when troubleshooting an internal healthcheck for a very slow service with configuration like this:
The first problem was that the timeout values are not applied by default:
Note that while the configuration specifies 15s the actual timeout was just under the default 10 seconds. Adding
-H X-Prometheus-Scrape-Timeout-Seconds:120
allows reaching the configured timeout:The text was updated successfully, but these errors were encountered: