OSMC 2009 | Erfahrungen bei der Migration einer kommerziellen Monitoringsuite zu Nagios bei Audi by Eric Pfaller

Erfahrungen bei der Migration einer kommerziellen
Monitoringsuite zu Nagios @ Audi
Eric Pfaller, 28.10.2009

2 Eric Pfaller, AUDI AG; 28. Oktober 2009
Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
4 Projektziele und Entscheidung für Nagios
5 Realisierung der Umstellung
6 Schnittstellen in PSC-K
7 Fazit

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

Die Marke Audi
HochwertigSportlich
Progressiv
Vorsprung durch Technik

AUDI AG - Wir über uns
• Die AUDI AG hat im Jahr 2008 insgesamt 1.003.450 Automobile der Marke Audi
verkauft und damit das 13. Rekordjahr in Folge erzielt.
• Audi produziert an den Standorten Ingolstadt und Neckarsulm (Deutschland), Gyır
(Ungarn), Changchun (China), Brüssel (Belgien), Bratislava (Slowakei) und
Aurangabad (Indien).
• 100-prozentige Töchter der AUDI AG sind unter anderem die Automobili
Lamborghini S.p.A. (Sant’Agata Bolognese/Italien) und die quattro GmbH
(Neckarsulm).
• Audi beschäftigt weltweit mehr als 57.000 Mitarbeiter, davon 46.000 in
Deutschland.
• Um den „Vorsprung durch Technik“ nachhaltig zu sichern, investiert Audi jedes Jahr
mehr als 2 Mrd. Euro, gefördert werden insbesondere die Bereiche Elektroantrieb,
Aluminium-Leichtbau und neue Werkstoffe sowie TDI und TFSI-Antrieb.
• Bis 2015 will Audi die Anzahl seiner Modelle auf 40 erweitern.

Der Audi Konzern - Kennzahlen
Veränderung
in %
20072008
Auslieferungen
•Marke Audi Fahrzeuge 1.003.469 964.151 + 4,1
•Marke Lamborghini Fahrzeuge 2.430 2.406 + 1,0
Mitarbeiter Durchschnitt 57.533 53.347 + 7,8
Umsatzerlöse Mio. EUR 34.196 33.617 + 1,7
Operatives Ergebnis Mio. EUR 2.772 2.705 + 2,5
Ergebnis vor Steuern Mio. EUR 3.177 2.915 + 9,0
Ergebnis nach Steuern Mio. EUR 2.207 1.692 + 30,4

AUDI AG - Standorte
Ingolstadt
Neckarsulm
Bratislava
Changchun
Aurangabad
Györ
Sant‘Agata
Brüssel

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

Verantwortung der Audi IT
Ingolstadt
• ca. 26.000 PC Anwender
• 1 Prod.-Rechenzentrum
• 32.600 Mitarbeiter
Neckarsulm
Györ
Brüssel
Sant‘Agata
• ca. 620 PC Anwender
5
Rechenzentren
ca. 55.100
Mitarbeiter
ca. 40.500
PC Anwender

IT-Kennzahlen (I/II)
Serversysteme
Anzahl virtuell Anzahl physisch
Unix 64 201
CAx - Server
CAx - Cluster
CAx – Workstations*
13
31
0
36
1318
671
SAP 0 36
Webcenter 7 513
p5-570/DWH 143 20
Windows-Server 220 605
Mainframe LPARS 10 2
Gesamt* ∑∑∑∑ 488 ∑∑∑∑ 2.731
* CAx – Workstations in der Gesamtserveranzahl nicht berücksichtigt.

Backbone LAN 2 x 4 GB
Netz nach Wolfsburg 2 x 1 GB
Benutzerkennungen
Windows User ca. 45.000
Mail-Accounts ca. 42.500
Netzwerk-Bandbreiten
Speichersysteme (Bruttokapazitäten)
SoD (SAN, NAS) 1.186 TB
Datensicherung 1.436 TB
HSM 1.135 TB
Gesamt ∑∑∑∑ 3.757 TB
IT-Kennzahlen (II/II)

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

