OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by Holger Koch

Nürnberg, 23.10.2013
DB Systel
Holger Koch
holger.koch@deutschebahn.com
10 Jahre Monitoring
mit Open Source Software bei der DB Systel

2DB Systel | Holger Koch | holger.koch@deutschebahn.com | 23.10.2013
1.
2.
3.
4.
5.
Vorstellung
Einführung von Nagios
Update Falle
Monitoring 2.0
Zusammenfassung/Fragen
Inhalt

1.
2.
3.
4.
5.
Vorstellung
Update Falle
Monitoring 2.0
Inhalt

Der Vortragende
Über mich:
 Holger Koch
 Mitarbeiter DB Systel –
„Strategy & Consulting, System Design (I.LVD 83)“
 Meine Aufgabengebiete
– Automatisierung
– Monitoring
– Förderung des Einsatzes von Open Source Software und
Techniken

Wir sind:
 3.100 Mitarbeiter an den drei Standorten Frankfurt/Main, Berlin und Erfurt
Wir betreiben:
 2 Rechenzentren mit über 3.300 Servern
 Datennetz mit rund 340.000 IP-Anschlüssen von DSL bis Breitband-Glasfaser
 Rund 500 produktive IT-Verfahren
 1,5 Petabyte Plattenspeicher / 4,5 Petabyte Backup-Kapazität
 bundesweit das digitale Funknetz der Bahn (GSM-R)
Wir betreuen bei der Bahn:
 80.000 Nutzer des Bürokommunikationssystems der Bahn
 92.000 VoIP-Anschlüsse
(Stand: Juni 2012)
DB Systel – Das Unternehmen
Der Auftrag
Daten & Fakten
5
Foto: DB Systel
5

Personenverkehr
 2,7 Milliarden Reisende mit Bahn und Bus pro Jahr
 26.000 Personenzüge pro Tag
 1-mal um die Welt fährt jeder ICE in Deutschland umgerechnet pro Monat
Netze
 5.700 Bahnhöfe
 33.600 km Streckennetz – 3-mal so lang wie die deutschen Autobahnen
 72.000 Weichen/Kreuzungen
 5-größter Stromversorger in Deutschland
Transport & Logistik
 412 Millionen Tonnen beförderte Güter auf der Schiene pro Jahr
 1,2 Million Tonnen Luftfrachtvolumen pro Jahr
 1,6 Millionen TEU1 Seefrachtvolumen pro Jahr
 96 Millionen Sendungen im europäischen Landverkehr pro Jahr
 Über 5 Millionen Quadratmeter Lagerfläche weltweit
Die Deutsche Bahn AG – Daten und Fakten
Geschäftsfelder in Zahlen (Stand 2012)
6
Foto: Roland Horn
1) Twenty-foot Equivalent Unit = Containereinheit

1.
2.
3.
4.
5.
Vorstellung
Update Falle
Monitoring 2.0
Inhalt

Zeitlicher Ablauf
 04/2003 IBM Tivoli nicht als Monitoring Plattform verwendbar
 05/2003 erster (inoffizieller) Nagios basierter Prototyp für die
Überwachung von INet Komponenten

Wie kam Nagios zur DB? – Architekturbild 01/2004
Architektur
Redundante
Auslegung =
hohe
Verfügbarkeit
Überwachung von
DMZ + GSB in
München und
Berlin sowie K2
Netz

Hostmatrix ca. 2005
Hostmatrix:
 Darstellung aller definierten Host in einer
Übersicht
 Zu jedem Host werden die Anzahl der ok,
warning und critical Checks angezeigt
 Durch einen Klick auf den jeweiligen Host
erscheint eine Liste mit sämtlichen Services
die auf der jeweiligen Maschine definiert
wurden

Verfahrensmatrix ca. 2005
Verfahrensmatrix:
Ähnlich der Hostmatrix
Sie gibt eine Übersicht aller Verfahren
Bei grün hinterlegten Verfahren sind alle
Tests positiv verlaufen
Bei Rot hinterlegten Verfahren ist
mindestens ein definierter Service im
Status „Critical“

Verfahrensübersichtsseite, ca. 2004
Verfahrensübersicht:
 Übersicht über alle
Services, die zu einem
bestimmten Verfahren
gehören
 Zusätzlich können durch
den Klick auf „Graph“ die
Performancedaten zu dem
jeweiligen Service
angezeigt werden

Zeitlicher Ablauf
 05/2004 erweiterte Funktionen wie Nagvis, Alarmierung per
Telefon und TEC, eigene Views usw. verfügbar

Visualisierung von Performancedaten, ca. 2004
Performance – Weblogic
 Die Graphen zeigen z.B.
den verbrauchten Speicher:
(grün = freier Speicher, gelb
= genutzer Speicher)
 Verschiedene Linien
definieren Warning und
Critical Werte; die blaue
Abschlusslinie kennzeichnet
den maximal zur Verfügung
stehenden Speicher
 Die Graphen zeigen alles
von der letzten Stunde bis
zu den letzen sechs
Monaten
 Engpässe lassen sich schon
vor Eintreten von Abstürzen
erkennen

Skriptheader "process_perfdatad"
#!/bin/bash
#
# Daemon um Performance Daten auszuwerten und in rrd's zu schreiben
#
# Das ist die normale Version, um Performance zu sparen, wurde auf alle DEBUG
# Ausgaben verzichtet.
#
# holgerkoch.de 980 6435
#
# Changelog:
# 0.1 Initial Release 10.5.2004
# 0.2 Update auf rrdtool 1.0.49 21.4.2005
# 0.3 Update auf rrdtool 1.2.23 03.07.2007
# Spaltennamen durchnummerieren, um Fehler bei gleichen Namen zu vermeiden
# Performance Improvement
# groessere Datanbasis, 1 Jahr
# 0.4 Entfernen aller DEBUG Ausgaben um Performance zu sparen 07.01.2008
# 0.5 Aufsplittung in Daemon und Worker fuer mehr Performance 22.04.2009
# 0.6 Pipe nur einmal oeffnen 02.06.2009
# 0.7 Workaround fuer Bash Bug 08.07.2009
#
############################################################################

Nagvis
Grafische Darstellung
 Schneller Überblick über
ein komplettes Verfahren
 Die grünen Hacken
werden zu blinkend
roten Kreuzen bzw.
gelben Fragezeichen
sobald ein Problem
besteht
 Anhand der
Architekturzeichnung
lassen sich Folgefehler
sofort erkennen
 Im oberen Teil ist das
Betriebsführungshand-
buch verlinkt, was einen
schnellen Zugriff auf alle
wichtigen Informationen
erlaubt

Skriptheader Nagvis
###################################################################
## NagVis ##
## Autor von NagVis 0.0.3: Jörg Linge <pichfork@ederdrom.de> ##
## ##
## Umgschrieben von Perl in PHP by Michael Lübben(MiCkEy2002) ##
## ##
## Lizenz GPL ##
###################################################################

Zeitlicher Ablauf
 03/2005 Nagios wird Mandantenfähig

Standardisierung Servicedescription
 Notwendigkeit mehrere Mandanten voreinander abzuschotten
 Aufbau der Servicedescription wird standardisiert:
<verfahren>_<mandant>_<umgebung>_<check>_<port>_<desc>
Verfahren: alphanummerisch, max. 8 Zeichen
Mandant: inet, sap, notes, zao, rv
Umgebung: p, a, e, s
Check: tcp, http, jmem,…
Port: Portnummer des Checks, ansonsten leer
desc: Freitextfeld, möglichst kurz, möglichst aussagekräftig
Beispiel: ecm_inet_p_tcp_44433_ tomcat_strang1

Verfahrensmatrix, ca. 2005
 Jeder Mandant hat eine einfache Übersicht über
seine Verfahren
 geordnet nach Umgebungen
 einfache Visualisierung der Anzahl und Zustände
der Checks eines Verfahrens
 wenn die Alarmierung für mindestens einen
Check deaktiviert ist, dann wird der Hintergrund
grau hinterlegt
 durch Klick auf Verfahrensname gelangt man zur
Verfahrensübersichtsseite

Verfahrensübersichtsseite 1/2, ca. 2005

Verfahrensübersichtsseite 2/2, ca. 2005
Verfahrensübersichtsseite
 generierte Seite pro Mandant,
Verfahren und Umgebung
 Management Funktionen um
einzelne oder alle Checks des
Verfahrens zu bearbeiten

1.
2.
3.
4.
5.
Vorstellung
Update Falle
Monitoring 2.0
Inhalt

Upgrade Falle status.log Format
AZUBILINUX-Server
status.log Format Nagios 1.X
 alle Status Informationen in einer Datei
 jeweils eine Zeile pro Service und Host
 Semikolon als Trenner
 einfach zu parsen
