pcp
[Top] [All Lists]

Re: [pcp] PCP / Zabbix Agent Loadable Module

To: myllynen@xxxxxxxxxx
Subject: Re: [pcp] PCP / Zabbix Agent Loadable Module
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 17 Nov 2015 20:24:53 -0500 (EST)
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5640F0C6.1080801@xxxxxxxxxx>
References: <563099A2.8040901@xxxxxxxxxx> <852045589.5144136.1446765609785.JavaMail.zimbra@xxxxxxxxxx> <5640F0C6.1080801@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 1NUyQk6QYPT8GtAYEFvsTabuUI3ebQ==
Thread-topic: PCP / Zabbix Agent Loadable Module
Hi Marko,

----- Original Message -----
> Hi,
> 
> On 2015-11-06 01:20, Nathan Scott wrote:
> >>
> >> - pmNewContext(PM_CONTEXT_LOCAL, "") of course works as expected from
> >> standalone clients but seems to fail from the DSO. This means that the
> > 
> > Can you paste the failure message somewhere?  (in case I can't get it
> > to work, below)  Off the top of my head I don't know why it would fail
> > in local context mode.
> 
> this might be something completely Zabbix related after all, I tried
> with the two attached tests which seems to work just fine.

I think its the same problem as you would see with "pminfo -L" (compared
to, say, "pminfo -L hinv" and "pminfo -n /var/lib/pcp/pmns/root_linux) -
where PM_ERR_NOAGENT is ultimately returned from pmTraversePMNS(3) - at
least, that's what was happening to me in the end.

A zbxpcp.so configuration file with explicit metrics (rather than trying
to expand all metrics possible via a local context) would resolve this.
But, using pmcd avoids the above and is the best way to get all available
metrics from all installed PMDAs into Zabbix, so perhaps we should use it
unconditionally.

> >> What do you think, could this live in pcp.git?
> > 
> > Maybe - there seems to be alot of conceptual overlap between this and
> > the "pmrep -o zabbix ..." kind of approach - I suspect we should focus
> > on doing one way well rather than both?
> 
> It sounds like Zabbix users have lots of different kinds of needs /
> environments so one tool won't fit all. But in general I think this
> loadable module approach might be more preferable one.

OK, seems like its worth continuing to work on making this available as
part of PCP.

> > How stable is the Zabbix module API/ABI?  Are those headers available
> > in distribution builds etc?
> 
> I'd suspect the API is not that widely used but it should be pretty
> stable, it was introduced in Zabbix 2.2 released in Nov 2013 and the API
> is still the same in Zabbix 3.0, currently under development.
> 
> I didn't find the headers in Fedora/RHEL packages so I downloaded the
> sources from http://www.zabbix.com/download.php, then unpacked, ran
> ./configure (no need for any params), and then the headers were ready
> for inclusion.

I looked into this a whole lot more, its interesting how they've set this up.

I assumed there would be headers and a shared library which the zbxpcp DSO is
including+linking with, which talks to zabbix_agent.  But, thats not entirely
the case.  Theres no shared library to link, its all macros and (very simple)
data structures in the headers.  Pretty much one header includes everything,
and the structures are so simple that we could even consider a local copy (in
PCP I mean) since they aren't shipped in any rpm & are license compatible.

Maybe.  It would have the endearing property of working out-of-the-box after
a PCP install (provided the Zabbix API is stable, which it seems to be), as
well as being very simple in the PCP build - no configure-scripting and no
conditional-enablement needed.

> > Done that - I'm missing a bit of the recipe here though: where do the
> > Zabbix headers come from?  (needed for compiling zbxpcp.c).  And once
> > I have that built, how do I inform Zabbix agent?  Taa.
> 
> See above, it's a bit clumsy. I added these lines to the
> /etc/zabbix/zabbix_agentd.conf file and restarted the agent:
> 
> LoadModulePath=/tmp
> LoadModule=zbxpcp.so
> 
> >> and then do something like "zabbix_agentd -p | grep pcp".
> > 
> > (I have "zabbix_agentd -p" working, but obviously not the bridge part
> > yet, so no "pcp" found just yet).
> 
> You can also test fetching individual metrics with something like:
> 
> $ zabbix_get -s 127.0.0.1 -s 10050 -k pcp.mem.util.free

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?


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 ...).

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?

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>