<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>de.credativ-Blog: Kategorie Migration</title>
    <link rel="alternate" type="text/html" href="http://blog.credativ.com/de/" />
    <link rel="self" type="application/atom+xml" href="http://blog.credativ.com/de/atom.xml" />
    <id>tag:blog.credativ.com,2010-03-05:/de//1</id>
    <updated>2010-11-24T09:32:44Z</updated>
    <subtitle>All about Linux and Open Source</subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type 4.34-en</generator>

<entry>
    <title>[Howto] Nagios-OpenNMS Migration Teil 2: Passive Checks</title>
    <link rel="alternate" type="text/html" href="http://blog.credativ.com/de/2010/11/howto-nagios-opennms-migration-teil-2-passive-checks.html" />
    <id>tag:blog.credativ.com,2010:/de//1.181</id>

    <published>2010-11-24T09:34:00Z</published>
    <updated>2010-11-24T09:32:44Z</updated>

    <summary>Dies ist der zweite Teil unseres Migrations-Howtos für Netzwerk-Überwachungs-Systeme von Nagios nach OpenNMS. Nachdem im ersten Teil die Integration von aktiven Nagios-Checks via NRPE (Nagios Remote Plugin Executor) diskutiert wurde, wenden wir uns in diesem zweiten Teil den passiven Nagios-Checks...</summary>
    <author>
        <name>Michael Banck</name>
        
    </author>
    
        <category term="Howto" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Migration" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Open Source" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="credativ" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="nagiosopennmsmigrationhowto" label="nagios opennms migration howto" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="de" xml:base="http://blog.credativ.com/de/">
        <![CDATA[<a href="http://blog.credativ.com/de/migration.png"><img alt="migration.png" src="http://blog.credativ.com/de/assets_c/2010/07/migration-thumb-150x134-74.png" width="120" height="107" class="mt-image-right" style="float: right; margin: 0 0 20px 20px;" /></a><em>Dies ist der zweite Teil unseres Migrations-Howtos für Netzwerk-Überwachungs-Systeme von Nagios nach OpenNMS. Nachdem im <a href="http://blog.credativ.com/de/2010/10/howto-migration-von-nagios-zu-opennms.html">ersten Teil</a> die Integration von aktiven Nagios-Checks via NRPE (Nagios Remote Plugin Executor) diskutiert wurde, wenden wir uns in diesem zweiten Teil den passiven Nagios-Checks durch NSCA (Nagios Service Check Acceptor) zu.</em>

<h3>Passive Nagios-Checks</h3>

Da es momentan keine spezielle <a href="http://www.opennms.org/wiki/Main_Page">OpenNMS</a>-Unterstützung für passive NSCA-Checks
gibt, müssen diese durch andere Mechanismen abgebildet werden. In diesem Howto
verwenden wir für jeden passiven NSCA-Check einen eigenen Service, dessen
Status durch externe Benachrichtigung geändert wird und der durch den
<tt>PassiveStatusKeeper</tt>-Mechanismus von OpenNMS überwacht wird.

<h4>Einbinden der Nagios SNMP-Trap Informationen</h4>

Für die sinnvolle Behandlung von SNMP-Traps wird eine Registrierung des
jeweiligen MIBs  (Management Information Base) als OpenNMS-Event benötigt.
OpenNMS kennt zwar von Haus aus eine Vielzahl von SNMP-Traps, die aus dem <a
href="http://sourceforge.net/projects/nagiosplug/files/nagiosmib/1.0.1/nagiosmib-1.0.1.tar.gz/download">Nagios-MIB</a>
sind jedoch nicht darunter. Die benötigte <tt>Nagios.events.xml</tt> Datei
wurde aus dem MIB <a
href="http://bugzilla.opennms.org/show_bug.cgi?id=3646">erstellt</a> und muss
in das <tt>events/</tt>-Unterverzeichnis der OpenNMS Konfiguration kopiert
werden und in der <tt>eventconf.xml</tt> Datei via
<tt>&lt;event-file&gt;events/Nagios.events.xml &lt;/event-file&gt;</tt>
eingebunden werden. Der in der Nagios-MIB definierte SNMP-Trap für Service-Events ist
<tt>nSvcEvent</tt>, welcher als numerische OID (Object Identifier) den Code
<tt>.1.3.6.1.4.1.20006.1.7</tt> besitzt.

<h4>Benachrichtigungen via SNMP-Trap</h4>

Das für passive NSCA-Checks verwendete Programm <tt>send_nsca</tt> kann etwa
durch folgendes Shell-Skript ersetzt werden, welches die Benachrichtigung von
OpenNMS via snmptrap durchführt:

<pre class='brush: plain'>
  #!/bin/bash

  SNMPTRAP=/usr/bin/snmptrap
  COMMUNITY=public

  while getopts &quot;H:d:p:&quot; OPTION; do
    case $OPTION in
      H) HOST=$OPTARG;;
      d) DELIM=$OPTARG;;
      p) PORT=$OPTARG;;
      *) ;;
    esac
  done

  if [ &quot;x$DELIM&quot; == &quot;x&quot; ]; then
    DELIM=&quot;\t&quot;
  fi

  if [ &quot;x$HOST&quot; == &quot;x&quot; ]; then
    echo &quot;No host defined, exiting&quot;
    exit
  fi

  array=(`awk -F&quot;$DELIM&quot; '{for(i=1;i&lt;=3;i++){print $i};
                    for(i=4;i&lt;=NF;i++){gsub(/ /,&quot;_&quot;,$i); print $i}}'`);
  NODE=${array[0]}
  SERVICE=${array[1]}
  STATUS=${array[2]}
  REASON=`echo ${array[3]} | sed s/_/\ /g`&quot;'&quot;

  $SNMPTRAP -v 2c -c $COMMUNITY $HOST '' NAGIOS-NOTIFY-MIB::nSvcEvent \
    NAGIOS-NOTIFY-MIB::nHostname s &quot;$NODE&quot; \
    NAGIOS-NOTIFY-MIB::nHostStateID i 0 \
    NAGIOS-NOTIFY-MIB::nSvcDesc s &quot;$SERVICE&quot; \
    NAGIOS-NOTIFY-MIB::nSvcStateID i &quot;$STATUS&quot; \
    NAGIOS-NOTIFY-MIB::nSvcAttempt i 1 \
    NAGIOS-NOTIFY-MIB::nSvcDurationSec i 1 \
    NAGIOS-NOTIFY-MIB::nSvcGroupName s &quot;&quot; \
    NAGIOS-NOTIFY-MIB::nSvcLastCheck i 0 \
    NAGIOS-NOTIFY-MIB::nSvcLastChange i 0 \
    NAGIOS-NOTIFY-MIB::nSvcOutput s &quot;$REASON&quot;
</pre>

Das Skript versteht die beiden <tt>nsca_send</tt> Optionen <tt>-H</tt> (Host)
und <tt>-d</tt> (Feldtrenner). <tt>$HOST</tt> ist dabei der OpenNMS-Server, für
den die Benachrichtigung vorgesehen ist. Der awk-Befehl zerteilt den per
Feldtrenner separierten NSCA-String (z.B. „<tt>postgres-test; Vaccuum;0;Vaccuum
OK 1276511175</tt>&#8220;) in seine Bestandteile, welche den Variablen
<tt>$NODE</tt>, <tt>$SERVICE</tt>, <tt>$STATUS</tt> und <tt>$REASON</tt>
zugeteilt werden. Diese werden schließlich beim Aufruf von snmptrap den
<tt>nSvcEvent</tt> Parametern <tt>nHostname</tt>, <tt>nSvcDesc</tt>,
<tt>nSvcStateID</tt> und <tt>nSvcOutput</tt> zugeteilt.  Den übrigen Parametern
<tt>nHosteStateID</tt>, <tt>nSvcAttempt</tt>, <tt>nSvcDurationSec</tt>,
<tt>nSvcGroupName</tt>, <tt>nSvcLastCheck</tt> und <tt>nSvcLastChange</tt>
werden allgemeine Werte zugeteilt, da sie bei  der Umsetzung des
<tt>nSvcEvent</tt>-Traps in ein OpenNMS-Event keine Rolle spielen und auch beim
Aufruf von <tt>send_nsca</tt> nicht bekannt sind. Damit die Parameter des <tt>nSvcEvent</tt>-Traps von <tt>snmptrap</tt> aufgelöst werden können, muss das NAGIOS-MIB der Net-SNMP-Installation bekannt sein.

<h4>Umwandlung von Traps in Events</h4>

Die eingehenden SNMP-Traps werden in OpenNMS-Events vom Typ <tt>nSvcEvent</tt> umgewandelt. Um diese nun einzelnen Nagios-Checks bzw. OpenNMS-Services zzuuweisen, müssen sie vom <tt>translatord</tt>-Dämon in <tt>passiveServiceStatus</tt> Events umgewandelt werden. Folgender Abschnitt ist hierfür in der Datei <tt>translator-configuration.xml</tt> nötig:

<pre class='brush: plain'>
&lt;event-translation-spec 
  uei=&quot;uei.opennms.org/vendor/nagios/traps/nSvcEvent&quot;&gt;
    &lt;mappings&gt;
      &lt;mapping&gt;
        &lt;assignment type=&quot;parameter&quot; name=&quot;passiveNodeLabel&quot;&gt;
          &lt;value type=&quot;parameter&quot; 
            name=&quot;.1.3.6.1.4.1.20006.1.1.1.2&quot; 
            matches=&quot;.*&quot; 
            result=&quot;${0}&quot; 
          /&gt;
        &lt;/assignment&gt;
        &lt;assignment type=&quot;parameter&quot; name=&quot;passiveIpAddr&quot;&gt;
          &lt;value type=&quot;field&quot; 
            name=&quot;interface&quot; 
            matches=&quot;.*&quot; 
            result=&quot;${0}&quot;
          /&gt;
        &lt;/assignment&gt;
        &lt;assignment type=&quot;parameter&quot; name=&quot;passiveServiceName&quot;&gt;
          &lt;value type=&quot;parameter&quot; 
            name=&quot;.1.3.6.1.4.1.20006.1.3.1.6&quot; 
            matches=&quot;.*&quot; 
            result=&quot;${0}&quot; 
          /&gt;
        &lt;/assignment&gt;
        &lt;assignment type=&quot;parameter&quot; name=&quot;passiveStatus&quot;&gt;
          &lt;value type=&quot;sql&quot; 
            result=&quot;SELECT CASE WHEN ?::integer = 0  
                                     THEN 'Up'        
                                     ELSE 'Down' 
                                     END;&quot; &gt;  
            &lt;value type=&quot;parameter&quot; 
              name=&quot;.1.3.6.1.4.1.20006.1.3.1.7&quot; 
              matches=&quot;.*&quot; 
              result=&quot;${0}&quot; 
            /&gt;
          &lt;/value&gt;
        &lt;/assignment&gt;
        &lt;assignment type=&quot;parameter&quot; name=&quot;passiveReasonCode&quot;&gt;
          &lt;value type=&quot;parameter&quot; 
            name=&quot;.1.3.6.1.4.1.20006.1.3.1.17&quot; 
            matches=&quot;.*&quot; 
            result=&quot;${0}&quot; 
          /&gt;
        &lt;/assignment&gt;
        &lt;assignment type=&quot;field&quot; name=&quot;uei&quot;&gt;
          &lt;value type=&quot;constant&quot; 
            result=&quot;uei.opennms.org/services/passiveServiceStatus&quot; 
          /&gt;
        &lt;/assignment&gt;
      &lt;/mapping&gt;
    &lt;/mappings&gt;
&lt;/event-translation-spec&gt;
</pre>

Die <tt>uei</tt> in der zweiten Zeile bezeichnet dabei den SNMP-Trap, wie er in der
jeweiligen events-XML Datei angegeben ist. Die Parameter
<tt>passiveNodeLabel</tt>, <tt>passiveServiceName</tt>, <tt>passiveStatus</tt>
und <tt>passiveReasonCode</tt> werden aus den jeweiligen Parametern
<tt>$NODE</tt>, <tt>$SERVICE</tt>, <tt>$STATUS</tt> und <tt>$REASON</tt> des
SNMP-Traps übernommen. Für die Ermittlung von <tt>passiveStatus</tt> ist dabei
eine SQL-Abfrage nötig, um je nach Nagios-Status ein "Up" oder "Down" zu
senden. Die IP-Adresse kann direkt aus dem "<tt>interface</tt>"-Feld des Events
übernommen werden. Schließlich wird in der letzten Zuordnung die OpenNMS UEI (Unique Event Identifier) von <tt>nSvcEvent</tt> nach <tt>passiveServiceStatus</tt> umgewandelt.

<h4>Einbinden von Passiven Checks als Services</h4>

Passive NSCA-Checks können naturgemäß nicht mit capsd entdeckt werden, deshalb
müssen sie per <tt>LoopPlugin</tt> für jede betreffende Node per <tt>ip-match</tt>
Property in der <tt>capsd-configuration.xml</tt> Datei aktiviert werden:

<pre class='brush: plain'>
    &lt;protocol-plugin 
      protocol=&quot;NSCA-check1&quot; 
      class-name=&quot;org.opennms.netmgt.capsd.plugins.LoopPlugin&quot;
      scan=&quot;on&quot;&gt;
        &lt;property key=&quot;ip-match&quot; value=&quot;192.168.178.158&quot; /&gt;
        &lt;property key=&quot;ip-match&quot; value=&quot;172.16.17.213&quot; /&gt;
        &lt;property key=&quot;is-supported&quot; value=&quot;true&quot; /&gt;
    &lt;/protocol-plugin&gt;
</pre>

Dabei bezeichnet <tt>protocol</tt> den Namen des betreffenen OpenNMS-Service.
<p>
Zusätzlich ist auch ein entsprechender Poller in
<tt>poller-configuration.xml</tt> nötig, zum einen der
<tt>&lt;service&gt;</tt>-Anker:

<pre class='brush: plain'>
    &lt;service name=&quot;NSCA-check1&quot; 
      interval=&quot;30000&quot; 
      user-defined=&quot;false&quot; 
      status=&quot;on&quot;&gt;
    &lt;/service&gt;
</pre>

Sowie schließlich ein <tt>PassiveServiceMonitor</tt>: 

<pre class='brush: plain'>
&lt;monitor service=&quot;NSCA-check1&quot; 
  class-name=&quot;org.opennms.netmgt.poller.monitors.PassiveServiceMonitor&quot;
/&gt;
</pre>

Mit diesen Änderungen und nach einem Neustart von OpenNMS sollten die
NSCA-Checks für die entsprechende Node im OpenNMS-Webinterface erscheinen und
sich wie normale OpenNMS Dienste in Bezug auf Ausfälle etc. verhalten.]]>
        
    </content>
