43,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Over 90 hands-on recipes that will employ Nagios Core as the anchor of monitoring on your network
About This Book
- Master the advanced configuration techniques of Nagios Core to model your network better by improving hosts, services, and contacts
- Filter and improve the notifications that Nagios Core sends in response to failed checks, which can greatly assist you when diagnosing problems
- Pull Nagios Core's data into a database to write clever custom reports of your own devise
Who This Book Is For
If you are a network or system administrator and are looking for instructions and examples on working with Nagios Core, then this book is for you. Some basic shell command-line experience is required, and some knowledge of scripting would be helpful when we discuss how plugins work.
What You Will Learn
- Manage the configuration of Nagios Core with advanced techniques to achieve fine detail in your checks
- Find, install, and even write your own check plugins
- Filter notifications to send them to the right people or programs at the right time
- Work around difficult network accessibility issues and delegate checks to other machines
- Tweak a Nagios Core server to achieve both high performance and redundancy in case of disaster
- Process the results of checks performed by other machines to monitor backups and similar processes
- Extend Nagios Core to allow advanced scripting, reporting, and network visualization behavior
In Detail
Nagios Core is an open source monitoring framework suitable for any network that ensures both internal and customer-facing services are running correctly and manages notification and reporting behavior to diagnose and fix outages promptly. It allows very fine configuration of exactly when, where, what, and how to check network services to meet both the uptime goals of your network and systems team and the needs of your users.
This book shows system and network administrators how to use Nagios Core to its fullest as a monitoring framework for checks on any kind of network services, from the smallest home network to much larger production multi-site services. You will discover that Nagios Core is capable of doing much more than pinging a host or to see whether websites respond.
The recipes in this book will demonstrate how to leverage Nagios Core's advanced configuration, scripting hooks, reports, data retrieval, and extensibility to integrate it with your existing systems, and to make it the rock-solid center of your network monitoring world.
Style and approach
Each chapter contains a set of step-by-step recipes to perform an example of a commonly performed task related to network administration. The book begins by focusing closely on the properties and configuration of Nagios Core itself, and gradually moves on to other pieces of software that can support, manage, and extend the system.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 500
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Nagios Core Administration Cookbook Second Edition
Nagios Core Administration Cookbook Second Edition
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: January 2013
Second Edition: February 2016
Production reference: 1230215
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78588-933-2
www.packtpub.com
Credits
Author
Tom Ryder
Reviewer
John C. Kennedy
Commissioning Editor
Priya Singh
Acquisition Editor
Ruchita Bhansali
Content Development Editor
Mayur Pawanikar
Technical Editor
Vivek Pala
Copy Editor
Neha Vyas
Project Coordinator
Nidhi Joshi
Proofreader
Safis Editing
Indexer
Mariammal Chettiyar
Graphics
Disha Haria
Production Coordinator
Nilesh Mohite
Cover Work
Nilesh Mohite
About the Author
Tom Ryder is a systems administrator and former web developer from New Zealand. He uses Nagios Core as part of his "day job" as a systems administrator, monitoring the network for a regional Internet service provider. Tom works a great deal with Unix-like systems, being a particular fan of GNU/Linux, and writes about usage of open source, command-line development tools on his blog, Arabesque, at http://blog.sanctum.geek.nz.
About the Reviewer
John C. Kennedy has worked with Unix and Linux since 1998. He has worked on Nagios as a monitoring tool for much of the past 5 years.
He has been reviewing and tech editing books in his spare time since 2001 and has about 20 open source-related books under his belt. He believes the best part of reviewing is that he learns something from every book he works on.
John was born in the U.S. and grew up in Northern Virginia. He spent some time in the U.S. Air Force and has lived in Germany and the United Kingdom. He has been married to Michele since 1994 and has two children, Denise and Kieran. He currently lives in Virginia.
I would like to thank my family, including my nephews, Aiden and Mason, and my niece, Harriet, for supporting all the silly things I do and for giving me time to work on this.
Thanks also to Nidhi Joshi whose great patience and flexibility around my very hectic schedule were VERY much appreciated. Also, my thanks go to the author, Tom Ryder. I learned a lot from the book, and it has been one of my favorite books to work on. Everyone at Packt Publishing also deserves recognition for all their titles and the hard work that goes into producing every one of them.
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why Subscribe?
Preface
Nagios Core, the open source version of the Nagios monitoring framework, is an industry standard for network monitoring hosted on Unix-like systems, such as GNU/Linux or BSD. It is very often used by network and system administrators to check the connectivity between hosts and to ensure that network services are running as expected.
Where home-grown scripts performing network checks can rapidly become unmaintainable and difficult for newer administrators to customize safely, Nagios Core provides a rigorous and configurable monitoring framework to make checks in a consistent manner and to alert appropriate people and systems of any problem it detects.
This makes Nagios Core a very general monitoring framework rather than an out-of-the-box monitoring solution, which is known to make it a little unfriendly to beginners and something of a "black box", even to the otherwise experienced administrators. Busy administrators charged with setting up a Nagios Core system will often set it up to send PING requests to a set of hosts every few minutes and send them an e-mail about any problem, and otherwise never touch it. More adventurous administrators new to the system might instate a few HTTP checks to make sure that company websites respond.
Nagios Core is capable of a great deal more than that, and this book's recipes are intended to highlight all of the different means of refining and controlling checks, notifications, and reporting for Nagios Core, rather than being a list of instructions for using specific plugins, of which there are many hundreds available online at the Nagios Exchange at https://exchange.nagios.org/. The book's fundamental aim is to get administrators excited about the possibilities of Nagios Core beyond elementary default checking behavior so that they can use much more of the framework's power and make it into the centerpiece of their network monitoring.
This also includes installing and even writing custom plugins beyond the standard Nagios Plugins set, writing and refining one's own checks, working with the very powerful Simple Network Management Protocol (SNMP), and the recording and reporting of performance data. It also includes refining notification behavior to only send appropriate notifications at appropriate times to appropriate people or systems, basic visualization options, identifying breakages in network paths, clever uses of the default web interface, and even extending Nagios Core with other open source programs. It includes all this in order to virtually check any kind of host property or network service on any network.
Where possible, this book focuses on add-ons written by the Nagios team themselves, particularly NRPE and NSCA. It omits discussion of popular forks of Nagios Core, such as Icinga. In the interest of conferring an in-depth understanding of advanced Nagios Core configuration, it also does not discuss any configuration frontends or wizards, such as NConf. Finally, as a Packt open source series book focusing on the use of the freely available Nagios Core, it also does not directly discuss the use of Nagios XI, the commercial version of the software supported by the Nagios team. This is done to instill a thorough understanding of Nagios Core itself, rather than to reflect the personal opinions of the author; curious administrators should definitely investigate all of these projects.
What this book covers
Chapter 1, Understanding Hosts, Services, and Contacts, gives you a basic idea of hosts, services, and contacts followed by the summary of this chapter.
Chapter 2, Working with Commands and Plugins, explains the architecture of plugins and commands, including installing new plugins and defining custom uses of existing ones. It also walks us through how to write a new plugin with Perl.
Chapter 3, Working with Checks and States, explains how Nagios Core performs its checks and how to customize that behavior, including scheduling downtime for hosts and services and managing "flapping" for hosts or services that keep going up and down.
Chapter 4, Configuring Notifications, explains the logic of how Nagios Core decides on what basis to notify, when, and to whom, including examples of implementing a custom notification method, escalating notifications that aren't fixed after a certain period of time, and scheduling contact rotation.
Chapter 5, Monitoring Methods, gives examples of the usage of some of the standard Nagios Plugins sets, moving from basic network connectivity checks with PING and HTTP to more complex and powerful checks involving SNMP usage.
Chapter 6, Enabling Remote Execution, shows how to use NRPE as a means of working around the problem of not being able to check system properties directly over the network, including a demonstration of the more advanced methods of check_by_ssh and check_mk.
Chapter 7, Using the Web Interface, shows some less-used features of the web interface to actually control how Nagios Core is behaving and to see advanced reports, rather than simply viewing the current state information. Use of the network map is not discussed here but in the next chapter.
Chapter 8, Managing Network Layout, explains how to make Nagios Core aware of the structure and function of your network with a focus on hosts and services depending on one another to function correctly, including monitoring clusters and using that layout information to build a network status map, optionally with icons and a background.
Chapter 9, Managing Configuration, shows how to streamline, refine, and control Nagios Core's configuration at a low level without the use of frontends. It focuses on the clever use of groups, templates, macros, and custom directives, and gives an example of generating configuration programmatically with the templating language m4.
Chapter 10, Security and Performance, shows how to manage simple access control, debugg runtime problems, and keep tabs on how Nagios Core is performing, and also contains a demonstration of basic monitoring redundancy.
Chapter 11, Automating and Extending Nagios Core, explains how to submit check results from other programs (including NSCA) to provide information about external processes via the commands file, and an introduction to a few popular add-ons (NDOUtils, MK Livestatus, NagVis, and Nagiosgraph).
What you need for this book
In an attempt to work with a "standard" installation of Nagios Core, this book's recipes assume that Nagios Core 4.0 or later and the Nagios Plugins set have been installed in /usr/local/nagios by the Nagios Quickstart Guides available at https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/quickstart.html.
If your system's package repositories include a package for Nagios Core 4.0 or later that you would prefer to use, this should still be possible, but the paths of all the files are likely to be very different. This is known to be a particular issue with the nagios3 package on Debian or Ubuntu systems. If you are familiar with the differences in the installation layout that your packaging system imposes, then you should still be able to follow the recipes with only a few path changes.
Who this book is for
This book is aimed at system and network administrators who are comfortable with basic Unix-like system administration via the command line. It is best suited for GNU/Linux administrators, but should work fine for BSD administrators too. It has particular focus on the kind of administrator identified in the preface: one who is comfortable working with their Unix-like system, may well have a basic Nagios Core installation ready with some PING checks, and now wants to learn how to use more of the framework's power and understand its configuration in more depth.
Administrators should be comfortable with installing library dependencies for the extensions, plugins, and add-ons discussed in the book. An effort is made to mention any dependencies; however, how these are best installed will depend on the system and its package repository. In almost all cases, this should amount to installing some common libraries and their headers from a packaging system. Debian and Ubuntu package names are given for some more complex cases.
The easier recipes in the first five chapters involve some recap of the basics of configuring Nagios Core objects. Users completely new to Nagios Core who have just installed it will almost certainly want to start with Chapter 1, Understanding Hosts, Services, and Contacts, after completing the Nagios Quickstart Guide, as the latter chapters assume a fair amount of knowledge.
Sections
In this book, you will find several headings that appear frequently (Getting ready, How to do it, How it works, There's more, and See also).
To give clear instructions on how to complete a recipe, we use these sections as follows:
Getting ready
This section tells you what to expect in the recipe, and describes how to set up any software or any preliminary settings required for the recipe.
How to do it…
This section contains the steps required to follow the recipe.
How it works…
This section usually consists of a detailed explanation of what happened in the previous section.
There's more…
This section consists of additional information about the recipe in order to make the reader more knowledgeable about the recipe.
See also
This section provides helpful links to other useful information for the recipe.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, and user input are shown as follows: "Nagios Core will only need whatever information the ping(8) tool would need for its own check_ping command."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "If the server restarted successfully, the web interface should show a brand new host in the Hosts list, in the PENDING state as it waits to run a check that the host is alive."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the ErrataSubmissionForm link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Understanding Hosts, Services, and Contacts
In this chapter, we will cover the following recipes:
Introduction
Nagios Core is appropriate for monitoring services and states on all sorts of hosts and one of its primary advantages is that the configuration can be as simple or as complex as required. Many Nagios Core users will only ever use the software as a way to send PING requests to a few hosts on their local network, or possibly the Internet, and use it to send an administrator an e-mail or pager message if they don't get any replies. Nagios Core is vastly capable of monitoring more complex systems than this, scaling from simple LAN configurations to being the cornerstone for monitoring for an entire network operations team.
However, for both simple and complex configurations of Nagios Core, the most basic building blocks of configuration are hosts, services, and contacts. These are the three things that administrators of even very simple networking setups will end up editing and probably creating. If you're a beginner to Nagios Core, you might have changed a hostname here and there or copied a stanza in a configuration to get it to do what you want; in this first chapter, we're going to look at what these configurations do in a bit more depth than that.
In a Nagios Core configuration, hosts, services, and contacts are three fundamental types of objects:
In this chapter, we'll add all three of these configurations, we'll learn how to group their definitions together to make the configuration more readable, and to work with hosts in groups rather than having to edit each one individually. We'll also set up a custom time period for notifications so that hardworking system administrators like us don't end up getting paged at midnight unnecessarily!
Creating a new network host
In this recipe, we'll start with the default Nagios Core configuration and set up a host definition for a server that responds to PING on our local network. The end result will be that Nagios Core will add our new host to its internal tables when it starts up and will automatically check it (probably using PING) on a regular basis. In this example, I'll use the example of my Nagios Core monitoring server with the DNS name olympus.example.net and add a host definition for a web server with the DNS name sparta.example.net. This is all on an example network 192.0.2.0/24.
Getting ready
You'll need a working Nagios Core 4.0 or greater installation with a web interface and all the Nagios Core plugins installed. If you have not yet installed Nagios Core, you should start with the quick start guide at http://nagios.sourceforge.net/docs/nagioscore/4/en/quickstart.html that is appropriate to your operating system.
We'll assume that the configuration file Nagios Core reads on startup is at /usr/local/nagios/etc/nagios.cfg, as is the case with the default installation. It shouldn't matter where you include this new host definition in the configuration, as long as Nagios Core is going to read the file at some point. However, it might be a good idea to give each host its own file in a separate objects directory, which we'll do here. You should have access to a shell on the server and be able to write text files using an editor of your choice; I'll use vi. You will need root privileges on the server via su or sudo.
You should know how to reload Nagios Core on the server so that the configuration you're going to add gets applied. It shouldn't be necessary to restart the whole machine to do this! A common location for the startup/shutdown script on Unix-like hosts is /etc/init.d/nagios, which I'll use here. On modern GNU/Linux systems, it may be a better practice to use system nagios reload.
You should also get the hostname or IP address of the server you'd like to monitor ready. We'll use IP addresses rather than DNS hostnames here, which means that our checks will keep working even if DNS is unavailable. You may prefer to use hostnames if your addresses change regularly. You shouldn't need the subnet mask or anything like that; Nagios Core will only need whatever information the ping(8) tool would need for its own check_ping command.
Finally, you should test things first; confirm that you're able to reach the host from the Nagios Core server using ping(8) by checking directly from the shell, to make sure your network stack, routes, firewalls, and netmasks are all correct:
How to do it...
We can create the new host definition for sparta.example.net as follows:
At the end of the file, add the following line:
If the server restarted successfully, the web interface should now show a brand new host in the hosts list and a PENDING state as it waits to verify that the host is alive:
In the next few minutes, the host's background should change to green to show that the verification was complete and the host status should change to UP, assuming that the checks succeeded:
If the test failed and Nagios Core was not able to get a PING response from the target machine after three tries, for whatever reason, it would probably look something like this:
How it works...
The configuration we included in the preceding adds a host to Nagios Core's list of hosts to check, Nagios Core will periodically send a PING request to 192.0.2.21, checking whether it receives a reply, and will update the status as shown in the Nagios Core web interface appropriately. We have neither defined any other services to check for this host yet, nor have we specified what action it should take if the host is down. However, the host itself will be automatically checked at regular intervals by Nagios Core and we can view its state in the web interface at any time.
The directives we defined in the preceding configuration are as follows:
Note that we added the definition in its own file called sparta.example.net.cfg and then referred to it in the main configuration file nagios.cfg. This is simply a conventional way of laying out hosts and it happens to be a tidy way to manage things to keep definitions in their own files.
There's more...
There are a lot of other useful parameters for hosts, but the ones we've used include everything that's required.
While this is a perfectly valid way of specifying a host, it's more typical to define a host based on a template, with definitions of how often the host should be checked, who should be contacted when its state changes and on what basis, and similar properties. Nagios Core defines a simple template host called generic-host, which could be used by extending the host definition, as with the use directive:
This uses all the parameters defined for generic-host and then adds on the details of the specific host that needs to be checked. If you're curious to see what's defined in generic-host, you'll find its definition by navigating to /usr/local/nagios/etc/objects/templates.cfg.
See also
Creating a new HTTP service
In this recipe, we'll create a new service to check on an existing host. Specifically, we'll check our sparta.example.net server to verify that it's responding to HTTP requests on the usual HTTP TCP port of 80. To do this, we'll be using a predefined command called check_http, which in turn uses one of the standard set of Nagios Core plugins, also called check_http. If you don't yet have a web server defined as a host in Nagios Core, you may like to try the recipe Creating a new network host in this chapter first.
After we've done this, not only will our host be checked for a PING response with its check_command, but Nagios Core will also run a periodic check to ensure that a HTTP service on that machine is responding to requests on the same host.
Getting ready
You'll need a working Nagios Core 4.0 or greater installation with a web interface, all the Nagios Plugins installed, and at least one host defined. If you need to set up a host definition for your web server first, you might like to read the Creating a new network host recipe in this chapter, for which the requirements are the same.
It would be a good idea to test that the Nagios Core server is actually able to contact the web server first, so we know that the test we're about to set up should succeed. The telnet(1) tool is a fine way to test that a response comes back from the TCP port 80 as we would expect from a web server:
How to do it...
We can create the service definition for sparta.example.net as follows:
If the server restarted successfully, the web interface should now show you a new service under the Services section and a PENDING state as the service awaits its first check:
Within a few minutes, the service's state should change to OK once the check has run and succeeded with an HTTP/1.1 200 OK response, or a similar response:
If the check had problems, perhaps because the HTTP daemon isn't running on the target server, the check may show CRITICAL instead. This probably doesn't mean that the configuration is broken; it more likely means that the network or web server isn't working:
How it works...
The configuration we've added adds a simple service check definition for an existing host, to check up to three times whether the HTTP daemon on that host is responding to a simple HTTP/1.1 request. If Nagios Core can't get a response to its test, it will flag the state of the service as CRITICAL and will try again two more times before sending a notification. The service will be visible in the Nagios Core web interface, we can check its state any time, and Nagios Core will continue testing the server on a regular basis and flagging whether the checks were successful or not.
It's important to note that the service is like a property of a particular host; we define a service to check for a specific host; in this case, the sparta.example.net web server. That's why it's important to get the definition for host_name right.
The directives we defined in the preceding configuration are as follows:
Note that we added the service definition in the same file as defining the host, directly after it. We can actually place the definition anywhere we like, but this happens to be a good way to keep things organized.
There's more...
The service we've set up to monitor on sparta.example.net is an HTTP service, but that's just one of the many possible services we could monitor on our network. Nagios Core defines many different commands for its core plugin set, such as check_smtp, check_dns, and others; all these commands, in turn, point to the programs that actually perform the check and return the results to the Nagios Core server to be dealt with. The important thing to take away from this is that a service can monitor pretty much anything and there are hundreds of plugins available for common network monitoring checks available on the Nagios Exchange website (http://exchange.nagios.org/).
There are a great deal more possible directives for services. In practice, we often want to have a service template object with common values, and then extend it for each service we need to check. This allows us to define values that we might want for a number of services, such as how long they should be in a CRITICAL state before a notification event takes place and someone gets contacted to deal with the problem.
One such template that Nagios Core's default configuration defines is called generic-service and we can use it as a basis for our new service by referring to it with the use keyword:
This may work well for you, as there are a lot of very sensible default values set by the generic-service template, which makes things a lot easier. We can inspect these values by looking at the template's definition at /usr/local/nagios/etc/objects/templates.cfg. This is the same file that includes the generic-host definition that we may have used earlier.
See also
Creating a new e-mail contact
In this recipe, we'll create a new contact with which hosts and services can interact with each other, chiefly to inform the contact when the state of hosts or services changes. We'll use the simplest example of setting up an e-mail contact and configuring an existing host so that this contact receives an e-mail message when Nagios Core's host checks fail and the host is apparently unreachable. In this instance, we'll arrange for [email protected] to receive an e-mail message whenever the sparta.example.net host goes from the DOWN state to the UP state, or vice-versa.
Getting ready
You should have a working Nagios Core 4.0 or better server running with a web interface and at least one host to check. If you need to do this first, refer to the Creating a new network host recipe in this chapter.
For this particular kind of contact, you'll also need to have a working SMTP daemon running on the monitoring server, such as Exim or Postfix. You should verify that you're able to send messages to the target address and that they're successfully delivered to the host you expect them to be delivered to.
How to do it...
We can add a simple new contact to the Nagios Core configuration as follows:
When we are done with the preceding steps, the next time our host changes its state we should receive messages like the one shown in the following screenshot:
When the host becomes available again, we should receive a recovery message as follows:
If possible, it's worth testing this setup with a test host that we can safely bring down and then up again to verify that we receive appropriate notifications.
How it works...
This configuration adds a new contact to the Nagios Core configuration and references it in one of the hosts as the appropriate contact to be used when the host has problems.
We've defined the required directives for the contact and a couple of others:
Note that we placed the definition for the contact in contacts.cfg, which is a reasonably sensible place. However, we can place the contact definition in any file that Nagios Core will read as part of its configuration; we can organize our hosts, services, and contacts any way we like, but it helps to choose some sort of system, so we can easily identify where definitions are likely to be when we need to add, change, or remove them.
There's more...
If we define a lot of contacts with similar options, it may be appropriate to have individual contacts extend contact templates, so they can inherit those common settings. The default Nagios Core configuration includes such a template, called generic-contact. We could instead define our new contact as an extension of this template as follows:
To see the directives defined for generic-contact, you can inspect its definition in the /usr/local/nagios/etc/objects/templates.cfg file.
See also
Verifying configuration
In this recipe, you'll learn the most basic step in debugging a Nagios Core configuration, which is to verify it. This is a very useful step to take before restarting the Nagios Core server to load an altered configuration because it will warn us about possible problems. This is a good recipe to follow if you're not able to start the Nagios Core server at any point because of configuration problems and instead get output like this:
Getting ready
You should have a working Nagios Core 4.0 or better server running.
How to do it...
We can verify the Nagios Core configuration as follows:
If there's a problem of some sort, we might instead see lines like the following, which is just an example of a possible error; here, my configuration is wrong because I neglected to add a contact_name directive for a new contact:
How it works...
The configuration is parsed as though Nagios Core were about to start up, to check that the configuration all makes sense. It will run basic checks, such as looking for syntax errors, and will also check things such as having at least one host and service to monitor. Some of the things it reports are warnings, meaning that they're not necessarily problems, such as hosts not having any services monitored or not reporting to any contacts.
This is the quickest way to get an idea of whether the Nagios Core configuration is sane and will work correctly and whenever, there's trouble restarting the Nagios Core server, it's a good idea to check the output of this command.
There's more...
The program at /usr/local/nagios/bin/nagios is actually the same program that runs the Nagios Core server, but the -v part of the command is a switch for the program that, instead of starting the server, verifies the configuration and shows any problems with it. The second path is to the configuration file with which Nagios Core starts, which in turn imports configuration files for objects such as the contact, host, and service definitions.
See also
Creating a new hostgroup
In this recipe, you'll learn how to create a new hostgroup; in this case, to group two web servers together. It is useful to have distinct groups of hosts that might have different properties, such as being monitored by different teams or running different types of monitored services. It also allows us to view a group breakdown in the Nagios Core web interface and to apply a single service to a whole group of hosts rather than doing so individually. This means that all we would have to do to get a new host monitored in the same way as all the other hosts would be to add it to the group, rather than having to specify the configuration manually.
Getting ready
You should have a working Nagios Core 4.0 or better server running with a web interface.
You should also have at least two hosts that form a meaningful group; perhaps they're similar kinds of servers, such as web servers, or are monitored by the same team, or both at a physical location.
In this example, we have two web servers, sparta.example.net and athens.example.net, and we're going to add them to a group called webservers.
How to do it...
We can add our new hostgroup webservers to the Nagios Core configuration as follows:
We should now be able to visit the Host Groups section of the web interface and see a new hostgroup with two members:
How it works...
The preceding configuration that we have added includes a new file with a new hostgroup into the Nagios Core configuration and inserts appropriate hosts into the group. The hostgroup creates a separate section in the web interface for us to get a quick overview of only the hosts in that particular group.
There's more...
The way we've added hosts to the preceding groups is actually not the only way to do it. If we prefer, we can instead name the hosts for the group inside the group definition, using the members directive, so we could have something like the following:
We can also make a hostgroup that always includes every single host, if we find that useful:
If we're going to be using hostgroups extensively in our Nagios Core configuration to add hosts to groups, we should use whichever of the two methods we think is going to be easiest for us to maintain.