Ausgangssituation
Eingesetzte Monitoring-Produkte
• IBM Tivoli* (seit Mitte der 90er Jahre) – Überwachung Server und
Applikationen
• Tivoli Management Framework 4.1.1
• IBM Tivoli Enterprise Console 3.9
• IBM Tivoli Monitoring 5.1.2
• IBM Tivoli Monitoring for Business Integration – WebSphere MQ
• IBM Tivoli Monitoring for Databases (Oracle)
• Tivoli Distributed Monitoring 3.7
• CA SPECTRUM* – Netzwerk-Monitoring
• CA EHealth* – historisches Reporting
• HP Business Availability Center* – E2E Monitoring
* Geschützte Marken

Ausgangssituation
Handlungsbedarf Tivoli
• Tivoli Distributed Monitoring 3.7 ist OutOfSupport
• Neue Betriebssysteme wie AIX 6, W2k8, W2kx 64-bit sind mit
eingesetzter Software nicht komplett überwachbar
• Hohe Migrationsaufwände für neues Tivoliprodukt IBM Tivoli
Monitoring V6

Ausgangssituation
Erwarteter Umfang
alt neu
Ca. 2000 Hosts
17.000 – 20.000
Servicechecks
Erwarteter Umfang
Nagiosinstanz aus Piloten
mit Produktion
1200 Hosts
5000 Servicechecks
Ca. 800 Hosts
60 Logadapater
Ca. 300 Monitoringprofile
Tivoliumgebung

Ausgangssituation
Schnittstellen und Views
• Integrationsfähigkeit des „neuen“ Systems in bestehende IT-Landschaft
• Integration in SPECTRUM (Incident-/ Problem-/ Changemanagement-Prozess)
• Integration HP Business Availability Center
• Verteilte Zuständigkeiten und verschiedene Standorte detaillierte Views
nötig
• Control Center als erste Anlaufstelle für Eskalationen
• Middleware-Administratoren (MQ, DB2, Oracle und zugehörige Server)
• Web-Administratoren (Webseitenchecks)
• SAP-Administratoren (SAP und zugehörige Server)
• Produktionssteuerung (AIX/FIS Server)
• Unix/Linux und UPSMON Administratoren
• Wintel (Windowsserver)
Große, inhomogene Umgebung mit unterschiedlichen Zuständigkeiten

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

Projektziele
• Überwachung der Server auf Open Source Basis
• Integration der gesetzten Monitoring-Tools
• Schaffung eins datenbankgestützten Monitoring-Portals
• Ermöglichen der notwendige Views
• Schlankes, zuverlässiges System
• Geringer Wartungsaufwand
• Müheloses Sammeln von Performancedaten einfache Reportingmöglichkeit
• Reduzierung von Wartungs- und Lizenzkosten
• Ermöglichen einer Distributed Monitoring-Umgebung
• ITIL Integration – Schnittstelle für Incident-/ Problemmanagement
• Einsatz von „SPECTRUM One-Click“ als Eventkonsole des Control Centers

Entscheidungskriterien für Nagios
• 80- 90 % aller Anforderungen mit minimalen Aufwand erfüllbar
• Plattformunabhängigkeit
• Anbindung an bestehende Systeme vorhanden
• Customscripte abbildbar
• Bereits im Einsatz, Konsolidierung
• Monitoring mit „kleinen“ Agenten oder Agentless möglich (z.B. per SSH)
• Out of the box verwendbar sowie flexibel erweiterbar
• Hohe Produktstabilität
• Schnelle Implementierung
• Open Source

