Echtzeit-Monitoring durch verteilte Logdatei-Analyse Diplomarbeit zur Erlangung des Grades eines Diplom-Medieninformatikers der Fakultät für Informatik der Technischen Universität Dresden vorgelegt von Lars Kreisz Geb. am: 29. Januar 1986 in: Elsterwerda Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Betreuer: Dr.-Ing. Stephan Groß Dipl.-Inf. Oliver Stache Dresden, den 29. September 2011
Inhaltsverzeichnis 1 Einleitung 1 1.1 Motivation............................. 1 1.2 Anwendungsfälle......................... 1 1.2.1 Info-Screens im Unternehmensnetz........... 2 1.2.2 Video-Streaming im Unternehmensnetz......... 3 1.2.3 Öffentliche Video-Plattform............... 3 1.3 Ziel................................. 4 1.4 Aufbau der Arbeit........................ 5 2 Grundlagen 7 2.1 Monitoring............................. 7 2.1.1 Daten: Transient vs. Persistent............. 7 2.1.2 Ausführung: Reaktiv vs. Proaktiv............ 8 2.1.3 Übertragung: Push vs. Pull............... 9 2.1.4 Monitoringprogramme.................. 10 2.2 Logdateien............................. 14 2.2.1 W3C Logdateiformat-Standards............. 14 2.2.2 Proxy- und Cache-Logdateien.............. 17 2.2.3 Analyse und Aggregation von Logdateien........ 17 2.2.4 Logdateianalysewerkzeuge................ 18 2.3 Visualisierung statistischer Daten................ 20 2.3.1 Skalenniveau....................... 21 2.3.2 Diagrammtypen...................... 22 2.3.3 Visualisierungsbibliotheken................ 24 3 Ziele 29 3.1 Anforderungen.......................... 29 3.1.1 Monitoring eines InfoScreen-Netzwerks......... 29 3.1.2 Echtzeit-Nutzerstatistiken von Videostreams...... 29 3.1.3 Nichtfunktionale Anforderungen............. 30 3.2 Bewertung betrachteter Lösungen................ 30 3.2.1 Monitoringprogramme.................. 30 3.2.2 Logdateianalysewerkzeuge................ 31 3.2.3 Visualisierungsbibliotheken................ 32
4 Konzept 35 4.1 Sammeln der Daten........................ 36 4.1.1 Messung.......................... 36 4.1.2 Aggregation........................ 37 4.1.3 Kontrollfluss........................ 39 4.2 Datenhaltung........................... 43 4.2.1 Datenstruktur....................... 43 4.2.2 Größe und Wachstum des Messdatenbestands..... 45 4.3 Datenzugriff............................ 45 4.3.1 Statistiken......................... 46 4.3.2 Visualisierung....................... 48 4.3.3 Ereignisorientierte Benachrichtigung.......... 49 5 Implementierung 51 5.1 Django............................... 51 5.1.1 Erweiterbare Architektur................. 51 5.1.2 Model-Abstraktion und Validierung........... 53 5.1.3 Template-Engine..................... 54 5.1.4 Kommandos........................ 54 5.2 Sammeln der Daten........................ 55 5.2.1 Struktur.......................... 55 5.2.2 Instanziierung....................... 56 5.2.3 Kollektoren........................ 57 5.2.4 Rezeptoren........................ 58 5.2.5 Agenten.......................... 58 5.3 Datenzugriff............................ 61 5.3.1 Statistiken......................... 61 5.3.2 Ereignisbehandlung.................... 64 5.4 Zusammenfassung......................... 65 6 Validierung und Diskussion 67 6.1 Umsetzung der Anforderungen.................. 67 6.1.1 Monitoring eines InfoScreen-Netzwerks......... 67 6.1.2 Echtzeitnutzerstatistiken von Videostreams....... 68 6.1.3 Nichtfunktionale Anforderungen............. 68 6.2 Fehleranfälligkeit......................... 69 6.3 Skalierbarkeit........................... 70
7 Zusammenfassung 73 A Konfigurationen der Anforderungen 75 A.1 Statistiken der Cache-Proxys im InfoScreen-Netzwerk..... 75 A.1.1 Cacheeffizienz....................... 75 A.1.2 Email-Benachrichtigung bei invaliden Requests..... 76 A.1.3 Arbeitsspeicherauslastung................ 77 A.2 Nutzerstatistiken von VideoStreams............... 78 A.2.1 Anzahl der Nutzer und Netzwerkbandbreite pro Standort 78 B Tabellen 80 C Abbildungen 80 D Referenzen 81
1 Einleitung 1.1 Motivation In Netzwerken von Unternehmen mit mehreren Standorten kommen zur Lastverteilung oftmals Cache-Systeme zum Einsatz, da die Bandbreite des Netzwerks zwischen den Standorten in der Regel um ein Vielfaches geringer ist, als die des standortinternen Netzwerks. Anwendungen sollen die Kommunikation zwischen den Standorten effizient gestalten. Darunter zählen beispielsweise entsprechende Cache-Systeme für diskrete Ressourcen (z.b. einfache HTTP-Cache-Server, die einmal bezogene Dateien für andere Nutzer bereithalten) sowie kontinuierliche Ressourcen (z.b. Video-Streaming-Server, die das Videosignal empfangen und standortintern zur Verfügung stellen) einzusetzen. Diese Cache-Systeme verstecken auch den Zugriff, da sich von der zentralen Quelle der Ressource aus keine Anfragen mehr für diese registrieren lassen. Fordert ein Nutzer eine Ressource an, die bereits im Cache-System durch die Anfrage eines anderen Nutzers vorrätig ist, wird diese direkt ausgeliefert, ohne dass die ursprünglichen Quelle Information darüber erhält. So sorgt dieser netzwerkentlastende Aspekt gleichzeitig dafür, dass der Quelle der Ressource verborgen bleibt, wieviele Nutzer aktuell diese Ressource konsumieren bzw. konsumiert haben, was eine zentrale Auswertung verhindert. In der Regel schreiben diese Cache-Systeme allerdings Logdateien, in denen die gesuchten Informationen ( Welcher standortinterne Nutzer rief welche Ressource wann ab? ) bereits in der Standardkonfiguration oder aber nachkonfigurierbar protokolliert werden. Diese Logdateien werden mit steigender standortinterner Nutzerzahl größer. Mit steigender Standortanzahl multiplizieren sich die Logdateien des Gesamtsystems zu einer Dateigröße, die nicht mehr effizient über die begrenzte Netzwerkanbindung zwischen den Standorten übertragen werden kann ohne mit der eigentlichen Anwendung um Netzwerkbandbreite zu konkurrieren. Zudem kann die Summe aller Logdateien von einem einzelnen Rechner nur ungenügend schnell ausgewertet werden. 1.2 Anwendungsfälle Die Problematik der Verdeckung des Zugriffs durch Cache-Systeme spielt in drei Szenarien eine Rolle, für die T-Systems Multimedia Solutions, in 1
dessen Zusammenarbeit diese Arbeit entstand, Lösungen vertreibt. Für jede dieser potentiellen Anwendungsfälle wird im folgenden kurz auf den infrastrukturiellen Aufbau sowie die von der Problematik betroffenen Informationen eingegangen. 1.2.1 Info-Screens im Unternehmensnetz Abbildung 1.1: Anwendungsfall: Info-Screen-System Der erst Anwendungsfall ist ein webbasiertes Informationssystem mit einem zentralen Webserver und über mehrere Standorte verteilte Clients, sog. Info-Screens, die im Wesentlichen aus einem großen Bildschirm mit einem Vollbildbrowser bestehen. Abbildung 1.1 verdeutlicht den Aufbau und zeigt ebenfalls den in jedem Standort installierten Cache-Proxy, der alle Anfragen an den zentralen Webserver sowie externen Medien (aktuelle Wetterinformationen, Videos von Internetportalen, etc.) zwischenspeichert. Aus den vom Cache-Proxy für jeden HTTP-Anfrage der Clients generierten Logeinträgen lassen sich folgende Informationen gewinnen: Cache-Effizienz (gesamt und pro Ressourcentyp) Navigationspfade eines speziellen Clients Fehlerhafte Anfragen externer Ressourcen 2
Abbildung 1.2: Anwendungsfall: Video-Streaming 1.2.2 Video-Streaming im Unternehmensnetz Ein weiterer Anwendungsfall betrifft ein Video-Streaming-System mit einem zentralen Video-Streaming-Server (siehe Abb. 1.2). In jedem Standort existiert ein weiterer Video-Streaming-Server, der den Video-Stream vom zentralen Server abholt und ihn standortintern zur Verfügung stellt. Die Clients rufen wiederum den Stream von ihrem jeweiligen standortinternen Video-Streaming- Server ab. Auf diese Weise ist sichergestellt, dass die Netzwerkaußenanbindung des Standorts konstant belastet wird, unabhängig von der Anzahl der Clients, die den Video-Stream abrufen. Der eingesetzte Video-Streaming-Server stellte einen Webservice bereit, über den diverse Informationen ableitbar sind: Zuschaueranzahl (gesamt und pro Standort) Welcher Client hat wann zu- und abgeschalten Systemmerkmale wie Netzwerk-/Prozessor- und Speicherauslastung 1.2.3 Öffentliche Video-Plattform Ein Blick auf den dritten Anwendungsfall in Abbildung 1.3 zeigt, dass dieselbe Problematik auch außerhalb der Unternehmensnetze auftritt. Der zentrale Server überträgt die Ressourcen in ein Content Delivery Network (CDN), ein Netzwerk aus vielen lokal verteilten Knoten, die alle eine Kopie der Ressource erhalten. Die Anfrage eines Clients nach einer Ressource wird vom CDN transparent zu dem Knoten geleitet, der die schnellste (Performance-Orientierung) und/oder bandbreitenschonendste (Kosten-Optimierung) Auslieferung garantiert. 3
Abbildung 1.3: Anwendungsfall: Mediathek mit Content Delivery Network (CDN) - Anbindung CDN-Anbieter bieten in aller Regel Reporting-Systeme an, die über einen Webservice abgefragt werden können: Anzahl der Anfragen pro Ressource / pro Zeitraum / pro Knoten Da CDN-Anbieter häufig nach verursachtem Datentransfervolumen bezahlt werden, sind beispielsweise auch die Kosten pro Ressource interessant 1.3 Ziel Diese verteilten Informationen gilt es bandbreitenschonend zusammenzutragen, um anschließend Statistiken und deren Visualisierungen zu generieren. Falls die Informationen nicht bereits aggregiert gewonnen werden können (siehe Anwendungsfälle 1.2.2 und 1.2.3), sollte der Aggregationsvorgang - im Fall 1.2.1 der Logdateien - auf den Cache-Systemen stattfinden, da diese entsprechend ihrer Funktion überwiegend netzwerklastige Arbeit verrichten und so ungenutzte Rechenkapazität zur Verfügung steht. Die so verlustbehaftet, aber zielorientiert komprimierten Informationen können dann zum zentralen Monitoringsystem übertragen und beispielsweise nochmals über alle Standorte aggregiert visualisiert werden. Wenn diese Analyse zyklisch ausgeführt wird, liefert sie, während die eigentliche Anwendung läuft, entsprechend der eingesetzten Analyse-Algorithmen Statistiken/Fehler/Auffälligkeiten der Anwendung. 4
Abbildung 1.4: Allgemeiner Überblick mit Monitoring Ziel der Arbeit ist der Entwurf und die prototypische Implementierung eines Monitoring-Frameworks, dem möglichst nur ein Erfassungs- und Aggregationsalgorithmus sowie eine Konfiguration zur Generierung der Statistiken übergeben wird und alle anderen Schritte, wie die entfernte Ausführung, Speicherung der aggregierten Daten sowie die Visualisierung entsprechend der Konfiguration übernommen wird. 1.4 Aufbau der Arbeit Bisher wurde im Kapitel 1 die Motivation und das Ziel dieser Arbeit grob umrissen. Im Kapitel 2 werden grundlegende Begriffe und Methoden zum Thema Monitoring erläutert, auf die Struktur und die Auswertung des Informationsgehalts von Logdateien im Webumfeld eingegangen sowie abschließend ein Blick auf die Visualisierung statistischer Daten geworfen. Zu jedem dieser Themen werden einige Werkzeuge und Programme betrachtet. Im Kapitel 3 werden die Anforderungen der Arbeit aufgestellt und die betrachteten Werkzeuge gemäß ihrer Anwendbarkeit bewertet. Das Konzept dieser Arbeit wird in Kapitel 4 vorgstellt. Kapitel 5 befasst sich mit der technischen Umsetzung und geht auf ausgewählte Bestandteile der Implementierung näher ein. Im Anschluss wird im Kapitel 6 gezeigt, wie die in Kapitel 3 aufgestellten Anforderungen umgesetzt wurden und welche Möglichkeiten darüber hinaus bestehen. Abschließend wird die Arbeit in Kapitel 7 kurz zusammengefasst und mögliche Verbesserungsvorschläge aufgezeigt. 5
6
2 Grundlagen Diese Arbeit beruht auf einigen grundlegenden Themen, die in diesem Kapitel näher erläutert werden. Beginnend mit der Definition des Begriffs des Monitoring und welche Methoden es gibt, soll in Abschnitt 2.1 geklärt werden. Anschließend befasst sich der Abschnitt 2.2 mit Logdateien, einer potentiellen Quelle der zu sammelnden Informationen, wie diese aufgebaut sind, welche Informationen in ihnen stecken und wie sie ausgewertet werden können. In Abschnitt 2.3 soll abschließend auf mögliche Visualisierungen der Informationen, die durch das Monitoring gesammelt wurden, eingegangen werden. 2.1 Monitoring Im Oxford Dictionary [OED89] wird Monitoring wie folgt definiert: To observe, supervise, or keep under review; to measure or test at intervals, especially for the purpose of regulation or control, or to check or regulate the technical quality of something. Grundsätzlich lässt sich alles überwachen - diese Arbeit beschränkt allerdings auf das System- und Service-Monitoring, d.h. den Betriebszustand eines Systems, der sich anhand diverser Systemmerkmale messen lässt und den Zustand der Anwendungen und Dienste, die auf diesem System betrieben werden. In diesem Abschnitt sollen einige Begrifflichkeiten und Methoden hinsichtlich Messdatenbeständigkeit(Abschnitt 2.1.1), Ereignisorientierung (Abschnitt 2.1.2) sowie Kontrollfluss (Abschnitt 2.1.3) geklärt und unterschieden werden. Anschließend werden in Abschnitt 2.1.4 zwei bestehende Monitoringprogramme näher betrachtet. 2.1.1 Daten: Transient vs. Persistent Grundlegend für die Festlegung der Datenerhebungs- und Datenübertragungsmethode ist die Unterscheidung der zu erhebenden Daten anhand ihrer Beständigkeit in transient und persistent. Transiente Daten sind nur für den Zeitpunkt verfügbar, in dem sie gemessen werden. Das trifft beispielsweise für Systemmerkmale wie Prozessoroder Arbeitsspeicherauslastung zu. Sobald der Zeitpunkt vorüber ist und das Systemmerkmal nicht gemessen wurde, geht dessen Wert verloren. 7
Persistente Daten hingegen bieten zum Messzeitpunkt Zugriff auf Systemmerkmale vergangener Zeiträume. Beispielsweise lassen sich mit Hilfe von Logdateien Werte und Zustände des Systems oder eines Dienstes über große Zeiträume hinweg einsehen. Allerdings lassen sich transiente Daten durch einen auf dem System installierten Dienst periodisch - entsprechend eines definierten Abtastintervall s - messen und in eine Datei schreiben, wodurch sie persistent werden. Ein solcher Dienst ist z.b. collectd (siehe Sektion 2.1.4), welcher periodisch viele Systemmerkmale misst und in RRD-Dateien (siehe Sektion 2.3.3) speichert. Visualisiert bieten diese Daten einem Systemadministrator einen Blick in die Vergangenheit des Systems. 2.1.2 Ausführung: Reaktiv vs. Proaktiv Man unterscheidet beim Systemmonitoring im Wesentlichen zwei Möglichkeiten der Ereignisorientierung, d.h. durch welches Ereignis ausgelöst die Merkmale des Systems ausgelesen werden [SM02]. Das Netzwerkdiagnosewerkzeug ping sendet ein Echo-Befehl des Internet Control Message Protocol s (ICMP) über das Netzwerk an ein entferntes System, welches seinerseits mit einem Echo-Reply-Befehl, dem sog. pong, antwortet. Es ist eines der meist genutzten Systemmonitoringwerkzeuge, um die Netzwerkverbindung zu überwachen [SM02], und soll als Beispiel zur Erläuterung der Unterscheidung dienen. Einerseits kann der Auslöser zur Überprüfung des Systemzustandes ein externes Ereignis sein, oftmals ein aufgetretener Fehler (z.b. der Webserver liefert die angeforderte Ressource nicht aus). Man spricht dabei von reaktivem Monitoring. Zur Fehlerdiagnose ließe sich dass System anpingen und somit überprüfen, ob die Netzwerkverbindung zwischen dem ressourcenanfragenden System und dem des Webservers korrekt funktioniert und ausgehend von dieser Information weitere Schlüsse ziehen. Überprüft man den Systemzustand andererseits ohne auslösendes Ereignis, sondern in regelmäßigen, zeitlichen Abständen spricht man proaktivem oder auch periodischem Monitoring. Mit einem erfolgreichen, periodischen Anpingen des Webserversystems lässt sich sicherstellen, dass die Netzwerkverbindung korrekt funktioniert, ohne dass ein Webserverfehler (externes Ereignis) auftritt. Im periodischen Monitoring differenziert man nochmals 2 Formen bezüglich der Latenz zwischen Messung und Auswertung der Merkmale des zu überwachenden Systems. 8
Beim Echtzeit-Monitoring geht es hauptsächlich darum, die gemessenen Werte möglichst schnell auszuwerten. Dazu werden die Messintervalle recht klein gehalten, um die Aktualität der Informationen zu erhöhen. Je älter die gemessenen Daten, desto uninteressanter sind sie, weswegen sie in aller Regel auch schnell wieder gelöscht werden können. In einer Langzeitauswertung betrachtet man die gesammelten Werte über relativ große Zeitintervalle hinweg (beispielsweise Tage/Wochen/Monate oder gar Jahre), um langfristige Veränderungen erkennen zu können. Dabei werden die Messintervalle relativ groß gewählt, da die Aktualität weniger wichtig ist als beim Echtzeit-Monitoring, wohl aber der Platzbedarf der gemessenen Daten, die über den gesamten Auswertungszeitraum hinweg gespeichert werden müssen. In automatisierten Systemmonitoring-Werkzeugen wird überwiegend der proaktive, periodische Monitoringansatz verfolgt, da die Benachrichtigung über externe Ereignisse nur umständlich realisierbar ist. Beide Ansätze lassen sich allerdings kombinieren, z.b. wenn durch proaktives Monitoring erkannte Fehlerstände mit durch reaktive Maßnahmen gewonnene Informationen erweitert werden. 2.1.3 Übertragung: Push vs. Pull Der Datenfluss beim Systemmonitoring verläuft immer vom beobachteten System zum überwachenden System, beim Kontrollfluss bestehen allerdings verschiedene Möglichkeiten. Zum Einen lässt sich die Kontrolle, wann und welches System überwacht werden soll, zentral im Monitoringsystem halten, welches aktiv Anfragen nach den gewünschten Systemmerkmalen an das zu überwachende System stellt, das daraufhin die entsprechenden Informationen aushändigt. Dabei spricht man von Pull-Methode, da das Monitoringsystem die Informationen aus dem überwachten System herauszieht. Dafür muss das Monitoringsystem alle zu überwachenden Systeme kennen, welche zudem eine geeignete Schnittstelle zum Abruf der Informationen bereitstellen müssen, z.b. eine HTTP-Schnittstelle oder auch einen Fernadministrationszugang, um Kommandozeilenbefehle auszuführen. Die Alternative ist die Installation eines Dienstes auf dem zu überwachenden System, welcher die Werte misst und selbstständig zum Monitoringsystem überträgt(push-methode). Dazu muss allen überwachten System das Monito- 9
ringsystem bekannt sein, welches seinerseits wieder eine Push-Schnittstelle bereitstellen muss, um die übertragenen Messdaten entgegenzunehmen. Beide Methoden haben Vor- und Nachteile und sind unter gewissen Voraussetzungen, wie z.b. die fehlende Möglichkeit einen Dienst auf dem zu überwachenden System zu installieren, gar nicht einsetzbar. 2.1.4 Monitoringprogramme Um den ordnungsgemäßen Betrieb von Servern zu Überwachen existieren eine ganze Reihe verschiedenster Programme. Auf zwei soll in dieser Sektion eingegangen werden. Einerseits ein kleines aber modulares Werkzeug namens collectd sowie andererseits das sehr etablierte Nagios zur Überwachung ganzer IT-Landschaften. collectd collectd ist ein Dienst zum periodischen Sammeln von Systemmerkmalen [SH09]. Bemerkenswert ist dabei die Modularität dieses Werkzeugs. Ein schlanker Kern, der vom System ausgeführt wird, und bei dem sich Plugins für drei Kategorien von Aufgaben registrieren können: Lesen von Systemmerkmalen wie CPU-, Arbeitspeicher- oder Netzwerkauslastung, sowie Informationen zum Zustand von Diensten. Schreiben der gesammelten Informationen, einerseits in verschiedene Dateiformate wie RRD und CSV, aber auch via verschiedener Netzwerkprotokolle einschließlich HTTP. Ereignisabfrage mit Hilfe von lesenden Plugins, z.b. die Überschreitung definierter Grenzenwerte. Daraufhin können definierte Befehle ausgeführt werden und mit Hilfe schreibender Plugins Informationen publiziert werden. collectd stellt eine Fülle an Plugins bereit, die zum Teil sehr generisch sind: das Tail-Plugin beispielsweise kann zur Analyse jeglicher Logdateien benutzt werden, indem durch reguläre Ausdrücke Logeinträge bestimmt werden, die entweder gezählt oder darin enthaltene Werte gezählt, summiert und auf andere Weise verrechnet werden. Abbildung 2.1 gibt einen Überblick über die Architektur von collectd. In ihr ist neben einigen integrierten Plugins auch ein Exec-Plugin zu erkennen, welches die Ausführung beliebiger Skript-Dateien ermöglicht und damit eine 10
Abbildung 2.1: Schema der Plugin-basierten Architektur von collectd. Quelle: http://collectd.org/ programmiersprachenunabhängige Erweiterbarkeit gewährleistet. Die Skalierbarkeit wird durch lesende und schreibende Netzwerkplugins gewährleistet, sodass z.b. viele collectd-instanzen ihre Messergebnisse an eine zentralen collectd-instanz weiterleiten. Nagios Nagios ist eine sehr verbreitete Monitoringlösung für große IT- Infrastrukturen. Die objektorientierte Konfiguration gibt einen Überblick über den Aufbau und klärt zugleich einige Begrifflichkeiten: Hosts sind zu beobachtende Systeme, gekennzeichnet durch ihre Netzwerkadresse und können zur einfacheren Verwaltung in Gruppen, sog. Hostgroups, zusammengefasst werden. Services sind die zu überwachenden Eigenschaften der Hosts. Dies können einerseits Systemmerkmale wie Prozessor-, Speicher- oder Netz- 11
werkauslastung, aber auch vom Host zur Verfügung gestellte Dienste wie Webserver, Datenbanken oder Fernzugriff sein. Kontakte können im Alarmfall je nach Dringlichkeit über verschiedene Kommunikationswege benachrichtigt werden. Kommandos werden ausgeführt, um Services zu überwachen oder Kontakte zu informieren. Die eigentliche Überwachung, also das Auslesen der Eigenschaften, übernehmen dabei Plugins, von denen es über 2000 Stück 1 gibt. Diese Plugins können dabei beliebige, ausführbare Dateien seien. Sie werden mit Grenzwerten als Parameter durch ein Kommando aufgerufen, messen ihrerseits die Eigenschaft des System, vergleichen sie mit den Grenzwerten und geben in einem durch die Nagios Plugin-Richtlinien [?] festgelegten Format den Status, typischerweise OK, WARNING oder CRITICAL, aus. In Abhängigkeit dieses Status werden entsprechende Benachrichtigungen an den für diesen Host und/oder Service konfigurierten Kontakt gesendet. Zusätzlich zu dem Status kann ein Plugin sog. Performance-Daten mitliefern, welche die gegen die Grenzwerte verglichenen Messwerte darstellen. Nagios speichert diese mit Hilfe des RRDTool s in RRD-Dateien, welche in Diagramme überführt und somit Trends der Werte im Verlauf der Zeit abgelesen werden können (siehe Abschnitt 2.3.3). Aktive Checks via NRPE Will man nun Services anderer, entfernter Hosts überwachen, müssen die Plugins auf dem entfernten Host ausgeführt werden. Eine Ausführung via Fernzugriff, z.b. über SSH, sorgt durch die Verschlüsselung der Verbindung allerdings bei steigender Host-Anzahl zu Problemen bei der Prozessorauslastung des Monitoringsystems und auch die zur Ausführung der Plugins notwendigen administrativen Rechte können als sicherheitskritisch betrachtet werden. Daher besteht die Möglichkeit, die gewünschten Plugins zusammen mit einer Nagios Remote Plugin Executor-Instanz auf dem zu beobachtenden System zu installieren, welches auf Anfrage des Monitoringsystems die Plugins ausführt und die Daten zurückliefert. So ist zur Laufzeit kein administrativer Fernzugriff notwendig, da nur bereits vorinstallierte Plugins ausgeführt werden 1 Nagios Exchange Plattform zum Austausch von Erweiterungen für Nagios - http://exchange.nagios.org/ (Stand Juli, 2011) 12
Nagios check_nrpe NRPE check_load check_disk Lokale Ressourcen und Dienste Monitoringsystem Überwachtes System Abbildung 2.2: Ausführung entfernter (aktiver) Service-Checks via NRPE. Nach [Nag11] können, und damit auch keine besonders komplexe Verschlüsselung. Da die Ausführung vom Monitoringsystem ausgelöst wird, entspricht NRPE dem Pull-Modus aus Abschnitt 2.1.3 - in der Nagios-Begriffswelt spricht man von aktiven Checks. Passive Checks via NSCA Eine alternative Möglichkeit ist der Einsatz des Nagios Service Check Acceptor s, bei dem der Kontrollfluss dem zu beobachtenden System übertragen wird (siehe Abb. 2.3). Nagios NSCA check_nrpe Programm/ Script Monitoringsystem Überwachtes System Abbildung 2.3: Ausführung entfernter (passiver) Service-Checks via NSCA. Nach [Nag11] Zusammen mit den Plugins wird ein aktiver Dienst auf dem entfernten System installiert, der periodisch die Plugins ausführt und die Informationen an das Monitoringsystem sendet (Push-Modus aus Abschnitt 2.1.3). Das Monitoringsystem nimmt die Resultate entgegen ( passive Checks ). 13
Es stehen neben einer mitgelieferten Weboberfläche viele weitere, meist Webinterfaces aber auch Desktopapplikationen, zur Verfügung, in denen alle Status der Hosts und Services und mitunter auch einfache Diagramme der Performance-Daten (z.b. siehe Abbildung 2.6) einsehbar sind. 2.2 Logdateien Auf einem Server dauerhaft und im Regelfall unbeaufsichtigt ausgeführte Anwendungen schreiben zur Protokollierung von diversen Ereignissen im Ablauf der Anwendung Logdateien (üblicherweise Textdateien). Für jedes vom Entwickler der Anwendung als bedeutend eingestufte Ereignis wird ein Logeintrag fester und damit auch maschinell auswertbarer Struktur, häufig bestehend aus einem Zeitstempel sowie mehreren kontextabhängigen Informationen, der Logdatei angehangen. Die Protokollierung erlaubt die Verfolgung der Programmlogik auf hohem Abstraktionsniveau, ohne dass die Anwendung in einem speziellem Debugmodus läuft [And07]. Neben einigen proprietären gibt es auch standardisierte Logdateiformate. Auf einen wichtigen Repräsentanten für Webserver soll in Abschnitt 2.2.1 eingegangen werden. Eine weitere, im Kontext dieser Arbeit wichtige Kategorie, sind die Logdateien von (Cache-)Proxy-Servern, mit der sich Abschnitt 2.2.2 befasst. Gerade für Serveranwendungen spielen Logdateien eine große Rolle, da sich durch diese sowohl die zu Fehler führenden Ereignisketten rekonstruieren, als auch mittels Aggregation Statistiken erzeugen lassen (siehe Abschnitt 2.2.3). 2.2.1 W3C Logdateiformat-Standards Speziell bei Webservern hat sich ein Standard durchgesetzt, den nahezu alle Webserver-Implementierungen neben dem eigenen, proprietären Format beherrschen. Das vom World Wide Web Consortium (kurz: W3C) standardisierte Logdateiformat enthält drei Varianten: die starren Formate Common sowie dessen Erweiterung Combined Logfile Format und das flexible Extended Logfile Format. W3C Common Logfile Format Das feste Common Logfile Format (kurz: CLF) markiert durch den reduzierten Aufbau einen Minimalstandard für Webserver [KK00]. Für jede Anfrage an den Webserver werden folgende Informationen als Zeile der Logdatei angehangen [Wor]: 14
remotehost r f c 9 3 1 authuser [ date ] " r e q u e s t " s t a t u s bytes remotehost Der Name oder die IP-Adresse des Clients. rfc931 Der Name des Nutzeraccounts des Clientsystems. Diese Information stammt aus den Anfangszeiten des Internets und wird im Normalfall nicht mehr mitgeliefert, sodass dessen Feld mit einem Bindestrich als invalide gekennzeichnet wird. authuser Nutzername mit dem sich der Nutzer beim Webserver authentifiziert hat. Dieses Feld ist nur dann gesetzt, wenn eine Authentifizierung zur Anfrage der Ressource auch notwendig war. date Zeitpunkt der Anfrage. request Die Anfrage selbst, die vom Client angefragt wurde (HTTP-Methode, Adresse, sowie HTTP-Protokoll-Version). status Der HTTP-Status-Code der zum Client gesendet wird. bytes Die Größe des Dokuments (gemessen in Bytes), welches zum Client gesendet wird. Diesen Informationen lassen sich 3 Kategorien zuordnen. Folgender Beispiellogeintrag soll dabei behilflich sein: 1 2 7. 0. 0. 1 frank [10/ Oct / 2 0 1 0 : 1 3 : 5 5 : 3 6 +0100] "GET / apache. g i f HTTP/1.0" 200 2326 Die ersten 3 Felder zählen zu den Nutzerinformation und bestehen aus der Netzwerkadresse (IP-Adresse 127.0.0.1 ), dem lokalen Nutzernamen des Benutzers ( - und somit invalide) sowie des Nutzernamen, unter dem er sich gegenüber des Webservers authentifiziert hat ( frank ). Das vierte Feld enthält die zeitliche Information( 10. Oktober 2000 um 13:55:36 ) und das fünfte, sechste und siebte Feld zählen zu den Ressourceninformationen (die Datei apache.gif mit einer Dateigröße von 2,3kB wurde erfolgreich (Statuscode 200) ausgeliefert). 15
W3C Combined Logfile Format Das Combined Logfile Format (DLF) ist lediglich eine Erweiterung des CLF um 2 weitere Felder: der Referrer sowie der UserAgent. Beide werden aus optionalen HTTP-Headern gewonnen, die der Client zusätzlich mit der Anfrage mitschickt. Der Referrer gibt die URL der Webseite an, über deren Link der Zugriff auf die aktuell angeforderte Ressource erfolgte. Der UserAgent beinhaltet Informationen über die vom Nutzer verwendete Browser-Version, seine präferierte Sprache sowie das eingesetzte Betriebssystem. Beide Felder sorgen also für weitere Informationen über den Nutzer. W3C Extended Logfile Format Das Extended Logfile Format ist gegenüber dem CLF und DLF nicht starr strukturiert. Die Motivation liegt darin, bestimmen zu können, welche Informationen pro Logeintrag enthalten sind. Dazu wird in der ersten Zeile der Logdatei die Struktur und Reihenfolge der Felder pro Logeintrag mit Hilfe standardisierter Bezeichner definiert. Generische Analyse-Werkzeuge lesen diese Definition aus und können daraufhin aus den darunterliegenden Logeinträgen die jeweiligen Daten auslesen. Folgendes Beispiel soll einen besseren Eindruck vermitteln: #F i e l d s : time cs method cs u r i c ip 0 0 : 3 4 : 2 3 GET / foo / bar. html 1 2 7. 0. 0. 1 1 2 : 2 1 : 1 6 GET / apache. g i f 1 2 7. 0. 0. 1 1 2 : 4 5 : 5 2 GET / foo / bar. html 1 9 2. 1 6 8. 1 7 8. 2 #Fields: Markerierung, dass nachfolgend die Struktur der Logeinträge definiert wird time Bezeichner für die Zeit der Anfrage. Auch date ist als Bezeichner verfügbar. cs-method Bezeichner für die Methode spezialisiert mit dem Präfix cs (für Client zu Server, also die HTTP-Methode, die der Client dem Server mitgeteilt hat. cs-uri Bezeichner für die vom Client beim Server angefragte Adresse. c-ip Die Client - IP-Adresse. Durch die Kombination aus Präfix und Bezeichner lassen sich viele Information zur Anfrage und zu dessen Antwort in der Logdatei festhalten. Eine Liste 16
aller Bezeichner, Präfixe und deren Kombinationsmöglichkeiten gibt es in der Dokumentation des Extended Logfile Format [HB]. 2.2.2 Proxy- und Cache-Logdateien Proxys befinden sich zwischen Client und Server, üblicherweise an Knotenpunkten des Netzwerks, und wurden anfangs überwiegend zur Zugangsbeschränkung und Filterung genutzt, später auch als Cache, also zur Pufferung einmal bezogener Ressourcen für weitere Zugriffe, um so die Netzwerklast zu reduzieren [MWE00]. Genau wie bei Webservern ist es auch bei Proxys üblich, für jede Anfrage einen Logeintrag zu erstellen. Die Logdatei eines Webservers enthält dabei Informationen der Anfragen von vielen Nutzern zu einem Server. Die Logdatei eines Proxys hingegen enthält die Informationen der Zugriffe von vielen Nutzern auf viele Webserver und zusätzlich den Cache-Status, also die Auskunft darüber, ob die angefragte Ressource aus dem Cache des Proxys bezogen werden konnte (HIT), da sie bereits schon einmal abgerufen wurde, oder ob die Anfrage zum Webserver weitergeleitet wurde (MISS). Der in Abschnitt 2.2.1 betrachtete Standard W3C Extended Logfile Format beinhaltet einen Bezeichner "cached", der in einem Logeintrag zu einer Anfrage angibt, ob sie durch einen Cache beantwortet wurde (1) oder nicht (0). Allerdings hat sich das W3C Extended Logfile Format nicht gegen die Formate der jeweiligen Proxy-Implementierungen durchsetzen können, welche zudem feinere Unterscheidungen beim Cache-Status treffen. Der sehr oft eingesetzte Proxyserver Squid 2 unterscheidet z.b. acht verschiedene HIT-Status - darunter, ob die Ressource aus dem Arbeitsspeicheranteil des Proxys kam oder von der Festplatte, oder die Ressource zwar im Cache des Proxys vorhanden war, aber bereits so alt, dass sich der der Proxy am Ursprungswebserver versichert hat, dass die Datei aktuell ist. Weitere 20 MISS- oder Fehler-Cache-Status lassen eine feine Unterscheidung bei der Protokollierung und somit auch bei der Auswertung der Logdateien zu. 2.2.3 Analyse und Aggregation von Logdateien Man unterscheidet grundsätzlich zwei Formen der Logdateianalyse [Val01]: Einerseits lassen sich Logeinträge, die beim Eintreten gewisser externer Ereignisse erzeugt wurden, als Transitionen eines definierten Zustandsautomaten 2 Squid Proxy Server - http://www.squid-cache.org/ 17
interpretieren und dann auf Konformität prüfen. Dies ist implizit der Fall, wenn ein Administrator nach einem Fehlerfall die Logdatei der betroffenen Anwendung prüft und die Ereigniskette rekonstruiert, die zum Fehlerzustand geführt hat. Andererseits können die einzelnen Logeinträge statistisch ausgewertet werden. Dafür werden in der Regel die Vorkommen bestimmter Werte oder die Anzahl von Logeinträgen bestimmter Form mit Hilfe diverser Aggregationsfunktionen zusammengefasst, z.b. addiert, der Durchschnitt gebildet oder der Maximalwert festgehalten. Im Falle eines Webservers, der viele verschiedene Ressourcen ausliefert und eine entsprechende Logdatei z.b. im W3C Extended Logfile Format (siehe Abschnitt 2.2.1) anlegt, ließe sich mit einer solchen statistischen Auswertung die am meisten abgerufenen Ressourcen ausmachen, indem alle Logeinträge mit gleichem Wert im cs-uri-feld gezählt werden. Eine periodische Ausführung dieser Auswertung liefert Informationen darüber, wie sich der Konsum einzelner Ressourcen über die Zeit verändert. Speziell für Logdateien im Bereich des Internets gibt es eine Vielzahl von Werkzeugen, die eine statistische Auswertung auf Basis von Web- und Proxy-Server-Logdateien erzeugen können (siehe Abschnitt 2.2.4). 2.2.4 Logdateianalysewerkzeuge Logdateien sind in aller Regel außerordentlich homogen. Viele Logeinträge sind nahezu identisch oder weisen nur geringe Unterschiede auf. Häufig lässt sich die eigentlich gesuchte Information nur durch eine statistische Analyse gewinnen. Dazu gibt es verschiedene Werkzeuge, die nach Analysekomplexität geordnet vorgestellt werden sollen. AWK Benannt nach seinen Entwicklern Alfred V. Aho, Peter J. Weinberger und Brian W. Kernighan, steht AWK in dieser Sektion als Repräsentant aller Unix-Werkzeuge zur Verarbeitung strukturierter Textdateien (awk, sed, sort, uniq, cat, tail, grep, etc.). Ein Programm der Skriptsprache AWK besteht aus mehreren Regeln, zusammengefasst als Datei oder als Parameter des Kommandozeilenbefehls. Jede Regel besteht dabei aus einem Muster in Form eines regulären Ausdrucks, der eine Zeile der auszuwertenden Logdatei entsprechen muss, und einer Aktion, die dann ausgeführt wird. Die Ausführung eines Programms erfolgt datengetrieben, d.h. man beschreibt die Daten die verarbeitet werden sollen 18
und was mit ihnen passieren soll, der Kontrollfluss wird durch den zeilenweise eingelesenen Datenstrom der Logdatei bestimmt. Zeilen und dementsprechend Logeinträge, die keinem Muster entsprechen, werden nicht beachtet und damit herausgefiltert. Diverse Kontrollstrukturen wie Bedingungen, Schleifen und benutzerdefinierte Funktionen runden die Möglichkeiten von AWK ab (für Details siehe [awk]). Verknüpft man nun den Ausgang eines AWK-Programmes mit dem Eingang weiterer textverarbeitenden Programme wie sort, welches Zeilen nach bestimmten Feldern sortiert, sowie uniq, das identische Zeilen zusammenfasst und dabei mitzählen kann, lassen sich Logdateien sehr flexibel aggregieren. Calamaris Mit dem Kommandozeilen-Werkzeug Calamaris 3 lassen sich die Zugriffe auf Cache-Proxy-Server auf Basis ihrer Logdateien statistisch auswerten. Calamaris generiert, ähnlich wie Analog 4 oder AWStats 5 für Webserver, festgelegte Berichte in einem Text- oder HTML-Format. Die Berichte befassen sich beispielsweise mit der Auswertung folgender Aspekte: Verteilung der Anfragen auf Top-, Second-, Third-Level-Domains oder Dateitypen, Anzahl ein- und ausgehender Verbindungen sowie HTTP-Methoden, Cache-Effizienz nach Dateitypen/-größen Diese Berichte sind für Systemadministratoren gedacht und bietet einen breiten Überblick über die Art und Beschaffenheit der Zugriffe. Hadoop/Chukwa 6 ist von Grund auf auf das Sammeln der Logdateien von vielen Systemen ausgelegt und wertet diese anschließend mit Hilfe eines Clusters aus. Dazu setzt es auf das MapReduce-Framework Hadoop und das Hadoop Distributed File System (HDFS) auf. HDFS ist ein verteiltes Dateisystem nach dem Vorbild von Googles GFS [GGL03], dessen Hauptmotivation es ist, trotz Einsatz günstiger Standardhardware anstatt teurer, robuster Serverhardware und den damit verbundenen Hardwareausfällen keinen Datenverlust zu erleiden [HDF09]. 3 Calamaris - http://calamaris.cord.de/ 4 Analog - http://www.analog.cx/ 5 AWStats - http://awstats.sourceforge.net/ 6 Chukwa - http://wiki.apache.org/hadoop/chukwa 19
MapReduce ist ein aus der funktionalen Programmierung stammendes Programmiermodell und eignet sich durch die natürliche Parallelisierbarkeit der beiden Funktionen map und reduce, die jeweils nur auf einem kleinen Teil der Daten arbeiteten, sehr gut für die Verarbeitung von großen, homogenen Datenmengen in Rechnerclustern. Agent Agent Agent Agent HTTP Post (seconds) Collector Collector HDFS Write (seconds) DataSink MapReduce-Job (minutes) Structured Storage Abbildung 2.4: Struktureller Aufbau der Logdatensammlung von Hadoop Chukwa. Nach [BRB + 08] Chukwa ist eine Erweiterung des Hadoop-Frameworks zum Einsammeln vieler Logdateien. In Abbildung 2.4 ist der Aufbau veranschaulicht. Sog. Agents werden auf den zu beobachtenden Systemen plaziert, die Informationen zu Systemmerkmalen und aus Logdateien verschiedener Dienste sammeln und zyklisch(im Sekundenbereich) an Collector genannte, dedizierte Clusterknoten übertragen. Die Collector, von denen es etwa einen auf 100 Agents gibt, nehmen die Informationen entgegen und schreiben sie gebündelt in die DataSink (HDFS). Im Takt von mehreren Minuten werden MapReduce-Jobs gestartet, die diese Daten analysieren und aggregieren und anschließend zur Langzeitarchivierung im StructuredStorage speichern. 2.3 Visualisierung statistischer Daten Statistisch erhobene Daten sind für den Nutzer schneller erfassbar, wenn sie in geeigneter Form grafisch visualisiert werden [DBM89]. Wie die geeignete Visualisierung aussehen kann, hängt stark vom Skalenniveau der gemessenen Merkmale ab, auf das in der Sektion 2.3.1 eingegangen werden soll. Welcher 20
Diagrammtyp nun in Abhängigkeit des Skalenniveaus sowie der eigentlichen Visualisierungsintention in Frage kommt, soll in Abschnitt 2.3.2 geklärt werden. 2.3.1 Skalenniveau Das Skalenniveau eines Merkmals bestimmt die Aussagekraft und Differenzierbarkeit zwischen Merkmalswerten und ergibt sich aus den Operationen, die auf diesen möglich sind. Die meist verwendete Klassifikation nach Steven unterscheidet 4 verschiedene Skalenniveaus [Ste46]: Nominalskala Entscheidendes Kriterium ist die fehlende Ordnungsrelation auf den Werten dieser Skala, d. h. das keinerlei Aussage darüber getroffen werden kann, ob ein Wert größer/kleiner oder besser/schlechter als ein anderer ist. Einzig auf Gleich- oder Ungleichheit kann geprüft werden. Beispiele für Werte einer Nominalskala sind "Deutsch/Englisch", "rot/gelb/blau" oder "ja/nein". Ordinalskala Im Gegensatz zur Nominalskala ist bei der Ordinalskala eine Ordnungsrelation vorhanden, d. h. es lässt sich sagen, ob ein Wert größer oder kleiner als ein anderer ist, allerdings nicht, um wieviel größer oder kleiner. Eine Äquidistanz der möglichen Werte ist nicht gegeben. Prominentes Beispiel für die ordinale Skalierung sind die Schulnoten 1-6, bei denen 1 besser als 2 ist, aber nicht unbedingt dem gleichen Abstand entsprechen muss, wie zwischen 3 und 4. Intervallskala Auf den Werten der Intervallskala ist eine Ordnungsrelation sowie Äquidistanz vorhanden. Allerdings entspricht der Nullpunkt auf einer Intervallskala nicht unbedingt dem Nullpunkt des empirischen Relativs (also der Wirklichkeit). Das Beispiel der Temperatur in Celsius verdeutlicht diese Diskrepanz: 20 C sind nicht doppelt so warm wie 10 C, denn 0 C ist nicht gleichbedeutend damit, dass keine Temperatur vorhanden wäre. Unabhängig davon lässt sich allerdings eine Durchschnittstemperatur von 14,7 C ermitteln. Verhältnisskala Die Verhältnisskala, auch Ratioskala, ist die aussagekräftigste Skalierung, da sie einen definierten Nullpunkt besitzt, an dem der Nullwert der Skala tatsächlich dem Nullpunkt im empirischen Relativ 21
entspricht. Die Temperatur, diesmal gemessen in Kelvin ist eine Verhältnisskala, denn 200 Kelvin ist doppelt soviel wie 100 Kelvin und 0 Kelvin entspricht wirklich der Abwesenheit von thermischer Energie. Die Merkmale der Nominal- und Ordinalskalen werden auch als qualitative oder auch kategoriale Merkmale bezeichnet [Few05], da sie immer eine Qualitätsstufe beschreiben und sich daher zur Darstellung qualitativer Ausprägungen eignen. Als quantitativ oder auch metrisch bezeichnet man hingegen die Merkmale der Intervall- und Verhältnisskala [Few05], da durch die gegebene Abstandsrelation zweier Ausprägungen eine Differenz interpretierbar wird. Des Weiteren lässt sich bei metrischen Merkmalen in stetige Merkmale, deren Merkmalswerte eineindeutig auf die reellen Zahlen abbildbar ist, und diskrete Merkmale, deren Ausprägungen eineindeutig auf die natürlichen Zahlen abbildbar ist, unterscheiden. 2.3.2 Diagrammtypen Es gibt natürlich sehr viele verschiedene Diagramme, strukturiert in Kategorien und Typen, mit verschiedenen Intentionen und Voraussetzungen an die zu visualisierenden Daten. Ein Großteil lässt sich auf wenige Basistypen zurückführen, beschreibt Wallgren in seinem Buch Graphing statistics & data[wal96], welches einen strukturierten Überblick über viele Diagrammtypen und deren Anwendung bietet. Im Laufe der Zeit haben viele Autoren Basistypen der Diagramme um ihre Visualisierungsintention erweitert, wodurch viele spezialisierte Diagrammtypen entstanden. Eine chronologisch orientierte Übersicht darüber liefert [Wei09]. Diese Arbeit beschränkt sich an dieser Stelle auf die grundlegenden Basisdiagrammtypen der Visualisierung statistischer Daten. Die Unterscheidung in kategoriale und quantitative Merkmale anhand des Skalenniveaus hat bereits Auswirkungen auf die Diagrammauswahl. So sollte bei kategorialen Merkmalen allein die Verteilung visualisiert werden. Bei nominalen Merkmalen mag dies durch die fehlende Ordnungsrelation sinnvoll erscheinen, jedoch dürfen auch bei ordinalen Merkmalen keine Ausprägungen auf Längen oder Flächen abgebildet werden. Denn damit wird der Abstand zweier Werte visualisiert, über den allerdings durch die Ordinalskalierung nichts bekannt ist [Few05]. Beslow et al. haben jedoch gezeigt, dass sich der Farbton dafür eignen kann [BTMR10]. 22
Abbildung 2.5: Visualisierung kategorialer Merkmalsausprägungen: Verteilung als Kreisdiagramm zu einem Zeitpunkt (rechts), Verlauf der Verteilung als gestapeltes Flächendiagramm über einen Zeitraum hinweg (links) Für kategoriale Merkmale eignet sich daher ein Kreisdiagramm, um die aktuelle Verteilung zu visualisieren. Ist die Visualisierungsintention eher der Verlauf der Verteilung über einen Zeitraum hinweg, lässt sich dies beispielsweise in einem sich zu 100% stapelnden Flächen- oder Säulendiagramm visualisieren (siehe Abb. 2.5). Bei quantitativen Merkmalen hingegen vergleicht man in aller Regel die jeweiligen Abstände mehrerer Werte des Merkmals zueinander. Wichtig ist die Skalierung der Abhängigkeit dieser Werten und ob darauf eine Ordnungsrelation existiert. Wenn diese Werte beispielsweise an aufeinanderfolgenden Zeitpunkten gemessen wurden, besteht diese Ordnungsrelation und die Werte können in einem Liniendiagramm visualisiert werden, in dem die verschiedenen Punkte verbunden und damit interpoliert werden. Besteht diese Ordnungsrelation nicht, z.b. wenn die Werte in Abhängigkeit zu verschiedenen Kategorien oder Modi gemessen wurden, sollte ein Säulendiagramm, bei dem es keine visuelle Verbindung der Werte gibt, eingesetzt werden. Besteht zudem eine Partitionierung der Werte in Teilwerte, lassen sich die bereits beschriebenen Diagrammtypen sehr einfach erweitern. Balken- oder Säulendiagramme nennt man gestapelt, wenn die jeweiligen Balken oder Säulen typischerweise mit unterschiedlichen Farben oder Schraffuren segmentiert werden. Analog dazu lassen auch Liniendiagramme diese Modifikation zu, indem alle Teilwerte durch jeweils eigene Linien dargestellt werden und jeder Teilwert auf den vorherigen aufaddiert wird. 23
2.3.3 Visualisierungsbibliotheken Um die gesammelten Informationen für den Menschen schneller erfassbar zu machen, müssen sie gemäß ihrer Beschaffenheit (siehe Abschnitt 2.3) in Diagrammen visualisiert werden. Dafür stehen bereits viele verschiedene Programme und Bibliotheken zur Verfügung. In diesem Abschnitt soll auf ein bereits oft im Monitoringbereich eingesetztes Werkzeug namens RRDTool eingegangen, sowie mit RGraph und Google Visualization API zwei grundsätzlich webbasierte Lösungen vorgestellt werden. Anschließend werden diese Bibliotheken anhand einiger Gesichtspunkte für den webbasierten Einsatz zur Visualisierung von statistischen Rohdaten verglichen. RRDTool Das RRDTool ist ein sehr verbreitetes Werkzeug zur Speicherung und Visualisierung von Monitoringdaten. Es besteht aus einer Palette von Befehlen zum Erstellen, Aktualisieren und Auslesen von Round Robin Database-Dateien. Abbildung 2.6: Ein von RRDTool generiertes Liniendiagramm Bei der Erstellung einer RRD-Datei wird anhand der Anzahl an Werten, des Messintervalls und des Zeitraumes eine Datei fester Größe angelegt, die beim Hinzufügen von Messwerten nicht anwächst, sondern den jeweils ältesten Wert überschreibt. Ein weiterer Befehl erzeugt aus den Werten einer RRD-Datei ein Linien- oder Flächendiagramm als statische Bilddatei (siehe Abbildung 2.6). Einige weitere Befehle und nähere Details lassen sich in der Dokumentation auf der Webseite 7 nachlesen. 7 RRDtool - http://oss.oetiker.ch/rrdtool/ 24
Alle Befehle stehen als Kommandozeilenprogramme und gebündelt in einer Softwarebibliothek zur Verfügung und können so in andere Werkzeuge integriert werden, wie z.b. in collectd (Abschnitt 2.1.4) und Nagios (Abschnitt 2.1.4). RGraph Die Javascript-Bibliothek RGraph zeichnet Diagramme in ein HTML5 canvas-element. Das canvas-element ist ein neuer HTML-Tag, welches einen rechteckigen Bildbereich definiert, indem unter Nutzung von Javascript-Befehlen Zeichenoperationen ausgeführt werden und somit Linien, Flächen, Schatten und ganze Bilder gezeichnet werden können. Diese Möglichkeit des clientseitigen Zeichnens bestand zwar vor Einführung des canvas-elements bereits durch Einsatz von Frameworks wie Microsofts Silverlight oder Adobe Flash, allerdings sind dazu spezielle Browser-Plugins für die jeweilige Plattform notwendig. Diese Browser-Plugins sind in aller Regel herstellerspezifische, proprietäre Implementierung und bei Weitem nicht für die stetig steigende Anzahl verschiedenartiger Plattformen, speziell im Sektor der mobilen Geräte, verfügbar. Das Ziel des HTML5 canvas-elements ist es, die Möglichkeiten dieser bestehenden Lösungen in einer nativeren Form abzudecken, ohne dass Plugins nötig sind. Abbildung 2.7: Ein mit RGraph erstelltes, gestapeltes Balkendiagramm [RGr11] RGraph unterstützt eine breite Sammlung an Diagrammtypen wie Linien-, Balken-, Gantt-, Kreis- und Radar-Diagramme und viele andere. Ein solches Diagramm wird per Javascript instanziiert und mit einem Javascript-Array, welches die zu visualisierenden Daten enthält, sowie einigen optionalen Ein- 25
stellungen zur Darstellung versehen. Das Diagramm wird dann auf dieser Basis vom Browser des Clients in das referenzierte canvas-element gezeichnet (siehe Abbildung 2.7) und lässt sich zusätzlich mit Tooltips und anderen Interaktionsmöglichkeiten anreichern. Google Visualization API Die Visualization API von Google ist eine Javascript-Bibliothek, die Diagramme als Scalable Vector Graphic (SVG) in eine Webseite einbettet. Ähnlich wie HTML ist SVG eine Beschreibungssprache auf Basis von XML, in der komplexe Darstellungen aus grafischen Einzelelementen in einem Document Object Model (DOM) zusammengesetzt werden können. Das svg- Element kann dazu verschiedene Form-Elemente wie Linien, Kreise oder beliebig definierbare Polygone sowie Elemente zur Darstellung von Text- und Bilddateien enthalten. Auch sind Transformations- und Filterknoten möglich, um diverse grafische Effekte abzubilden. Die Struktur der Elemente bleibt im DOM erhalten und damit referenzierbar, wodurch nachträgliche Änderungen am Aussehen sowie das Hinzufügen und Entfernen von weiteren Elementen möglich werden. Abbildung 2.8: Eine mit der Google Visualization API erzeugte Kombination aus Balken- und Liniendiagramm mit Tooltips [GVi11] 26
Die Visualization API bietet eine Reihe von Standarddiagrammen wie Linien-, Balken-, Kreis- und Flächendiagrammen an, aber auch speziellere wie z.b. Kartendiagramme bei denen Daten auf Farben einer lokalen Region abgebildet werden. Zwischen den Diagrammen lässt sich einfach wechseln und es können auch problemlos benutzerdefinierte Diagramme hinzugefügt werden, da alle Diagramme auf einer gemeinsamen Datenstruktur, der sog. DataTable, beruhen. Die Abbildung 2.8 zeigt ein Kombination aus Balken- und Liniendiagramm mit aktivierten Tooltips, die bei Auswahl der entsprechenden Elemente unter anderem die exakten Werte anzeigen. Neben der direkten Angabe der zu visualisierenden Daten als DataTable besteht die Möglichkeit eine DataSource per URL anzugeben. Eine vom Diagramm ausgeführte, asynchrone HTTP-Anfrage auf diese URL gibt entsprechend der DataSource-Schnittstellenspezifikation die zu visualisierenden Daten als DataTable zurück. Alle Tabellen aus Googles Online-Tabellenkalkulation sind auch als DataSource-Schnittstelle abrufbar und lassen sich auf diese Weise schnell visualisieren. Auch unterstützt Google Webentwickler bei der Implementierung der Schnittstelle mit hilfreichen Bibliotheken, sodass eigene Datenbestände als DataSource angeboten und in Diagramme überführt werden können. 27
28
3 Ziele In diesem Kapitel werden die Anforderungen an das zu entwickelnde System aufgestellt und anschließend die in Kapitel 2 betrachteten Werkzeuge, Programme und Bibliotheken anhand dieser bewertet. 3.1 Anforderungen Zur Umsetzung folgender konkreter Anforderungen soll eine gemeinsame Architektur gefunden und in einem Framework implementiert werden, welches ausgehend von einer anwendungsfallspezifischen Konfiguration Informationen sammelt und daraus Statistiken generiert, welche in aufbereiteter Form zur Visualisierung bereitgestellt werden. Ein wesentliches Ziel dieser Arbeit ist dabei, die Netzwerklast zu reduzieren und erste Auswertungen bereits auf dem zu beobachtenden System auszuführen. 3.1.1 Monitoring eines InfoScreen-Netzwerks Die folgenden Anforderungen beziehen sich konkret auf das InfoScreen- Netzwerk mit einem Cache-Proxy pro Standort aus dem Anwendungsfall 1.2.1. A1.1 Stündliche Auswertung der Logdateien der Cache-Proxys aller Standorte hinsichtlich Cache-Effizienz pro Dateityp und Visualisierung der durchschnittlichen Effizienz der letzten 24 Stunden als Balkendiagramm pro Dateityp und Standort A1.2 Email-Benachrichtigung der Administratoren, falls HTTP-Anfragen von InfoScreens unerwartete Antworten erhalten (z.b. 400er HTTP-Status) A1.3 Flächendiagramm des durchschnittlichen, aller 5 Minuten gemessenen Arbeitsspeicherauslastung (used, cached, free) der Cache-Proxy-Systeme der letzten Woche 3.1.2 Echtzeit-Nutzerstatistiken von Videostreams Folgende Anforderungen beziehen sich auf das über viele Standorte verteilten Video-Streaming-System (siehe Anwendungsfall 1.2.2). Die nötigen Informationen folgender Diagramme werden periodisch aller 5 Sekunden von der 29
Webservice-Schnittstelle der Standort-Video-Streaming-Server abgefragt und bestehende Diagramme sollen entsprechend aktualisiert werden. A2.1 Gestapeltes Flächendiagramm der Zuschaueranzahl partitioniert nach Standort A2.2 Balkendiagramm der Netzwerkbandbreite in Senderichtung pro Standort 3.1.3 Nichtfunktionale Anforderungen A3.1 Das System soll einen einfachen, modularen Aufbau besitzen, sodass einzelne Teile unabhängig getestet und Laufzeitprobleme besser lokalisiert werden können. A3.2 Auf die Erweiterbarkeit und Flexibilität des Systems wird mehr Wert gelegt als auf die Laufzeitperformanz. Wann immer eine Entscheidung zwischen diesen beiden Kriterien getroffen werden muss, soll diese zugunsten der Erweiterbarkeit bzw. Flexibilität erfolgen. A3.3 Das System soll sich nahtlos in die bereits bestehende Umgebung auf Basis der Programmiersprache Python 8 und dem Webframework Django 9 integrieren, sodass das System von damit vertrauten Entwicklern einfach angewendet werden kann. 3.2 Bewertung betrachteter Lösungen Auf Basis der Anforderungen sollen die im Grundlagenkapitel betrachteten Werkzeuge und Programme bewertet werden. Dazu wird erst auf die Monitoringprogamme, anschließend auf die Loganalysewerkzeuge eingegangen und abschließend die betrachteten Visualisierungsbibliotheken miteinander verglichen. 3.2.1 Monitoringprogramme In Abschnitt 2.1.4 wurden die Monitoringprogramme collectd und Nagios vorgestellt. Diese sollen in diesem Abschnitt kurz bewertet werden. 8 Python Programming Language Official Website - http://www.python.org/ 9 Django The Web framework for perfectionists with deadlines - http://www.djangoproject.com/ 30
collectd Unter den Gesichtspunkten dieser Arbeit betrachtet, lässt sich erkennen, dass collectd einerseits durch seine generischen Plugins, wie das Tail-Plugin, bereits große Informationsquellen auf dem zu beobachtenden System analysieren lassen. Andererseits kann durch die flexible Erweiterbarkeit ein benutzerdefiniertes Skript komplexere Analysen vornehmen. Allerdings muss jede collectd-instanz mit privilegierten Rechten und administrativem Aufwand installiert und konfiguriert werden, denn eine zentrale Konfiguration ist nicht möglich. Auch die Ausführung von verschiedenen lesenden Plugins zu unterschiedlichen Zeiten ist durch einen festen Intervall von Standardmäßig 10 Sekunden nicht möglich, da es mehr zur Messung von Systemmerkmalen ausgelegt ist als zur Ausführung größere Analysen. Nagios Für umfassendes System- und Servicemonitoring eines Systems oder mit Hilfe von NRPE oder NSCA eines ganzen Netzwerks aus Systemen ist Nagios sehr gut geeignet. Nagios Hauptziel ist die Erkennung von Problemen und die Benachrichtigung der Administratoren. Die gesammelten Performance-Daten werden eher als zusätzliches Feature im Webinterface zu Analysezwecken visualisiert. Wenn es hauptsächlich um das Einsammeln einiger weniger Daten zur statistischen Auswertung und anschaulichen Präsentation geht, übersteigt der Installations- und Konfigurationsaufwand den Nutzen. 3.2.2 Logdateianalysewerkzeuge Die in Sektion 2.2.4 vorgestellten Werkzeuge zur Logdateianalyse werden in diesem Abschnitt kurz bewertet und anschließend in der Tabelle 3.1 miteinander verglichen. AWK Die kleinen UNIX-Textverarbeitungswerkzeuge rund um awk, sort und uniq haben den Vorteil, dass sie auf fast jedem unixartigen System bereits vorinstalliert sind. Für einfache Logdateianalyse wie das Zählen von Vorkommen oder Summieren von Werten können sie ohne Einrichtungsaufwand direkt zur Bewältigung der Analyse eingesetzt werden. Jedoch stoßen diese kleinen, komponierbaren Programme an ihre Grenzen, wenn es um komplexere Berechnungen geht. Calamaris Die durch die Auswertung berechneten Einzelwerte der von Calamaris und ähnlichen Werkzeugen erzeugten Berichte können weiterver- 31
wendet werden, wenn man sie aus dem HTML-Dokument wieder ausliest, was durch die immer gleiche Struktur der Berichte keine Hürde darstellt. Problematisch ist hingegen die Flexibilität, denn es können lediglich die Berichte erzeugt werden, die durch das Programm angeboten werden. Für individuelle Erweiterungen gibt es keinerlei Schnittstellen oder Möglichkeiten. Hadoop/Chukwa Chukwa ist grundsätzlich zur zentralen Auswertung von Systemmerkmalen und Logdaten entworfen und benötigt deshalb auch einen Hadoop-Cluster, um die Menge an Daten überhaupt verarbeiten zu können (zentralisierte Rechenlast). Zudem werden alle Daten unkomprimiert über das Netzwerk gesendet, da von einer breiten Netzwerkanbindung zwischen den zu beobachtenden Systemen, auf denen die Agents laufen, und den Collectors ausgegangen wird. Ziel dieser Arbeit ist eigentlich genau das Gegenteil zu tun: Rechenlast auf die zu beobachtenden Systeme verteilen und das Netzwerk zu schonen. Man müsste Chukwas Agents bereits die erste Auswertung und Komprimierung der Daten vornehmen lassen. Allerdings wäre dann fraglich, ob der administrative und infrastrukturelle Aufwand eines Hadoop-Clusters zur zentralen Analyse noch notwendig ist. Werkzeug Mächtigkeit Flexibilität Einrichtung AWK - + ++ Calamaris + - + Hadoop/Chukwa ++ + Tabelle 3.1: Vergleich der betrachteten Logdateianalysewerkzeuge 3.2.3 Visualisierungsbibliotheken Die in Abschnitt 2.3.3 betrachteten Visualisierungswerkzeuge RRDTool, RGraph und die Google Visualization API sollen in diesem Abschnitt anhand einiger, zur Erfüllung der Anforderungen nötiger, Gesichtspunkte für den webbasierten Einsatz zur Visualisierung von statistischen Rohdaten miteinander verglichen werden. Eine kurze Zusammenfassung dieses Vergleiches zeigt anschließend die Tabelle 3.2. 32
Diagrammtypen Das in Abschnitt 2.3.2 betrachtete Grundspektrum an Diagrammtypen decken RGraph und die Google Visualization API komplett ab, beinhalten viele weitere und letztere Lösung kann relativ einfach um zusätzliche Diagrammtypen erweitert werden. Lediglich RRDTool bietet ausschließlich Linien- und Flächendiagramme an und geht zudem generell von einer zeitlichen Ordnung zwischen den Datenpunkten aus. Diagrammberechnung Der größte Unterschied ist der Ort der Überführung der statistischen Daten zur grafischen Visualisierung. Beim RRDTool erfolgt dies serverseitig und bei RGraph und der Google Visualization API clientseitig. RRDTool erzeugt unter Rechenlast eines zentralen Systems das Diagramm. Damit nicht bei jedem Aufruf jedes Nutzers das Diagramm erzeugt werden muss, wird in aller Regel die Diagrammerstellung zyklisch ausgeführt und das Resultat an alle Nutzer ausgeliefert. Diese Methode hat wiederum den Nachteil, dass das Diagramm sehr oft ohne Nutzeranfrage berechnet wird. Die beiden clientseitigen Lösungen hingegen werden unter Nutzung von Javascript, welches im Browser des Nutzers läuft, berechnet und erzeugen keinerlei Rechenlast auf dem Server. Dabei gleicht sich die Performance der jeweiligen Basistechnologien SVG und Canvas unter unterschiedlichen Rahmenbedingungen aus [JJK08]. Dynamische Aktualisierbarkeit In einem Echtzeit-Anwendungsfall (z.b. Anwendungsfall 1.2.2) sollte das Diagramm stets den aktuellsten Informationsstand visualisieren. Die einzige Möglichkeit beim Einsatz von RRDTool ist es, stets die aktuellste statische Bilddatei nachzuladen. Dabei wird bei jeder Aktualisierung die komplette Bilddatei neu heruntergeladen und damit erhebliche Netzwerkbandbreite beansprucht. RGraph und die Google Visualization API hingegen laden lediglich die neuen statistischen Daten nach, deren Größe einen Bruchteil einer Bilddatei umfasst. Im Anschluss muss RGraph das canvas-element löschen und einen neuen Zeichenvorgang ausführen. Google Visualization API kann dagegen die referenzierbaren SVG-Elemente aktualisieren bzw. neue hinzufügen. Beide Bibliotheken bringen Aktualisierungsfunktionen bereits mit. Browserkompatibilität Eine von RRDTool erzeugte statische Bilddatei kann von jedem grafischen Browser wiedergegeben werden. Die mit HTML5 33
erst neue hinzugekommenen Elemente svg und canvas hingegen werden nur von den aktuellsten Browserversionen unterstützt. Gerade auf Unternehmenssystemen befinden sich allerdings aus Gründen der Kompatibilität mit anderen Anwendungen ältere Browserversionen (insbesondere Microsofts Internet Explorer), die keine Unterstützung für diese neuen Technologien bieten. RGraph bietet an dieser Stelle keine Ausweichlösung, man kann den Nutzer lediglich darüber informieren, dass sein Browser diese Technologie nicht unterstützt. Google Visualization API bietet speziell für Microsofts Internet Explorer eine Abbildung auf die Vector Markup Language (VML), eine unter anderen von Microsoft entwickelte Auszeichnungssprache, die ausschließlich von Microsoft-Produkten beherrscht wird. Bibliothek RRDTool - - - ++ GoogleVisAPI + + + + RGraph + + + - Diagrammtypen Aktualisierbarkeit Diagrammberechnung Browserkompatibilität Tabelle 3.2: Vergleich der betrachteten Visualisierungswerkzeuge 34
4 Konzept Dieses Kapitel befasst sich mit dem strukturellen Aufbau und der Funktionsweise des entwickelten Monitoring-Frameworks. Beginnend mit einem groben Überblick wird anschließend auf verschiedene Bestandteile näher eingegangen und zwischen Frameworkfunktionalität und anwendungsfallspezifischen Informationen differenziert. <<component>> Monitoring-System Beschreibung Aggregation Aggregation Struktur Messdaten Messdaten API Statistiken Kollektor Rezeptor Installation Push Statistiken Ereignisse Pull <<component>> Server <<component>> Cache-System Agent <<component>> <<component>> Client <<component>> Client Client Ressourcen Cache Abbildung 4.1: Monitoring-Framework im Überblick. Die Abbildung 4.1 zeigt einen Überblick des Monitoringsystems, integriert in die grau gekennzeichnete Zielinfrastruktur: Ein ressourcenausspielender Server, pro (Unternehmens-)Standort ein ressourcencachendes System, welches Hauptziel der Beobachtung ist, und eine unbestimmte Anzahl ressourcenkonsumierender Clients. Ausgehend von einer zentralen Konfiguration werden die orange gekennzeichneten Schnittstellen zum Sammeln der Daten erzeugt, mit welchen sich Abschnitt 4.1 eingehend befasst. Die gesammelten Messdaten werden in einer ebenfalls durch die Konfiguration festgelegten Struktur gespeichert. Abschnitt 4.2 befasst sich mit der Definition der Messdatenstruktur sowie mit Möglich- 35
keiten der Reduktion des Messdatenbestandes. Abschließend beschäftigt sich Abschnitt 4.3 mit der Berechnung von Statistiken. 4.1 Sammeln der Daten In diesem Abschnitt soll auf das Sammeln der gesuchten Informationen sowie auf Methoden zur Übertragung dieser zum Monitoringsystem eingegangen werden. Abschnitt 4.1.1 beschäftigt sich dazu mit dem Messvorgang und wie sich dieser flexibel für verschiedene Anwendungsfälle strukturieren lässt. Darauf aufbauend wird in Abschnitt 4.1.2 geklärt, wie die Messdaten bereits vor der Übertragung verdichtet werden können, um Netzwerkbandbreite einzusparen. Der darauf folgende Abschnitt 4.1.3 befasst sich mit den beiden Möglichkeiten der Lagerung des Kontrollflusses des gesamten Messvorganges. 4.1.1 Messung Die Messung oder auch Abtastung von transienten Systemmerkmalen wird in aller Regel mit Hilfe von betriebssystemeigenen Befehlen durchgeführt. Diese Befehle liefern dabei zumeist viele Werte verschiedener Merkmale in einem strukturell festen Format, aus dem die Einzelmesswerte zuverlässig ausgelesen werden können. Allerdings ist die Ausgabe jedes Befehls unterschiedlich, sodass für jedes zu messende Merkmal neben dem Befehl ein Ausdruck zum Auslesen des Wertes aus der Ausgabe des Befehls benötigt wird. Persistente Merkmale liegen in der Regel als Datei vor und können einerseits mit einfachen Unix-Textverarbeitungskommandos wie z.b. awk (siehe Abschnitt 2.2.4) oder mit entsprechenden Logdateianalyse-Programmen wie z.b. calamaris (siehe Abschnitt 2.2.4) ausgewertet werden, wodurch bereits ein erheblicher Anteil der Rechenlast auf das zu überwachende System verlagert wird. Beiden Analysemethoden gemein ist ein Kommandozeilenbefehl sowie ein Ausdruck zum Parsen der einzelnen, zu messenden Werte. An dieser Stelle soll daher eine einheitliche Schnittstelle festgehalten werden, die die Beständigkeit der Merkmale abstrahiert. Ausschlaggebend ist die Angabe eines Kommandozeilenbefehls, dessen Ausgabe folgendem Format entspricht. merkmal1=wert1 merkmal2=wert2... Das Framework liest dieses Format mit Hilfe einer Abbildungsfunktion zur Weiterverarbeitung ein. Dieses Format entspricht dem der Performance-Daten 36
der Nagios Plugin-Richtlinien [?], wodurch die Performance-Daten jedes bestehenden Nagios-Plugins ohne weitere Konfiguration ausgelesen werden können. Falls dieses Format nicht direkt durch den Kommandozeilenbefehl unterstützt wird, lässt sich diese Abbildungsfunktion überschreiben. Die Möglichkeit diese Funktion zu überschreiben birgt ferner die Option, einen komplexeren Analysealgorithmus anzugeben, der mit einfachen Textverarbeitungskommandos oder installierten Analyseprogrammen schwierig oder gar nicht möglich ist. Beispielsweise kann der Kommandozeilenbefehl einfach eine Logdatei ausgeben und die benutzerdefinierte Abbildungsfunktion verarbeitet Zeile für Zeile und gibt ihrerseits erhobene Werte an das Framework weiter. Folgende Informationen einer Messung unterscheiden sich zwischen mehreren, konkreten Anwendungsfällen und müssen daher konfigurierbar bleiben: Messintervall Kommandozeilenbefehl, der die gesuchten Informationen ausgibt Abbildungsfunktion, falls der Kommandozeilenbefehl nicht bereits das oben beschriebene Format unterstützt 4.1.2 Aggregation In einem verteilten Monitoringsystem gibt es neben dem Abtastintervall zusätzlich ein Übertragungsintervall, welches angibt, wie oft die gemessenen Daten zu einer zentralen Instanz übertragen werden. Bei vielen Monitoringsystemen ist das Übertragungsintervall gleich dem Abtastintervall, d.h. nach jeder Messung werden die Werte per Netzwerk zum zentralen System übertragen. Genau an dieser Stelle liegt das Potential Netzwerkbandbreite einzusparen, indem das Übertragungsintervall vom Abtastintervall entkoppelt wird. Dazu gibt prinzipiell verschiedene Ansätze: Bündelung Das Bündeln mehrerer Messwerte verschiedener Systemmerkmale des gleichen Zeitpunkts, gleicher Systemmerkmale verschiedener Zeitpunkte oder gar beides reduziert einerseits den möglichen Overhead des Netzwerkprotokolls, da nur eine statt vieler Übertragungen durchgeführt werden muss, und andererseits können eventuelle Redundanzen zwischen den Werten ausgenutzt werden, um das Übertragungdatenvolumen durch eine verlustfreie Kompression weiter zu verringern. 37
Filterung Eine weitere Methode ist es, nur bestimmte Messwerte zu übertragen. Wann ein Messwert übertragen wird legt ein Grenzwert oder eine Funktion auf Basis vorheriger Messwerte fest. Aggregierung Viele Messwerte eines Systemmerkmals lassen sich mit Hilfe einer Aggregationsfunktion zu einem einzigen Wert zusammenfassen. Beispiele für Aggregationsfunktionen sind die Summe, der Mittel-, Maximal- oder Minimalwert. Die Bündelung aller Messwerte verschiedener Systemmerkmale zu einem Übertragungspaket wird von vielen Monitoringwerkzeugen unterstützt, bietet zugleich aber die geringste Bandbreitenersparnis, da trotzdem alle Messwerte übertragen werden. Die Filterung hingegen birgt die Gefahr, dass - wenn ausschließlich kritische Werte übertragen werden - das zu beobachtende System komplett ausfällt, ohne dass das zentrale Monitoringsystem über den Ausfall informiert wird. Die Verdichtung vieler Messwerte mit Hilfe einer anwendungsfallspezifischen Aggregationsfunktion bietet neben der Reduktion der zu übertragenden Werte trotzdem regelmäßig Informationen an das zentrale Monitoringsystem. Das Aggregationsintervall, also der Zeitraum innerhalb dessen alle Messwerte aggregiert werden, entspricht dem Übertragungsintervall, d.h. nach jeder Aggregierung erfolgt die Übertragung Abtastintervall Abtastintervall Aggregationsintervall Übertragungsintervall Aggregationsintervall Übertragungsintervall Messung Aggregation Übertragung Messung Aggregation Bündelung Übertragung Abbildung 4.2: Schema der Verdichtung der Messwerte einstufig per Aggregation (links) und zweistufig mit Aggregation und Bündelung (rechts) Ein weiterer Schritt ist die Entkopplung des Aggregationsintervalls vom Übertragungsintervall, sodass mehrere aggregierte Messwerte zusammen über- 38
tragen werden können. Prinzipiell bieten sich an dieser Stelle wieder die bereits genannten Möglichkeiten: Bündelung, Filterung und Aggregation, wobei die Filterung aus gleichen Gründen ausscheidet und eine weitere Aggregation nur Sinn macht, wenn sich die Aggregationsfunktion ändert, was wohl nur für sehr spezifische Analysen notwendig ist. Daher soll an dieser Stelle die Bündelung der aggregierten Messwerte zum Einsatz kommen, um somit die Vorteile beider Methoden zu kombinieren. Durch die Aggregation wird ein Teil der Berechnung der resultierenden Statistiken bereits auf dem zu beobachtenden System ausgeführt und damit Rechenlast auf dieses System übertragen und Netzwerklast eingespart. Allerdings erhöht sich dadurch die Latenz bis ein Messwert beim zentralen Monitoringsystem eintrifft. Verstärkt wird diese Latenz, wenn zusätzlich auch eine Bündelung eingesetzt wird. Folgende Informationen über die Aggregation müssen für einen konkreten Anwendungsfall in der Konfiguration enthalten sein: Aggregationsintervall, entweder als Zeitraum oder als Anzahl zu aggregierender Messungen Aggregationsfunktion als Teil der Berechnung der Statistik 4.1.3 Kontrollfluss Folgend wird auf die konzeptionelle Umsetzung des Push- sowie des Pull- Modus zum Sammeln der Messdaten eingegangen und anschließend geklärt, welcher Modus unter welchen Bedingungen eingesetzt werden sollte. Push Beim Push-Kontrollfluss findet die periodische Ausführung der Messung (gemäß Abschnitt 4.1.1), Aggregation (Abschnitt 4.1.2) und Übertragung auf dem zu beobachtenden System statt. Diese Aufgabe übernimmt ein als Agent bezeichneter Dienst, der auf dem zu beobachtenden System installiert werden muss. Der Agent sendet die gemessenen und aggregierten Daten an eine dafür vorgesehene Schnittstelle auf dem Monitoringsystem, welche im folgenden Rezeptor genannt wird (siehe Abbildung 4.3). Das Übertragungsmodul des Agents muss dabei stets zum Rezeptor passen, um eine korrekte Kommunikation zu gewährleisten. Der Rezeptor nimmt die Daten entgegen, validiert und speichert sie. 39
Messen Agent Rezeptor Speichern Aggregieren Senden Empfangen Validieren Abbildung 4.3: Aufgaben sowie Datenfluss von Agent und Rezeptor Das Framework stellt dazu eine HTTP-Rezeptor-Implementierung bereit, welche alle nötigen Schnittstelleninformationen aus Namensgebung und Datenstruktur der zu messenden Merkmale ableitet und somit ohne zusätzliche Konfiguration auskommt. Das HTTP-Protokoll wurde aus Gründen der Flexibilität (gemäß Anforderung A3.2) gewählt, da neben den auf dem zu beobachtenden System installierten Agents auch Javascript-basierte Agents, die im Browser eines Clients ausgeführt werden, diese Schnittstelle ansprechen können. Zu dem Rezeptor kann mit Hilfe der Netzwerkadresse des Monitoringsystems auch das Sendemodul des Agents generiert werden, da alle nötigen Informationen vorhanden sind. Der Programmquellcode des Agents könnte dabei in beliebigen Scriptsprachen erzeugt werden, die auf dem zu beobachtenden System ausgeführt werden können. Im Rahmen dieser Arbeit wird dafür ein Agent-Generator für Python bereitgestellt. Abbildung 4.4 zeigt den von einem Administrator ausgelösten Ablauf der Generierung und Installation der Agenten auf den zu überwachenden Systemen der Standorte. Die installierten Agenten beginnen mit den Messungen, von denen eine konfigurierbare Anzahl aggregiert und anschließend an den entsprechenden Rezeptor übertragen wird, der diese voraggregierten Messdaten validiert und speichert. Pull-Kontrollfluss Bei einem Pull-Kontrollfluss ist das Monitoringsystem aktiv und fragt die Informationen über eine definierte Schnittstelle des zu beobachtenden Systems ab (siehe Abschnitt 2.1.3). Im Kontext des zu entwickelnden Frameworks wird der aktive, Informationen sammelnde Mechanismus folgend als Kollektor bezeichnet. Die Schnittstelle, über die der Kollektor die Informationen des zu beobachtenden Systems abfragt, kann je nach Anwendungsfall unterschiedlich aussehen und muss daher abstrahiert werden. Allen 40
Rezeptor Administrator Start Messdatenbestand Agent- Generator Agent #1 Generieren Agent #2 Generieren Installieren Agent Standort #1 Installieren Agent Standort #2 loop loop Messung Messung Messintervall abwarten Messintervall abwarten Aggregation Aggregation #1 Daten #1 Speichern #1 Validieren #2 Daten #2 Speichern #2 Validieren Abbildung 4.4: Sequenzdiagramm der Kommunikation von Rezeptor und Agenten zur Laufzeit Anwendungsfällen gemein ist jedoch der periodische Abruf der Informationen über die Schnittstelle. Das Framework bringt zwei Kollektor-Implementierungen mit, auf deren anwendungsfall- sowie schnittstellenspezifisch konfigurierbaren Eingabedaten kurz eingegangen werden soll: HTTP(S) Eine der gängigsten Schnittstellen/Protokolle zum Abruf von Informationen von einem entfernten System ist HTTP. Dafür ist ein Webserver auf dem zu beobachtenden System erforderlich, der alle Messdaten zum Abruf bereitstellt. Die nötigen Eingaben dazu beschränken sich in einem einfachen Szenario auf eine URL, in der Protokoll (HTTP/HTTPS), Domain, Port, Pfad sowie Parameter inkl. optionaler Authentifizierung über HTTP BasicAuth zusammengefasst sind. Zusätzlich könnte in der Anfrage ein strukturiert formatierter Text mit Informationen darüber, welche Daten angefordert werden, mitgesendet 41
werden, der vom Zielsystem interpretiert wird und mit entsprechende Informationen beantwortet wird (wie z.b. bei SOAP/XML). Lokaler Kommandozeilenbefehl Eine weitere Schnittstelle stellt die lokale Kommandozeile dar, über die beliebige, auf dem Monitoringsystem installierte Programme aufgerufen werden können. Somit lassen sich eine Vielzahl weiterer Netzwerkanalysen einbinden und zusätzlich lokale Systemmerkmale des Monitoringsystems messen. Weitere Implementierungen können an dieser Stelle einfach hinzugefügt werden. Allen gemein ist aber, dass sie mehrfach - für jedes zu beobachtende System - ausgeführt werden und dass das jeweilige Resultat ein strukturierter Text ist, welcher wieder mit Hilfe einer Abbildungsfunktion (aus Abschnitt 4.1.1) auf die Merkmalsdatenstruktur abgebildet wird. Falls die Ausgabe nicht bereits im definierten Format vorliegt, kann die Abbildungsfunktion einfach überschrieben werden. Egal ob es sich beispielsweise um ein XML- oder JSON-Format eines HTTP-Webservices oder eine zeilenbasierte Ausgabe eines Kommandozeilenbefehls handelt. Messdatenbestand Webservice Standort#1 Webservice Standort#2 Webservice Standort#3 Administrator Start Kollektor loop GET #1 GET #2 GET#3 #1 Speichern #1 Daten #2 Speichern #2 Daten #3 Speichern #3 Daten Stop Abtastintervall abwarten Abbildung 4.5: Sequenzdiagramm des Ablaufs der Kollektoren Abbildung 4.5 zeigt den von einem Administrator gestarteten, sich wiederholenden Vorgang, wie die Kollektoren mehrere entfernte Webservice- 42
Schnittstellen ansprechen und deren Ergebnis in den Messdatenbestand aufnehmen. Folgende Informationen müssen für einen konkreten Anwendungsfall in der Konfiguration enthalten sein: Messintervall Schnittstellenspezifische Eingabedaten für jedes zu beobachtende System (z.b. HTTP-URL und -Parameter oder Kommandozeilenbefehl) Abbildungsfunktion vom Resultat der Schnittstellenimplementierung auf die Messdatenstruktur Die Entscheidung, ob der Pull-Modus mit Kollektoren oder Push-Modus auf Basis von Rezeptoren und Agenten eingesetzt wird, hängt vom den zu messenden Merkmalen ab und wie diese gemessen werden können. Existiert auf dem zu beobachtenden System eine Schnittstelle, die die gesuchten Informationen anbietet und vom Monitoringsystem aus abgerufen werden kann, ist der Pull-Modus zu präferieren. Steht diese Schnittstelle auf dem zu beobachtenden nicht bereit, muss ein entsprechender Agent auf dem System installiert werden, der die Messungen selbst durchführt und anschließend an den Rezeptor überträgt. 4.2 Datenhaltung Dieser Abschnitt beschäftigt sich mit der Speicherung der gesammelten Informationen. Dazu wird im Abschnitt 4.2.1 eine Unterscheidung von Merkmalen vorgenommen und beschrieben wie diese zusammengesetzt sein können. Der darauf folgende Abschnitt 4.2.2 befasst sich mit dem anfallenden Platzbedarf der Messdaten und dessen Wachstum und beschreibt Möglichkeiten, diesen zu begrenzen. 4.2.1 Datenstruktur Um Messwerte in einer Datenbank speichern zu können, ist eine Beschreibung ihrer Struktur notwendig. Wichtigste Unterscheidung ist hierbei der Datentyp des zu messenden Merkmals sowie die Angabe eventueller Einschränkungen des Wertebereichs, um invalide Messwerte zu erkennen. 43
Nicht immer bestehen die zu überwachenden Informationen aus einzelnen, skalaren Werten. Oft ist gerade die Kombination aus mehreren Werten interessant, z.b. lässt sich die Auslastung des genutzten Arbeitsspeichers eines Systems einerseits als einzelnes, prozentuales Merkmal überwachen, andererseits bietet die Differenzierung in freien Speicherbereich, von ausgeführten Programmen belegten und als Festplattencache genutzten Bereich einen genaueren Überblick. Eine solche Kombination mehrerer Einzelmerkmale als zusammengefasste Einheit wird folgend als Charakteristik bezeichnet. Um die Messdaten im richtigen Zusammenhang speichern zu können, sind zudem weitere Kontextdaten notwendig. Der Zeitpunkt der Messung ist ein anwendungsfallübergreifendes Kontextdatum und wird daher implizit jeder Charakteristik zugeordnet. Ein weiteres, allerdings anwendungsfallspezifisches, Merkmal ist z.b. der Ort bzw. das System von dem die Messdaten stammen, um so z.b. verschiedene Standorte differenzieren zu können. Zeitpunkt Standort frei benutzt cache 16.08.2011 15:00:00 Berlin 150.541 450.245 399.452 16.08.2011 15:00:00 Dresden 120.569 461.236 420.632 16.08.2011 15:01:00 Berlin 145.156 455.654 399.362 16.08.2011 15:01:00 Dresden 120.355 461.789 420.045 Tabelle 4.1: Beispieldatenbanktabelle einer Charakteristik zur Arbeitsspeicherauslastung eines zu beobachtenden System pro Standort Tabelle 4.1 stellt eine Datenbanktabelle einer Charakteristik des genannten Beispiels der Arbeitsspeicherauslastung dar. Die Bezeichnung sowie der Datentyp der Spalten dieser Tabelle werden durch die Datenstrukturbeschreibung festgelegt. Jeder Eintrag beinhaltet die Kontextdaten Zeitpunkt und Standort sowie die von Kollektoren oder Rezeptoren gesammelten Messdaten. Um sich allerdings nicht auf eine Datenbank festzulegen, soll eine geeignete Abstraktion zur Beschreibung der Datenstruktur verwendet werden, mit deren Hilfe für jeden Anwendungsfall die Namen und Datentypen der Merkmale beschrieben werden können. 44
4.2.2 Größe und Wachstum des Messdatenbestands Die im Monitoringsystem zusammengetragenen Messdaten benötigen einen gewissen Speicherplatz. Im Beispiel der Arbeitsspeicherauslastung (siehe Tabelle 4.1) steigt der Speicherbedarf pro Standort, denn für jeden Zeitpunkt kommt eine Zeile dazu. Die Faktoren für das Wachstum des Speicherbedarfs sind das Produkt der Wertebereiche der Kontextdatenmerkmale und die zeitliche Abtastrate. Verdoppelt sich einer dieser Faktoren, verdoppelt sich der Speicherplatzbedarf der Charakteristik. Bei 10 Standorten und einer Abtastrate von einer Minute ist der Speicherplatzbedarf gleich dem mit 5 Standorten und Abtastrate aller 30 Sekunden. Hält man alle Kriterien konstant steigt der Platzbedarf zur Laufzeit linear an. Trotzdem muss das zu entwickelnden Framework eine Funktionalität zur Reduktion der Datenmenge beinhalten. Eine einfache Möglichkeit ist das Löschen alter Daten. Dafür sollte pro Charakteristik ein maximales Alter der Messdaten konfigurierbar sein oder dieses implizit aus der Standardabdeckung der Statistiken ausgelesen werden. Eine alternative Möglichkeit stellt die Aggregation älterer Rohdaten gemäß gegebener Aggregationsfunktionen dar, um die Messdaten je nach Alter in gröberer zeitlicher Auflösung zu speichern. Im Idealfall entspricht die Auflösung der gespeicherten Messdaten immer der Auflösung der definierten Statistik. 4.3 Datenzugriff Dieser Abschnitt beschäftigt sich mit der Nutzung der gesammelten Daten. Hauptziel ist die Generierung von Statistiken um aktuelle Werte oder die Trends von Merkmalswerten über längere Zeiträume hinweg zu betrachten. Mit diesem Thema befasst sich der Abschnitt 4.3.1 näher. Darauf aufbauend sollen die Daten, die diesen statistischen Auswertungen entstammen, in Diagrammen visualisiert werden. Abschnitt 4.3.2 befasst sich damit, wie die statistischen Daten ohne viel Aufwand an bestehende Visualisierungsbibliotheken übergeben werden können. Abschließend wird Abschnitt 4.3.3 erläutern, wie dem Entwickler die Möglichkeit gegeben wird, auf die Über- oder Unterschreitung selbst definierter Grenzwerte der Messdaten zu reagieren. 45
4.3.1 Statistiken Um aus den Rohdaten, die potentiell in großem Umfang - typischer Weise über viele Kontextmerkmale z.b. Standorte und Zeit verteilt - vorliegen, sinnvolle statistische Auswertungen zu erzeugen, ist es nötig die Messwerte entsprechend zu aggregieren. Die Kontextmerkmale dienen dabei zur Differenzierung der Aggregation. Die erste Aggregation wurde mitunter bereits dezentral von einem Agent (siehe Abschnitt 4.1.3) durchgeführt. Eine weitere Aggregation wird vom zentralen Monitoringsystem ausgeführt. Beide Aggregationsstufen werden zentral konfiguriert und berechnen zusammen die resultierende Gesamtstatistik. Daher sollte die Deklaration der Aggregationsfunktionen eine einheitliche Grammatik besitzen. Aggregationsabstraktion Um die Agent- und die zentrale Aggregation zu vereinheitlichen wurde eine gemeinsame Schnittstelle für die zentrale Konfiguration definiert, die die folgenden Funktionen mitbringt: Verschiedene Aggregationsfunktionen (z.b. Summe, Mittelwert, etc.), die auf individuelle Merkmale anwendbar sind Gruppierung der Aggregationsergebnisse anhand gegebener Kontextmerkmale Mehrstufige Aggregierung durch Verschachtelung gruppiert nach > 0..* <<interface>> Merkmal 1 < aggregiert <<interface>> Summe <<interface>> Mittelwert <<interface>> 0..1 Aggregation 1..* <<interface>> Aggregationsfunktion <<interface>> Minimum <<interface>> Maximum < basiert auf Abbildung 4.6: UML-Klassendiagramm der Aggregationsschnittstelle 46
Zeit Standort Anzahl 15:40 Berlin 24 15:40 Dresden 13 15:41 Berlin 26 15:41 Dresden 12 15:42 Berlin 28 15:42 Dresden 12 15:43 Berlin 28 15:43 Dresden 14 15:44 Berlin 28 15:44 Dresden 16 15:45 Berlin 29 15:45 Dresden 15......... Zeit Standort Anz. 15:40 Berlin 26.8 15:40 Dresden 13.4 15:45 Berlin 27.6 15:45 Dresden 14.8......... Zeit Anz. 15:40 40.2 15:45 42.4...... Tabelle 4.2: Mehrstufige Aggregation am Beispiel der Zuschaueranzahl gemäß des Video-Streaming-Anwendungsfalls 1.2.2. / V. l. n. r. Rohdatentabelle, erstes Aggregationsergebnis (Mittelwert über die 5 Minuten pro Standort), zweites Aggregationsergebnis (Summe über Standorte pro Zeit) Abbildung 4.6 zeigt den Aufbau der Schnittstelle. Die Klasse Aggregation steht für eine Aggregationsstufe und komponiert mehrere Aggregationsfunktionen, die sich jeweils auf ein Merkmal beziehen und mehrere Werte aggregieren. Welche Werte aggregiert werden sollen, wird durch eine Liste von Gruppierungsmerkmalen und implizite Zeitangaben, die unabhängig von der Aggregationsdeklaration angegeben werden, festgelegt. Diese Zeitangaben bestehen aus einem zeitlichen Betrachtungsintervall, welches den minimalen und maximalen Zeitpunkt definiert und damit alle dazwischenliegenden Messdaten in die Statistikberechnung aufnimmt, und einer zeitlichen Auflösung, die bestimmt wie dicht die Messdaten aggregiert werden sollen. Eine mehrstufige Aggregation, die alle diese Funktionen nutzt, ist in Tabelle 4.2 verdeutlicht. Diese Schnittstelle soll als Deklarationsbasis dienen. Daraus wird einerseits - für die zentrale Aggregation auf dem Monitoringsystem - eine Abbildung der notwendigen Rechenoperationen für die genutzte Datenbank generiert (SQL) und andererseits eine Python-Repräsentation für die Agent-Generierung. 47
Folgende Kriterien einer Statistik müssen für einen konkreten Anwendungsfall in der Konfiguration enthalten sein: Referenzname, denn pro Charakteristik lassen sich mehrere Statistiken definieren Eine Deklaration der Aggregationsfunktion mit Hilfe der Aggregationsschnittstelle Betrachtungsintervall und dessen zeitliche Auflösung Da die Berechnung nur mit den Daten durchgeführt wird, die sich in der Datenbank befinden, ist sie einerseits unabhängig vom Ablauf der Messdatensammlung und andererseits auch unabhängig von der zeitlichen Auflösung der Messdaten in der Datenbank. Allerdings birgt sie auch die Gefahr, dass die aggregierten Daten verzerrt werden, wenn für einen bestimmten Zeitraum nicht durchgängig alle Messdaten vorhanden sind. Bei einer Mittelwertberechnung äußert sich die Verzerrung durch das Fehlen einiger Teilwerte vermutlich nicht so stark, wie bei einer Summe als Aggregationsfunktion. Sollten gänzlich andere Statistiken benötigt werden, bietet das Framework durch den nativen Zugriff auf die Datenbank bzw. durch die verwendete Datenbankabstraktionsschicht ebenfalls die Möglichkeit individuelle Statistiken zu erzeugen. 4.3.2 Visualisierung Um die webbasierte Visualisierung der errechneten Statistiken möglichst flexibel zu halten, legt das Framework keine Visualisierungsbibliothek oder Technologie fest. Die Daten können unter einer vom Referenznamen der Statistik abgeleiteten Adresse abgerufen werden. Ein Parameter regelt dabei das Format. Sind die Daten einmal im passenden Format, beschränkt sich bei Einsatz einer Visualisierungsbibliothek der weitere Aufwand auf Einstellungen des Aussehens des Diagrammes, welches für jeden Anwendungsfall potentiell unterschiedlich ist. Abbildung 4.7 zeigt, wie in Abhängigkeit des HTTP-Parameters formatter entweder eine JSON-formatierte Version der Statistik ausgeliefert wird oder ein Format gemäß Google Visualization API DataSource-Schnittstelle (siehe Abschnitt 2.3.3). Die Formatter-Schnittstelle ist erweiterbar, sodass weitere Visualisierungsbibliotheken einfach angesteuert werden können, aber auch statische Bild-Dateien serverseitig generierbar wären. 48
Rohdaten Aggregation formatter JSON GvizDataSource PNG HTTP- Anfrage Statistische Berechnung Formatierung HTTP- Antwort Abbildung 4.7: Abarbeitung der Abfrage einer Statistik Um nicht bei jedem Aufruf die Statistik neu zu berechnen, werden für einen konfigurierbaren Zeitraum alle Ergebnisse der Formatter (fertig aggregiert und formatiert) in einem Cache gespeichert. 4.3.3 Ereignisorientierte Benachrichtigung Dieser Abschnitt befasst sich mit der Möglichkeit der Reaktion auf einerseits kritische Messwerte und andererseits dem Fehlverhalten innerhalb des Messvorganges. Kritische Messwerte Um auf kritische Messwerte reagieren zu können, ist es nötig diese erst einmal zu erkennen. Anwendungsfallspezifische Grenzwerte für Merkmalswerte müssen dazu genauso konfigurierbar sein, wie die Reaktion darauf. Für jeden neuen Messwert wird eine Überprüfung gemäß dieser Grenzwerte durchgeführt und bei Über- oder Unterschreitung die vom Entwickler referenzierte Behandlung gestartet. Fehlschlagende Messungen Wenn ein Fehler beim Abholen von Messwerten durch einen Kollektor, der auf dem Monitoringsystem ausgeführt wird, auftritt, können entsprechende Fehlerinformationen zur späteren Analyse gespeichert oder ein Alarm ausgelöst werden. Wenn allerdings ein Agent innerhalb des für ihn festgelegten Übertragungsintervalls keine Messwerte sendet, führt das auf dem Monitoringsystem zu keinem direkt eintretenden Ereignis, welches eine Fehlerbehandlung auslöst. Daher wird an dieser Stelle periodisch eine Routine ausgeführt, die die Messwerte seit der letzten Ausführung auf Vollständigkeit überprüft und gegebenenfalls Alarm schlägt. 49
Wie ein Alarm oder eine Fehlerbehandlung aussieht, kann vom Entwickler festgelegt werden. Eine aktivierbare Emailbenachrichtigung wird vom Framework bereitgestellt. Zusammenfassung In diesem Kapitel wurde der konzeptionelle Aufbau des zu entwickelten Frameworks beschrieben und geklärt, welche Konfigurationsbestandteile notwendig sind, um ein zentral konfiguriertes aber verteilt ausgeführtes Monitoringsystem zu betreiben. Dazu wurden verschiedene Methoden besprochen, Daten von entfernten System via Kollektoren abzuholen oder automatisch generierte Agenten- Dienste auf ihnen zu installiern, die die Messungen vornehmen, erste Analysen durchführen und mittels Aggregationsmechanismen die Messdaten komprimieren sowie anschließend an sog. Rezeptoren, entsprechende Schnittstellen des Monitoringsystems, senden. Die so zusammengetragenen Messdaten werden in einer Datenbank gesammelt und es können Statistiken mit Hilfe einer Aggregationsschnittstelle deklariert werden, die sich - in verschiedenen Formaten ausgegeben - direkt in bestehende Visualisierungsbibliotheken und -werkzeuge integrieren lassen. Eine Möglichkeit über kritische Messwerte sowie fehlerhafte Messvorgänge informiert zu werden rundet die Funktionalität ab. 50
5 Implementierung Dieses Kapitel beschäftigt sich mit der technischen Umsetzung des entwickelten Monitoring-Frameworks sowie dessen Integration in das Webframework Django. Dazu wird im Abschnitt 5.1 Django kurz vorgestellt und auf die wesentlichen Funktionen eingegangen, auf die für die Umsetzung aufgebaut wird. Der folgende Abschnitt 5.2 zeigt wie Kollektoren und Rezeptoren in diese Umgebung integriert wurden und wie mit Hilfe von Django Agenten generiert werden. Abschließend geht Abschnitt 5.3 auf Statistiken und die Implementierung der Aggregatonsschittstelle ein. 5.1 Django Django ist ein in Python geschriebenes Webframework, welches dem Model- View-Controller-Entwurfsmuster [Ree03] folgt. Ursprünglich als Basis für eine Nachrichten-Webseite entwickelt, wurde es 2005 quelloffen unter einer BSD-Lizenz veröffentlicht und seitdem von einer wachsenden Community gepflegt. Neben einer integrierten Objekt-Relational-Mapping(ORM)-Schicht, welche gängige relationale Datenbanken unterstützt und auf die im Abschnitt 5.1.2 näher eingegangen wird, bietet Django ein mächtige Template-Engine, mit deren Hilfe sich dynamische HTML-Dokumente, aber auch andere Artefakte (siehe Abschnitt 5.1.3 sowie 5.3.1) erzeugen lassen. Weitere integrierte Features sind: Flexible URL-Konfiguration mittels regulärer Ausdrücke Erweiterbares Authentifizierungs- und Rechtesystem Automatisch generiertes und produktionstaugliches Administrationsinterface weitere Systeme zur Unterstützung für Caching, Sitemaps- und Feed- Generierung und Internationalisierung 5.1.1 Erweiterbare Architektur Djangos Architektur ist der Garant für dessen Erfolg, denn Flexibilität und Erweiterbarkeit sind Hauptziele bei der Entwicklung. So wird jedes Modul, 51
jedes Teilsystem als sog. Applikation getrennt entwickelt. Abhängigkeiten zwischen den Applikationen können dabei auf Model-Ebene mittels abstrahierten Fremdschlüsselbeziehungen sowie auf Logikebene mit Hilfe von sog. Signalen, einem Publish-Subscribe-Mechanismus, umgesetzt werden. Ein individuelles Projekt setzt sich dann aus mehreren Applikationen zusammen. All diese Applikationen sind einerseits austauschbar oder aber besitzen eine sog. Backend-Schnittstelle, die die von der Applikation bereitgestellte API auf alternative Implementierungen oder Dienste abbildet. Paradebeispiel ist die Datenbankabstraktionschicht (siehe 5.1.2) mit Backends für verschiedene Datenbanken, aber auch die Authentifizierung lässt neben dem Login via Nutzername und Passwort alternative Backends für eine oder viele verschiedene Single-Signon-Implementierungen zu, ohne dass andere Applikationen, die vom Authentifizierungsystem abhängen, davon beeinflusst werden. Abbildung 5.1: Beispiel Django-Applikationen mit austauschbaren Backends Abbildung 5.1 zeigt ein Beispiel in dem die Datenbank-Applikation eine Model-Klasse bereitstellt, deren erbende Klassen in verschiedene Datenbank- Backends gespeichert werden können. Die Authentifizierungs-Applikation definiert eine User-Klasse, deren Instanzen somit speicherbar sind und stellt einen Authentifierungsprozess via verschiedener Backends bereit. An dieses User-Model kann in eine individuelle Applikation ein Foto anhängen, welches von einer Klasse einer Drittanbieter-Applikation erbt, die beliebige Dateien in verschiedene Backends speichern kann. Die Abstraktion der eigentlichen Technologien und Dienste sorgt für eine lose Kopplung, sodass bei sich ändernden Anforderungen schnell auf passende Technologien umgestiegen werden kann. 52
Auch werden viele weitere Applikationen und Backend-Implementierungen durch Drittanbieter und die Community bereitgestellt. 5.1.2 Model-Abstraktion und Validierung Eine grundlegender Bestandteil von Django ist seine ORM-Schicht. Deklaration Domänenobjekte lassen sich als Python-Klassen deklarieren und mit Attributen verschiedener Datentypen versehen. Die Liste integrierter Datentypen stellt ein breites Spektrum bereit, kann aber auch individuell erweitert werden. Folgendes Beispiel definiert die Klasse Person mit Namen und Geburtsdatum. 1 from django. db import models 2 3 class Person ( models. Model ) : 4 name = models. CharField ( max_length=30) 5 birthday = models. DateField ( ) Das Kommando syncdb (siehe Abschnitt 5.1.4) dient zur Einrichtung der Datenbank und generiert aus der Klasse Person folgende SQL-Anweisung zum Anlegen einer entsprechenden Tabelle: 1 CREATE TABLE myapp_person ( 2 " id " s e r i a l NOT NULL PRIMARY KEY, 3 "name" varchar ( 3 0) NOT NULL, 4 " birthday " date NOT NULL 5 ) ; Validierung Der Wertebereich der Attribute eines Models lässt sich zudem mit sog. Validatoren einschränken, um nur bestimmte Werte zuzulassen. Django kann aus der Modeldeklaration ein Formular erzeugen, welches mit Werten befüllt, alle Validatoren ausführt und gegebenenfalls die Modelinstanz neu anlegt bzw. aktualisiert. Dieser ganze Vorgang beruht allein auf der Modeldefinition und deren Validatoren und spielt daher eine große Rolle im entwickelten Framework. Anfragen Django bietet zum Anlegen, Abfragen, Aktualisieren und Löschen eine API die vom benutzten Datenbank-Backend abstrahiert. Über diese API 53
lassen sich sog. QuerySets kombinieren, die jeweils verschiedene limitierende Aspekte einer Anfrage verknüpfen. Beispielweise gibt es nach Eigenschaften filternde QuerySets, exkludierende und aggregierende QuerySets, die sich beliebig kombinieren lassen und erst bei ihrer Evaluation echte Anfragen an die Datenbank senden. Eingebaute Cache-Mechanismen sorgen zudem für weitere Optimierungen. 5.1.3 Template-Engine Dynamisch generierte Webseiten, also HTML-Dokumente, sind das, was Django als Webframework üblicherweise produziert, um mit dem Browser des Nutzers zu kommunizieren. Um die Programmlogik von der Präsentation zu trennen, benutzt Django sog. Templates, die HTML-Fragmente mit eingebetteten, logischen Kontrollstrukturen darstellen. Folgendes Beispiel zeigt ein Template, welches in Abhängigkeit ob der Nutzer sich authentifiziert hat, verschiedene Inhalte erzeugt. 1 {% i f r e q u e s t. user. i s _ a u t h e n t i c a t e d %} 2 Hi {{ r e q u e s t. user. name } }! 3 <a href="/ l o g o u t ">Logout</a> 4 {% e l s e %} 5 <a href="/ l o g i n ">Login</a> 6 {% e n d i f %} Diese Templates lassen sich hierarchisch anordnen, um gleichbleibende Elemente einer Webseite nicht unnötig duplizieren zu müssen. Die Erweiterbarkeit der Kontrollstrukturen runden die Template-Engine ab. 5.1.4 Kommandos Aktionen und Routinen, die nicht durch HTTP-Anfragen ausgelöst werden, sondern direkt vom Administrator auf der Kommandozeile, werden in sog. Management-Commands verpackt, die jede Applikation mitbringen kann. Diese bieten ein standardisierte Schnittstelle mit dem Django-Projekt und stellen sicher, dass die gesamte Umgebung inklusive ORM-Schicht korrekt geladen wurde. python manage. py syncdb python manage. py r u n s e r v e r 54
Die erste Zeile startet beispielsweise die Synchronisation der definierten Models mit der Datenbank und erstellt neue Tabellen und Spalten. Der zweite Command startet das Django-Projekt in einem Entwicklungsmodus. 5.2 Sammeln der Daten Dieser Abschnitt beschäftigt sich mit der Integration der Merkmalsdatenstrukturen sowie von Kollektoren und Rezeptoren in die Django-Umgebung und zeigt Konfigurationsbeispiele. 5.2.1 Struktur Strukturell ist das entstandene, in Abbildung 5.2 dargestellte, Framework streng hierarchisch aufgebaut. Characteristic attributes statistics save() collect Collector agent Receptor <<creates>> Agent collect_data() generate_agent() sample() send() HTTPCollector collect_data() LocalCollector collect_data() HTTPReceptor url_path recept_data(request) generate_agent() <<creates>> HTTPAgent send() Abbildung 5.2: Vereinfachtes Klassendiagramm des Monitoring-Frameworks Die allgemeine Characteristic-Klasse umfasst dabei die Merkmalsdefinition und damit die Struktur des Messdatenbestandes, eine zentrale Funktion zum Speichern neuer Messwerte sowie die Statistiken, auf die im Abschnitt 5.3.1 näher eingegangen wird. Die erste Vererbungsstufe stellt die Unterscheidung dar, wie Messwerte ins System gelangen - via aktivem Kollektor oder passivem Rezeptor - und dient zur einheitlichen Behandlung aller Kollektoren 55
und Rezeptoren, unabhängig von ihrer Implementierung, die durch die zweite Vererbungsstufe unterschieden wird. In konkreten Anwendungsfällen kann von den Kollektor- oder Rezeptor- Implementierungen geerbt werden und es müssen lediglich die Konfigurationen als Klassenattribute überschrieben werden. Folgender Abschnitt beinhaltet ein Beispiel dafür. 5.2.2 Instanziierung Folgendes Konfigurationsbeispiel dient als Basis zur Beschreibung der Funktionen des Frameworks. 1 class StreamViewers ( HTTPCollector ) : 2 a t t r i b u t e s = { 3 l o c a t i o n : models. CharField ( max_length=30), 4 viewers : models. I n t e g e r F i e l d ( min_value=0) 5 } 6 c o l l e c t = { 7 i n t e r v a l : 5 s, 8 s o u r c e s : [ 9 { name : b e r l i n, 10 u r l : http : / / b e r l i n. example. de :8080/ s t a t u s. xml }, 11 { name : dresden, 12 u r l : http : / / dresden. example. de :8080/ s t a t u s. xml } 13 ], 14 mapping : lambda s, response, source : { 15 l o c a t i o n : source [ name ], 16 v iewers : xpath ( response, // viewers / c u r r e n t ) 17 } 18 } Die Klasse StreamViewers fasst die gesamte Konfiguration zentral zusammen. Die Merkmale werden mit Hilfe der ORM-API von Django definiert (Zeile 2-5), wodurch dessen Messwerte automatisch von Kollektoren und Rezeptoren validierbar und speicherbar werden. Die durch die Vererbung (Zeile 1) festgelegte Funktion als HTTPCollector erwartet die Angabe des Klassenattributes collect, in der die Konfiguration dieser Kollektor-Implementierung gekapselt wird. Neben dem Abtastintervall, wird eine Liste von Quellen definiert (Z. 9-12), von denen die Messwerte bezogen werden sollen - in diesem Fall XML-Dateien von verschiedenen Servern. Da der textbasierte Inhalt der XML-Dateien nicht direkt auf die Merkmalstruktur abbildbar ist, wird eine, in diesem Fall anonyme, Abbildungsfunktion angegeben (Z. 14-17), die jeweils 56
ein Wert pro Merkmal zurückgibt. Für das Merkmal location wird hierbei der aktuelle Quellenname benutzt und für viewers wird aus der XML-Datei mit Hilfe einer XPath-Funktion der eigentliche Messwert extrahiert. 5.2.3 Kollektoren Da Kollektoren entsprechend ihres definierten Abtastintervalls periodisch, unabhängig von eintreffenden HTTP-Anfragen ausgeführt werden müssen, wurde ihre Ausführung in einen Management-Command verlagert. Für die periodische Ausführung standen 2 Möglichkeiten zur Auswahl: Ein eigener Dienst, der dauerhaft läuft und einen Kollektor entsprechend seines Abtastintervalls startet oder ein externer Taktgeber, der entsprechend des Abtastintervalls konfiguriert werden muss. Da ein eigener Dienst mitunter nicht robust genug ist und die Konfiguration eines externen Taktgebers für viele verschiedene Kollektoren kompliziert werden könnte, fiel die Entscheidung auf eine Zwischenlösung, die beide Nachteile umgeht. Der äußerst robuste Dienst cron ruft als externer Taktgeber minütlich den Management-Command collectors auf, der alle Kollektoren entsprechend ihrer Abtastintervalle für eine Minute aufruft und sich danach beendet. Abbildung 5.3 verdeutlicht diesen Ablauf. cron cron cron manage.py collectors manage.py collectors manage.py collectors c1 c1 c1 c1 c1 c1 c2 c2 Abbildung 5.3: Ausführung verschiedener Kollektoren(c1 und c2) durch den cron-gesteuerten Management-Command collectors Wie die konkreten Kollektoren die Messdaten beschaffen, legt jede Implementierung selbst fest. Die bereitgestellte HTTP-Kollektor-Implementierung erzeugt für jede Quelle einen Thread, sodass die potentiell lange Abrufdauer möglichst gleichzeitig abläuft. Falls eine sehr große Anzahl von Quellen definiert werden soll, ist eine Optimierungen an dieser Stelle mittels Semaphoren 57
denkbar. Die korrekte zeitliche Ausführung sowie die Abbildung der Resultate auf die Merkmalsdefinition wird für alle Kollektoren einheitlich ausgeführt. 5.2.4 Rezeptoren Rezeptoren sind einfache Schnittstellen, die Messdatensätze entgegennehmen. Da Django als Webframework bereits eine HTTP-Schnittstelle bereitstellt, können HTTP-Rezeptoren unter einer bestimmten URL registriert werden und Django leitet eintreffende HTTP-Anfragen an diese Rezeptoren weiter, die lediglich Messwerte in verschiedenen Formaten (JSON, XML, URL-Encoded) entgegennehmen, entsprechend der Merkmalsdefinition validieren und speichern. 5.2.5 Agenten Die direkten Kommunikationspartner der Rezeptoren sind die Agenten, die auf dem zu beobachtenden System ausgeführt werden, dort Messungen vornehmen und die Messwerte an die Rezeptoren übertragen. Die Agenten-Software wird dazu entweder manuell von einem Software-Entwickler erstellt oder vom Framework automatisch generiert. Voraussetzung für diese Generierung der Agent-Software ist ein Unix-basiertes Zielsysteme mit installiertem cron- Dienst sowie die Unterstützung der erzeugten Programmiersprache. Generator Das Framework bringt einen Python-Agent-Generator mit, der als Management-Comamnd umgesetzt ist und mit Hilfe der Template-Engine von Django statt der üblichen HTML-Dokumente ein Python-Script generiert. Dieses generierte Script setzt sich aus vier verschiedenen Modulen zusammen: Messung Die Messung erfolgt über einen konfigurierten Kommandozeilenbefehl. Abbildung Eine in der Konfiguration enthaltene Abbildungsfunktion wird per Quelltextinspektion ausgelesen und in den Agent-Quelltext eingebettet. Aggregation Alle Messwerte der Merkmale werden anhand eines mit Hilfe der Aggregationsschnittstelle formulierten Ausdrucks aggregiert. Dazu wird der konfigurierte Ausdruck auf entsprechende Python-Funktionen abgebildet (siehe 5.3.1) und eingebettet. 58
Übertragung Wie der Agent die aggregierten Messergebnisse überträgt, hängt vom Rezeptor ab, daher stellt jeder Rezeptor ein Template- Fragment bereit, welches den nötigen Python-Quelltext zur Übertragung beinhaltet. Folgender Template-Ausschnitt zeigt, wie der Basis-Agent-Code erzeugt wird und die sog. Blöcke definiert werden, an denen erbende Übertragungs- Templates weiteren Quellcode hinzufügen können. Aus Gründen der Übersichtlichkeit ist hier nur ein Ausschnitt abgebildet. Die kompletten Templates können im praktischen Teil dieser Arbeit eingesehen werden. 1 #! / usr / bin /env python 2 import os, time, datetime 3 # import i n j e c t i o n p o i n t o f sending module 4 {% block imports %}{% endblock %} 5 6 # sample method 7 def sample ( ) : 8 p = os. popen ( {{ sampling_command }} ) 9 out = p. read ( ) 10 p. c l o s e ( ) 11 return out 12 13 # send method hook 14 {% block send %}{% endblock %} 15 16... Der ausgewählte Rezeptor steuert sein eigenes Template zur Generierung des Übertragungsmethode bei, welches vom Basis-Template erbt und dessen Blöcke ausfüllt. Für den HTTP-Rezeptor sieht dieses Übertragungstemplate so aus: 1 {% extends " agent_code / base. py" %} 2 3 {% block imports %}import u r l l i b 2, j s o n{% endblock %} 4 5 {% block send %} 6 def send ( data ) : 7 req = u r l l i b 2. Request ( {{ r e c e p tor_url }}, 8 j s o n. dumps( data ), 9 { content type : a p p l i c a t i o n / j s o n }) 10 u r l l i b 2. urlopen ( req ) 11 {% endblock %} 59
Die benutzerdefinierte Abbildungsfunktion sowie die vom Rezeptor bereitgestellte Übertragungsfunktion sollten dabei auf in der Python Standard Bibliothek verfügbare Funktionen zurückgreifen, um keine zusätzlichen Abhängigkeiten zu schaffen. Falls doch Drittbibliotheken zum Einsatz kommen, müssen diese auf dem Zielsystem installiert werden. Deployment Um dem Administrator die Installation der generierten Agenten auf den Zielsystemen zu ersparen, stellt das Framework einen weiteren Management-Command bereit, der eine Liste von Zielsystemen in der Agent- Konfiguration erwartet. Die Installation erfolgt dabei via SSH, wobei vorausgesetzt wird, dass der Nutzeraccount die nötigen Rechte zu Ausführung des Agents inklusive des darin enthaltenen Kommandozeilenbefehls besitzt. cron cron Agent m1 m2 m3 m4 m5 m6 aü Agent m1 m2 m3 m4 m5 m6 aü Abbildung 5.4: Ausführung des cron-gesteuerten Agenten der viele Messungen (m1-m6) ausführt und nach Ablauf des Übertragungsintervalls die Ergebnisse aggregiert und überträgt(aü) Die Agenten-Script-Datei wird dazu auf dem System abgelegt und der Aufruf dieser in der cron-konfiguration des Nutzeraccounts so eingestellt, dass sie im Übertragungsintervall aufgerufen werden. Abbildung 5.4 zeigt, wie der Agent im Übertragungsintervall von cron aufgerufen wird, der entsprechend des Messintervalls den Kommandozeilenbefehl absetzt, dessen Ausgabe mit Hilfe der Abbildungsfunktion geparst wird und nach Ablauf des Übertragungsintervall aggregiert und übertragen wird. 60
5.3 Datenzugriff Abschnitt 5.3.1 zeigt wie die Berechnung der Statistiken auf Basis der Aggreggationsschnittstelle für unterschiedliche Ausführungsumgebungen generiert wird. Des Weiteren geht Abschnitt 5.3.2 auf die Möglichkeit der Behandlung kritischer Messwerte ein. 5.3.1 Statistiken Die Berechnung der Statistiken besteht aus 2 Schritten, einem verteilt ausgeführtem Schritt - entweder durch einen Agent ausgeführt oder einer anderen Instanz, welche die Ergebnisse über eine Schnittstelle abrufbar bereithält - und einem zentral ausgeführten Schritt, der nochmals auf allen zusammengetragenen Messwerten eine Berechnung ausführt. Für beide Schritte wurde eine einheitliche Beschreibungsmöglichkeit entworfen, welche aus einem Namen, einem folgend näher beschriebenen Aggregationsausdruckes sowie eines zeitlichen Betrachtungsintervalls und einer zeitlichen Auflösung besteht. Aggregationsschnittstelle Die bereits in Abbildung 4.6 beschriebenen Schnittstellenelemente wurden als Python-Klassen implementiert, die durch Instanziierung mit gleichzeitiger Zuweisung als Konstruktorparameter eine übersichtliche Deklarierung eines Aggregationsalgorithmus allein durch die entstehende komplexe Struktur zulassen. Folgendes Beispiel einer Statistikkonfiguration entspricht der zweistufigen Aggregation, die in Tabelle 4.2 dargestellt wurde. 1 class StreamViewers ( HTTPCollector ) : 2 a t t r i b u t e s = { 3 l o c a t i o n : models. CharField ( max_length=30), 4 viewers : models. I n t e g e r F i e l d ( min_value=0) 5 } 6 s t a t i s t i c = [ { 7 name : average viewers o v e r a l l, 8 a g g r e g a t i o n : Aggregation (SUM( viewers ), 9 based_on=aggregation (AVG( viewers ), 10 group_by=[ l o c a t i o n ] 11 ) 12 ), 13 f o r : 3h, 14 s t e p s : 5m, 15 } ] 61
Agent-Aggregation Bei der Aggregation, die der generierte Agent durchführt, wird für jedes Merkmal eine Liste von gesammelten Messwerten zu einem Wert zusammengefasst. Für diese Funktionalität wird entsprechender Python-Quellcode benötigt. Folgender Auszug aus der Implementierung der Aggregationsmethoden zeigt die Abbildung der bestehenden Aggregationsmethoden auf entsprechende Python-Standardfunktionen: 1 class AggregationMethod ( o b j e c t ) : 2 def init ( s e l f, a t t r i b u t e ) : 3 s e l f. a t t r i b u t e = a t t r i b u t e 4 5 def to_python ( s e l f, var_name ) : 6 return s e l f. s q l % { var : var_name } 7 8 class SUM( AggregationMethod ) : 9 python = sum(%( var ) s ) 10 11 class AVG( AggregationMethod ) : 12 python = sum(%( var ) s ) / l e n (%( var ) s ) Der Agent-Generator ruft dazu die Methode to_python auf der Klasse AggregationMethod auf und übergibt den Namen der Variable im Agent- Quelltext, die die Liste der zu aggregierenden Messwerte enthält. Die Methode greift dazu auf ein Attribut der konkreten, erbenden Klassen zu, welches den entsprechenden Quelltext mit einem Platzhalter für die Variable enthält und ersetzt diesen. Auf diese Weise lassen sich einfach weitere Aggregationsmethoden hinzufügen. Datenbank-Aggregation Die zentral ausgeführte Aggregation zur Erzeugung von Statistiken auf Basis der gesammelten Rohdaten wird von der Datenbank ausgeführt. Die dazu nötigen Instruktionen werden ausgehend von einem Aggregationsschnittstellenausdruck auf eine SQL-SELECT-Anweisung abgebildet. Auf die gleiche Weise, wie bereits die Python-Repräsentation einer Aggregationsmethode erzeugt wurde, wird auch die nötige SQL-Repräsentation generiert und gewährleistet damit die Erweiterbarkeit der Aggregationsmethoden. 62
1 class AggregationMethod ( o b j e c t ) : 2... 3 def to_sql ( s e l f ) : 4 return s e l f. s q l % { var : s e l f. a t t r i b u t e } 5 6 class SUM( AggregationMethod ) : 7... 8 s q l = SUM(%( var ) s ) 9 10 class AVG( AggregationMethod ) : 11... 12 s q l = AVG(%( var ) s ) Die komplette SELECT-Anweisung wird mit Hilfe des Django-Templatesystems und folgendem Template generiert: 1 SELECT {{ timestamp_field_name }} 2 3 {% f o r aggr_method in a g g r e g a t i o n. methods %} 4, {{ aggr_method. to_sql }} 5 {% endfor %} 6 7 {% f o r c o n t e x t _ a t t r i b u t e in a g g r e g a t i o n. group_by %} 8, {{ c o n t e x t _ a t t r i b u t e }} 9 {% endfor %} 10 11 FROM ({{ base_table }}) 12 13 WHERE {{ timestamp_field_name }} 14 BETWEEN "{{ time_from }}" AND "{{ time_until }}" 15 16 GROUP BY UNIX_TIMESTAMP({{ timestamp_field_name }}) 17 DIV {{ time_ steps }} 18 19 {% f o r c o n t e x t _ a t t r i b u t e in a g g r e g a t i o n. group_by %} 20, {{ c o n t e x t _ a t t r i b u t e }} 21 {% endfor %} Die SELECT-Elemente bestehen dabei aus dem impliziten, immer mitgeführten Zeitpunkt, dessen Spaltenname aus Kompatibilitätsgründen variabel gehalten wurde, den SQL-Repräsentationen der Aggregationsmethoden sowie den Kontextmerkmalen, nach denen gruppiert wurde. 63
Die FROM-Klausel enthält die Variable base_table, die entweder den Namen der Rohdatentabelle enthält oder - falls eine mehrstufige Aggregation definiert wurde - wieder eine komplette SELECT-Anweisung der Aggregtion die via based_on-argument übergeben wurde. Die WHERE-Klausel schränkt allein den Betrachtungszeitraum ein und die GROUP BY-Klausel definiert hierfür die zeitliche Auflösung, also wie viele Messwerte aggregiert werden. Dazu wird der Zeitpunkt in einen UNIX- Zeitstempel (Sekunden seit 01.01.1970) und damit in eine Ganzzahl umgewandelt, die durch die Sekundenanzahl der gewünschten Auflösung ganzzahlig dividiert wird. Messdaten, deren Ganzzahldivisionsergebnis dabei gleich ist, werden mit Hilfe der in der SELECT-Klausel definierten Aggregationsmethoden zusammengefasst. Formatierungs-Frontends Um die Ergebnisse der Datenbank-Aggregation in ein übertragbares Format zu bringen durchlaufen sie sog. Formatierungs- Frontends, die Djangos Backends nachempfunden sind und eine zusätzliche Möglichkeit der Erweiterbarkeit darstellen. Im Framework enthalten sind ein JSON-Formattierungs-Frontend, welches als Standardfrontend dient und das Datenbank-Aggregationsergebnis in ein JSON-Objekt konvertiert, und ein Google Visualization API DataSource 10 -Formattierungs-Frontend, mit dessen Hilfe sehr schnell verschiedene Diagramme auf Basis der Google Visualization API (siehe 2.3.3) erstellt werden können. 5.3.2 Ereignisbehandlung Um dem Entwickler die Möglichkeit zu geben, auf kritische Werte zu reagieren, besteht die Möglichkeit eine sonst leere Methode zu überschrieben, die beim Eintreffen neuer Messwerte aufgerufen wird. 1 class StreamViewers ( HTTPCollector ) : 2.... 3 def on_new_values ( s e l f, v a l u e s ) : 4 i f v a l u e s [ v iewers ] > 128: 5 mail_admins (... ) 10 Google Visualization API DataSource - http://code.google.com/intl/de/apis/ chart/interactive/docs/dev/implementing_data_source.html 64
Die Methode on_new_values existiert für Kollektoren und Rezeptoren gleichermaßen und bekommt die aktuellen Messwerte übergeben. Ein Entwickler kann diese analysieren und entsprechende Maßnahmen veranlassen, z.b. über die Administratoren-Email-Benachrichigung von Django. 5.4 Zusammenfassung In diesem Kapitel wurde auf die Implementierung des entwickelten Monitoring- Frameworks eingegangen und gezeigt, wie die hierarchisch aufgebaute Struktur Erweiterbarkeit gewährleistet. Viele Funktionen in Sachen Datenhaltung und HTTP-Schnittstellen konnten durch die enge Integration mit dem Webframework Django wiederverwendet werden. Speziell Djangos flexibles Template- System wurde intensiv zur Generierung der entfernt auszuführenden Agenten sowie zur Abbildung der Aggregationsschnittstelle auf die Datenbankabfragen zur Berechnung von Statistiken genutzt. 65
66
6 Validierung und Diskussion Dieses Kapitel zeigt wie die Anforderungen mit Hilfe des entwickelten Frameworks umgesetzt wurden und geht anschließend auf die Fehleranfälligkeit sowie die Skalierbarkeit des Monitoringsystems zum Einsatz in großen Netzwerken ein. 6.1 Umsetzung der Anforderungen Zur Erfüllung der in Abschnitt 3.1 definierten Anforderungen wurde das entwickelte Framework jeweils entsprechend konfiguriert und einige Zeit in einem Testbetrieb überwacht. 6.1.1 Monitoring eines InfoScreen-Netzwerks A1.1 Die Überwachung der Cache-Effizienz wurde mittels Push-Modus umgesetzt. Ein generierter und automatisch installierbarer Agent nimmt dazu unter Nutzung des Logdateianalysewerkzeuges Calamaris eine statistische Auswertung der Logeinträge der letzten Stunde vor und überträgt dessen Resultat anschließend zum Monitoringsystem. Eine entsprechende Statistik errechnet den Durchschnitt der letzten 24 Stunden und erzeugt das in Abbildung 6.1 dargestellte Diagramm. Die vollständige Konfiguration kann im Anhang A.1.1 eingesehen werden. A1.2 Für die Email-Benachrichtigung kam ein Agent zum Einsatz, der periodisch die Cache-Proxy-Logdatei unter Einsatz von awk (siehe Abschnitt 2.2.4) nach dem HTTP-Status der Kategorie 400 filtert und die Ergebnisse überträgt. Eine Ereignisbehandlung überprüft diese Daten und sendet entsprechende Emails an die in der Django-Konfiguration eingetragenen Administratoren. Die vollständige Konfiguration kann im Anhang A.1.2 eingesehen werden. A1.3 Die Arbeitsspeicherauslastung wird ebenfalls per Agent gemessen, der aller 10 Sekunden eine Messung ausführt und nach 5 Minuten den Durchschnitt aller Messungen zum Monitoringsystem überträgt. Eine entsprechende Statistik berechnet nochmals den Durchschnitt über alle Standorte und stellt diesen in einem Flächendiagramm dar. Die vollständige Konfiguration kann im Anhang A.1.3 eingesehen werden. 67
Abbildung 6.1: Balkendiagramm der durchschnittlichen Cache-Effizienz der letzten 24 Stunden pro Dateityp und Standort 6.1.2 Echtzeitnutzerstatistiken von Videostreams A2.1 und A2.2 Die Nutzerstatistiken sowie die ein- und ausgehende Netzwerkbandbreite der Standort-Videostreaming-Server stammen aus dessen angebotenen Webservice und werden per HTTP-Kollektor aller 5 Sekunden abgefragt und gespeichert. Da die Google Visualization API bereits eine periodische Aktualisierung der Diagramme unterstützt, musste bei der Deklarierung nur das Intervall konfiguriert werden. Die Abbildung 6.2 zeigt eine Momentaufnahme des erzeugten Flächendiagrammes. Die vollständige Konfiguration kann im Anhang A.2.1 eingesehen werden. 6.1.3 Nichtfunktionale Anforderungen A3.1 Eine grundlegende Dekomponierbarkeit des System ist bereits durch die funktionale Trennung vom Sammeln der Messdaten und deren Auswertung gegeben. Darauf aufbauend werden beide Hauptfunktionszweige abermals in separate Teilschritte gegliedert (siehe Kapitel 4), sodass unabhängiges Testen gewährleistet ist. 68
Abbildung 6.2: Flächendiagramm der aktuellen Zuschaueranzahl partitioniert nach Standort A3.2 Das Framework wurde von Grund auf erweiterbar konzipiert. Die bisher umgesetzten Komponenten, wie der HTTP-Kollektor sowie der HTTP- Rezeptor wurden allein aus Gründen der Flexibilität des HTTP-Protokolls gewählt und sind sehr einfach durch Implementierungen für andere Protokolle und Schnittstellen austauschbar. Auch können weitere Aggregationsfunktionen (siehe Abschnitt 5.3.1) oder Formatierungsfrontends zur Anbindung anderer Werkzeuge oder Visualisierungen (siehe Abschnitt 5.3.1) sehr einfach hinzugefügt werden. A3.3 Das entwickelte Framework lässt sich als Django-Application (siehe 5.1.1) in jedes Django-Projekt integrieren und da es größtenteils auf den Basis-Funktionen des Webframeworks basiert, kann es leicht von mit Django vertrauten Entwicklern verwendet und erweitert werden. 6.2 Fehleranfälligkeit In einem Testlauf über mehrere Wochen hat sich das System als überwiegend stabil erwiesen. Die aufgetretenen Probleme entstanden einerseits durch temporäre Netzwerkausfälle oder andererseits durch den Ausfall bzw. eine Fehlfunktion des abgefragten Webservices. All diese fehlgeschlagenen Messungen wurden entsprechend protokolliert, sodass sie von einem Administrator im Django-Administrationsinterface einsehbar sind. 69
Diese fehlgeschlagenen Messungen erzeugen allerdings eine Lücke in den Messdaten, die sich je nach Weiterverwendung der Messdaten unterschiedlich auswirken kann. Im Falle der Visualisierung mit Hilfe der Google Visualization Abbildung 6.3: Diagramm mit durch fehlgeschlagene Messungen entstandener Lücke API, die das ausgegebene Datumsformat und damit diese Lücken erkennt, entstehen die Lücken auch im erzeugten Diagramm (siehe Abb. 6.3). Falls jedoch eine andere Visualisierungsbibliothek eingesetzt werden soll oder aber ein anderer Dienst die Messdaten konsumiert, muss dieser die am immer mitgesendeten Zeitpunkt ablesbaren Lücken erkennen und entsprechend behandeln können, damit es zu keiner fehlerhaften Verarbeitung kommt. 6.3 Skalierbarkeit Die bisher ausgeführten Tests bezogen sich auf ein eher kleines Netzwerk mit nur wenigen Standorten, sodass das entwickelte Framework direkt als Bestandteil eines bestehenden Django-Projekts integriert wurde. Jedoch haben Lasttests gezeigt, dass wenn über genügend simulierte Agenten ihre Messdaten übertragen, die zur Verarbeitung dieser erforderliche Rechenlast die Funktion des Django-Projekts empfindlich behindern kann. Ein erster Schritt, diesem Problem beizukommen ist die Auslagerung des Frameworks auf ein dediziertes System. Dazu kann das als Django-Applikation entwickelte Monitoring-Framework einfach in ein neues, leeres Django-Projekt auf dem dedizierten System integriert werden. Ein Test auf einem System mit 2GHz-Doppelkern-Prozessor, auf dem das Monitoring-Django-Projekt sowie die benutzte MySQL-Datenbank installiert wurde, hat gezeigt, dass etwa 1350 Messdaten-Übertragungen der Agenten verarbeitet werden können. Allerdings überschreiten bei weiter steigender Anzahl der überwachten 70