SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
www.immobilienscout24.de
Monitoring als Quelle der Wahrheit
im Wellendeployment
Nürnberg | 24.10.2013 | Thomas Lehmann
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
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
Betriebliche Anforderungen
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 4
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
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
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.
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.
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.
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.
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, ….
Yadt in Aktion
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 12
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
Monitoring bei IS24
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 14
Monitoring bei IS24
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 15
Unterteilt sich in:
- Historisierung
- Alarming
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,
…
Datenfluss im IS24 Monitoring
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 17
Datenfluss im IS24 Monitoring
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 18
Datenfluss im IS24 Monitoring
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 19
Datenfluss im IS24 Monitoring
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 20
Datenfluss im IS24 Monitoring
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 21
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
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
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
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.
Graphite Überblick
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 26
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
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
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
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.
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.
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
„dashboardfähige“ Graphen
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 33
Metrik reiche Graphen darstellen.
Lösung: Graphsky
Anforderungen: hohe Verwendungsquote
„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
Fallstricke
Monitoring als Quelle der Wahrheit im Wellendeployment | Thomas Lehmann
Seite 35
Graphite:
o Gleichmäßige Lastverteilung über die Eingangs Relays notwendig.
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.
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, …
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.
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
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

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann

Zentrales Logging mit Elasticsearch
Zentrales Logging mit ElasticsearchZentrales Logging mit Elasticsearch
Zentrales Logging mit ElasticsearchSimonSchneider24
 
Nagios Conference 2006 | SAP Monitoring I by Michael Kienle
Nagios Conference 2006 |  SAP Monitoring I by Michael KienleNagios Conference 2006 |  SAP Monitoring I by Michael Kienle
Nagios Conference 2006 | SAP Monitoring I by Michael KienleNETWAYS
 
AdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsAdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsChristoph Adler
 
Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...
Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...
Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...OPITZ CONSULTING Deutschland
 
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24Schlomo Schapiro
 
SMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPM
SMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPMSMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPM
SMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPMNETFOX AG
 
Service Mesh - Kilometer 30 im Microservices-Marathon
Service Mesh - Kilometer 30 im Microservices-MarathonService Mesh - Kilometer 30 im Microservices-Marathon
Service Mesh - Kilometer 30 im Microservices-MarathonMichael Hofmann
 
Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performanceglembotzky
 
argvis; Maintenance Portal für SAP PM/EAM
argvis; Maintenance Portal für SAP PM/EAMargvis; Maintenance Portal für SAP PM/EAM
argvis; Maintenance Portal für SAP PM/EAMargvis GmbH
 
OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz
OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens SchanzOSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz
OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens SchanzNETWAYS
 
Wüstenrot Webinar
Wüstenrot Webinar Wüstenrot Webinar
Wüstenrot Webinar Dynatrace
 
iPaas: Mehr Kür, weniger Pflicht – Integration Platform as a Service
iPaas: Mehr Kür, weniger Pflicht – Integration Platform as a ServiceiPaas: Mehr Kür, weniger Pflicht – Integration Platform as a Service
iPaas: Mehr Kür, weniger Pflicht – Integration Platform as a ServiceSEEBURGER
 
santix Application Management Lösungsansatz
santix Application Management Lösungsansatzsantix Application Management Lösungsansatz
santix Application Management LösungsansatzMichael Santifaller
 
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...NETWAYS
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringQAware GmbH
 
Camunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM OffensiveCamunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM Offensivecamunda services GmbH
 
Nagios Conference 2007 | Business Process Monitoring mit Nagios by Michael K...
Nagios Conference 2007 | Business Process Monitoring mit Nagios  by Michael K...Nagios Conference 2007 | Business Process Monitoring mit Nagios  by Michael K...
Nagios Conference 2007 | Business Process Monitoring mit Nagios by Michael K...NETWAYS
 
Digitalisierung leicht gemacht - Keynote
Digitalisierung leicht gemacht - KeynoteDigitalisierung leicht gemacht - Keynote
Digitalisierung leicht gemacht - KeynoteDetlev Sandel
 

Ähnlich wie OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann (20)

Zentrales Logging mit Elasticsearch
Zentrales Logging mit ElasticsearchZentrales Logging mit Elasticsearch
Zentrales Logging mit Elasticsearch
 
Nagios Conference 2006 | SAP Monitoring I by Michael Kienle
Nagios Conference 2006 |  SAP Monitoring I by Michael KienleNagios Conference 2006 |  SAP Monitoring I by Michael Kienle
Nagios Conference 2006 | SAP Monitoring I by Michael Kienle
 
AdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsAdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsights
 
Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...
Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...
Wie baue ich eine KI, die besser als jeder Mensch ein Problem und dessen Ursa...
 
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24
 
SMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPM
SMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPMSMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPM
SMART SUPPORT / BPM Veranstaltung Berlin 2009 10 15 - BPM
 
Service Mesh - Kilometer 30 im Microservices-Marathon
Service Mesh - Kilometer 30 im Microservices-MarathonService Mesh - Kilometer 30 im Microservices-Marathon
Service Mesh - Kilometer 30 im Microservices-Marathon
 
Skalierung & Performance
Skalierung & PerformanceSkalierung & Performance
Skalierung & Performance
 
argvis; Maintenance Portal für SAP PM/EAM
argvis; Maintenance Portal für SAP PM/EAMargvis; Maintenance Portal für SAP PM/EAM
argvis; Maintenance Portal für SAP PM/EAM
 
Process Monitoring mit Camunda
Process Monitoring mit Camunda Process Monitoring mit Camunda
Process Monitoring mit Camunda
 
OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz
OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens SchanzOSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz
OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz
 
Wüstenrot Webinar
Wüstenrot Webinar Wüstenrot Webinar
Wüstenrot Webinar
 
iPaas: Mehr Kür, weniger Pflicht – Integration Platform as a Service
iPaas: Mehr Kür, weniger Pflicht – Integration Platform as a ServiceiPaas: Mehr Kür, weniger Pflicht – Integration Platform as a Service
iPaas: Mehr Kür, weniger Pflicht – Integration Platform as a Service
 
santix Application Management Lösungsansatz
santix Application Management Lösungsansatzsantix Application Management Lösungsansatz
santix Application Management Lösungsansatz
 
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Camunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM OffensiveCamunda Community Day_Wiener BPM Offensive
Camunda Community Day_Wiener BPM Offensive
 
Open Source Monitoring
Open Source MonitoringOpen Source Monitoring
Open Source Monitoring
 
Nagios Conference 2007 | Business Process Monitoring mit Nagios by Michael K...
Nagios Conference 2007 | Business Process Monitoring mit Nagios  by Michael K...Nagios Conference 2007 | Business Process Monitoring mit Nagios  by Michael K...
Nagios Conference 2007 | Business Process Monitoring mit Nagios by Michael K...
 
Digitalisierung leicht gemacht - Keynote
Digitalisierung leicht gemacht - KeynoteDigitalisierung leicht gemacht - Keynote
Digitalisierung leicht gemacht - Keynote
 

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