Dynamic Nagios Configuration

[Christos Triantafyllidis]

Hi all,

    long ago i volunteered myself to start the work on a tool that will create dynamic
Nagios configuration based on external information (i.e. infra-hosts).

    You can find my work on this at:
git://fedorapeople.org/~ctria/DynamicNagiosConfig.git

     The idea is that there is a main configuration file:
DNC.yml
which specifies which modules to use to create the configuration. Given that the only
information i could get from infra-hosts was the host's information itself this only
does host configs but can be easily extended to support services, contacts etc.

The execution is simple, checkout the infra hosts repository in sample_configs/infra-hosts
folder and execute:
./DNC.py

You should get all hosts at standard output.

Finally a simple YAML based file module allows overrides to be specified.

I'm willing to move this forward so i'd definitely like to hear your comments

Regards,
Christos

PS: This is my first python script from scratch so don't be very hard on me :)

[Kevin Fenzi]

On Tue, 12 Jun 2012 01:15:36 +0300
Christos Triantafyllidis <christos.triantafyllidis(a)gmail.com&gt; wrote:

>  Hi all,
>  
>      long ago i volunteered myself to start the work on a tool that
>  will create dynamic Nagios configuration based on external
>  information (i.e. infra-hosts).
>  
>      You can find my work on this at:
>  git://fedorapeople.org/~ctria/DynamicNagiosConfig.git
>  
>       The idea is that there is a main configuration file:
>  DNC.yml
>  which specifies which modules to use to create the configuration.
>  Given that the only information i could get from infra-hosts was the
>  host's information itself this only does host configs but can be
>  easily extended to support services, contacts etc.
>  
>  The execution is simple, checkout the infra hosts repository in
>  sample_configs/infra-hosts folder and execute: ./DNC.py
>  
>  You should get all hosts at standard output.
>  
>  Finally a simple YAML based file module allows overrides to be
>  specified.
>  
>  I'm willing to move this forward so i'd definitely like to hear your
>  comments 
A good start. ;) 

So, what other information do we need to make this generate (most if
not all of our nagios configs)? 

I'd guess:

- vpn info. I'd like to get our vpn info in there so we have the right
  dependencies so we can only get one alert from a site being down
  instead of 10. ;) 

- contacts

- services - perhaps we could populate these in infra-hosts too? Not
  sure how best to do this. 

I guess the next step I would say is look at our current nagios config
and see how we can autogenerate the rest of it, or at least the parts
related to machines. 

kevin

[Станислав Ханжин-Цветков]

Hi all,
Why don't you use check_mk as nagios config generator?

I use it in production on CentOS for almost 2 years and I can name it a 
great solution for monitoring automation.

For further info see: http://mathias-kettner.de/check_mk.html

On 06/14/2012 08:43 PM, Kevin Fenzi wrote:
>  On Tue, 12 Jun 2012 01:15:36 +0300
>  Christos Triantafyllidis <christos.triantafyllidis(a)gmail.com&gt; wrote:
>
> > Hi all,
> >
> >      long ago i volunteered myself to start the work on a tool that
> > will create dynamic Nagios configuration based on external
> > information (i.e. infra-hosts).
> >
> >      You can find my work on this at:
> > git://fedorapeople.org/~ctria/DynamicNagiosConfig.git
> >
> >       The idea is that there is a main configuration file:
> > DNC.yml
> > which specifies which modules to use to create the configuration.
> > Given that the only information i could get from infra-hosts was the
> > host's information itself this only does host configs but can be
> > easily extended to support services, contacts etc.
> >
> > The execution is simple, checkout the infra hosts repository in
> > sample_configs/infra-hosts folder and execute: ./DNC.py
> >
> > You should get all hosts at standard output.
> >
> > Finally a simple YAML based file module allows overrides to be
> > specified.
> >
> > I'm willing to move this forward so i'd definitely like to hear your
> > comments
>  A good start. ;)
>
>  So, what other information do we need to make this generate (most if
>  not all of our nagios configs)?
>
>  I'd guess:
>
>  - vpn info. I'd like to get our vpn info in there so we have the right
>     dependencies so we can only get one alert from a site being down
>     instead of 10. ;)
>
>  - contacts
>
>  - services - perhaps we could populate these in infra-hosts too? Not
>     sure how best to do this.
>
>  I guess the next step I would say is look at our current nagios config
>  and see how we can autogenerate the rest of it, or at least the parts
>  related to machines.
>
>  kevin
>
>
>  _______________________________________________
>  infrastructure mailing list
>  infrastructure(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure

[Kevin Fenzi]

On Thu, 14 Jun 2012 20:48:21 +0400
Stanislav Hanzhin <hanzhin.stas(a)gmail.com&gt; wrote:

>  Hi all,
>  Why don't you use check_mk as nagios config generator?
>  
>  I use it in production on CentOS for almost 2 years and I can name it
>  a great solution for monitoring automation.
>  
>  For further info see: http://mathias-kettner.de/check_mk.html 
It's been suggested before. ;) 

It sounds interesting, but the first hurdle is that we need someone to
package it up and get it into EPEL. 

I'd be happy to help in efforts to do this... 

kevin

[yancy ribbens]

Another great tool for Nagios config management is NagiosQL.  Config files
are stored and managed using PHP and MYSQL, and then written to Nagios
config files on demand.

http://exchange.nagios.org/directory/Addons/Configuration/NagiosQL/details

-Yancy

On Fri, Jun 15, 2012 at 4:57 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  On Thu, 14 Jun 2012 20:48:21 +0400
>  Stanislav Hanzhin <hanzhin.stas(a)gmail.com&gt; wrote:
>
>  > Hi all,
>  > Why don't you use check_mk as nagios config generator?
>  >
>  > I use it in production on CentOS for almost 2 years and I can name it
>  > a great solution for monitoring automation.
>  >
>  > For further info see: http://mathias-kettner.de/check_mk.html
>
>  It's been suggested before. ;)
>
>  It sounds interesting, but the first hurdle is that we need someone to
>  package it up and get it into EPEL.
>
>  I'd be happy to help in efforts to do this...
>
>  kevin
>
>  _______________________________________________
>  infrastructure mailing list
>  infrastructure(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>

[Станислав Ханжин-Цветков]

Kevin, the real job there is to construct good SELinux policy for check_mk
serverside. Clients are already packaged.

2012/6/16 yancy ribbens <yancy.ribbens(a)gmail.com&gt;

>  Another great tool for Nagios config management is NagiosQL.  Config
> files
>  are stored and managed using PHP and MYSQL, and then written to Nagios
>  config files on demand.
>
>  http://exchange.nagios.org/directory/Addons/Configuration/NagiosQL/details
>
>  -Yancy
>
>  On Fri, Jun 15, 2012 at 4:57 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>
> > On Thu, 14 Jun 2012 20:48:21 +0400
> > Stanislav Hanzhin <hanzhin.stas(a)gmail.com&gt; wrote:
> >
> > > Hi all,
> > > Why don't you use check_mk as nagios config generator?
> > >
> > > I use it in production on CentOS for almost 2 years and I can name it
> > > a great solution for monitoring automation.
> > >
> > > For further info see: http://mathias-kettner.de/check_mk.html
> >
> > It's been suggested before. ;)
> >
> > It sounds interesting, but the first hurdle is that we need someone to
> > package it up and get it into EPEL.
> >
> > I'd be happy to help in efforts to do this...
> >
> > kevin
> >
> > _______________________________________________
> > infrastructure mailing list
> > infrastructure(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/infrastructure
> >
>
>
>  _______________________________________________
>  infrastructure mailing list
>  infrastructure(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>

[Kevin Fenzi]

On Sun, 17 Jun 2012 20:05:27 +0400
Станислав Ханжин <hanzhin.stas(a)gmail.com&gt; wrote:

>  Kevin, the real job there is to construct good SELinux policy for
>  check_mk serverside. Clients are already packaged. 
Well, we prefer anything we use if at all possible to be in EPEL. 

That way we know: 

- The package has passed review and is mostly sane. 
- There's a bug tracker so we can report bugs. 
- Packages are signed and distributed in a good way. 
- Other people are using the same packages so they can report/fix
  problems before they happen to us. 

Anyhow, check_mk does look interesting... perhaps someone would like to
drive a proposal for using it? ie, can you show us a sample config for
what we do? how it would work with puppet, etc?

kevin