[1379673459]SERVICE;tiefurt;nagios_inet_p_tcp_44412_nsca_server_dillenburg;OK;1/10;HAR
D;1379673295;1379673435;PASSIVE;0;1;1;1377106440;0;OK;130601497;0;0;39675;0;0;1;168;
5;1;0;0.00;0;1;1;0;TCP OK - 0.013 second response time on port 44412 [[2B]

AZUBILINUX-Server
Service Lines:
[Time of last update] SERVICE;
Host Name (string);
Service Description (string);
Status (OK/WARNING/CRITICAL/UNKNOWN);
Retry number (#/#);
State Type (SOFT/HARD);
Last check time (long time);
Next check time (long time);
Check type (ACTIVE/PASSIVE);
Checks enabled (0/1);
Accept Passive Checks (0/1);
Event Handlers Enabled (0/1);
Last state change (long time);
Problem acknowledged (0/1);
Last Hard State (OK/WARNING/CRITICAL/UNKNOWN); ……………

AZUBILINUX-Server
 sehr viele Skripte parsen notwendige Informationen direkt aus der status.log Datei
Beispielsweise:
check_aktiv-passiv,
check_aktuell,
check_flapping,
check_freshness,
check_health_dinslaken,
gen_header,
gen_hostmatrix,
gen_serviceproblems,
gen_verfahrensmatrix_inet,
uvm.

AZUBILINUX-Server
status.dat Format Nagios 2.X
 Strophenbasierte Speicherung von Status Informationen
 keine feste Anzahl von Zeilen pro Strophe
 es wurde ein Tool geschaffen, um das neue Format in das alte zu überführen

Upgrade – Warum?
AZUBILINUX-Server
Upgrade – Warum?
 es war kein maßgeblicher Vorteil von Nagios 2.X erkennbar
 hoher Aufwand für Migration aller Tools, Skripte, Patches, eigener Views usw.
 unser Monitoring passte wie ein Maßanzug
Von 2006-2013 nur marginale Anpassungen und Betriebsführung.
Trotzdem keine nennenswerten Ausfälle!!!

1.
2.
3.
4.
5.
Vorstellung
Update Falle
Monitoring 2.0
Inhalt

Monitoring 2.0
 Druck zur Erneuerung des Monitorings
wurde immer größer
 Kunden forderten immer mehr Funktionen
für Verlaufsmonitoring
 Speicherung von Informationen in
RRD DB‘s nicht mehr zeitgemäß
 Reporting schwer realisierbar
 altes Monitoring hatte immer häufiger
Performanceprobleme

Zeitlicher Ablauf
 01/2012 Arbeiten an Monitoring2.0 beginnen

Verwendete Technik 1/2
 Icinga:
 Jeder Mandant bekommt seine eigene Icinga Infrastruktur
 lokale Speicherung von Checkergebnissen, mittels rsync verteilt
 über Verlinkungen und Skripte wird einfache Betriebs-
führbarkeit sichergestellt
 Icinga-Web:
 Alle Informationen der einzelnen Icinga Instanzen laufen in einer
Icinga Web DB zusammen
 Entwicklung von DB spezifischen Anpassungen durch Netways

Verwendete Technik 2/2
 Lconf:
 Transparenzschicht für Produkt unabhängiges, graphisches
Modellieren von Checks
 viele Anpassungen vorgenommen für produktiven Einsatz
 Erstellung von Check Bundels und Verlinkungssystem für
standardisierte Überwachung von Komponenten
 Ingraph:
 Speicherung aller Performance Werte in MySQL DB
 einfaches Reporting mit Jaspersoft möglich
 Nagvis:
 Kopplung des Rechtesystems über Views in Icinga-Web DB

Monitoring 2.0 - Architektur

Zeitlicher Ablauf
 01/2012 Arbeiten an Monitoring2.0 beginnen
 09/2013 Produktivgang

Mandantenmatrix

Verfahrenssicht

Basisüberwachung

ButtonPortal

Wiki-Integration

Knowledge Base

1.
2.
3.
4.
5.
Vorstellung
Update Falle
Monitoring 2.0
Inhalt

Zusammenfassung
Monitoring mit Nagios/Icinga
 Extrem flexible und stabile Plattform
 beliebig anpassbar und erweiterbar an eigene Anforderungen
 Speziell bei Icinga-Web und LConf noch „Schwächen“ bei
Stabilität und Performance
 Sehr guter Support in Deutschland erhältlich
Gewinn für die DB
 Ideale Plattform für:
- Verlaufs- und Verfügbarkeitsmonitoring
- Reporting
- sehr große Monitoring Umgebung durch Skalierbarkeit
auf allen Ebenen

Fragen oder Anregungen ... ?
Vielen Dank für Ihre Aufmerksamkeit!
Tel. +49 361 300 5957
Mobil +49 151 628 45 902
holger.koch@deutschebahn.com
DB Systel GmbH
Schlachthofstraße 80
99098 Erfurt
www.dbsystel.de
Holger Koch
I.LVD83

OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by Holger Koch

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by Holger Koch

Ähnlich wie OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by Holger Koch (20)

OSMC 2013 | 10 Jahre Monitoring mit Open Source Software bei der DB Systel by Holger Koch