Temperature reported twice in metrics for some drives about check_smart HOT 4 CLOSED

Hi @der-michik , thanks for reporting!
That's a very interesting case and it might even be a misinterpretation of the attributes coming from smartctl (smartmontools). According to https://en.wikipedia.org/wiki/S.M.A.R.T., attribute id 194 is the most used attribute to show the current temperature, whereas attribute id 231 is Life Left (SSDs) or Temperature. As your drive is an SSD, this is more likely to be "Life Left".
Again from the Wikipedia page:

Indicates the approximate SSD life left, in terms of program/erase cycles or available reserved blocks.[67] A normalized value of 100 represents a new drive, with a threshold value at 10 indicating a need for replacement. A value of 0 may mean that the drive is operating in read-only mode to allow data recovery.[68] Previously (pre-2010) occasionally used for Drive Temperature (more typically reported at 0xC2).

Your SSD drive shows the value 100 which shows a perfectly healthy drive, according to this attribute.

Can you please check the smartctl/smartmontools version on this particular host? We should probably report this upstream.

Update: Seems already fixed in smartmontools, check out: https://github.com/smartmontools/smartmontools/blob/master/smartmontools/drivedb.h#L4082 and smartmontools/smartmontools@160ecb1#diff-5c51af8dba19f3a4f4187af4b46e415f

And the ultimate finding: smartmontools/smartmontools#4

from check_smart.

Ah, interesting, thanks for your research! That explains a lot. I did not think about having a detailed look at smartmontools as upgrading that on the affected systems is not really an option for me anyway whereas patching the script was an easy workaround.

Nevertheless, we maybe should think about a more flexible exclude option. Currently, -e only excludes attributes from failure reporting and only by name. Names are known differ somewhat between drive vendors (even if the information in the attributes is correct) and are not always unique like in my example. IDs would probably be a bit more reliable and exclusion from the performance data as well would be nice to have. Then I could exclude the broken attributes for the affected hosts not in the script on the hosts themselves but in the Icinga configuration instead (and that is build from Ansible using the monitored hosts' facts, so I could even detect it automatically).

Maybe I will have a look at it and do a pull request tomorrow.

from check_smart.

Currently, -e only excludes attributes from failure reporting and only by name. Names are known differ somewhat between drive vendors (even if the information in the attributes is correct) and are not always unique like in my example. IDs would probably be a bit more reliable

That was actually my intended answer here (to use -e attribute_id) :D
I somewhat forgot that the ID could not be excluded. But it's fairly easy to do and add this.
If you want, I'll let you do the code change and PR. If you don't find the time, let me know.

from check_smart.

As this is originally an already solved upstream issue anyway and I have a nice workaround now that fits my workflow, this can be closed I think.

from check_smart.