> 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.