</entry>

<entry>
    <title>[Howto] Migration von Nagios zu OpenNMS</title>
    <link rel="alternate" type="text/html" href="http://blog.credativ.com/de/2010/10/howto-migration-von-nagios-zu-opennms.html" />
    <id>tag:blog.credativ.com,2010:/de//1.169</id>

    <published>2010-10-19T08:54:00Z</published>
    <updated>2010-10-21T08:45:07Z</updated>

    <summary>Hier bei credativ setzen wir bevorzugt Nagios für das Monitoring ein, aber wenn es die Richtilinien bei Kunden verlangen, arbeiten wir natürlich auch mit anderen Überwachungs-Systemen. Dieses Howto beschreibt die Integration von aktiven und passiven Nagios-Checks in ein OpenNMS-System, so...</summary>
    <author>
        <name>Michael Banck</name>
        
    </author>
    
        <category term="Howto" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Migration" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Open Source" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="credativ" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="nagiosopennmsmigrationhowto" label="nagios opennms migration howto" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="de" xml:base="http://blog.credativ.com/de/">
        <![CDATA[<img alt="migration.png" src="http://blog.credativ.com/de/assets_c/2010/07/migration-thumb-150x134-74.png" width="120" height="107" class="mt-image-right" style="float: right; margin: 0 0 20px 20px;" /><em>Hier bei credativ setzen wir bevorzugt Nagios für das Monitoring ein, aber wenn es die Richtilinien bei Kunden verlangen, arbeiten wir natürlich auch mit anderen
Überwachungs-Systemen. Dieses Howto beschreibt die Integration von aktiven und
passiven Nagios-Checks in ein OpenNMS-System, so dass zwar die entwickelten Checks weiter verwendet, der Nagios-Server aber abgeschaltet werden kann.</em>

<h3>Einleitung</h3>

 <a
href="http://www.opennms.org/wiki/Main_Page">OpenNMS</a> ist ein Open-Source Netzwerk-Monitoring-System. Es ist in Java
geschrieben und benutzt PostgreSQL als Datenbank. Die Konfiguration erfolgt
über XML-Dateien, teilweise (vor allem Reports, Benachrichtigungen usw.) auch
über die Web-Oberfläche. OpenNMS ist relativ stark auf SNMP fokussiert, vor
allem was das Sammeln von Performance-Daten angeht. Ob Rechner (oder Dienste
auf Rechnern) erreichbar sind, kann jedoch auch einfach anderweitig abgefragt
werden.
<br />
Dieses Howto behandelt die Migration eines Netzwerk-Überwachungs-Systems von
<a href="http://www.nagios.org/">Nagios</a>/<a href="http://www.icinga.org/">Icinga</a> zu OpenNMS.  Für aktive Nagios-Checks beruht diese Migration auf dem
NRPE Plugin (Nagios Remote Plugin Executor), welches von der stabilen
OpenNMS-Version bereits unterstützt wird. Es erfordert also ein bereits
vorhandenes NRPE-Setup für Nagios, bzw. eine Migration des Nagios-Setups zu
NRPE.  Passive Nagios-Checks via NSCA (Nagios Service Check Acceptor) werden
durch SNMP-Traps in OpenNMS integriert und bedürfen keiner Änderung auf der
Nagios-Seite, lediglich das <tt>send_nsca</tt>-Skript muss zentral ausgetauscht werden.
Die Sammlung und Bearbeitung von Performance-Daten ist mit diesem Howto
nicht möglich, hierfür wäre eine Erweiterung der OpenNMS Code-Basis nötig.

<h3>Aktive Nagios-Checks</h3>

Die aktiven NRPE-Checks werden durch den OpenNMS Service <tt>pollerd</tt>
ersetzt. Dieser stellt das Modul <tt>NrpeMonitor</tt> zur Verfügung, welches im
Prinzip dazu gedacht ist, einen NRPE-Service auf einem der bekannten Rechner zu
überwachen. Dazu wird alle 5 Minuten (dieser Wert ist für jeden Dienst einzeln
konfigurierbar) versucht, den NRPE-Dämon zu erreichen, wobei im Normalfall der
Befehl „<tt>_NRPE</tt>&#8220; abgefragt wird, welcher vom NRPE-Dämon als
Spezialfall aufgefasst wird und bei normalen Betrieb ein „<tt>OK</tt>&#8220;
und die Versionsnummer von NRPE zurück liefert.
<br />
Alternativ kann jedoch in der Konfigurations-Datei des pollerd ein beliebiges
Kommando für den NRPE-Dämon eingestellt werden, z. B. <tt>check_load</tt>. Wenn
dieses Kommando dem NRPE-Dämon bekannt ist, wird es ausgeführt und liefert den
üblichen Nagios-Status zurück (<tt>OK</tt> mit Rückgabewert 0, <tt>WARNING</tt>
mit Rückgabewert 1, <tt>CRITICAL</tt> mit Rückgabewert 2 oder <tt>UNKNOWN</tt>
mit Rückgabewert 3) sowie die Performance-Daten, welche jedoch momentan vom
<tt>pollerd</tt> bzw. OpenNMS nicht ausgewertet werden.
<br />
Um die bestehenden Nagios-Checks in OpenNMS abzubilden, wird für jeden bisher verwendeten aktiven Nagios-Check ein NRPE-Service in OpenNMS definiert. Diese werden dann unabhängig voneinander in OpenNMS geführt. Hierfür sind zwei Konfigurations-Dateien von OpenNMS zu ändern:

<ul>
<li>Die Datei <tt>capsd-configuration.xml</tt> bestimmt, auf welche Dienste ein
Rechner vom OpenNMS Service <tt>capsd</tt> beim Scannen untersucht werden soll.</li>

<li>Die Datei <tt>poller-configuration.xml</tt> bestimmt, welche bzw. in
welcher Art die vom <tt>capsd</tt> gefundenen Dienste vom <tt>pollerd</tt>
überwacht werden sollen.</li>
</ul>

Aus Sicherheitsgründen sollten dem NRPE-Dämon keine variablen Parameter
übergeben werden; die Abfrage des gleichen Checks mit verschiedenen Parametern
oder Schwellen-Werten sollte also als jeweils unterschiedliche Checks in NRPE
definiert werden.

<h4>Anpassung der capsd Konfiguration</h4>

Für jeden NRPE-Check muss ein neuer protocol-plugin Abschnitt in
<tt>capsd-configuration.xml</tt> definiert werden. Der <tt>class-name</tt> ist
dabei stets <tt>org.opennms.netmgt.capsd.plugins.NrpePlugin</tt>, normalerweise
müssen lediglich die Werte für protocol und der für das Attribut
„<tt>command</tt>&#8220;  angepasst werden.  Ein Beispiel wäre:

<pre class='brush: plain'>
    &lt;protocol-plugin 
      protocol=&quot;NRPE-load&quot; 
      class-name=&quot;org.opennms.netmgt.capsd.plugins.NrpePlugin&quot; 
      scan=&quot;on&quot;&gt;
        &lt;property key=&quot;banner&quot; value=&quot;*&quot; /&gt;
        &lt;property key=&quot;port&quot; value=&quot;5666&quot; /&gt;
        &lt;property key=&quot;timeout&quot; value=&quot;3000&quot; /&gt;
        &lt;property key=&quot;retry&quot; value=&quot;2&quot; /&gt;
        &lt;property key=&quot;command&quot; value=&quot;check_load&quot; /&gt;
    &lt;/protocol-plugin&gt;
</pre>

Der Wert für „<tt>protocol</tt>&#8220; bezeichnet den Dienst, wie er intern
bzw. im Web-Interface von OpenNMS geführt werden soll. Das Attribut
„<tt>port</tt>&#8220; bezeichnet den Port, auf dem der NRPE-Dämon zu erreichen
ist, der Standard hierfür ist 5666. Das Attribut „<tt>command</tt>&#8220;
bezeichnet den vom NRPE-Dämon auszuführenden Check, wie er in
<tt>/etc/nagios/nrpe.cfg</tt> (oder evtl. <tt>/etc/nagios/nrpe_local.cfg</tt>)
definiert ist. In diesem Fall wird der übliche Nagios-Check
„<tt>check_load</tt>&#8220; für die Überprüfung der System-Auslastung in Bezug
auf die Anzahl der laufenden Prozesse ausgeführt.
<br />
Zu beachten ist hierbei, dass OpenNMS vor Version 1.6.9 nicht genauer den
Rückgabewert prüft und im Falle eines Checks, der nicht ein „<tt>OK</tt>&#8220;
(sondern vorübergehend ein „<tt>WARNING</tt>&#8220; oder
„<tt>CRITICAL</tt>&#8220;) zurück gibt den jeweiligen Check nicht erkennt.
Hierfür wurde von uns ein Patch entwickelt, welcher ab Version 1.6.9 in OpenNMS
enthalten ist. Falls eine frühere Version von OpenNMS eingesetzt wird, kann das
Problem durch eine temporäre Anpassung der Schwellen-Werte in der
NRPE-Konfigurations-Datei auf dem jeweiligen Rechner behoben werden, so dass
zum Zeitpunkt der Erkennung NRPE den Dienst als „<tt>OK</tt>&#8220; ansieht.
<br />
Falls in einem großen Rechner-Netzwerk eine Prüfung auf eine potentiell große
Anzahl von NRPE-Checks nicht im allgemeinen erwünscht ist, können diese auch
auf ein einzelnes Netzwerk-Segment oder einen IP-Bereich beschränkt werden.
Dazu wird die Beispiel-Konfiguration in einen protocol-configuration Abschnitt
eingebettet:

<pre class='brush: plain'>
    &lt;protocol-plugin 
      protocol=&quot;NRPE-load&quot; 
      class-name=&quot;org.opennms.netmgt.capsd.plugins.NrpePlugin&quot; 
      scan=&quot;off&quot;&gt;
        &lt;protocol-configuration scan=&quot;on&quot; user-defined=&quot;false&quot;&gt;
        &lt;range begin=&quot;192.168.178.0&quot; end=&quot;192.168.178.254&quot;/&gt;
        &lt;specific&gt;10.0.0.2&lt;/specific&gt;
        &lt;specific&gt;10.0.0.7&lt;/specific&gt;
        &lt;property key=&quot;banner&quot; value=&quot;*&quot; /&gt;
        &lt;property key=&quot;port&quot; value=&quot;5666&quot; /&gt;
        &lt;property key=&quot;timeout&quot; value=&quot;3000&quot; /&gt;
        &lt;property key=&quot;retry&quot; value=&quot;2&quot; /&gt;
        &lt;property key=&quot;command&quot; value=&quot;check_load&quot; /&gt;
        &lt;/protocol-configuration&gt;
    &lt;/protocol-plugin&gt;
</pre>

Wichtig ist hierbei der Tag <tt>&lt;range begin=&#8220;$IP_ADRESSE&#8220;
end=&#8220;$IP_ADRESSE&#8220;/&gt;</tt>, welcher den IP-Bereich definiert.
Alternativ können auch über
<tt>&lt;specific&gt;$IP_ADRESSE&lt;/specific&gt;</tt> Tags bestimmte
IP-Adressen festgelegt werden.  Durch die Option <tt>scan=
&#8220;off&#8220;</tt> in der ersten Zeile wird auf allen anderen Rechnern
nicht auf diesen Check geprüft.
<br />
Nach der Änderung von <tt>capsd-configuration.xml</tt> ist ein Neustart von
OpenNMS nötig; alternativ (ein OpenNMS-Neustart kann je nach Größe des überwachten Netzwerks eine längere Zeit dauern) kann der <tt>capsd</tt>-Daemon per JMX RPC neu gestartet werden:

<pre class='brush: plain'>
for i in stop init start; do
  wget --proxy=off -O /dev/null \
&quot;http://manager:manager@localhost:8181/invoke?objectname=OpenNMS%3AName%3DCapsd&amp;operation=$i&quot;; 
done
</pre>

Wenn die Änderung hauptsächlich für einen bestimmten Rechner veranlasst wurde
und sofort aktiv sein soll, muss für diesen Rechner ein „Rescan&#8220;
ausgeführt werden; entweder per Web-Interface oder mit Hilfe des
<tt>send-event.pl</tt> Skripts, welches das entsprechende Event
(<tt>forceRescan</tt>) an OpenNMS (auf localhost laufend) übermittelt:

<pre class='brush: plain'>
send-event.pl uei.opennms.org/internal/capsd/forceRescan localhost --interface 10.0.0.2
</pre>

<h4>Anpassung der pollerd Konfiguration</h4>

Die Konfigurations-Datei für den <tt>pollerd</tt>-Service muss für jeden
NRPE-Check an zwei Stellen geändert werden; zum einen muss ein
<tt>&lt;service&gt;</tt> Absatz hinzugefügt werden, in dem der zu überwachende
Service ähnlich wie in der capsd-Konfigurationsdatei definiert wird, außerdem
muss eine <tt>&lt;monitor service=[...]/&gt;</tt> Zeile eingefügt werden um die
Überwachung des jeweiligen Services zu aktivieren. Analog zu dem Beispiel im
letzten Abschnitt wäre dies etwa folgendes:

<pre class='brush: plain'>
    &lt;service name=&quot;NRPE-load&quot; 
      interval=&quot;300000&quot; 
      user-defined=&quot;false&quot; 
      status=&quot;on&quot;&gt;
        &lt;parameter key=&quot;retry&quot; value=&quot;3&quot; /&gt;
        &lt;parameter key=&quot;timeout&quot; value=&quot;3000&quot; /&gt;
        &lt;parameter key=&quot;port&quot; value=&quot;5666&quot; /&gt;
        &lt;parameter key=&quot;command&quot; value=&quot;check_load&quot; /&gt;
        &lt;parameter key=&quot;padding&quot; value=&quot;2&quot; /&gt;
    &lt;/service&gt;
</pre>

Jeweils zu ändern sind auch hier die Angaben für „<tt>service name</tt>&#8220;
und der Parameter „<tt>command</tt>&#8220;. Die Option
„<tt>interval</tt>&#8220; gibt das Überwachungs-Intervall in Millisekunden an,
der Standard-Wert ist hier üblicherweise 300000, was 5 Minuten entspricht.  Die
entsprechende Zeile für die Aktivierung des <tt>NrpeMonitor</tt> ist 

<pre class='brush: plain'>
&lt;monitor service=&quot;NRPE-load&quot; 
 class-name=&quot;org.opennms.netmgt.poller.monitors.NrpeMonitor&quot; 
/&gt;
</pre>

Auch beim Ändern der Datei <tt>poller-configuration.xml</tt> ist ein Neustart
von OpenNMS nötig, bzw. ein analoger Aufruf der RPCs wie im letzten Abschnitt,
mit <tt>Pollerd</tt> statt <tt>Capsd</tt> als Argument:

<pre class='brush: plain'>
for i in stop init start; do
  wget --proxy=off -O /dev/null \
&quot;http://manager:manager@localhost:8181/invoke?objectname=OpenNMS%3AName%3DPollerd&amp;operation=$i&quot;; 
done
</pre>

Im demnächst folgenden zweiten Teil dieses Howtos wird die Integration von passiven Nagios-Checks behandelt.]]>
        
    </content>
</entry>

</feed>

