Hello all,

I am following this discussion with lot of interest. I don't really know how the python module that convert the config files in the dictionary internal representation, but I currently have some though about plugin Shinken with other tools. The more obvious use case I see (and I'm interested in) is to be able to plug Shinken with a CMDB like tool to automatically generate probe definition from what is configured in architecture referential. Change the definition in the central database, and monitoring tools (and even other tools) automatically adapt to it.
I know such kind of thing is already done with GLPI with the help of a module but there is currently no way to "easily" plug to another tool. I see 3 ways it can be done :

    1/ One develop a module that will plug into shinken and will after startup add all necessary host/services extracted from the given external tool. It may be the more robust, but need developing skills and knowing Shinken's internal to add even a simple connexion

    2/ Completely externally to shinken (a bit like centreon works), the external tools generate a nagios like config file that is then read by Shinken. More standard format like json or xml may help in this direction

    3/ Introducting python code directly into config file may be a mid point between those two ones : in the config file, a small fonction is written that query the external tool and merge the adequate config into the config file

My own point is that I don't sufficiently know Shinken's internal (for now) to develop a module even for very simple case and is sticked to solution 2 that I don't really like because of all the hassle with file generation when multiples sources are required.
I planned to learn in a few month how Shinken load config files and work an a module for my particular needs, but if it can be used in the standard Shinken release it's even better ! I will be glad to help if there is no hurry to implement this feature.


2013/2/25 nap <naparuba@gmail.com>

On Mon, Feb 25, 2013 at 10:02 AM, Hermann Lauer <Hermann.Lauer@iwr.uni-heidelberg.de> wrote:
Hello all,

just an idea to put in there: Is it feasible to have different config
"languages" like the salt config management tool has ? Those can use at
least yaml, direct python code, jinja2 and xml.
One is the (settable) default for the config files, but this can be changed
with a shebang syntax in every individual file.

Of course shinken would have additionally the nagios compatible "language",
in the beginning as the default "language".

An important point would be that the direct python code would allow to
introduce self defined functions, objects and more, so not every new
dynamic feature has to be introduced in the nagios "language", as you
can use python code.

This would also be a path to merge the daemons config into the main
config in the long run.

Shurely no short time idea...
Thanks very much for all the work,


Sounds possible indeed (in the Shinken internal, the objects are just a key=>value dictionary with strings, so we don't really care about the input format.). But maybe we should try to find some use cases where this can be used, and see if the effort will really solve a real user problem, or if the current configuration features are enough.

It's true that the nagios configuration style was a problem, but after some quick features for simplify the configuration, now it's quite good, even for linking lot of objects together (like escalations and hosts for example). So let's find something that will change admin habits with this new capabilities, and then we can look if we should add a configuration overlay (like direct python or jinja, I'm really not a fan of XML and YAML :p ).


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Shinken-devel mailing list