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 upStandard internal error counter for all exporters? #1278
Comments
This comment has been minimized.
This comment has been minimized.
|
There's so many ways that an exporter can fail that this isn't practical. For example that issue is a user configuration error, which is different from the target having an error which is different from a failure. At most we can offer only general guidance. |
brian-brazil
closed this
Dec 30, 2015
This comment has been minimized.
This comment has been minimized.
|
While I readily agree that there is a myriad of reasons, the point is that this would allow me to look at anything that is not zero. |
This comment has been minimized.
This comment has been minimized.
|
#1169 is somewhat related to this. |
This comment has been minimized.
This comment has been minimized.
|
#1169 is to cover a failure of the exporter itself to handle a failure. |
This comment has been minimized.
This comment has been minimized.
|
Correct. One is for failures that could be handled/ignored, one is for the ones which could not. |
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 24, 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. |
RichiH commentedDec 30, 2015
I think it would make sense to have a canonical metric for internal error counting of all exporters. This would allow easy monitoring when scrape happens upon a partially misconfigured or otherwise non-ideal target.
This is partially motivated by prometheus/snmp_exporter#16