Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign up`prometheus_target_scrapes_exceeded_sample_limit_total` not incremented #3668
Comments
brian-brazil
added
kind/bug
component/scraping
labels
Jan 9, 2018
This comment has been minimized.
This comment has been minimized.
|
Thanks for reporting this. Would you like to send a PR fixing it? A unittest would be great too. |
ant1441
referenced this issue
Jan 9, 2018
Merged
Fix the incrementing of prometheus_target_scrapes_exceeded_sample_limit_total #3669
brian-brazil
closed this
in
#3669
Jan 9, 2018
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 23, 2019
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
lock
bot
locked and limited conversation to collaborators
Mar 23, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
ant1441 commentedJan 9, 2018
What did you do?
When a target goes over the configured
sample_limit, I looked at theprometheus_target_scrapes_exceeded_sample_limit_totalmetric.What did you expect to see?
I expected this to increase for each scrape which hit the sample limit, as per the help on the metric:
(from scrape.go#L83)
What did you see instead? Under which circumstances?
This metric was not incremented.
Environment
System information:
Linux 4.4.0-103-generic x86_64
Prometheus version:
Seen on the
prom/prometheus:v2.0.0Docker image, reproduced with local build from master branch:Alertmanager version:
NA
Prometheus configuration file:
Alertmanager configuration file:
NA
Logs:
Notes
It appears to be the case that at scrape.go#L907 the metric will be incremented if
err == nil && sampleLimitErr != nil.However, if I am understanding correctly,
errwill always be the same assampleLimitErras once the limit has been hit all further samples will also result in that error. Though there is the possibility that a different error is raised at the final stage of the loop.My guess would be that scrape.go#L907 should be changed to just
sampleLimitErr != nil, but I'm not certain how the lineerr = sampleLimitErrshould be changed. If I am understanding things correctly,errwould always already besampleLimitErr, so that line is unneeded.