ITEK Fokus-Sitzung: Monitoring

Transkript

1 ITEK Fokus-Sitzung: Monitoring Teilnehmer Moderation: Beiträge: Roland Dietlicher Elmar Heeb, Dani Wunderli, Kaspar Brand, Jan Rellermeyer, Luca Previtali, Beat Müller, Jürgen Winkelmann, Uwe Sujata, Christian Hallquist Protokoll: Präsentation: Thomas Löffler Rolf Moser

2 Thema & Topics: Monitoring (was läuft auf einer Maschine) System-Sanity (z.b. Disk Fehler) Alarmierung (wann werden Meldungen an wen geschickt Accounting und Usage (wer braucht was und wie viel) Verfügbarkeit von Maschinen und Services; History und Reporting über längere Zeiträume Bei den Vorträgen soll auf die Aspekte Aussen- und Innensicht eingegangen werden.

3 Motivation: Servicedienstleister intern und extern Bibliothek, ID etc. mit internen und externen Kunden Optimierung der Dienstleistung (Performancesteigerung und Tuning) Systemverfügbarkeit überwachen und belegen Servicegüte definieren und belegen (Zielsetzungen) Gesamtansicht der komplexen Systeme Einzelmessungen an Systemen ergeben keine Gesamtansicht Endkunden aussagekräftig unterstützen Kunde kann Service nicht erreichen, alle Systeme sind jedoch OK > Innen- und Aussensicht automatische Alarmierung der Verantwortlichen etc.

4 Motivation: Servicedienstleister intern ISG mit internen Kunden Systemverfügbarkeit überwachen und ev. belegen Früherkennung von Problemen (Hardware und Software) bessere Lokalistaion von Problemen automatische Alarmierung der Verantwortlichen SLA Leistungsausweis Systemstatus abfragen (für Kunden)

5 Motivation: Servicedienstleister intern mit Schlüsselservices (z.b DNS) ID / Kommunikation etc. Systemverfügbarkeit überwachen und ev. belegen Früherkennung von Problemen Kunden informieren nicht oder falsch bessere Lokalisation von Problemen Kunde kann Problem nicht eingrenzen Aussage: Internet funktioniert nicht automatische Alarmierung der Verantwortlichen

6 Was wird überwacht? Server Clients Komponenten wie Router / Switches etc. Server/Clients

7 Innensicht & Aussensicht Beim Aufspüren von Problemen kann es wichtig sein das Problem von zwei Seiten einzugrenzen Bottlenecks can occur everywhere ISP ISP ISP Router Router Firewall Load Web Balancer Servers You can buy capacity, but you have to manage for performance and availability Application Server Database Server

8 Monitoring mit Agent Funktion Auf Systeme die überwacht werden muss ein Agent installiert werden Agent übermittelt Resultate an einen Collector oder eine Managmentkonsole Benötigt oft spezielle Privilegien Monitoring ohne Agent Überprüft die laufenden Protokolle und Services Benötigt in der Regel keine erhöhten Privilegien

9

10 Eingesetzte Tool s Kommerzielle Tool s (4) Bibliothek: Mecury Tools Topaz (Aussensicht) und SiteScope (Innensicht) ID Basisdienste: MOM (Innensicht) NET: Intermapper / Big Brother Probes (Innensicht) ID System Dienste: Patrol (Innensicht) und e-ranger (Aussensicht) OpenSource/gratis für nichtkommerziellen Einsatz (1) D-PHYS: Big Brother (Innensicht), RRD (Mail), MRTG (Netzwerk und Fileserver) gemischter Einsatz OpenSource Eigenentwicklungen (1) D-INFK: Nagios und ISG Cockpit (Innensicht) Eigenentwicklungen (2) ID Kommunikation: Checksystem.sh Testsuite (shell) (Innensicht) D-ITET: GOSSIPS (Innensicht)

11 Alarmierung Alarmierung erfolgt nach vorgegebenen Kriterien via SMS via Pager via Mail Zum Teil auch via unabhängiges Wählmodem nur Alarm-Meldungen mit höchster Priorität Adressat Systemverantwortliche Systemmanager Gruppenleiter

12 Alarmierung Alarm Alarm info MODEM Lokal SMS GW Extern/Netz D DNS LOGFILE

13 Alarmierung > Probleme Optimierung der Monitorsysteme Möglichst keine False Positives und False Negatives Optimierung der Systeme, dass keine False Positives ausgelöst werden Alarme nur in dringenden Fällen weitergeben Vielfalt von Events richtig interpretieren und nur berechtigte Alarme weitergeben und eskalieren lassen (z.b. erst nach 10 Wiederholungen Alarm auslösen)!

14 Knowledge Base In verschiedenen Systemen ist eine Knowledge Base integriert und die Tools bieten ein vertieftes Verständnis der Systeme Mecury Tools Topaz und SiteScope (Knowlege Base & Tuning) MOM (Knowlege Base und Konfigurations-Test s etc.) ID System Dienste: Patrol und e-ranger (Knowlege Base etc.) D-ITET: GOSSIPS (Knowlege Base)

15 System Sanitiy Checks an einem laufenden System: System-Sanity Früherkennung von Problemen bevor ein Ausfall auftritt SiteScope MOM Patrol Big Brother etc.

16 Benefit Monitoring kann folgendes bewirken bedeutende Performancesteigerungen effizientere Problembehebung schützt IT-Investitionen hilft bei der Kapazitätsplanung erhöht Effektivität der IT Mitarbeiter zum Teil sind grosse Knowledgebase s im Produkt integriert (MOM, TOPAZ) und unterstützen SYSADMINS verbesserter Kundensupport Akzeptanz der IT-Dienstleistung beim Kunden wird besser etc.

17 Sitescope Beispiel Topaz / Sitescope

18 (Customer) Feedback Liebe Kolleginnen Liebe Kollegen Die Verbesserung der Antwortzeiten des Nebis-Katalogs ist ja gewaltig. So stark habe ich den Effekt nicht eingeschätzt. Vor allem war mir nicht klar, dass auch normale Suchen um einen Faktor 5 und mehr schneller sind. Vorher Nachher Startseite Neustart Wortsuche Indexsuche Vielen Dank an Uwe für die aussagekräftigen Zahlen. Mit freundlichen Grüssen

19 Beispiel: big brother

20 Beispiel: MOM

21 Beispiel: MOM

22 Diskussion Uwe Sujata (ETH-Bibliothek) Mecury Topaz und SiteScope Was sind die Kosten Das System kann auch von anderen ETH Einheiten eingesetzt werden Wie hoch ist der Aufwand für Anpassungen? Scriptsprache: 1-2 Tage Lernaufwand Personalaufwand Nach Implementation eher entlastend (spart Zeit). Minimaler Pflegeaufwand Alarme (zu viele oder zu wenige?) Bei 340 Monitorpunkten 5-10 Warnungen und 1-2 Alarme Wie ist es mit der Sicherheit Falls zentrale Konsole behackt ist > Zugriff auf alle überwachten Systeme möglich Privilegierter Benutzer Es braucht einen privilegierten Nutzer um Daten abholen zu können Ohne Topazkonsole messen Clients weiter und speichern lokal

23 Diskussion Jan Rellermeyer, Luca Previtali (D-INFK) Nagios / ISG Cockpit Wie gross ist die anfallende Datenmenge? 1000 Einträge pro Tag (log) Wer sind die Kunden? Ziel ist das Überwachen der Server (ISG) Service auch für IK s der Institute Zeit und Kosten Opensource-Lösung, somit keine Lizenzkosten Praktikant entwickelt System in ca. 3 Monaten Diverse Bausteine müssen zusammengebracht werden

24 Diskussion Christian Hallqvist (ID Kommunikation) Checksystem.sh Wie wird false-positive ausgeschlossen? Durch die 10 Zyklen bis zum Alarm wird false-positive ausgeschlossen

25 Diskussion Kaspar Brand (D-ITET) GOSSIPS Es gibt Tools, die diese Wünsche erfüllen. Warum selbst entwickeln? Am Anfang im Jahr 2000 waren keine solchen Tool s vorhanden Evaluation im Jahr 2000 hat zur Entwicklung von GOSSIPS geführt Die damals vorhandenen Tools genügten den Anforderungen der ISG.EE nicht Das Tool ist mit der Zeit gewachsen (Stück für Stück wurde weiterentwickelt)

26 Diskussion Daniel Wunderli (ID Basisdienste) MOM Packages für Linux? Können selbe geschrieben werden Keine Erfahrungen mit Hetrogenen Umgebungen! Für Nicht-Standard-Umgebungen müssen eigene Scripts erstellt werden Wie gut sind die KnowlegeBase Artikel? Sehr hilfreich! Kosten Für 15 Server ca. Fr einmalig

27 Diskussion Elmar Heeb (D-Phys) Big Brother, RRD, MRTG Durch die verschiedenen Tool s werden die Daten mehrfach gesammelt! Das ist kein Nachteil Monitoring muss bei gewissen Ereignissen keinen Alarm auslösen Die Granularität kann so erhöht werden

28 Diskussion Jürgen Winkelmann (ID Systemdienste) Patrol / e-ranger Wie brauchbar sind die Reports für die Kunden? Helfen Probleme einzugrenzen Liegt das Problem beim Kunden oder beim Service-Erbringer Reporting belegt Systemverfügbarkeit gegenüber dem Kunden (SLA)

29 Besten Dank Besten Dank für Eure Aufmerksamkeit Protokoll auf