-
Notifications
You must be signed in to change notification settings - Fork 8.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
Batch metrics and flush periodically #2957
Conversation
/assign @aledbf |
Codecov Report
@@ Coverage Diff @@
## master #2957 +/- ##
==========================================
+ Coverage 47.55% 47.57% +0.01%
==========================================
Files 77 77
Lines 5633 5633
==========================================
+ Hits 2679 2680 +1
+ Misses 2602 2600 -2
- Partials 352 353 +1
Continue to review full report at Codecov.
|
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aledbf, ElvinEfendi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@ElvinEfendi this looks great. Thank you for working on this! |
What this PR does / why we need it:
Currently Lua code sends metrics to the controller for every request right after Nginx finishes responding. This means the load on controller increases linearly with the number of requests. That results in high CPU usage and dropped metrics ("
Resource unavailable
- when the controller can not process the metrics)".This PR changes the logic in Lua side to batch the metrics and send the batches periodically to the controller. I've configured the period to 1s for now. Since we are batching the metrics in Nginx worker's memory to avoid potential unbounded memory increase I've also added limit on the number of metrics that can be batched during that
1s
. That number is10000
right now - which is a really high number. With this change Nginx would be dropping metrics only if an Nginx worker is handling more than10000 RPS
.I've tested this change locally under heavy load and did not see any example of metric being dropped or "Resource unavailable" error. Note however this change means metrics will be delayed for a second.
Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close that issue when PR gets merged): fixes #Special notes for your reviewer: