2008年（105）
分类： LINUX
2008-07-25 17:31:31
Timeperiods
[me@mymachine nagios] vim timeperiods.cfg
# ‘24×7′ timeperiod definition
define timeperiod{
timeperiod_name 24×7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
# ‘workhours’ timeperiod definition
define timeperiod{
timeperiod_name workhours
alias “Normal” Working Hours
monday 08:00-17:00
tuesday 08:00-17:00
wednesday 08:00-17:00
thursday 08:00-17:00
friday 08:00-17:00
}
# ‘nonworkhours’ timeperiod definition
define timeperiod{
timeperiod_name nonworkhours
alias Non-Work Hours
sunday 00:00-24:00
monday 00:00-09:00,17:00-24:00
tuesday 00:00-09:00,17:00-24:00
wednesday 00:00-09:00,17:00-24:00
thursday 00:00-09:00,17:00-24:00
friday 00:00-09:00,17:00-24:00
saturday 00:00-24:00
}
# ‘none’ timeperiod definition
define timeperiod{
timeperiod_name none
alias No Time Is A Good Time
}
You can specify as many of these as you want. For instance, say you have a need to contact folks only on the weekends. You can create a template “weekends” and use only Friday, Saturday, Sunday with the appropriate times as you see fit.
Contacts/Contact Groups
Contacts are split into two different files. One holds the actual contact options, and the other holds contacts together in groups. The groups are whom you specify Nagios to contact later on.
[me@mymachine nagios] vim contacts.cfg
# service_notification_options are w,u,c,r,f,n
# w=warning u=unknown c=critical r=recovery f=flapping n=none
# host_notification_options d,u,r,f,n
# d=down u=unreachable r=recovery f=flapping n=none
define contact{
contact_name me
alias me
service_notification_period 24×7
host_notification_period 24×7
service_notification_options c,r
host_notification_options d,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email me@myemailaddress.whatever
}
define contact{
contact_name you
alias you
service_notification_period workhours
host_notification_period workhours
service_notification_options c,r
host_notification_options d,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email you@youremailaddress.whatever
}
You can choose to do as you wish, but for my purposes I only set contacts up to be notified on critical and recovery alerts. I really have no interest in most things I’m monitoring alerting me when there may be a temporary glitch, or when something is in a warning state, especially at 4:00 a.m. The reason I don’t is because a) I frequently check the Nagios CGI interface throughout the day, and b) all of my alerts get forwarded to a ticketing system. With that said, I don’t want unnecessary tickets being generated simply because a plugin failed to execute this time around. If I was very inspired, I could set up a separate contact and group to receive only the warning and unknowns, and then pipe these through a different e-mail address. Again, completely adaptive to your needs. Also, I’m using e-mail only. My e-mail system takes care of processing where the alerts are going. However, you could set up nagios to pipe messages straight to pagers. Again, check the object configuration options for timeperiods.cfg on the docs. If you want to see the commands being prosecuted for alerts, check out /etc/nagios/misccommands.cfg. On to the contact groups.
[me@mymachine nagios] vim contactgroups.cfg
# ‘einsteins’ contact group definitions
define contactgroup{
contactgroup_name einsteins
alias einsteins
members me,you
}
This is a simple example of contacts and contact groups. You can nest as many possibilities as you really want to. You can create as many contacts you need as well. It’s rather straightforward.
Hosts and Host Groups
Host and host group information is stored in the two files hosts.cfg and hostgroups.cfg. Just as you can mix and match contacts in various contact groups, you can do the same thing with host names in host groups. I prefer to create template configurations that I can leech off of later on in my configuration file. It saves you an incredible amount of time typing down the road.
[me@mymachine nagios] vim hosts.cfg
# Generic host definitions
define host{
name generic-host ; Generic template name
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
}
# This creates a generic template that any host can use.
# Notifies never, checks 15 times before showing critical on CGI interface,
define host{
name basic-host
use generic-host
check_command check-host-alive
max_check_attempts 15
notification_interval 0
notification_period none
notification_options n
register 0
}
# This creates a generic host that your routers can use
# monitors host(s) 24×7, notifies on down and recovery, checks 15 times before going critical,
# notifies the contact_group every 30 minutes
define host{
name your-routers-host
use generic-host
check_command check-host-alive
max_check_attempts 15
notification_interval 30
notification_period 24×7
contact_groups einsteins
notification_options d,r
register 0
}
define host{
use basic-host
host_name mymachine1
alias mymachine1
address 192.168.100.101
}
define host{
use your-routers-host
host_name router1
alias router1
address 192.168.100.100
}
You can begin to see how much time predefined templates can save you down the road when adding hosts. I’m monitoring around 100 hosts and over 200 services, so doing things the template way can really be productive in the long haul. It can get a little confusing, but stick to the docs and you’ll learn pretty quickly. When it comes to all of the template object options each file can contain, look for this (or your IP)/nagios/docs/configobject.html. This will help you tremendously, because there are so many options Nagios allows you to choose from. I split things up because I want notifications on your-routers-host, but I don’t want notification on the basic-host container. Starting to understand why you use templates? Ok, now on to host groups.
[me@mymachine nagios] vim hostgroups.cfg
define hostgroup{
hostgroup_name basic-clients
alias basic clients
members mymachine1
}
define hostgroup{
hostgroup_name your-routers
alias routers
members router1
}
That’s about as simple as this can get. You specify your clients from hosts.cfg into host groups in this file. You can split them into multiple groups. For instance, mymachine1 can live within both the basic-clients and your-routers group if you so desired. Pretty simple…
Services
To start, you’re going to need at least one service to monitor. This would be a simple check-host-alive, or ping. Again, I split things into templates to make it easier down the road just as demonstrated above.
[me@mymachine nagios] vim services.cfg
# Generic service definition template
define service{
name generic-service ; Generic service name
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
parallelize_check 1 ; Active service checks should be parallelized (don’t disable)
obsess_over_service 1 ; We should obsess over this service (if necessary)
check_freshness 0 ; Default is to NOT check service ‘freshness’
notifications_enabled 1 ; Service notifications are enabled
event_handler_enabled 1 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
process_perf_data 1 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
}
# Generic for all services
define service{
use generic-service
name basic-service
is_volatile 0
check_period 24×7
max_check_attempts 15
normal_check_interval 10
retry_check_interval 2
notification_interval 0
notification_period none
register 0
}
define service{
use basic-service
name ping-service
notification_options n
check_command check_ping!1000.0,20%!2000.0,60%
register 0
}
define service{
use ping-service
service_description PING
contact_groups einsteins
hostgroup_name basic-clients,your-routers
}
This is the classic example of how to nest templates. I’ve declared a general template to use called “basic-service” which leeches off of the “generic-service” definitions above that. The next defines a new service called “ping-service” which checks to see if host groups are alive specified with a simple ping. The reason I split this out is because say you want to create another host group called “your-switches,” but you want notifications to go out on this service to a different contact group. Then you just define another service and add this host group to that definition, and apply a different contact group. Ultimately, the last definitions override all other containers above it. Last man standing type deal. The last option Nagios sees, is the one it goes by. For example:
define service{
use ping-service
service_description PING
contact_groups group2
hostgroup_name your-switches
}
