feat(storage): add telemetry for pre-warmed ranges in ObjectDescriptorImpl - #16323
feat(storage): add telemetry for pre-warmed ranges in ObjectDescriptorImpl#16323kalragauri wants to merge 4 commits into
Conversation
…nges in ObjectDescriptorImpl
There was a problem hiding this comment.
Code Review
This pull request introduces tracking and telemetry for the cache status ("HIT", "MISS", "EVICTED") of pre-warmed ranges in ObjectDescriptorImpl, recording it as an OpenTelemetry span attribute. The review feedback suggests limiting the size of the new evicted_ranges_ set to prevent unbounded memory growth, and optimizing performance by using absl::string_view instead of std::string to avoid unnecessary copies of the cache status.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #16323 +/- ##
==========================================
- Coverage 92.24% 92.23% -0.01%
==========================================
Files 2227 2227
Lines 209208 209234 +26
==========================================
+ Hits 192976 192982 +6
- Misses 16232 16252 +20 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
74d6e87 to
73a17bb
Compare
| // Check if this range matches a pre-warmed range. | ||
| auto cache_key = std::make_pair(p.start, p.length); | ||
| auto cache_it = prewarmed_ranges_.find(cache_key); | ||
| auto cache_status = InitialReadRangesCacheStatus::kMiss; |
There was a problem hiding this comment.
So every standard read on a normal descriptor (without ReadRangesOption) attaches gl-cpp.initial-read-ranges.cache-status:kMiss? Is it decided behaviour? Also will it add noise in Otel?
| } | ||
|
|
||
| private: | ||
| absl::string_view cache_status_; |
There was a problem hiding this comment.
Is it safe to use string_view here? if cache_status will be deleted then it might point to free memory?
This PR adds OpenTelemetry instrumentation for multi-range pre-warming requests in the GCS async client.