Hello,
Yes I do feel that it was never the intent but I do think it is a
direction we should head in since it feels more optimal to just specify
that this is a checkpoint firewall for example and then all relevant
services will be checked. Of course this can be done with hostgroups but
not if some checkpoint firewalls are clusters and some are not then you
need two different hostgroups for that and it would add a hostgroup for
each feature that might differ.
if we can help these more complex plugins from within naemon I think it
is something we should do.
Thanks for the register 0 on hostgroups I didn't know that.
I can't find any information on updating the custom attributes with
livestatus, what is the lql syntax for that?
Best Regards
Magnus
On 2015-04-06 11:24, Sven Nierlein wrote:
Hi Magnus,
Well, plugins are meant to be small check scripts which fetch and verify some
numbers and things. You are creating
more something like a check framework. Thats possible, but this was never meant
to be done by plugins. However,
a few things are possible already.
1. Templates might be a solution for this problem.
2. hostgroups with "register 0" should be invisible in the gui.
3. thats totally up to your plugins.
4. creating tmp files has always been a bad idea. You could store values in
naemon custom attributes which can be retrieved and updated via livestatus.
The only cavehat with that, is that the custom attribute must exist
already if you want to update it via livestatus. But since you generate your
config
anyway, just create it empty.
Cheers,
Sven
On 05/04/15 13:00, Magnus wrote:
Hello,
I am very interested in what future plans you guys have for naemon. To me
naemon is to limited in the way plugins interact with naemon.
For example a plugin should be able to tell if a service has been acknowledged.
I use this in my plugins. Earlier i had to parse status.dat but now I use
livestatus for that.
Also for performance reasons (both on the naemon machine and snmp/network
utilization) when monitoring a switch with a lot of interfaces I have written a
plugin that fetches all the interfaces that should be monitored and creates
services for each interface by creating cfg files and restarting naemon. There
are a few problems with this, first creating the config files and restarting
naemon can cause problems if someone is editing the config and the config is in
an erranous state causes naemon to die. Also if there naemon is restarted
(which only happens when new interfaces are discovered) then the plugins output
is not collected by the restarted naemon process (I did find a workaround for
this by waiting for a second and then submitting the main service results as
passive though I don't feel very comfortable with this solution yet it works).
For this typ of usage I envision the dynamic services doesn't even need to be
added to the configuration files at all. A plugin should
be able to create "ghost" services that are only available when the plugin
creates them after a restart they would be gone but would appear when the main service
check script is run again.
Perhaps creating services could be through livestatus but I think a new
interface might be better. Using livestatus has the drawback that you have to
know your own hostname and the service name (when checking for example if the
service for which this script is being run has been acknowledged). An interface
where you could query with filters like current_host and current_service for
example would be very useful.
I think naemon should strive to have an easy configuration and having to create
47 services when you monitor 47 different interfaces on a switch is
unneccessary.
I have a few more idees I would like to see in naemon.
1. Hosts that inherit hostgroups custom variables.
2. Hostgroups that are not visible in the web ui (I use hostgroups to have the
same services for several hosts (for example in a cluster) but the hostgroup
itself has no value and only adds more hostgroups that confuse operators).
3. Since I create a lot of passive services in my plugins I think having -c and
-w is very limited since the same plugin could have a lot of different
thresholds for different stuff so I use different custom variables for this,
perhaps this should be more standardized in some way.
4. Creating the files in /tmp for storing information which a lot of plugins
use seems less then optimal for me. I think a plugin should be able to create
read/write variables within the naemon process of course this would need to be
limited to a certain amount per host or something so a plugin cant create a
memory leak we are most likely talking very small amounts of data her for
example the last interface utilization counters and such. Naemon would store
these in its state file so they are still there after a restart.
I will involve myself in this both code and design wise but I would like for
you guys to at least think this is a direction you think naemon should head in.
Also my c coding skills are rusty so they might need some finishing touches by
someone more skilled. I suck at graphics and web interfaces but I could also
help with documentation and writing plugins.
Regards
Magnus
