You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
m.labels(controller_name=controller_name, array_name=array_name, logical_drive_name=logical_drive_name,
**{n: logical_drive_properties.get(n, "") for n in (
"device",
"raid_level",
"logical_drive_label",
"multidomain_status",
"parity_initialization_status",
"status"
)
},
caching=bool_or_none_to_label_value( logical_drive_properties.get("caching") )
)
(here an example where I set some of the properties directly, and some via dict unpacking)
It would fail if I forgot a label.
I could use label names as attribute names, like controller_name= rather than "controller_name"=... which is however not super important
With InfoMetricFamily seem quite a bit different:
add_metric() now has the parameters labels and value.
As far as I understand the code, labels are actually not labels, but values for these, namely the ones set with labels in the constructor of InfoMetricFamily.
It's no longer possible to give labels as dict, one really needs to give them in the right order as sequence. Why does Info allow that but not this?
AFAICS, there is no check if exactly those labels are set, that were given in the constructor. Why over at Info but not here? What sense does it then even make to set the labels in the constructor?
value is misleading in so many ways. It's not the value of the metric (that is 1) and even if it relates to the labels being the “value”, then it should be values.
It might have perhaps even been better to swap the two names... or rater use some completely different names.
Anyway... guess this can't be changed now without breaking the ABI.
the idea is one can give labels and/or value and both are merged in a final dict of label/value pairs.... but then it would be nice if labels and value were not required.
Why not simply give them default values () respectively {}?
I could provide a patch if nothing speaks against that particular change. But the above points are IMO still problematic. Especially also that the behaviour is considerable different from Info, which is not really obvious.
Cheers,
Chris.
The text was updated successfully, but these errors were encountered:
It seems even worse... the other objects like GaugeMetricFamily do not allow to set their labels as dict... so one always must present them in the right order, which is error prone.
Why don't they just offer the same means as Gauge.labels() :-(
Hey.
I was looking into
InfoMetricFamily
’sadd_metric()
and I either I just don't get it or the API is a bit strange.With an
Info
object I'd have done something like this:and then set it like:
(here an example where I set some of the properties directly, and some via
dict
unpacking)controller_name=
rather than"controller_name"=
... which is however not super importantWith
InfoMetricFamily
seem quite a bit different:add_metric()
now has the parameterslabels
andvalue
.labels
are actually not labels, but values for these, namely the ones set withlabels
in the constructor ofInfoMetricFamily
.labels
asdict
, one really needs to give them in the right order as sequence. Why doesInfo
allow that but not this?Info
but not here? What sense does it then even make to set the labels in the constructor?value
is misleading in so many ways. It's not the value of the metric (that is1
) and even if it relates to the labels being the “value”, then it should bevalues
.Anyway... guess this can't be changed now without breaking the ABI.
However, as far as I understand the code:
client_python/prometheus_client/metrics_core.py
Line 372 in 09a5ae3
the idea is one can give
labels
and/orvalue
and both are merged in a finaldict
of label/value pairs.... but then it would be nice iflabels
andvalue
were not required.Why not simply give them default values
()
respectively{}
?I could provide a patch if nothing speaks against that particular change. But the above points are IMO still problematic. Especially also that the behaviour is considerable different from
Info
, which is not really obvious.Cheers,
Chris.
The text was updated successfully, but these errors were encountered: