Nagios configuraion best practice

[dave stern - e-mail.pluribus.unum]

I think this is more a personal (or site) preference.

But using host groups can be very useful to eg
insure that
all windows machines get thus-and-such service checks
all RedHat machines get thus-and-such service checks
etc

In other words, a wildcard or hostgroup tag for a service check
can substantially reduce the size of your config, make it
more readable and insure uniformity.

>From a grouping perspective, ie if you tend to display by
hostgroups, it's often helpful to list all hosts once and only
once. However, in other environments, some find it very useful
to list some (or all ) machines in multiple groups.
This would allow you to easily view all RHEL9 hosts,
SLES10 hosts that have not yet been updated, hosts in room 123,
etc. The downside of this is when hosts go red, you'll see a lot more red...



On Wed, Dec 8, 2010 at 7:52 AM, Kenneth Holter <kenneho.ndu at gmail.com> wrote:
> Hi all,
>
>
> I'm picking up this old tread, as I'm about to start restructuring
> parts of my Nagios configuration. In my current configuration I've
> created host groups to which I've linked both hosts and services.
> Example: I have a host group called "linux-servers", to which all
> linux servers are linked. A number of service checks common for all
> linux servers are also linked to this host group. When adding new
> linux boxes I simply link them to the "linux-servers" host group. In a
> similar fashion I have a host-group called "application-servers" to
> which all application servers and related service checks are linked.
> When adding a new application server, I make sure it links to both
> "linux-server" and "applications-servers".
>
> This setup works pretty well, but it really clutters up the host
> groups web page. Is this the way others have structured their nagios
> configuration?
>
>
> Regards,
> Kenneth
>
>
> On Wed, Sep 17, 2008 at 2:55 PM, Kenneth Holter <kenneho.ndu at gmail.com> wrote:
>> I should have been more precise regarding the cluttering of the display - it
>> was the hostgroup display I was referring to. :/
>>
>> Would it be an idea to as much as possible use this configuration method:
>> hosts --- hostgroups --- services? To elaborate some: Hosts are always
>> connected to host groups, and the same for services. This way one will
>> avoid linking services to specific hosts, making the service definitions
>> more clean.
>>
>> Also, I'm thinking about having a host group called for example
>> "linux-servers", to which all linux servers are linked. A number of service
>> checks common for all linux servers are also linked to this host group. When
>> adding new linux boxes I simply link them to the "linux-servers" host group,
>> and add extra services checks where needed. In a similar fashin I would
>> create a host-group called for example "dell-servers" to which all Dell
>> hosts and related service checks are linked. New Dell servers are then
>> linked to this host group.
>>
>> I'm thinking this may be a good idea, but would like to hear how others have
>> structured their configuration and if there may be some hidden pitfalls in
>> my proposed configuration method.
>>
>>
>>
>> On 9/16/08, dave stern - e-mail.pluribus.unum <dit.dash at gmail.com> wrote:
>>>
>>> Not quite sure what you're trying to do. If you monitor a service,
>>> it's going to be on the nagios
>>> service details pagre regardless, That's the whole point. There are
>>> some tricks to slim down
>>> some other displays eg I define a whole bunch of services under a host
>>> without defining the
>>> hosts these services run on explicitly. I just feed the IP address as
>>> part of the check_command.
>>> This reduced the hostgroup grid page. I don't think that will work for
>>> you.
>>>
>>> If you're asking how to most efficiently code this in your configs,
>>> the timesaving tips page
>>> mentions ganging together services. ie you don't need a service stanza
>>> for each host you want
>>> to run this on. Rather, use a wildcard or group.
>>> define service{
>>>             use             generic
>>>              host_name    hosta, hostb
>>>              hostgroup     special-ones,!webguy
>>>           .....
>>> }
>>>
>>> Run the service on hosts hosta, hostb, all hosts in the hostgroup,
>>> "special-ones" but not "webguy"
>>>
>>> One other thing you should consider. Where will the plugins live? The
>>> easy answer is to put them
>>> on an NFSmounted partition that all hosts can access and that you can
>>> easily update. This is a
>>> bad practise. What happens when NFS breaks? You should really copy the
>>> plugins to each
>>> host st they run locally.
>>>
>>> On Tue, Sep 16, 2008 at 8:05 AM, Kenneth Holter <kenneho.ndu at gmail.com>
>>> wrote:
>>> >
>>> > Thanks for the reply. I'll read the documents you listed.
>>> >
>>> > Meanwhile, I have a design question: What's the best way to set up a
>>> > service
>>> > check to be executed on a selected few (or maybe all for that matter)
>>> > nodes?
>>> > Say I need to monitor a particular process (lets call this service A) on
>>> > a
>>> > number of systems, how would I implement this? I guess one way would be
>>> > to
>>> > link service A to a hostgroup, say hostgroup A, and add the selected
>>> > systems
>>> > to that hostgroup. This, however, will somewhat clutter up the web
>>> > display,
>>> > so I'm looking for alternative approaches.
>>> >
>>> > Any suggestions?
>>> >
>>> >
>>> >
>>> > On 9/15/08, dave stern - e-mail.pluribus.unum <dit.dash at gmail.com>
>>> > wrote:
>>> >>
>>> >> Assuming you're already familiar with nagios, I'd look at the nagios
>>> >> documentation
>>> >> in the following order:
>>> >>
>>> >> Under "Configuring nagios", look at "Object definitions" and make sure
>>> >>   you understand all parameters and what would make sense in your
>>> >> environment
>>> >> Under "Advanced Topics", look at "Timesaving tips for object
>>> >> definitions"
>>> >> Under "Advanced Topics", look at "host and service dependancies"
>>> >>
>>> >> Under "Advanced Topics", look at both "Distributed Monitoring" and
>>> >> "Redundant and
>>> >>   Failover Monitoring".
>>> >> Finally, under Security and Performance Tuning, look at Large
>>> >> Installation Tweaks
>>> >>
>>> >> On Mon, Sep 15, 2008 at 10:23 AM, Kenneth Holter
>>> >> <kenneho.ndu at gmail.com>
>>> >> wrote:
>>> >> > Hello all,
>>> >> >
>>> >> >
>>> >> > I'm new to Nagios, and are planning on using Nagios for monitoring
>>> >> > our
>>> >> > network of Linux servers.
>>> >> >
>>> >> > Are there any best practice documents on how to manage the different
>>> >> > definitions such as hostgroups, services, servicegroups, and so forth
>>> >> > in
>>> >> > an
>>> >> > enterprise environment?
>>> >> >
>>> >> >
>>> >> > Regards,
>>> >> > Kenneth Holter
>>> >> >
>>> >> >
>>> >> >
>>> >> > -------------------------------------------------------------------------
>>> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> >> > challenge
>>> >> > Build the coolest Linux based applications with Moblin SDK & win
>>> >> > great
>>> >> > prizes
>>> >> > Grand prize is a trip for two to an Open Source event anywhere in the
>>> >> > world
>>> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> >> > _______________________________________________
>>> >> > Nagios-users mailing list
>>> >> > Nagios-users at lists.sourceforge.net
>>> >> > https://lists.sourceforge.net/lists/listinfo/nagios-users
>>> >> > ::: Please include Nagios version, plugin version (-v) and OS when
>>> >> > reporting
>>> >> > any issue.
>>> >> > ::: Messages without supporting info will risk being sent to
>>> >> > /dev/null
>>> >> >
>>> >
>>> >
>>> >
>>> > -------------------------------------------------------------------------
>>> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> > challenge
>>> > Build the coolest Linux based applications with Moblin SDK & win great
>>> > prizes
>>> > Grand prize is a trip for two to an Open Source event anywhere in the
>>> > world
>>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> > _______________________________________________
>>> > Nagios-users mailing list
>>> > Nagios-users at lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/nagios-users
>>> > ::: Please include Nagios version, plugin version (-v) and OS when
>>> > reporting
>>> > any issue.
>>> > ::: Messages without supporting info will risk being sent to /dev/null
>>> >
>>
>>
>
> ------------------------------------------------------------------------------
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null