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
--
Sven Nierlein [email protected]
ConSol* GmbH http://www.consol.de
Franziskanerstrasse 38 Tel.:089/45841-439
81669 Muenchen Fax.:089/45841-111
