Hi Marko,
----- Original Message -----
> On 2016-07-19 06:49, Nathan Scott wrote:
> > ----- Original Message -----
> >> [...]
> > "libvirt.domstats.net.0.rd.times" - this looks like it's representing
> > individual network devices using the metric namespace, is that right?
>
> Correct.
>
> > That has proved highly problematic in the past - in general, much more
> > flexibility (not to mention correctness often, too) is to found in the
> > approach of using a new indom with a compound instance name, e.g.
> >
> > libvirt.domstats.net.rd.times[vmXXX/ifNNN]
> >
> > This tends to make things easier on the client side too, from a users
> > point of view - e.g. writing pmie rules, pmchart configs, etc.
>
> 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.
pmchart configs have similar issues, regex matching on instance names
is available but metric names are expected to be more static (and need
individual expansion in the configuration files).
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).
> 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 ... so I'd tend to favour the use
of instances for those cases too.
cheers.
--
Nathan
|