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
When using this exporter it seems to rather regularly fail to fetch temperature data because it receives a 429 response. I can reproduce this issue at polling intervals all the way up to 1m so I am pretty sure it is not the scraping frequency that is the culprit.
time="2022-07-08T00:08:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
time="2022-07-08T00:09:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
time="2022-07-08T00:10:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
time="2022-07-08T00:11:26Z" level=error msg="Can't scrape /temp.json: HTTP status 429" source="main.go:205"
Debugging
I did some debugging and I think the issue is the tight loop that this exporter uses. I think, and this is sorta ironic, that the code executes the call to /temp.json too soon after calling /status.json.
In some cases, 429 errors come with a Retry-After header that could be used to space out the requests but I don't see that in the response from the miner.
I went looking for documentation from bobcat but I can't seem to find any details on the miner HTTP server or how it is configured...
By testing, I found the limit, at least on my miner, could be as low as 1 request per 1.5s!
Possible solution
I think there are a couple of things that could be done:
The fetch routine could be improved to have a retry with a back-off
There could be a configurable constant sleep time for requests (seems questionable to me)
The fetching could be done in the background instead of on-demand. I think this is "best" but does not really fit with what you had going here. It also adds a lot of complexity.
I mention the above because I am happy to do any of them but since this is not my project, and I don't wanna fork it, I wanted to see what you the author thought.
Let me know and if I have some time I may send a PR your way.
Take care!
The text was updated successfully, but these errors were encountered:
Also just learned that as of the time of writing the status.json endpoint is being removed. As of:
Bobcat Firmware version updated to 1.0.3.1
Helium Firmware version updated to 2022.07.14.0_GA
Bobcat miners will be lite so they will not have a sync status. Syncing will be done by validators I guess... So the above might be a non-issue. The only metric you can really track without impacting the bobcat would be the temperature.
What happened
When using this exporter it seems to rather regularly fail to fetch temperature data because it receives a 429 response. I can reproduce this issue at polling intervals all the way up to 1m so I am pretty sure it is not the scraping frequency that is the culprit.
Debugging
I did some debugging and I think the issue is the tight loop that this exporter uses. I think, and this is sorta ironic, that the code executes the call to
/temp.json
too soon after calling/status.json
.In some cases, 429 errors come with a
Retry-After
header that could be used to space out the requests but I don't see that in the response from the miner.I went looking for documentation from bobcat but I can't seem to find any details on the miner HTTP server or how it is configured...
By testing, I found the limit, at least on my miner, could be as low as 1 request per 1.5s!
Possible solution
I think there are a couple of things that could be done:
I mention the above because I am happy to do any of them but since this is not my project, and I don't wanna fork it, I wanted to see what you the author thought.
Let me know and if I have some time I may send a PR your way.
Take care!
The text was updated successfully, but these errors were encountered: