Avoid using InfoMetricFamily when possible

[gabrielcocenza]

I think it's not a good practice to just dump content using InfoMetricFamily and then need to have to query using labels.

E.g:
canonical/hardware-observer-operator#354 shows that the ssacli_controller is giving false alerts.

It's cleaner in my opinion if we return 1 for OK 0 for DOWN and -1 for unknown or others.

This can simplify expressions, so instead of using something like:

ssacli_controller_info{status!~"^(OK|NOT CONFIGURED)$"} we could just use ssacli_controller_info == 0

Moreover, I think it's easier to identify if ssacli changed the output if we observe that all metrics are returning -1 instead of checking the status. Always returning 1 with InfoMetricFamily is way less expressive

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/SOLENG-992.

This message was autogenerated

[aieri]

for clarity, after discussing, the proposal is to encode rich status (i.e. strings) into metric values (integers) without dropping the human readable labels. For example, we could see the following in prometheus:

ssacli_controller_info{status = "OK"} = 1
ssacli_controller_info{status = "NOT CONFIGURED"} = -1

(specific value mapping TBD)

[aieri]

we should be careful in how we handle upgrades:

• hardware-observer revision and hardware-exporter revision should match (one provides the metrics, the other the alerts)
• ensure that the old alerts are removed from COS upon upgrade