-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[scrapehelper] Make the initial scrape interval configurable #7635
[scrapehelper] Make the initial scrape interval configurable #7635
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #7635 +/- ##
==========================================
+ Coverage 90.74% 91.10% +0.35%
==========================================
Files 296 297 +1
Lines 14784 14662 -122
==========================================
- Hits 13416 13358 -58
+ Misses 1092 1043 -49
+ Partials 276 261 -15
☔ View full report in Codecov by Sentry. |
One thing worth pointing out for this change is that having scrapers starting on collector / component start will have an increase on resource usage (CPU, Mem, I/O, etc ...) since scraper start will happen shortly after create and the missed interval for |
With this change, the utilization metrics will still be misaligned with others, right? Maybe we can better fix those instead? We can record the initial utilization values on Start. I like the current state of reporting metrics on |
Yes, they will continue to be offset by one collection (specifically for the hostmetric receiver, not sure if other receivers also experience this).
I like this idea, perhaps worth raising an issue in contrib for the host receiver (since I only noticed it there.)
My only hesitation on keeping as it is with |
I like this, just brainstorming an idea: maybe we have a config for "initial scrape delay" and have that set to 1sec or something like that, then we do the interval from there? |
Yeah that makes sense to me, we can keep the current behaviour (ie: |
0003918
to
5b958b2
Compare
5b958b2
to
a92f0ac
Compare
I've updated the PR to be more of an opt out approach so users are required to explicitly set |
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.
I love this enhancement.
I wonder if/what changes we need to make in contrib to make sure this change does not surprise users. I noticed that the ScraperControllerSettings struct is often initialized like this:
ScraperControllerSettings: scraperhelper.ScraperControllerSettings{
CollectionInterval: defaultCollectionInterval,
},
In those cases, the InitialDelay will be initialized to 0
, right? Should we make sure is it initializes with the scraper controller's default value of 1 second?
Mmm, this is a good point. Let me go find those receivers referencing the struct directly and I will update them to use the function so it shouldn't come as a complete surprise. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Adding the ability to scrape on start allows for scrapers who depend on delta values but require an initial value to start emitting values on t+duration instead of t + 2*duration.
fec8609
to
52ed230
Compare
@bogdandrutu , @mx-psi , @astencel-sumo This change should be safe to merge in now without any issues. |
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.
This is a great enhancement!
We're going to need to update all the affected contrib components' README files with the new initial_delay
option, I think it's going to be done in this PR:
Should be done :) |
Description:
This change will allow scrapers to start gather values on scrape controller start instead of having to wait for scrape controller duration to perform the initial scrape.
This is particularly useful for components such as
hostmetrics receiver
that generateutilization
metrics that require an initial state to compute that value. With this change, it means that this metrics will start being sent fromStart + Duration
instead ofStart + 2*Duration
which for scrape durations like30s
means that this value won't be sent til a minute has elapsed.Link to tracking Issue:
N/A
Mostly because I forgot to raise an issue before I did this.
Testing:
Updated the test cases where appropriate.
Documentation:
I don't believe any user / dev docs need to be updated beyond the change log since the only behavioural change is when the scrapers are called which shouldn't impact any behaviours scrapers.