snmp_exporter and HP ILO cpqhlth mib

354 views
Skip to first unread message

Bruno Orfao

unread,
Sep 8, 2023, 12:33:07 PM9/8/23
to Prometheus Users
Hi all,

Long time lurker but 1st time poster and I was wondering if someone could help with a SNMP query.

Current using the latest version of Promethus and SNMP Exporter to collect metrics from HP servers via iLO and all works well, with the exception of 1 metric - cpqHeEventLogInitialTime.

This metric provides the date and time of a specific iLO alert but the data is present on OCTET format like this :
0x07E7051B0801

I have tried to force the Object to be DisplayString on the original mib - cpqhlth.mib and regenerate a new snmp.yml viathe generator.yml, but not matted I use for override ( tried DisplayString and DateAndTime)
I cannot get the data / time convertion to work.

When the cpHeEventLogInitialtime object type is set to anything other than OCTET string, I weird character beign displayed in Prometheus:


cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="189", cpqHeEventLogInitialTime=" � "}

cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="190", cpqHeEventLogInitialTime=" � "}

cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="191", cpqHeEventLogInitialTime=""}

cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="192", cpqHeEventLogInitialTime=""}

cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="193", cpqHeEventLogInitialTime="", "}

cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="194", cpqHeEventLogInitialTime="",}

cpqHeEventLogInitialTime{cpqHeEventLogEntryNumber="195", cpqHeEventLogInitialTime="", }


It looks like it is splitting the string as I get a lot more Event Log Number generated.
Other labels have been removed as they are not relevant.



Any ideas?


2023-09-07_12-54.png

Brian Candler

unread,
Sep 8, 2023, 5:56:36 PM9/8/23
to Prometheus Users
> This metric provides the date and time of a specific iLO alert but the data is present on OCTET format like this :
> 0x07E7051B0801

I found the following MIB description here:

"The time stamp when the event log entry was first created. field octets contents range ===== ====== ======== ===== 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minute 0..59 The year field is set with the most significant octet first. A value of 0 in the year indicates an unknown time stamp."

The sample value you have given is as follows, which looks plausible:
0x07e7 = 2023 (year)
0x05 = 5 (month)
0x1b = 27 (day)
0x08 = 8 (hour)
0x01 = 1 (minute)

Parsing this as a DisplayString isn't going to help you though, because then it would treat each byte as a single ASCII character, which will give you garbage (as you've found).

When it's left as the default OctetString format, how do the labels display?

If it looks like foo="07e7051b0801" then you'll be able to split the label in Prometheus using metric relabelling and label_replace(), but unfortunately it will still be in hex.

But more importantly: if this value is actually the timestamp of a log event, then it's completely unsuitable for use in metrics, because of huge cardinality (a whole set of new time series every minute). You'll need to drop it anyway. If you want to keep it, then you'll need to use something other than Prometheus (e.g. Loki or Elasticsearch).

However if this value is the time that the logging system started (and therefore is stable, except for when the system reboots) then it's fine to use as a label, although not especially interesting.
Reply all
Reply to author
Forward
0 new messages