592 Konzept zur Überwachung von verteilten Stationen in einem Frühwarnsystem mittels Nagios Stephan GENSCH und Ralph HENNEBERGER Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung Dieser Artikel beschreibt ein Konzept zur Überwachung von Sensorstationen, die über ein Satellitennetzwerk eingebunden sind, innerhalb des Tsunami Frühwarnsystems für die Stationstypen Seismik, cgps und Pegel. Daten über den Zustand einer Sensorstation werden als Housekeeping-Daten bezeichnet, welche im Monitoring System Nagios (Nagios, 2012) dargestellt werden. Nagios ist eine freie, web-basierte Softwarelösung für die Überwachung komplexer IT Infrastruktur. Die Übertragung von Housekeeping-Daten wird über die regulären Datenströme der Sensornutzdaten realisiert. Sensornutzdaten sind Phänomene, welche die Sensorstationen ihrer Funktion nach messen. Um eine Anwendung des Konzeptes zu zeigen, werden derzeit vorhandene meteorologische Daten der Stationsumgebung genutzt, die in einer späteren Umsetzung um relevante Housekeeping-Daten einer Station (Status von PC Komponenten, Gerätetemperatur, Türsensor) erweitert werden sollen. Dieses Konzept soll die Fehlermeldung von defekten Komponenten und deren Analyse ermöglichen und die Wartungs- und Instandsetzungsplanung erleichtern. 1 Einführung Im Frühjahr 2011 konnte das Tsunami Frühwarnsystem, das im Rahmen des German Indonesian Tsunami Early Warning System (GITEWS) Projektes (RUDLOFF et. al. 2009) entstand, an die indonesischen Behörden übergeben werden. Einen erheblichen Anteil am Gesamtsystem haben die zahlreichen Sensoren und Sensorsysteme, die zum Teil über große räumliche Distanzen entfernt aufgestellt sind. Sensornutzdaten werden über eine robuste Kommunikationsarchitektur (ANGERMANN et. al. 2010) an das Warnzentrum in Jakarta weitergeleitet. Über die Sensornutzdatenpakete können Housekeeping-Daten der Sensorstationen in regelmäßigen Abständen mitgeliefert werden, da in der Regel ein Direktzugriff für die Abfrage von Housekeeping-Daten über Satellitenverbindungen zu kostspielig wäre. Zahlreiche Komponenten des Frühwarnsystems sind bereits in das vor Ort installierte Monitoring-System Nagios (NAGIOS 2012) integriert und bieten eine automatisierte Benachrichtigung im Fehlerfall. Im Folgenden wird unser Ansatz der Integration von Housekeeping-Daten der Stationstypen Seismik, cgps (continuous GPS) und Pegel beschrieben. Durch eine permanente Überwachung können Leistungsab- und Systemausfälle zeitnah registriert und Wartungs- und Reparaturmaßnahmen eingeleitet werden. Dies ist besonders Strobl, J., Blaschke, T. & Griesebner, G. (Hrsg.) (2012): Angewandte Geoinformatik 2012. Herbert Wichmann Verlag, VDE VERLAG GMBH, Berlin/Offenbach. ISBN 978-3-87907-520-1.
Konzept zur Überwachung von verteilten Stationen in einem Frühwarnsystem 593 im Hinblick auf schwer, oder nur zu bestimmten Jahreszeiten, erreichbare Stationen von großer Bedeutung. 2 Monitoring verteilter Stationen Sensorstationen müssen auch in abgelegenen Gebieten ohne ausreichende Infrastruktur (keine bis instabile Stromversorgung, keine Kommunikationsanbindung) einsetzbar sein. Neben den funktionalen Komponenten für die Sensordatenerhebung existieren Komponenten für stabile Stromversorgung, Kommunikation und die Überwachung meteorologischer Daten. Eine Erfassung der Housekeeping-Daten, wie Stromspannung, Kapazität und Zustand der Batterie, Luftfeuchtigkeit und Betriebstemperatur von Subsystemen, erlaubt eine Einschätzung des Zustands der Sensorstation aus der Ferne. Es gibt für die Stationstypen Seismik, cgps und Pegel eine Reihe gemeinsamer oder ähnlicher Eigenschaften für den Betrieb (Stromversorgung, Kommunikationsanbindung), aber logischerweise auch funktionale Unterschiede bei der Sensordatenermittlung, Weiterverarbeitung und Datenübertragung/-integration. Diesen Unterschieden und möglichen Lösungswegen wird in den folgenden Unterabsätzen Rechnung getragen. Abbildung 1 stellt den Lösungsansatz einführend dar. Abb. 1: Übersicht des Monitoring-Konzeptes für verteilte Stationen im GITEWS Projekt
594 S. Gensch und R. Henneberger 2.1 Monitoring von Pegelstationen Im Verlauf des GITEWS Projektes wurden vom GFZ zehn küstennahe Pegelstationen in Richtung des Indischen Ozeans in Indonesien errichtet (SCHÖNE et. al. 2011). Abb. 2: Verteilung von Pegelstationen in Indonesien (SCHÖNE et. al. 2011) Diese Pegelstationen liefern zeitgenaue Angaben über Meereshöhe, meteorologische Daten und Angaben über den vertikalen Versatz durch cgps. Der integrierte Stationsrechner kann ungewöhnliche Veränderungen der Meereshöhe (Sea Level Events [SLE]) durch eine Analyse des Tidenhubs auffinden, die möglicherweise den Zeitpunkt des Eintreffens eines Tsunami anzeigen. Insgesamt sind fast einhundert Pegelstationen an indonesischen Küstengebieten im Einsatz, wie Abbildung 2 verdeutlicht. Neben den Pegelstationen des GFZ werden auch indonesische (Badan Koordinasi Survei dan Pemetaan Nasional [BAKOSURTA- NAL]) und internationale (Intergovernmental Oceanographic Commission [IOC]) Pegelstationen benutzt. 2.1.1 Technische Daten und Datenformat Sensornutzdaten werden regelmäßig in Abständen von zwanzig Sekunden erfasst und in einer Datenlogging-Einheit vorgehalten. Für die Wasserstands-Messung sind in der Regel 3 Sensortypen vorgesehen, ein Radarsensor, ein Drucksensor und ein Wasserstands-Sensor. Daten werden in einer eigenen PC Einheit gespeichert und täglich an das Datenverarbeitungszentrum im BAKOSURTANAL weitergeleitet. Das Datenformat der Pegelstationen ist über eine Data Record Definition spezifiziert und enthält Pegel-, cgps- und Meteodaten, sowie zugehörige Metadaten. Das Standarddatum einer Pegelstation (tg_record) enthält unter anderem die Spannungswerte des Stromver-
Konzept zur Überwachung von verteilten Stationen in einem Frühwarnsystem 595 sorgungs-subsystems sowie die Verfügbarkeiten von Sensor 1 bis 3, die für das Monitoring von Interesse sind. Meteodaten geben Aufschluss über Temperatur und Luftfeuchtigkeit in der Umgebung der Station. Denkbare Erweiterungen wären Sensoren, welche die strukturelle Integrität von Pegelstationen (Türverschluss, Detektion von Wassereinbruch) überwachen. 2.1.2 Integration und Nachrichtenfluß Sensornutzdaten von Pegelstationen werden auf Dateisystemebene propagiert und liegen in einem binären Format als *.tgd-dateien vor. Somit ist ein leichtgewichtiger Datenaustausch möglich, was aufgrund der Anbindung über Satellitenkommunikation wichtig ist. Für die Interpretation der Binärdaten sind passende Module (Parser), welche in der Sensorintegrationsplattform Tsunami Service Bus (TSB) (FLEISCHER ET. AL., 2010) implementiert sind, notwendig. Für das Monitoring der Housekeeping-Daten lässt sich der TSB so nachnutzen. Daten werden korrekt interpretiert und in der TSB-eigenen Datenbank vorgehalten. Der TSB stellt Services entsprechend der Sensor Web Enablement (SWE) Spezifikation (OPEN GEOSPATIAL CONSORTIUM, 2012) bereit, über die ein Client Benachrichtigungen über neue Sensornutzdaten empfangen und Abfragen über Sensornutzdaten absetzen kann, z. B. über Nutzung des Sensor Observation Service (SOS). 2.1.3 Methodik der Einbindung Ziel ist die Bereitstellung von Housekeeping-Daten für das Monitoring System Nagios. Über die Implementierung eines Sensor Observation Service (SOS) Client Adapters für Nagios, können konfigurierbare Abfragen mittels valider XML-Dokumente an die TSBinterne Datenbank realisiert werden. Eine Abfrage für ein tg_record liefert so Housekeeping-Daten für einen festgelegten Zeitpunkt für eine Station. Die SOS-Abfrage in Abbildung 3 bezieht sich auf das Offering tidegaugeobservations in der Zeit vom 29. Januar 2012, 0 Uhr, bis zum 31. Januar 2012, 0 Uhr, und das Phänomen aggregatetidegaugewaterheight einer bekannten Station (stationid). Das Resultat wird wiederum in einem XML-Dokument ausgegeben. Es enthält unter anderem eine Zusammenfassung der zur Verfügung stehenden Compo nents, also Elementen des tg_records innerhalb eines Datenarrays. Abbildung 4 stellt exemplarisch ein Meßergebnis eines Meßzeitpunktes dar, der neben den Sensordaten auch Housekeeping-Daten über die Spannung des Subsystems, sowie die Verfügbarkeit der Sensoren enthält. Aus diesem Ansatz heraus kann der angedachte Nagios SWE Client relevante Housekeeping-Daten aus dem aktuellsten Messwert (das letzte Element des Datenarrays) filtern und bereitstellen. Die Reihenfolge der Elemente im resultierenden Dokument wird im Dokument selbst spezifiziert. Das ist entscheidend dafür, dass der Nagios SWE Client den Datensatz korrekt interpretiert und die Werte Subsystem Spannung und Sensor # Verfügbarkeit entsprechend zuordnet. Der Nagios SWE Client kann zusätzlich die WNS (Web Service Notification) Schnittstelle des TSB implementieren und so aktiv über neu eintreffende Daten informiert werden und entsprechende SOS Anfragen absetzen und an den Nagios Rechner leiten.
596 S. Gensch und R. Henneberger <?xml version="1.0" encoding="utf 8"?> <sos:getobservation xmlns:sos="http://www.opengis.net/sos/1.0" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" service="sos" version="1.0.0" srsname="urn:ogc:def:crs:epsg:4326"> <sos:offering> urn:urnsubelement:def:offering:tidegaugeobservations </sos:offering> <sos:eventtime> <ogc:tm_during> <ogc:propertyname> urn:ogc:data:time:iso8601 </ogc:propertyname> <gml:timeperiod> <gml:beginposition> 2012 01 29T00:00:00.000 </gml:beginposition> <gml:endposition> 2012 01 31T00:00:00.000 </gml:endposition> </gml:timeperiod> </ogc:tm_during> </sos:eventtime> <sos:procedure>urn:urnsubelement:stationid</sos:procedure> <sos:observedproperty> urn:urnsubelement:def:phenomenon:aggregatetidegaugewaterheight </sos:observedproperty> <sos:responseformat>text/xml;subtype="om/1.0"</sos:responseformat> </sos:getobservation> Abb. 3: Beispiel einer SOS-Abfrage @@ # Trennzeichen 2012 01 30T08:20:40.000, # Zeitstempel true, # Systemverfuegbarkeit 0.024, # Sensor 1 Wert 2 13.6, # Subsystem Spannung, # Sensor 2 Wert 2 31.6 # Sensor 2 Wert 1,1.766 # Sensor 1 Wert 1,true # Sensor 1 Verfuegbarkeit,11.57 # Sensor 3 Wert 1,true # Sensor 3 Verfueugbarkeit,true # Sensor 2 Verfueugbarkeit, 0.038 # Sensor 3 Wert 2,true # Verfuegbarkeit ausgewerteter Sensor, 0.024 # Wert 2 ausgewerteter Sensor,1.766 # Wert 1 ausgewerteter Sensor Abb. 4: Beispiel eines Sensordatenauszugs innerhalb eines Antwortdokuments auf eine- SOS-Abfrage 2.2 Monitoring von cgps-stationen Im Anwendungsbereich von Frühwarnsystem kommt es besonders auf Zuverlässigkeit, Genauigkeit und auf die schnelle Verfügbarkeit der Daten an. Dazu wurden die am GFZ entwickelten sogenannten cgps Real-Time Referenzstationen (RTR) aufgebaut. Die Sta-
Konzept zur Überwachung von verteilten Stationen in einem Frühwarnsystem 597 tionen zeichnen sich besonders durch ihren modularen Aufbau und die damit verbundene gute Wartbarkeit aus. Im Fehlerfall können einzelne Komponenten sehr einfach ausgetauscht werden. 2.2.1 Technische Daten und Datenformat Die folgende Abbildung zeigt einen typischen Aufbau einer cgps RTR-Station. Abb. 5: Vordergrund: Vorderseite mit Modulen und Verkabelung einer GITEWS cgps RTR-Station; Hintergrund: VSAT-Antenne für Satellitenkommunikation (links) und cgps-antenne auf Betonfundament (rechts) (RUDLOFF et. al. 2012) In der ersten Phase des GITEWS-Projekts war es nur möglich die einzelnen RTR-Stationen in definierten Zeitabständen (alle 10 Minuten) auf Erreichbarkeit zu prüfen. Im Fall, dass die Station nicht mehr erreichbar war, gab es keine Möglichkeit die genaue Ursache herauszufinden. Mögliche Fehler können der Ausfall der VSAT-Antenne (Very Small Aperture Terminal Satellitenempfänger und -sender) oder des Modems, ein Spannungsabfall der Stromversorgung oder auch eine Überhitzung des Rechners sein. 2.2.2 Methodik der Einbindung Durch die Erweiterung in der Überwachung der RTR Stationen können jetzt zusätzlich zu den Sensornutzdaten auch die Messwerte der externen meteorologischen Sensoren (Temperatur, Luftfeuchtigkeit, Luftdruck, Spannungsversorgung der Batterie) als Housekeeping- Daten übertragen und separat ausgelesen werden. Dabei werden die relevanten Daten für das Monitoring in eine separate Datei auf dem Nagios Rechner in einem definierten Verzeichnis im Receiver Independent Exchange Format (RINEX) abgelegt. Abbildung 6 zeigt den Aufbau einer Datei für die Station Maumere (MMRI).
598 S. Gensch und R. Henneberger 2.1 METEOROLOGICAL DATA RINEX VERSION / TYPE meteo_read 1.0 GFZ Potsdam 24 Jan 2012 07:12 PGM / RUN BY / DATE mmri MARKER NAME Sensor ID: : C3540006 COMMENT 3 PR TD HR # / TYPES OF OBSERV Vaisala PTU300 0.1 TD SENSOR MOD/TYPE/ACC Vaisala PTU300 0.1 PR SENSOR MOD/TYPE/ACC Vaisala PTU300 1.5 HR SENSOR MOD/TYPE/ACC END OF HEADER 12 01 24 07 00 00 1001.8 28.9 72.8 12 01 24 07 05 00 1001.8 28.9 72.2 12 01 24 07 10 00 1001.7 29.0 72.2 Abb. 6: RINEX Beispieldatei. Die letzten 3 Zeilen bilden Zeitstempel, Luftdruck, Temperatur und Luftfeuchtigkeit ab. Es werden jeweils drei Messzeitpunkte mit einen Zeitstempel und den Messergebnissen gespeichert. Diese Daten werden vom Nagios Rechner ausgewertet und graphisch dargestellt. Abb 7: Beispiel Temperatur: Indonesische cgps-station in Maumere Somit kann ein langfristiges Monitoring sowie eine statistische und graphische Auswertung der Umgebungsparameter gewährleistet werden. Dies erlaubt im Falle einer Fehlermeldung eine schnelle Ursachenanalyse und gegebenenfalls die Einleitung benötigter Wartungsarbeiten. Um die Aktualität der eintreffenden Daten zu verifizieren wird der Zeitpunkt der Messung mit dem Datum des Analyserechners abgeglichen und aus der sich ergebenen Differenz das tatsächliche Alter der Messdaten ermittelt. So werden Fehlermeldungen in den Housekeeping-Daten der cgps Sensoren immer nur aus den aktuellsten Messungen generiert. Im Falle einer Zeitdifferenzüberschreitung wird eine separate Fehlermeldung erstellt. Abb. 8: Darstellung von meteorologischen Housekeeping Daten im Web-Interface von Nagios
Konzept zur Überwachung von verteilten Stationen in einem Frühwarnsystem 599 2.3 Monitoring von seismischen Stationen Die Überwachung der seismischen Stationen erfolgt über einen ähnlichen Ansatz wie bei den anderen Sensortypen. Es werden die vorhandenen Datenübertragungswege benutzt, um zusätzlich die Housekeeping-Daten der seismischen Stationen abzugreifen. In Indonesien gibt es derzeit ca. 160 seismische Stationen, die alle über das Internet verbunden sind. Die Daten der einzelnen Station werden mittels SeedLink-Protokoll im Mini-SEED-Format übertragen. (HEINLOO, A., 2012) Diese bestehen aus 512-Byte großen Mini-SEED-Paketen. SeedLink ist als TCP/ IP Client-Server-Anwendung konzipiert. Abb. 9: Integration von Housekeeping-Daten seismischer Stationen Die SeedLink Client-Server-Schnittstelle erlaubt einem Client von jedem System, welches eine TCP/ IP-Verbindung zum SeedLink Server aufbauen kann, die Daten abzufragen. Diese Möglichkeit wird für die Überwachung einzelner Station genutzt. Der Nagios Rechner fragt den SeedLink Server nach Daten für eine bestimmte Station ab, wertet die empfangenen Daten aus und stellt sie dar. Abb. 10: Darstellung von Housekeeping Daten einer seismischen Station im Web- Interface von Nagios 2.4 Systembedingte Einschränkungen Bedingt durch die Kosten bei der Übertragung von Stationsdaten über das Satellitennetzwerk, werden Daten in längeren Zeitabständen zusammengefasst gesendet und ermöglichen so keine Überwachung der Station in Echtzeit oder Beinahe-Echtzeit. Jedoch sind alle Daten eines Zeitabschnittes für Statistiken ab dem Empfangszeitpunkt vorhanden. Der letzte Messzeitpunkt kann jedoch zeitlich weit vor dem Abfragezeitpunkt liegen, je nachdem wann Stationsdaten empfangen wurden. Besonders bei den Pegelstationen, wo Daten in der Regel einmal pro Tag empfangen werden, können sich so große zeitliche Lücken ergeben. Durch die separate Prüfung der Zeitstempel der Daten sind jedoch für eine Analyse verwertbare Daten vorhanden. Eine Erfassung weiterer Leistungsparameter (Rechnertemperatur, Kernspannung) kann zusätzlich über die Sensornutzdaten übermittelt werden und mit dem gleichen Konzept verwertet werden. Zurzeit wird als echtes Housekeeping- Datum einer Station die Spannung der Stromversorgung erfasst. Die meteorologischen Daten geben naturbedingt keine Aussage über den Zustand einer Station wieder, unterstützen jedoch, wie eingangs beschrieben, als Platzhalter das angedachte Konzept.
600 S. Gensch und R. Henneberger 3 Zusammenfassung und Ausblick In Abbildung 1 wurde das bestehende Konzept des Stations-Monitoring noch einmal zusammengefasst verdeutlicht. Es werden zwei mögliche Ansätze zur Erfassung von Housekeeping-Daten dargestellt. Für seismische und cgps Stationen wird ein Parallel-Dump des Datenstroms erzeugt und über angepasste Nagios Skripte verwertet. Diese Lösung ist kurzfristig und schnell einsetzbar und für cgps Daten bereits erfolgreich umgesetzt. Da Pegeldaten im binären Format übertragen und erst prozessiert werden müssen, bietet sich die Lösung eines parallelen Dumps nicht an, da die komplette Weiterverarbeitung erneut implementiert werden muss, und so zu erhöhter Last auf den produktiven Hosts führt. Aus diesem Grund ist angedacht, die vorhandene Prozessierung durch einen zu entwickelnden Nagios SWE Client zu nutzen. Um das Konzept weiter zu vereinheitlichen, kann der Nagios SWE Client um die seismischen und cgps Daten erweitert werden, und so die Methodik des Parallel-Dumps ersetzen, wie in Abbildung 11 dargestellt. Abb. 11: Vereinheitlichung des Monitoring-Konzeptes für verteilte Stationen im GITEWS Projekt Die Housekeeping-Daten des seismischen und des cgps Systems müssen ebenfalls in die Sensorintegrationsplatform TSB übertragen werden. Dadurch kann eine Vereinheitlichung des Stations-Monitoring erreicht und die zu wartenden Softwarekomponenten bei der Erweiterung von Housekeeping-Daten verringert werden. Literatur ANGERMANN, M., GUENTHER, M. & WENDLANDT, K. (2010), Communication architecture of an early warning system. In: Natural Hazards and Earth System Science, 10/11, 2215-2228. FLEISCHER, J., HÄNER, R., HERRNKIND, S., KLOTH, A., KRIEGEL, U., SCHWARTING, H. & WÄCHTER, J. (2010), An integration platform for heterogeneous sensor systems in GITEWS Tsunami Service Bus. In: Natural Hazards and Earth System Science, 10/06, 1239-1252. HEINLOO, A. (o. J.), SeedLink Design Notes and Configuration Tips. http://geofon.gfzpotsdam.de/geofon//seiscomp/seedlink.html (31.01.2012).
Konzept zur Überwachung von verteilten Stationen in einem Frühwarnsystem 601 LAUTERJUNG, J., KOLTERMANN, P., WOLF, U. & SOPAHELUWAKAN, J. (2010), The UNES- CO-IOC framework establishing an international early warning infrastructure in the Indian Ocean region. In: Natural Hazards and Earth System Science, 10/12, 2623-2629. NAGIOS (O. J.), The Industry Standard in IT Infrastructure Monitoring. http://nagios.org (31.01.2012). OPEN GEOSPATIAL CONSORTIUM (o. J.), Sensor Web Enablement. http://opengeospatial.org/ ogc/markets-technologies/swe (31.01.2012). RUDLOFF, A., LAUTERJUNG, J., MÜNCH, U. & TINTI, S. (2009), Preface The GITEWS Project (German-Indonesian Tsunami Early Warning System). In: Natural Hazards and Earth System Science, 9/04, 1381-1382. RUDLOFF, A., LAUTERJUNG, J. & MÜNCH, U. (o. J.), GPS Real-Time Referenzstationen. http://www.gitews.de (31.01.2012). SCHÖNE, T., ILLIGNER, J., MANURUNG, P., SUBARYA, C., KHAFID, ZECH, C. & GALAS, R. (2011), GPS-controlled tide gauges in Indonesia a German contribution to Indonesia's Tsunami Early Warning System. In: Natural Hazards and Earth System Science, 11/3, 731-740.