OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann
•
0 gostou•42 visualizações
ImmobilienScout24 betreibt fast 2.000 Server Instanzen mit 160 Applikationen, die von 100 Entwicklern erweitert und von 30 Admins betreut werden, so dass sich Systemänderungen quasi im Stundentakt ergeben. DevOps Mindset, Automation, Continuous Delivery, Sprengfestigkeiten und das konsequente Stagen aller Changes sind Themen die uns bewegen. Die zentrale Komponente zur Datenspeicherung und Auswertung bei ImmobilienScout24 ist Graphite, welches alle Monitoring Informationen enthält. Diese Komponente wird aktiv von Icinga ausgewertet und mit konfigurierten Schwellwerten verglichen. Ziel ist die clientbasierte Konfiguration des Icinga Alarmings, durch Rollout der entsprechenden Werte auf den Client Die Erweiterung unseres Monitoring zur Quelle der Wahrheit im Wellendeployment ist das aktuelle Ziel. Das Icinga Alarming überwacht Instanzen während des Deployment, beeinflusst den Verlauf des Wellenrollout durch unsere Open Source Lösung YADT und informiert die Anwendungsbetreuer bei Fehlern. Da wir hierbei immer wieder an die Konzept- und Leistungsgrenze bestehender OpenSource Lösungen stoßen, entwickeln wir diese zusammen mit den Projekt-Maintainern upstream weiter und stellen diese der Open Source Community zur Verfügung. In dieser agilen Welt ein verlässliches und umfassendes Monitoring und Alarmsystem zu bauen ist Inhalt dieses Talks.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann
Semelhante a OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann (20)
OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann
- 1. www.immobilienscout24.de Monitoring als Quelle der Wahrheit im Wellendeployment Nürnberg | 24.10.2013 | Thomas Lehmann
- 2. Kennzahlen Immobilienscout24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 2 20 Million Besucher pro Monat (35% Mobil) 33,000 Professionelle Immobilien Anbieter pro Monat 73,000 Private Immobilien Anbieter pro Monat 1,5 Million Immobilien Angebote pro Jahr Mehr als 250 Millionen Exposeabrufe pro Monat (47% Mobil) *1 Mehr als 2,6 Millionen Anbieter Kontakte (25% Mobil) *1 *1 August 2013 Quelle ImmobilienScout24
- 3. IT Kennzahlen Immoblienscout24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 3 Breite und Tiefe: ● Mehr als 12.000 Seiten unterhalb der IS24 Domain ● 2 Mobile Web Apps, 9 iOS Apps, 6 Android Apps, 1 Win Mobile App ● Mehr als 1900 Server > 230 Service Typen ● Mehr als 2,5 Millionen Lines of Code IT Operations / Infrastruktur: ● Zwei DataCenter (Berlin, Hamburg) ● Vier Uplink Providers ● Akamai als Content Delivery Network Technology Stack: ● Redhat Enterprise Linux, Scientific Linux ● Java JDK, Tomcat, Ruby, Grails, Python ● Spring MVC, Spring Webflow, Hibernate, JPA ● Oracle RAC Database, Mongo DB, MySQL, Hadoop, elasticsearch August 2013 Quelle ImmobilienScout24
- 4. Betriebliche Anforderungen Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 4
- 5. RPM basiertes Deployment bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 5 Jedes File wird in RPM verpackt: ● Betriebssystem ● Anwendung: Java Tomcat IS24-Scout-Webapp, … ● Config
- 6. RPM basiertes Deployment bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 6 Jedes File wird in RPM verpackt: ● Betriebssystem ● Anwendung: Java Tomcat IS24-Scout-Webapp, … ● Config Vorteile: ● File Mapping ● Updates ● Dependencies ● Cleanup
- 7. Deployment bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 7 Continous Live Deployment (CLD): ● Warum: Features kurz nach Entwicklung live stellen. Schnelles User Feedback für einfache Tests am Markt. ● Das bedeutet für Operations: Releases oft live nehmen. Geringes Risiko, da kleine Änderungen live gehen.
- 8. Deployment bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 8 Continous Delivery: ● Warum: Features kurz nach Entwicklung live stellen, Schnelles User Feedback für einfache Tests am Markt. ● Das bedeutet für Operations: Releases oft live nehmen, Geringes Risiko, da kleine Änderungen live gehen. Stages: ● Aufteilung in Development, QA System und Produktion ● Jedes Update läuft über die drei Stages.
- 9. Deployment bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 9 Continous Delivery: ● Warum: Features kurz nach Entwicklung live stellen. Schnelles User Feedback für einfache Tests am Markt. ● Das bedeutet für Operations: Releases oft live nehmen. Geringes Risiko, da kleine Änderungen live gehen. Stages: ● Aufteilung in Development, QA System und Produktion ● Jedes Update läuft über die drei Stages. Sprengfestigkeit: ● Host lassen sich immer aus den automatisierten Beschreibungen neu aufsetzen. ● Nutzdaten liegen im SAN und werden nicht berührt.
- 10. YADT Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 10 Ziel: Orchestrierung der Inbetriebnahme von Diensten. Voraussetzung: Die Software liegt als Softwarepakete (RPM oder DEB) vor.
- 11. YADT Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 11 Ziel: Orchestrierung der Inbetriebnahme von Diensten. Voraussetzung: Die Software liegt als Softwarepakete (RPM oder DEB) vor. Eigenschaften: ● Berücksichtigt Dienste Modell zur Koordination von Aktualisierungen. ● Kommunikation erfolgt ausschließlich über SSH, ● Dienste werden hochverfügbar hergestellt, ● Steuert die externen Abhängigkeiten in der Umgebung: - Loadbalancer, - Alarming, ….
- 12. Yadt in Aktion Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 12
- 13. Dezentrales Konfiguration-Management Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 13 Stand: ● Verteile Informationen über Betriebssystem / Anwendung / Config, ● Kein zentrales Konfiguration Management oder Beschreibung vorhanden / geplant Warum: Zentrale Konfiguration-Management Systeme sind immer unvollständig, veraltet und für uns nicht nutzbar. Nur der Applikation Server hat die Information welche: ● Anwendungsreleases, ● passende Konfiguration, ● zum Anwendungsrelease passendes Alarming installiert ist. Prinzip: Separation of Concerns
- 14. Monitoring bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 14
- 15. Monitoring bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 15 Unterteilt sich in: - Historisierung - Alarming
- 16. Monitoring ECO System Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 16 Unterteilt sind in drei Bereiche: ● Quellen: Diamond Collector (System Managment), Appmon4j (applikative Metriken), Vmstats (VMware Metriken), … ● Speicherung: Graphite ● Verarbeitung: Icinga, Graphite-Web, Graphsky, …
- 17. Datenfluss im IS24 Monitoring Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 17
- 18. Datenfluss im IS24 Monitoring Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 18
- 19. Datenfluss im IS24 Monitoring Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 19
- 20. Datenfluss im IS24 Monitoring Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 20
- 21. Datenfluss im IS24 Monitoring Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 21
- 22. IS24 Monitoring Projekte YAML Server Exportiert ein Verzeichnis mit YAML Dateien via HTTP. Die YAML Dateien (*.yaml) werden alphabetisch sortiert und gemeinsam ausgeliefert. Features: ● Überschreibungsmechanismus, ● Generische Lösung für YAML Export. Monitoring-Config-Generator Ließt die Monitoring Konfiguration als YAML-Data und schreibt daraus Icinga Config. Features: ● Läuft auf den Icinga Host, ● Bekommt Hostname übergeben, ● Substitution von Variables, ● ETAG Auswertung. Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 22 YAML-files --> YAML-Server --> Monitoring-Config-Generator --> Icinga
- 23. Graphite Basics Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 23 ● Graphite ist eine webbasiserte Graphing Anwendung für Zeit-/Daten Serien ● Geschrieben in Python ● Besteht aus verschiedenen Daemons für Skalierung ● Speicher Backend - Whisper Ähnlich wie RRD, mit weniger Einschränkungen
- 24. Graphite Basics 2 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 24 ● Graphite – Web Web Frontend und API Provider ● Carbon Relay Metrik Transport Duplizierung für Redundanz über Destination Rules Sharding zur Lastverteilung ● Carbon Cache Schreiben die Daten in die Whisperfiles Halten die letzten Updates im RAM > weniger DiskIO ● Whisper für Data Storage als Ring Puffer Aggregation in definierten Intervallen
- 25. Graphite Anforderungen Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 25 ● Geo. Redundante Datenhaltung, ● min. 1 Mio. Metrik Updates pro Minute plus Leselast ● Hochverfügbarkeit, ● Sprengfest, ● Wellendeployment.
- 26. Graphite Überblick Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 26
- 27. Key Features neues Monitoring bei IS24 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 27 ● Measure Anything, Measure Everything ● Eine Implementierung für Alarming und Historisierung von Metriken ● Herstellen einer Abhängigkeit zwischen fachlicher Anwendung und Alarming ● Automatisierte Konfiguration / Staging / Deployment von Alarming Konfiguration ● Steuerung des Alarming während eines Deployments ● „Dashboardfähige“ Graphen und Übersichten
- 28. Measure Anything, Measure Everything Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 28 ● Alle Metriken und alle Events der Plattform sollen historisiert werden ● Zeitlich Korrelation von Events wird möglich ● Alarme für alle relevante Metriken keine Historisierung über Icinga ● Einheitliche Datenerfassung Lösung: Graphite Ausblick: Automatische Suche nach Trends / Anomalien
- 29. Herstellen einer Abhängigkeit zwischen fachlicher Anwendung und Alarming Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 29 Fachliches RPM ändert sich Alarming kann sich ändern! ● Alarming im RPM kann mit der Anwendung angepasst werden. ● Monitoring prüft im weitesten Sinne eine Funktion. ● Funktion ist abhängig von: Software (Version) Config ● Nur auf dem Server stehen alle Informationen zur Verfügung. Service Monitoring Config Applikation prüft
- 30. Staging Alarming Config Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 30 Verlagerung der Monitoring Config auf den Applikation Host ● Stellt die Alarm Definition auf jedem Host zur Verfügung. Host spezifische Variablen für Staging z.B.: Graphite Host pro Stage Basis Set an Alarmen für Systemmanagement Hinzukommen die applikativen Alarmdefinition ● Alarming Config wird über alle Stages ohne Anpassungen propagiert.
- 31. Deployment von Alarming Config Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 31 ● Import und Konvertierung der Konfiguration über monitoring_config_generator ● Erzeugt die Icinga Konfiguration auf dem monserver01 Hosts unter /etc/icinga/conf.d/generated/hostname.cfg (1Host <-> 1File) ● Wertet ein ETAG aus und lädt nur geänderte Konfiguration.
- 32. Steuerung des Alarming während des Deployments Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 32 livestatus_service Rüstet fehlende Icinga Fernsteuerungsmöglichkeiten per http nach. Setzt auf MK- Livestatus auf und gibt den lokalen Socket ins lokale Netz frei. Wird von YADT genutzt. Gründe: ● Für Deployment Automation zwingend notwendig, ● Vorhandene SSH Implementierung passt nicht zum Prinzip: alles ist sprengbar. Features: ● MK-Livestatus Zugang ohne passwortlosen SSH Zugang, ● In Python geschrieben, ● Setzt auf Apache httpd und WSGI, ● Nutzt Apache httpd Server-Side Authentication. YADT --> livestatus_service --> Icinga
- 33. „dashboardfähige“ Graphen Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 33 Metrik reiche Graphen darstellen. Lösung: Graphsky Anforderungen: hohe Verwendungsquote
- 34. „dashboardfähige“ Graphen Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 34 Großbildwand mit Metriken versehen Per Graphsky URL API: …/graph.php?env=grp&c=tuvgrp11&l=no&g=is24-cpu&from=-1 hour&until=-30 seconds&z=xlarge
- 35. Fallstricke Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 35 Graphite: o Gleichmäßige Lastverteilung über die Eingangs Relays notwendig.
- 36. Fallstricke Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 36 Graphite im Wellendeployment: ● Remote Files werden, obwohl Redundanz besteht, nicht korrekt angezeigt. ● Geo Rendundanz in aktueller Implementierung nicht vorgesehen. ● Feature Request Graphite interne Cluster Kommunikation: ● Find - Requests belasten den Cluster, ● Weitere sinnvolle Scalierung fraglich, da Cluster Kommunikation proportional steigt. Icinga Reload Zeiten: ● „Verschwindende“ Hosts im Icinga Web nach einem Reload. ● Schlechter Vektor für CLD und viele Reloads pro Tag.
- 37. Ausblick Q4/2013 bzw. Q1/0214 Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 37 VM Lifecycle vorsehen ● Automatische Dekommissionierung weggefallener Systeme Alarming Abhängigkeiten unter den Services / Host übergreifend umsetzen ● Automatische Erkennung der Abhängigkeiten, ● Automatisches Generieren der notwendigen Icinga Config. Icinga Reloadzeiten optimieren Anreichern von Alarmen mit Zusatzinformation wie: ● Hardware Service Tag, ● Support Telefonnummern, ● Wartungsablauf, …
- 38. Ausblick – Quelle der Wahrheit Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 38 Ziel: ● YADT-Deployment Tool verlässt sich auf den Status im Alarming. ● Verkürzung der Zeit zwischen Rollout - und Anwendung des Config Updates. Idee: ● YADT steuert MonConfUpdater Aktualisiert Alarming Config den Deployment und prüft den Host sofort ● Vor dem Loadbalancer Update (enable Node) muss der Host in Alarming aktuell und Grün sein.
- 39. URLs / Links Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann Seite 39 o Yadt: http://www.yadt-project.org/ o Yaml-Server: https://github.com/ImmobilienScout24/yaml-server o Monitoring-Config-Generator: https://github.com/ImmobilienScout24/monitoring-config-generator o Livestatus-Service https://github.com/ImmobilienScout24/livestatus_service
- 40. www.immobilienscout24.de Vielen Dank für Ihre Aufmerksamkeit! Kontakt: Immobilien Scout GmbH Andreasstraße 10 10243 Berlin Thomas Lehmann Fon +49 30 24 301-1139 Fax +49 30 24 301-1500 thomas.lehmann@immobilienscout24.de