Projektlaufzeit
Projektlaufzeit Oktober 2008 – Juni 2010
10/08
Deaktivierung
der „alten“
Monitor-Strukturen
Detailanaylse
incl.
Ausschreibung
Beginn
Dienstleitung
AIX
Basis-
agenten
Windows
Basisagent
► Migration bestehende Nagiosinstanz
► Monitoring Portal
► Migration Applikationsmonitoring
► Schnittstellendesign
► Deaktivierung Tivoliagenten
03/09 06/09 06/10
Projekt-
auftrag

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

Realisierung
Sizing „Distributed Nagios-Umgebung“
• 1 Mastercluster
• 2x HP DL380 G5 (2*XEON E5430 2.66 GHz Quadcore), 8 GB RAM
• 2*146 GB Lokale Platten
• SAN 300 GB über 2*Emlx LP1150
• RHEL 5, Veritasclustersoftware
• 3 Slavecluster
• 1 Test-/Integrationsumgebung

Realisierung
Serverarchitektur
Client-/Serverkommunikation
• Unix/Linux SSH
• Wintel NSClient++ Port 5666
Server/Serverkommunikation
• SSH

Realisierung
Eingesetzte Software – Serverseitig
• Nagios 3.0.6 ( Versionsstand wg. „telefonierst du nach Hause“)
• Icinga Webfrontend
• Netways Grapher V2
• MySQL 5.0.45
• Open-LDAP 2.3.43 Server für die Vorhaltung der Objektdefinitionen und
Objektkonfigurationen
• Subversion 1.4.2 zur Versionierung von …
… Nagios-Paketen (Nagiosserver)
… Nagios-Plugins (Unterschiedliche OS-Versionen und Versionsstände vorhanden)
… Nagios-Konfiguration (Objektdefinition zusätzl. zum LDAP-Backup zur
Gewährleisung der Revisionssicherheit)

Realisierung
Clientfunktionalitäten (I/II)
• Für Windows-Systeme NSCLient++ (Version 0.3.6)
• Integriertes Strawberry Perl für Custom-Scripte
• Versionsinformationen und Serverinformationen serverseitig abrufbar
• Updatemechanismen Serverseitig steuerbar
• Durchführung der Updates der Windows Agenten über einen mehrstufigen
Prozess
• Dieses Verfahren ist notwendig um ein automatisiertes Aktualisieren
möglich zu machen
• Hierbei werden folgende Schritte sequentiell ausgeführt:
• Initialisierung des Updates an zentraler Stelle mittels NRPE
• Ausführen des Kopiervorgangs mittels CIFS von Agentenrepository
• Planung/ Ausführung des Updatejobs

Realisierung
Clientfunktionalitäten (II/II)
• Unix und Linux-Derivate
• Überwachung „Agentless“ mit Public bzw. Privatkey mittels SSH (check_by_ssh)
• Versionsinformationen und Serverinformationen serverseitig abrufbar
• Updatemechanismen serverseitig steuerbar
Standard OS-Bordmittel via SSH

Realisierung
Verteiltes Monitoring (I/II)
• Authentifizierung über Windows Active Directory
• Austausch der Config-Files
• Export nötiger Config-Dateien zu einzelnen Monitoringknechten bei Config-
Generierung
• Austausch der Monitoringergebnisse
• Probleme beim Austausch der Checkergebnisse via NSCA bei „normalen“
Lastverhalten auf einzelnen Slaves
• Servicelatency „explodiert“
NSCA benötigt mehr Zeit
Differgenz einzelner Timestamps der Servicechecks vom Master zu den Slaves

Realisierung
Verteiltes Monitoring (II/II)
► Austausch der Monitoringergebnisse (Alternative)
► Nutzung der „performance-data“ Funktion auf Slaves
► Import Checkergebnisse der Slaves auf Mastercluster:
Perldaemon auf Masterserver, der zeitgesteuert (30s) die Daten per
SSH abholt und mittles „nagios.cmd“ die Daten Masterseitig pushed
Vorteile:
Latencyreduzierung
Zentrale Konfiguration masterseitig (NSCA-Lösung – Slaveseitig)

Realisierung
Erstellung und Pflege Nagios-Config
• Anforderungen
• Vererbung
• Sowohl per Script als auch per GUI steuerbar und konfigurierbar
• Automatische Generierung skriptbasiert
• Definition von Standards und detaillierte Ausnahmen
• Definition von verschiedene Zuständigkeiten
• Open-Source
• Standards
Verschiedene Verantwortlichkeiten für
Server, Betriebssysteme und Applikationen
Server 1 Server 2 Server 3
Appl. 1
Appl. 2
Appl. 3
Appl. 1
Appl. 2
Appl. 3
Appl. 1
Appl. 2
Appl. 3

Realisierung: Spezielle Plugins
• check_cache
• Performanceoptimierung und Lastverringerung auf Nagios-Servern
• Plugin-Aufrufe werden konsolidiert und zwischengespeichert
Serverseitig konfiguierbares Plugin (keine Konfiguration auf Client nötig)
Minimaler Konfigurationsaufwand
Transparente Verwendung von check_cache
Konstanter Plugin-Output (steht nach check_cache weiter zur Verfügung)
Kein Verlust von Performancedaten
Konfigurierbares Cache-Verhalten
• check_logfiles für Logfile-Monitoring (inkl. Abbildung der Tivolieigenen Formatfiles in
check_logfiles konformes Format)
• check_oracle_health
• Eigenentwicklung für das Filesystem-Monitoring, Loadüberwachung auf AIX
Systemen Pflege der Schwellwerte (Monitoring und Loadverhalten) durch Admins

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

PSC-K Schnittstellen
Troubleticketing (I/II)
► Zuweisungsgruppe
► Severity
► SCIM / CI /
Servicerequest
► Beschreibung /
Eskalationsinfos für CC
DB2
DB
► Aktuelle Zuweisungs-
gruppe
► Journal Updates - zu
evaluieren -
► Aktueller Status
Flexible
Steuerung
der Incident-
generierung
und
Eventanreicherung
pro Überwachungs-
szenario
NAGIOS
PSC-K

Troubleticketing (II/II)
► Gründe für eine Datenbank
► Historie über Eskalationen
► Update von Einträgen in Nagios und PSC-K möglich
► Entscheidung für DB2
► Definierte Standards bei Audi
► Garantierte Verfügbarkeit im Hinblick auf SLAs
► Verlagerung der Wartung und Pflege zu Serviceprovidern

Sicht des Monitoring
• Derzeitige Implementierung – IST Zustand
• Tivoli ↔ PSC-K
• Mailschnittstelle
• Zukunft – SOLL Zustand
• SPECTRUM ↔ PSC-K
• SPECTRUM ↔ Nagios
• Technische Details
• Übersicht OPEN
• Übersicht CLOSE Incident in PSC-K
• Übersicht Monitoring-System meldet Zustand wieder OK
• SNMP-Trap basiert

Technische Details – Übersicht OPEN
• Szenario OPEN
1. Nagios meldet Event an SPECTRUM oder SPECTRUM-Event
2. Klick auf Troubleshooter in SPECTRUM erzeugt Datenbank-Insert in DB2 DB
(Automatisches Öffnen bei speziell gekennzeichneten Events muss gegeben sein)
3. PSC-K holt sich neue Einträge aus DB2 DB Ticketeröffnung in PSC-K
4. PSC-K liefert Status, Ticketnummer und Eröffner an DB zurück
5. SPECTRUM holt Ticket-Werte aus DB
6. Rückmeldung der Informationen an Nagios
PSC-KSPECTRUMNagios
1. SNMP-Trap
DB2-
DB
4. DB-Update
2. DB-Insert 3. Generierung Ticket
5.6.

Technische Details – Übersicht CLOSE
• Szenario CLOSE
1. Nach CLOSE Incident veranlasst PSC-K einen Datenbank-Update
2. Die DB2-Datenbank übergibt die Werte (Ticket-Bearbeiter) an SPECTRUM; Event
in SPECTRUM wird geschlossen
3. SPECTRUM meldet Zustand an Nagios zurück; Service/Host-Check wird auf OK
gesetzt
PSC-KSPECTRUMNagios DB2-
DB
1. DB-Update2.3.

Technische Details – Meldung Zustand OK
• Szenario Zustand wieder OK & Incident vorhanden
1. Nagios-Event: Nagios sendet Trap an SPECTRUM = „Clear“ Alarm wird gelöscht
2. UPDATE des Incidents in DB2 DB „Monitoringsystem cleared the event at
dd.mm.yyyy hh:mm“
3. Meldung Zustand OK „Close Ticket“ Ticket wird in PSC-K geschlossen
PSC-KSPECTRUMNagios
1. SNMP-Trap
DB2-
DB
2. Update 3. Close Ticket

Technische Details – SNMP Trap Aufbau (I/III)
Traps, die von Nagios zu SPECTRUM gesendet werden, sind je nach Fehlerart fest
definiert und haben einen generischen Teil gemeinsam.
SPECTRUMNagios
1. SNMP-Trap

► Trap mit zugehöriger OID sendet Variablen mit Varbind
► Hostchecks
Varbind1=NAGIOS-NOTIFY-MIB::nHostname s
Varbind2=NAGIOS-NOTIFY-MIB::nHostStateID i
Varbind3=NAGIOS-NOTIFY-MIB::nHostOutput s
► Servicechecks i.d.R.
Varbind1=NAGIOS-NOTIFY-MIB::nSvcHostname s
Varbind2=NAGIOS-NOTIFY-MIB::nSvcDesc s
Varbind3=NAGIOS-NOTIFY-MIB::nSvcStateID i
Varbind4=NAGIOS-NOTIFY-MIB::nSvcOutput s
Technische Details – SNMP Trap Aufbau (II/III)

► Definition für Steuerung der PSC-K Schnittstelle und INFO
► PSC Schnittstelle(Auszug)
varbind40= __SC_ASSIGNMENT (Zuweisungsgruppe, default „CC OPERATING AUDI
IN“ bzw. „CC OPERATING AUDI NE“)
varbind47= __SC_SEVERITY (Severity in SC, default 3 bei produktiven, 4 bei
Testsystemen)
varbind48= __SC_DESCRIPTION (Incident description, Skript erlaubt flexibles
Zusammenbauen, Default z.B.
…
Host/Servicecheckname: Output
Host, HostIP
Hostgroup
Status
DATE (now)
Detailinformation:
Last Check:
…
Technische Details – SNMP Trap Aufbau (III/III)

Agenda
1
2
Die AUDI AG
IT im Konzern
3 Ausgangssituation
7 Fazit

► Stabile Monitoringumgebung
► Im Einsatz befindliche Customscripte lassen sich mit geringem Aufwand
migrieren
► Anpassung Output und Returncode
► Automatische Configgenerierung aus LDAP
► Schnittstellendesign über Standards realisiert
► Wenig Probleme bei der Migration
► Performanceschwierigkeiten bei verteilter Monitoringumgebung
Fazit

Vielen Dank.

OSMC 2009 | Erfahrungen bei der Migration einer kommerziellen Monitoringsuite zu Nagios bei Audi by Eric Pfaller

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2009 | Erfahrungen bei der Migration einer kommerziellen Monitoringsuite zu Nagios bei Audi by Eric Pfaller

Ähnlich wie OSMC 2009 | Erfahrungen bei der Migration einer kommerziellen Monitoringsuite zu Nagios bei Audi by Eric Pfaller (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

OSMC 2009 | Erfahrungen bei der Migration einer kommerziellen Monitoringsuite zu Nagios bei Audi by Eric Pfaller