Hi Marko,
----- Original Message -----
> [...]
> I think this might be an acceptable approach, with inttypes.h + module.h
> we'll have all we need and if the API ever changes then module.h will be
> out of date but if we want to use the possible newer API we'd need more
> substantial code changes anyway.
+1
> > Yep - its all setup now and I see PCP values. There seems to be a bit of
> > a problem with instances - e.g. pcp.filesys.* - only the one instance is
> > ever reported (instance ID zero) - is that the same for you?
>
> It seems to work ok here:
Ah - one difference is I'm using "zabbix_agent -p" from your earlier mail,
e.g.
$ zabbix_agentd -p | fgrep pcp.disk.partitions.read_bytes
pcp.disk.partitions.read_bytes[sda1] [u|234808]
$ pminfo -f disk.partitions.read_bytes
disk.partitions.read_bytes
inst [0 or "sda1"] value 234808
inst [1 or "sda2"] value 234784
inst [2 or "sda3"] value 234784
inst [3 or "sda4"] value 232548
inst [4 or "sda5"] value 234784
inst [5 or "sda6"] value 33544
inst [6 or "sda7"] value 91563013
inst [7 or "sda8"] value 232548
inst [8 or "sda9"] value 637712
inst [9 or "sda10"] value 232676
> > There's some things we can improve in the way we're communicating with pmcd
> > here, and a bunch of smaller details we'd need to figure out (tutorial, QA,
> > man page, where to install a Zabbix module to, packaging, the timeout
> > value,
> > need to know a bit more about the Zabbix security model, diagnostics, and
> > so
> > on ...).
>
> Improving pmcd communication sounds interesting, what did you have in
> mind, client side caching or something else?
Definitely caching things like instances and descriptors if we can, and also
seeing if we can batch metric fetches (everything doing single-PMID pmFetch's
atm). Not sure if we can use that "mtime" field that is passed in via one of
the data structures, or whether we should simply fetch and cache for short
periods of time (and reply using values out of the cache).
Not a big deal, anyway.
> I assumed timeout is not needed as pmcd kills unresponsive PMDAs?
This is client code, we should probably set PMCD_REQUEST_TIMEOUT to that
value passed in (if I'm understanding it correctly). Again, easily done.
> What aspects of Zabbix security model are relevant here? Anything the
> user gives as an instance will go to pmLookupName() which should handle
> unsanitized input already and if the agent is properly configured then
> it can be queried from the trusted server only.
We (pmcd) run code as root and pass info on to auto-authenticating local:
processes (zabbix_agent) - so I'm just wondering what access controls it
might have to make sure we're not putting sensitive information (proc.*)
onto the network. We have some options we can use, like opting to use an
inet pmcd connection instead of af_unix (so, not auto-authenticated - we
give less privileged info back then, e.g. proc.* values/instance wouldn't
be available to Zabbix in that mode).
zabbix_agent -p seems to show sensitive stuff already though (/etc/passwd
contents, for example) - so I presume there must be some higher level ACL
mechanisms in Zabbix to make sure that info isn't handed out to any old
(remote?) Zabbix client?
> > But I think its all doable - with a bit of work, this seems to me like it
> > is
> > definitely something we could include in PCP, if you are still keen to see
> > this one merged Marko?
>
> Sure, let's try to get it done (with the caveat that I'll try prioritize
> the pmrep work in the coming days).
>
No problem - I'll start hacking on some of these things next week too.
cheers.
--
Nathan
|