feat: collect SSD endurance information where available in smartctl #11391
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks so much for the pull request! |
telegraf-tiger
bot
added
the
feat
|
Thanks so much for the pull request! |
|
!signed-cla |
|
@bentasker for some reason CircleCI tests didn't get triggered, mind rebasing on master to see if it would trigger them? Thanks! |
…where it's present (related to influxdata#8701) There isn't a standardised attribute ID (or name) for SSD endurance information with SMART data. Some vendors use ID 202, others use 177 (and others use others). The two following entries indicate the remaining lifetime of two different SSDs 202 Percent_Lifetime_Remain P---CK 094 094 000 - 6 177 Wear_Leveling_Count ------ 100 100 050 - 432 Because those device manufacturers that *don't* use `202` might use `202` for other information, we cannot safely rely on the ID to identify the information. This commit introduces `deviceFieldNames` which is a map of names (such as `Percent_Lifetime_Remain`). When the SMART data is iterated over in `gatherDisk()`, each entry's name is checked against `deviceFieldNames` andd a field created where a match is made
…bute (see influxdata#8701) This form of wording is used in the smart attributes on WD HGST SSDs. It's functionally identical to the "Percent Used" attribute seen on various other brands
Although the different values are assumed to mean the same thing, because their implementation is vendor specific that assumption probably isn't safe.
…used:" Adds a new SMART snippet (as none of the existing examples had it) and adds a test
The earlier commits introduced new fields, so update the expected result counts to reflect this
bentasker
force-pushed
the
20220624_smartctl_ssd_endurance
branch
from
b0d3144 to
41fee36
Compare
|
@sspaink sure, done |
sspaink
suggested changes
Jun 30, 2022
sspaink
approved these changes
Jun 30, 2022
sspaink
added
the
ready for final review
MyaLongmire
suggested changes
Jul 11, 2022
Other fields seem to be emitted using lowercase, so this follows that convention as well as keeping processing of `deviceFieldNames` in line with the processing applied to `deviceFieldNames`.
MyaLongmire
approved these changes
Jul 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Required for all PRs:
Adjusts the
smartinput plugin to collect SSD endurance information in more situations (for example, resolves #8701)The
smartplugin already collects endurance information ifattributesistrueand the NVME log contains the attributePercentage Used.However, this PR adjusts the plugin to also collect endurance information if it's available in the following locations
Percentage used endurance indicatorPercent_Lifetime_Remain,Wear_Leveling_CountorMedia_Wearout_IndicatorBecause the SMART data fields are vendor specific, the ID cannot be relied on, so this PR introduces the ability to match rows by name rather than ID.
Additionally, for safety, it is not assumed that the value of any one of those field values could/should overwrite the other, so three new output fields are created
endurance_remain_percendurance_wear_levellingendurance_media_wearoutFor the majority of vendors, these values start at 100 and count down - it is expected that there will be exceptions, but this PR doesn't attempt to address those as it seems better to let the user handle those as they see fit at query time.