-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
vmagent doesn't follow redirects without stream_parse #1945
Comments
Note that |
Hello, For information, I still have the issue with vmagent v1.79.5...
|
@earendilfr do you know how many redirects are there? It could be checked via browser... |
@hagen1778 : sorry, I have changed of jobs so hard to me to have this information but, if I remember correctly, I have only one redirect because, in this case, it's was just a redirect from http to https on the same server. |
hi, have you solved this? |
@yrka5180 have you tried enabling/disabling stream parse? |
we just ran into this same issue: a single hop redirect http -> https fails with we enabled streamParse for all of vmagent via arguments, but i don't feel we should have to do this and after enabling streamParse we see some new |
Is it possible to compile docker-compose env where this issue can be reproduced? This would simplify debug from our side.
Not that I'm aware of. Have you checked https://docs.victoriametrics.com/vmagent.html#troubleshooting ? |
After reading some code, perhaps this behavior is unfortunate but expected. VictoriaMetrics/lib/promscrape/client.go Line 291 in fb9b8f6
I expect that http->https qualifies as changing the host, but |
I believe it will be possible to fix this case, but @valyala may not love it If we detect this case on redirect in promscrape |
Here's a PR (the code is awful! it's just to communicate the idea) that shows it is possible to fix this behavior #4897 |
I believe, the issue would be fixed if we completely migrate vmagent to native HTTP lib. @zekker6 I recall you was working on that some time ago... wdyt? |
@hagen1778 When I've been testing this native HTTP lib was consuming more memory than fasthttp, and we decided to keep it as is in order to avoid increasing resource usage during scrapes. |
Agreed, moving away from Note that in my example here I'm only handling http->https redirects but "different hostname" redirects could also be handled with the same approach. If you'd like me to do any more work down this road, or clean up this code a bit, just let me know! I factored the creation of the |
This will allow to handle redirect easily as fasthttp.Client creates new fasthttp.HostClient on demand and caches created instances per URL. See: #1945 Signed-off-by: Zakhar Bessarab <z.bessarab@victoriametrics.com>
I ran into this with federation targets. This specifically seems to be a problem because it looks like prometheus doesn't let you write I think this means that you can't write a completely compatible configuration that works on both (this is probably only an issue while transitioning) |
I can confirm that at least vmagent v1.93.4 does follow redirects only when stream_parse is true, no matter if follow_redirects is set to true or false. I. e. follow_redirects has no effect at all. |
…Client for scraping targets in non-streaming mode While fasthttp.Client uses less CPU and RAM when scraping targets with small responses (up to 10K metrics), it doesn't work well when scraping targets with big responses such as kube-state-metrics. In this case it could use big amounts of additional memory comparing to net/http.Client, since fasthttp.Client reads the full response in memory and then tries re-using the large buffer for further scrapes. Additionally, fasthttp.Client-based scraping had various issues with proxying, redirects and scrape timeouts like the following ones: - #1945 - #5425 - #2794 - #1017 This should help reducing memory usage for the case when target returns big response and this response is scraped by fasthttp.Client at first before switching to stream parsing mode for subsequent scrapes. Now the switch to stream parsing mode is performed on the first scrape after reading the response body in memory and noticing that its size exceeds the value passed to -promscrape.minResponseSizeForStreamParse command-line flag. Updates #5567 Overrides #4931
…Client for scraping targets in non-streaming mode While fasthttp.Client uses less CPU and RAM when scraping targets with small responses (up to 10K metrics), it doesn't work well when scraping targets with big responses such as kube-state-metrics. In this case it could use big amounts of additional memory comparing to net/http.Client, since fasthttp.Client reads the full response in memory and then tries re-using the large buffer for further scrapes. Additionally, fasthttp.Client-based scraping had various issues with proxying, redirects and scrape timeouts like the following ones: - #1945 - #5425 - #2794 - #1017 This should help reducing memory usage for the case when target returns big response and this response is scraped by fasthttp.Client at first before switching to stream parsing mode for subsequent scrapes. Now the switch to stream parsing mode is performed on the first scrape after reading the response body in memory and noticing that its size exceeds the value passed to -promscrape.minResponseSizeForStreamParse command-line flag. Updates #5567 Overrides #4931
FYI, the commit bc7cf49 should fix following redirects in stream parsing mode when the redirect is performed to different hostname. This commit will be included in the next release. In the mean time it is possible to build |
|
Describe the bug
vmagent doesn't follow redirects without setting stream_parse: true
for details see slack thread:
https://victoriametrics.slack.com/archives/CGZF1H6L9/p1639404018163100
Expected behavior
it should follow redirects in a way that is similar to prometheus
VM agent config
Version
tried v1.7.0 and v1.68.0 and latest docker version
The text was updated successfully, but these errors were encountered: