-
Notifications
You must be signed in to change notification settings - Fork 302
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
Threadstats: 413 - Request Entity Too Large #465
Comments
Hello @trygvebw You should be able to instantiate your threadstats object with the new param |
Hi @zippolyte, that PR seems promising. I don't have time to check if it solves the problem this week (the issue was fixed for the time being by lowering the flush_interval), unfortunately, but I might have time later. |
Another issue: It would be very useful to be able to handle any exceptions thrown by threadstats, including HTTPError but also other exceptions, instead of threadstats just silently swallowing most exceptions. Currently this doesn't seem to be possible; correct me if I'm wrong. Ideally I'd be able to provide threadstats with an error handler function that is invoked every time threadstats throws an exception. |
When threadstats receives too many metrics within a flush_interval window, it receives a 413 error from the Datadog server upon submitting the metrics, resulting in the following exception being thrown:
Is this behaviour new? This has happened several times in the past two weeks or so, but I cannot find any occurences of HTTP 413 errors in my logs from before that.
Whether or not this is new, is there a better way of handling large variances in the volume of metrics than turning flush_interval way down and hoping that the metric load won't get too high again? Ideally the flush_interval would have an "auto" mode that let it be automatically adjusted when the metric load increases and decreases, but as far as I can tell this is not available.
The text was updated successfully, but these errors were encountered: