1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Indirect Host and Service Checks</title>
<STYLE type="text/css">
<!--
.Default { font-family: verdana,arial,serif; font-size: 8pt; }
.PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
-->
</STYLE>
</head>
<body bgcolor="#FFFFFF" text="black" class="Default">
<p>
<div align="center">
<h2 class="PageTitle">Indirect Host and Service Checks</h2>
</div>
</p>
<hr>
<p>
<strong><u>Introduction</u></strong>
</p>
<p>
Chances are, many of the services that you're going to be monitoring on your network can be checked directly by using a plugin on the host that runs Nagios. Examples of services that can be checked directly include availability of web, email, and FTP servers. These services can be checked directly by a plugin from the Nagios host because they are publicly accessible resources. However, there are a number of things you may be interested in monitoring that are not as publicly accessible as other services. These "private" resources/services include things like disk usage, processor load, etc. on remote machines. Private resources like these cannot be checked without the use of an intermediary agent. Service checks which require an intermediary agent of some kind to actually perform the check are called <i>indirect</i> checks.
</p>
<p>
Indirect checks are useful for:
</p>
<p>
<ul>
<li>Monitoring "local" resources (such as disk usage, processer load, etc.) on remote hosts
<li>Monitoring services and hosts behind firewalls
<li>Obtaining more realistic results from checks of time-sensitive services between remote hosts (i.e. ping response times between two remote hosts)
</ul>
</p>
<p>
There are several methods for performing indirect active checks (<a href="passivechecks.html">passive checks</a> are not discussed here), but I will only talk about how they can be done by using the <a href="addons.html#nrpe">nrpe</a> addon.
</p>
<p>
<strong><u>Indirect Service Checks</u></strong>
</p>
<p>
The diagram below shows how indirect service checks work. Click the image for a larger version...
</p>
<p>
<a href="images/indirectsvccheck.png"><img src="images/indirectsvccheck.png" border=1 width=200 height=275 alt="Indirect Service Checks"></a>
</p>
<p>
<strong><u>Multiple Indirected Service Checks</u></strong>
</p>
<p>
If you are monitoring servers that lie behind a firewall (and the host running Nagios is outside that firewall), checking services on those machines can prove to be a bit of a pain. Chances are that you are blocking most incoming traffic that would normally be required to perform the monitoring. One solution for performing active checks (<a href="passivechecks.html">passive checks</a> could also be used) on the hosts behind the firewall would be to poke a tiny hold in the firewall filters that allow the Nagios host to make calls to the <i>nrpe</i> daemon on one host inside the firewall. The host inside the firewall could then be used as an intermediary in performing checks on the other servers inside the firewall.
</p>
<p>
The diagram below show how multiple indirect service checks work. Notice how the <i>nrpe</i> daemon is running on hosts #1 and #2. The copy that runs on host #2 is used to allow the <i>nrpe</i> agent on host #1 to perform a check of a "private" service on host #2. "Private" services are things like process load, disk usage, etc. that are not directly exposed like SMTP, FTP, and web services. Click on the diagram for a larger image...
</p>
<p>
<a href="images/indirectsvccheck2.png"><img src="images/indirectsvccheck2.png" border=1 width=200 height=275 alt="Multiple Indirected Service Checks"></a>
</p>
<p>
<strong><u>Indirect Host Checks</u></strong>
</p>
<p>
Indirect host checks work on the same principle as indirect service checks. Basically, the plugin used in the host check command asks an intermediary agent (i.e. a daemon running on a remote host) to perform the host check for it. Indirect host checks are useful when the remote hosts being monitored are located behind a firewall and you want to restrict inbound monitoring traffic to a particular machine. That machine (remote host #1 in the diagram below) performs will perform the host check and return the results back to the top level <i>check_nrpe</i> plugin (on the central server). It should be noted that with this setup comes potential problems. If remote host #1 goes down, the <i>check_nrpe</i> plugin will not be able to contact the <i>nrpe</i> daemon and Nagios will believe that remote hosts #2, #3, and #4 are down, even though this may not be the case. If host #1 is your firewall machine, then the problem isn't really an issue because Nagios will detect that it is down and mark hosts #2, #3, and #4 as being unreachable.
</p>
<p>
The diagram below shows how an indirect host check can be performed by using the <a href="addons.html#nrpe"><i>nrpe</i></a> daemon and <i>check_nrpe</i> plugin. Click the image for a larger version.
</p>
<p>
<a href="images/indirecthostcheck.png"><img src="images/indirecthostcheck.png" border=1 width=200 height=275 alt="Indirect Host Checks"></a>
</p>
<hr>
</body>
</html>
|
