sein, wenn man solche Ohren hat. Monitoring von Web-Anwendungen Provisioning HTTP und DNS Services Lab: Provisioning Web-Server Lab: HTTP Monitoring verbessern Lab: Web-UI kennen lernen 3 / 49
Eigene Events in OpenNMS einbinden Was sind Events Wie werden sie verwaltet Wozu können Sie verwendet werden. Lab: Eigene Events anlegen Lab: Events mit send-event.pl erzeugen 5 / 49
in OpenNMS einbinden Aktives überwachen mit OpenNMS Passives überwachen mit Net-SNMP und Traps Lab: Konfiguration mit Threshold Lab: Konfiguration mit SNMP traps 6 / 49
Netzwerk-Geräte als Node bezeichnet. Ein Node ... kann ein physikalische oder logische Komponente in einem Netzwerk sein. ist bspw. physikalisch als Server, Switch oder Router modelliert. ist bspw. logisch als hochverfügbarer Router mit virtuellen IP Adressen oder als Web-Seite modelliert. hat IP-Netzwerkschnittstellen kann physikalisch Schnittstellen haben wie bspw. Switch mit Ethernet ports ohne IP’s ist eindeutig über eine Node-ID identifiziert. hat Events, Notifications und Alarms kann Inventarinformationen wie bspw. Seriennumer, Modellnummer, Inventarnummer oder den Standort besitzen. 8 / 49
Nodes im Monitoring interessiert, weil sie wertvolle Services bereitstellen. Ein Service in OpenNMS ... wird von einer IP-Adresse bereitgestellt wird von Pollerd getestet und als verfügbar oder nicht verfügbar angezeigt. dient als Einstiegspunkt für die Leistungsdatenerfassung. hat Events, Notifications und Alarms wird von einer Service-ID eindeutig identifiziert. 9 / 49
Möglichkeiten ihr Netzwerk abzubilden Nodes, Assetinformation, Interfaces und Services Das Bereitstellen von Nodes, Interfaces, Services und Assets im Netzwerk-Monitoring wird provisioning bezeichnet. Provisioning hat verschiedene Ansätze:(vollautomatisch, halb-automatisch oder komplett manuell) 10 / 49
Monitorig the Web-Anwendung auf vic.labmonkeys.de und www.google.de Einfache HTTP Verbindung HTTP error code auswertbar Regexp nach Inhalt in der Seite suchen 18 / 49
Group für Web-Seiten anlegen Zwei Nodes mit der Bezeichnung www.google.de und vic.labmonkeys.de anlegen. (Node label) www.google.de interface 173.194.44.56 hinzufügen vic.labmonkeys.de interface 83.169.39.12 hinzufügen Beide als snmp-primary setzen HTTP und ICMP auf die beiden Interfaces manuell setzen. Requisition Group importieren. WebUI prüfen. Wie ist der Status? 20 / 49
Monitoring Konfiguration und VHost macht es notwendig, dass für jeden VHost ein Monitor angelegt werden muss :/ host-name muss dynamisch gesetzt werden. Optionale Unterscheidung zwischen IPv4 und IPv6 PageSequenceMonitor for the win ... 24 / 49
benachrichtigen wenn etwas schief läuft. Benachrichtigungen werden von events erzeugt. Notifd ist die Komponente in OpenNMS die Benachrichtigungen versendet. Files für Benachrichtigungen sind: /etc/opennms/notifd-configuration.xml /etc/opennms/notifications.xml /etc/opennms/notificationCommands.xml /var/log/openmms/daemon/log/notifd.log 27 / 49
können über verschiedene Protokolle versendet werden. Die Protokolle können erweitert werden. Beispiel: eMail, Jabber, Asterisk Anruf Benachrichtigungen können an Benutzer und Gruppen gesendet werden. Diese Einstellungen werden als Destination Path bezeichnet. Benachrichtigungen können eskaliert werden. Benachrichtigungen können verzögert werden. 28 / 49
benachrichtigen lassen. Einrichten einer Benachrichtigungsverzögerung von 5 min. Benachrichtigung nur von komplettem Node down einrichten. Bestätigen von Benachrichtigungen Benachrichtigungszeitplan für Benutzer 30 / 49
Änderungen im System werden von Events initiiert. Diese Events können von den folgenden Komponenten erzeugt werden: OpenNMS selbst im Monitoring, bspw. Pollerd (NodeDown, NodeLostService, InterfaceDown), Collectd (Threshold exceeded) Externe logging Protokolle wie Syslog und SNMP-Traps werden in Events umgewandelt. Externe Anwendungen über TCP 5817 und XML Daten oder send-event.pl 33 / 49
Events in OpenNMS werden über einen Unique Event Identifier (UEI) identifiziert. Sie beschreiben und klassifizieren ein Event z.B.: uei.opennms.org/nodes/nodeDown uei.opennms.org/nodes/interfaceDown uei.opennms.org/nodes/nodeLostService Events von externen Quellen wie bspw. Syslog oder SNMP traps müssen UEI zugewiesen bekommen. 34 / 49
1 <event> 2 <uei>uei.opennms.org/nodes/nodeLostService</uei> 3 <event-label>OpenNMS-defined node event: nodeLostService</event-label> 4 <descr> <p>A %service% outage was identified on interface %interface%. 5 </p> 6 <p>A new Outage record has been created and service level 7 availability calculations will be impacted until this outage is 8 resolved.</p> 9 </descr> 10 <logmsg dest="logndisplay">%service% outage identified on interface %interface% 11 with reason code: %parm[eventReason]%. 12 </logmsg> 13 <severity>Minor</severity> 14 <alarm-data reduction-key="%uei%:%dpname%:%nodeid%:%interface%:%service%" 15 alarm-type="1" auto-clean="false"/> 16 </event> 36 / 49
1 <event> 2 <uei>uei.opennms.org/nodes/nodeRegainedService</uei> 3 <event-label>OpenNMS-defined node event: nodeRegainedService</event-label> 4 <descr> <p>The %service% service on interface %interface% was previously down 5 and has been restored.</p> 6 <p>This event is generated when a service which had previously failed 7 polling attempts is again responding to polls by OpenNMS. </p> 8 <p>This event will cause any active outages associated with this 9 service/interface combination to be cleared.</p> 10 </descr> 11 <logmsg dest="logndisplay">The %service% outage on interface %interface% 12 has been cleared. Service is restored. 13 </logmsg> 14 <severity>Normal</severity> 15 <alarm-data 16 reduction-key="%uei%:%dpname%:%nodeid%:%interface%:%service%" 17 alarm-type="2" 18 clear-key="uei.opennms.org/nodes/nodeLostService:%dpname%:%nodeid%:%interface%:%service %" 19 auto-clean="false"/> 20 </event> 37 / 49
<UEI> [host] [options] 2 3 the UEI is a required field! 4 Usage: ./send-event.pl <UEI> [host] [options] 5 6 Options: 7 8 <UEI> the universal event identifier (URI) 9 [host[:port]] a hostname to send the event to (default: localhost) 10 --version, -V print version and exit successfully 11 --verbose, -v print the raw XML thats generated 12 --help, -h this help message 13 14 --timezone, -t the time zone you are in 15 --service, -s service name 16 --nodeid, -n node identifier (numeric) 17 --interface, -i IP address of the interface 18 --descr, -d a description for the event browser 19 --logmsg, -l a logmsg for the event browser (secure field by default) 20 . 21 . 22 . 40 / 49
eines eigenen "down" events. Bitte vergewissern, dass alarm-data mit angegeben ist. Erstellen eines eigenen "up" events. Dieses Event löst das vorher gehende Event auf. Sicherstellen dass die Events korrekt verwendet werden Test zum überschreiben der severity und der logmsg 42 / 49
Web UI sicher stellen, dass das Event unter "Events" als auch unter "Alarms" angezeigt wird. Das Event "down" wiederholt senden. Es sollte in "Events" zweimal und in den "Alarms" einmal angezeigt werden. Senden des "down" Event mit anderer Severity: send-event.pl -x 7 uei.opennms.org/class/downTest Sicherstellen, Alarm sollte immer noch einmal angezeigt werden. Senden des "up" Event mit: send-event.pl uei.opennms.org/class/upTest Event in der "Event-Liste" und den Alarm prüfen 30 Sekunden warten und refresh des Alars. Was passiert? 45 / 49
fast voll sind, reagieren Anwendungen oft nicht mehr oder werden sehr langsam. Es gibt verschiedene Varianten diese Ziel zu erreichen: Aktiv: OpenNMS zeichnet Plattenfüllstand auf und misst gegen einen Schwellwert Polling mit einem Monitor gegen den Füllstand und als Service abbilden. Passiv: Net-SNMP agent sendet uns einen SNMP-Trap 46 / 49
indigo
cmusudakeisuke
msato
hogelog
kazuhitotakahashi
.jpeg){kind=avatar}
ostk0069
niwatakeru
kazzpapa3
iotengineer22
shimastripe
oracle4engineer
lycorp_recruit_jp
kamina_zzz
trallard
sonatard
jponch
malarkey
notwaldorf
aarron
chriscoyier
csswizardry
phodgson
62gerente
mclloyd
keavy
