Nathan Scott <nathans@xxxxxxxxxx> writes:
> [...]
>> > "libvirt.domstats.net.0.rd.times" - this looks like it's representing
>> > individual network devices using the metric namespace, is that right?
>> [...]
>> > That has proved highly problematic in the past - in general, much more
>> > flexibility (not to mention correctness often, too) [...]
What is an example of the not mentioned "correctness" problems?
>> What kind of "highly problematic" scenarios there has been in the past?
>
> So, one example is pmie - there is no equivalent of some_inst, etc for
> metric names, so rules end up having to be expanded for every metric.
That's true. And many pm$clients tolerate partially specified pmns
paths, but reject tail constraints:
pminfo foo
-> foo.bar.doze foo.bar.joze foo.baz.doze foo.baz.joze
pminfo foo.*.doze
-> no can do
OTOH most of those same clients can't do instance constraints by
regexps or such either.
> Another class of problems is around naming - metric names are defined
> to be less flexible than instance names (as per that pmns(5) extract,
> from earlier).
That is not a problem when the pmns name components are simple
ordinals, like in the present case.
>> I'm also wondering which one would be more easier approach e.g. with
>> pmwebd/grafana or Zabbix?
>
> Not sure it will make a big difference there, except that you have more
> flexibility with naming of instances [...]
In the pmwebd/grafana case, the two scenarios are interchangeable.
Instances appear at the last component of the graphite metric
description, with PMNS names before that. One could put a
wildcard/glob anywhere. In this way, it has a more powerful selection
capability than normal pm$clients.
- FChE
|