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 upMetric tracking crash recoveries? #1918
Comments
This comment has been minimized.
This comment has been minimized.
|
As discussed in person, I think a metric like that would make sense. It's usually obvious from the logs that it happened, but you have to check the logs to find out. So the fact that you should check the logs would be something for a ticketing alert. Could be |
beorn7
added
kind/enhancement
component/local storage
labels
Aug 26, 2016
This comment has been minimized.
This comment has been minimized.
|
Thanks, I'll raise a PR soon. |
mattbostock
added a commit
to mattbostock/prometheus
that referenced
this issue
Aug 27, 2016
mattbostock
referenced this issue
Aug 27, 2016
Merged
Storage: Add crash recovery metric 'started_dirty' #1927
juliusv
closed this
in
#1927
Aug 28, 2016
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. |
lock
bot
locked and limited conversation to collaborators
Mar 24, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
mattbostock commentedAug 24, 2016
•
edited
There's a metric to track inconsistencies in the local storage:
prometheus/storage/local/persistence.go
Lines 242 to 247 in 70490fe
...but it's not incremented (as far as I can tell) when the storage is found dirty during startup (and crash recovery is invoked):
prometheus/storage/local/persistence.go
Lines 700 to 708 in 70490fe
The help for the above metric says:
So it probably doesn't make sense to use it to indicate that crash recovery took place when Prometheus started.
Should we have a separate metric dedicated to this purpose?