feat: Bucket feature count labels in latency metrics - #6811
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6811 +/- ##
==========================================
- Coverage 47.08% 47.08% -0.01%
==========================================
Files 419 419
Lines 51878 51876 -2
Branches 7525 7525
==========================================
- Hits 24429 24427 -2
Misses 25700 25700
Partials 1749 1749
*This pull request uses carry forward flags. Click here to find out more.
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
The macOS Python 3.12 unit-test job is still failing after the rerun. I checked the failure, and the only failing test is test_module_level_fips_sets_env_before_pyarrow_import, which times out after 60 seconds while importing feast.offline_server. All feature-server-related tests and the other Python/macOS/Linux unit-test jobs pass, so this appears unrelated to the changes in this PR. |
Signed-off-by: Jingqian Liu <ljqstella@gmail.com>
bac23ab to
9b57eb5
Compare
Signed-off-by: Jingqian Liu <ljqstella@gmail.com>
What this PR does / why we need it:
The
feature_countlabel onfeast_feature_server_request_latency_secondscurrently uses the exactnumber of requested features. For workloads with widely varying feature
counts, this can create a large number of Prometheus time series and
increase metric cardinality.
This PR:
feature_countlabel values using configurable boundaries.metrics.feature_count_bins, defaulting to[10, 50, 200].0,1-10,11-50,51-200, and201+.0as a separate label for zero-feature requests.metric label is bucketed.
increasing.
For example: