Hi Marko,
----- Original Message -----
> 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.
OK, thanks - that makes more sense now.
> 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.)
Yes, I was more under the impression that the "zabbix_agentd -p" mode
was "normal" - so, the expand-everything, fetch-everything, every-time
model there had me a bit worried. It looks like thats not actually the
normal access method, in which case I agree - lets want and see how it
pans out in practice.
> 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".
OK. For now, I've made the one-line change from local: to localhost
context string, which means we expose less sensitive information.
If we go with the configuration file option (from the zbxpcp TODO list
in the source), we could pass authentication information from there &
allow an admin to enable access to that info if thats useful, not clear
if proc.* level of detail would be of value here anyway.
> > [...] - I'll start hacking on some of these things next week too.
>
I've pushed the build/package/test side of things into my git repo - see
previous mail. One small issue I came across - the module.h header says
GPL (from Zabbix), whereas your module code says LGPL. This might need
to be discussed with the Zabbix crew, AIUI the intention is to allow for
Zabbix modules that are LGPL?
cheers.
--
Nathan
|