Hi,
On 2015-11-20 05:07, Nathan Scott wrote:
> ----- Original Message -----
>
> 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]
yes, that's expected, in zbx_module_pcp_add_metric() the first instance
is added as a "test parameter" which is then used with -p.
>> 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 didn't see a way to batch fetches or results with the current API, I
also thought a bit about caching but I was hoping that looking up
instances and descriptors would already be quite optimal as that's very
common operation for clients. But mostly I was thinking that trying to
avoid few metric related lookups would fall into the micro-optimization
category and is probably not going to be very helpful in the big
picture. OTOH it all adds up so if there's something you see that could
be easily added then why not.
(Although the fetch+cache is probably not going to be useful in that
sense that I'd expect most people to use 1+ minute intervals with Zabbix
and if someone wants to check more often than that then they'd probably
expect to see the actual values and if they're already willing to load
the network then they're also willing to load pmcd as well. But this is
a bit of speculation, perhaps we could wait for feedback to see what's
needed.)
>> 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.
Ah, thanks for pointing that out, indeed it'd be worth to add, looks
line a one-liner.
> 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?
I'm afraid the agent options are pretty much limited to configuring the
allowed IPs to connect to the agent and running it as non-root (the
default is the "zabbix" user). Otherwise passing stuff like /etc/passwd
contents is probably considered a "feature".
> No problem - I'll start hacking on some of these things next week too.
Thanks,
--
Marko Myllynen
|