-
Notifications
You must be signed in to change notification settings - Fork 805
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
Added a new metric to the workflow cache #6064
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
... and 13 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
This is to track the max number of requests to a single workflow per domain
Pull Request Test Coverage Report for Build 018fc948-db5d-46cf-88b8-780d605911b9Details
💛 - Coveralls |
- Change from gauge to timer - Only track for workflow IDs the timer will do the bookkeeping for max value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed offline.
The metric counts per workflowID maximum with per-domain dimension.
This could be helpful, though it cannot answer the question about offending workflowID, but at least can help identifying/informing customers on the possible problems.
* Added a new metric to the workflow cache This is to track the max number of requests to a single workflow per domain * Updated based on review - Change from gauge to timer - Only track for workflow IDs the timer will do the bookkeeping for max value * Moved the method to workflowIDCountMetric as it modifies this only
What changed?
In the per workflow Id cache we have added request counting for each workflow Id for the external rate limits. We keep track of the number of requests for the current second for each workflow ID and emit this as a timer metric.
The timer metric keeps track of different percentiles of the metrics, as well as a max count, so we do not need to do this bookkeeping manually.
Why?
We use the tracked information above to emit a metric stating the request count per workflow ID in a domain. We have to do the bookkeeping manually. Emitting a metric for each workflow ID would have way to high cardinality, and would overwhelm the metrics system.
How did you test it?
Unit tests
Potential risks
It should just emit a metric, so should be low risk.
Release notes
Documentation Changes