Mathieu - I'm going to give this a whirl but I might get it a bit mixed
up ... anyone correct me if I'm being misleading here.
I'll take the easy one first:
<monitor service="service_name" class-name="my.java.class.name"/> in
poller-configuration.xml merely maps a service name to the underlying
java class that will implement polling of that service. This is used
when we want to poll a service, we go looking for this class, load it
and then call it's polling methods.
Capsd takes a slightly different approach to the configuration file and
actually embeds the class-name in the <protocol-plugin /> definitions
... it's just preference as far as I can tell.
As for the <service /> stuff in poller, this actual tells OpenNMS what
to do (parameters, etc) and it's important that service's are 'packaged'
together. So for a given package if you pass the criteria to fit into
the package (in the example it's an IPLIKE expression that matches
everything) then you will be polled, using the services in the package
at those intervals. It's actually very straight forward.
Just remember it all works from discovery onward. So a node needs to be
discovered -> then it's capabilities are scanned -> and then it's
polled. Typically you can include/exclude nodes based on IP's in each
of these steps (capsd is the exception, you state whether you want the
node managed or unmanaged based on the IP).
hope that helps.
On Thu, 2002-08-22 at 08:51, Mathieu DESPRIEE wrote:
> Hi everybody !
> Could anybody explain the subtleties between :
> - <service> ... </service> in packages, in poller-configuration.xml
> - <monitor service=.../> for all packages, in poller-configuration.xml
> - <protocol-plugin> ... </protocol-plugin>, in capsd-configuration.xml
> Which is service configuration ? Which triggers the polling ?
> Thanks in advance,
> To subscribe, unsubscribe, or change your list options, go to:
Ian Wallace - iwallace@...
303.209.5623 (w) 720.308.5696 (m) 303.209.5620 (f)
Context Managed Services, Denver CO