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.
OSMC 2016 | Komponenten Monitoring und Performance Management mit Icinga bei ...NETWAYS
DATEV ist Deutschlands führender Anbieter von Online Anwendungen, Softwarelösungen und Dienstleistungen für Steuerberater, Rechtsanwälte, Wirtschaftsprüfer und deren Mandanten. Dieses Angebot basiert zum Großteil auf einer Vielzahl von IT-Services, welche wiederum durch die verschiedensten IT-Komponenten abgebildet werden. Zielgerichtetes Monitoring dient der Vermeidung von Ausfällen bzw. einer schnelleren Entstörung. Dies bedeutet eine bessere Servicequalität, somit zufriedene Kunden und am langen Ende auch niedrigere Aufwände. Die Open Source Software Icinga ist ein zentraler Baustein der Monitoring Umgebung der DATEV. Der Vortrag betrachtet den Werdegang dieser Erfolgsgeschichte. Angefangen von den ersten Gehversuchen auf den PCs einzelner Mitarbeiter bis hin zur Mehrinstanzen Umgebung mit ca. 14.000 Hosts. Besonderes Augenmerk wird dabei auf die Integration von Icinga in die bestehende IT Service Management Tool und Prozesslandschaft gelegt.
OSMC 2016 - Komponenten Monitoring und Performance Management mit Icinga bei ...NETWAYS
Gunter Geib (40) ist bei der DATEV seit seinem Abschluss als Diplom Ingenieur der Daten- und Informationstechnik im Jahr 2001. Neben diversen anderen Themen (u.a. Verzeichnisdienste) in den ersten Jahren beschäftigt er sich schon immer mit Monitoring und Event Management. Als Consultant im Rang eines Teamleiters berät er nun zu allen Aspekten eines nachhaltigen Monitorings der DATEV-Services. Er fungiert als Bindeglied zwischen Service Ownern, IT-Prozessen, Management, Fachabteilungen und Projekten. Themenschwerpunkte seiner Arbeit sind Event Management, Service Monitoring, IT-Komponenten Monitoring sowie die Prozessintegration nach ITIL. Des Weiteren ist er aktiv an der Weiterentwicklung des Service Asset and Configuration Management Process beteiligt.
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...NETWAYS
Der Geschäftsbereich Enterprise Platforms des IT Dienstleisters s IT Solutions AT betreibt für die Erste Group eine große Anzahl an Systemkomponenten in den Bereichen UNIX, Windows, Applikationen, Datenbanken, Virtualisierung, Storage- und Hardware-Management. Für die Überwachung dieser Systemkomponenten kommt eine Icinga-Umgebung zum Einsatz. Derzeit werden etwa 46000 Host- und Servicechecks auf einer Umgebung durchgeführt, welche für 65000-80000 checks ausgelegt ist, Tendenz steigend.
Im Vortag wird ein Migrationsprojekt von Tivoli Endpoints auf Icinga mit Schwerpunkt auf die Probleme in Zusammenhang mit einer großen Icinga-Installation geschildert. Wesentliche Merkmale sind die (Teil-)Automatisierung der Konfigurationsgeneration aus der CMDB, die Zuordnung von Hosts zu verschiedenen Hostgruppen anhand unterschiedlicher Kriterien, die Automatisierung des deployments von Agents und Plugins sowie die Schnittstelle zum übergeordneten, unternehmensweiten Umbrella Monitoring.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
JCON 2018, Düsseldorf: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaQAware GmbH
Mastering Kubernetes, Juli 2022, Franz Wimmer (@zalintyre, Senior Software Engineer bei QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Observability ist eine entscheidende Komponente jeder ernsthaften Kubernetes-basierten Plattform. Nur so können der zuverlässige Betrieb Cloud-nativer Anwendungen und das schnelle Debugging kniffligster Probleme, die nur in der Produktionsumgebung auftreten, durch die Entwickler gewährleistet werden.
Die wesentlichen Säulen guter Observability sind Logs, Metriken und Traces. Es gibt eine große Anzahl kommerzieller Tools und SaaS-Anbieterr, welche die Aggregation und Analyse der relevanten Diagnosedaten unterstützen.
In diesem Vortrag verwenden wir hingegen einen vollständig auf Open-Source-Bausteinen basierenden Stack: Promtail zum Weiterleiten von Logs an Loki, Prometheus zum Sammeln von Metriken und Tempo zum Empfangen von Traces. Wir zeigen zudem, wie mit der neuen Exemplars-Storage-Funktion der schnelle Übergang von Metriken zu Traces und Logs möglich wird.
CCD 2013 - Aus der Praxis: Performance-Management für ConfluenceWolfgang Gottesheim
Die Performance einer Collaboration-Platform wie Confluence ist ein offensichtliches Kriterium für hohe Akzeptanz und User-Zufriedenheit. Doch die Überwachung von Performance und Verfügbarkeit alleine aus der Rechenzentrumsperspektive ist heute nicht mehr ausreichend. Am Beispiel der Compuware APM Community – einem Self-Service Kunden-Portal mit mehr als 60000 registrierten Usern – zeigen wir, wie wichtig es ist, die Performance aus Anwenderperspektive zu betrachten, da diese auf den unterschiedlichen Endgeräten und in unterschiedlichen geographischen Regionen Einfluss auf die tatsächliche Nutzungserfahrung hat. Wir diskutieren auch jene Kennzahlen die uns helfen, Aussagen über die Nutzung unseres Portals zu gewinnen, um es ständig zu verbessern.
CCD 2013: Performancemanagement für ConfluenceCommunardo GmbH
Veranstaltung "Confluence & JIRA Community Day 2013" in Frankfurt/M. am 21. November 2013.
Eine Präsentation zum Thema "Performancemanagement mit Confluence" von Wolfgang Gottesheim, Technical Product Specialist bei Compuware.
OSMC 2016 | Komponenten Monitoring und Performance Management mit Icinga bei ...NETWAYS
DATEV ist Deutschlands führender Anbieter von Online Anwendungen, Softwarelösungen und Dienstleistungen für Steuerberater, Rechtsanwälte, Wirtschaftsprüfer und deren Mandanten. Dieses Angebot basiert zum Großteil auf einer Vielzahl von IT-Services, welche wiederum durch die verschiedensten IT-Komponenten abgebildet werden. Zielgerichtetes Monitoring dient der Vermeidung von Ausfällen bzw. einer schnelleren Entstörung. Dies bedeutet eine bessere Servicequalität, somit zufriedene Kunden und am langen Ende auch niedrigere Aufwände. Die Open Source Software Icinga ist ein zentraler Baustein der Monitoring Umgebung der DATEV. Der Vortrag betrachtet den Werdegang dieser Erfolgsgeschichte. Angefangen von den ersten Gehversuchen auf den PCs einzelner Mitarbeiter bis hin zur Mehrinstanzen Umgebung mit ca. 14.000 Hosts. Besonderes Augenmerk wird dabei auf die Integration von Icinga in die bestehende IT Service Management Tool und Prozesslandschaft gelegt.
OSMC 2016 - Komponenten Monitoring und Performance Management mit Icinga bei ...NETWAYS
Gunter Geib (40) ist bei der DATEV seit seinem Abschluss als Diplom Ingenieur der Daten- und Informationstechnik im Jahr 2001. Neben diversen anderen Themen (u.a. Verzeichnisdienste) in den ersten Jahren beschäftigt er sich schon immer mit Monitoring und Event Management. Als Consultant im Rang eines Teamleiters berät er nun zu allen Aspekten eines nachhaltigen Monitorings der DATEV-Services. Er fungiert als Bindeglied zwischen Service Ownern, IT-Prozessen, Management, Fachabteilungen und Projekten. Themenschwerpunkte seiner Arbeit sind Event Management, Service Monitoring, IT-Komponenten Monitoring sowie die Prozessintegration nach ITIL. Des Weiteren ist er aktiv an der Weiterentwicklung des Service Asset and Configuration Management Process beteiligt.
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...NETWAYS
Der Geschäftsbereich Enterprise Platforms des IT Dienstleisters s IT Solutions AT betreibt für die Erste Group eine große Anzahl an Systemkomponenten in den Bereichen UNIX, Windows, Applikationen, Datenbanken, Virtualisierung, Storage- und Hardware-Management. Für die Überwachung dieser Systemkomponenten kommt eine Icinga-Umgebung zum Einsatz. Derzeit werden etwa 46000 Host- und Servicechecks auf einer Umgebung durchgeführt, welche für 65000-80000 checks ausgelegt ist, Tendenz steigend.
Im Vortag wird ein Migrationsprojekt von Tivoli Endpoints auf Icinga mit Schwerpunkt auf die Probleme in Zusammenhang mit einer großen Icinga-Installation geschildert. Wesentliche Merkmale sind die (Teil-)Automatisierung der Konfigurationsgeneration aus der CMDB, die Zuordnung von Hosts zu verschiedenen Hostgruppen anhand unterschiedlicher Kriterien, die Automatisierung des deployments von Agents und Plugins sowie die Schnittstelle zum übergeordneten, unternehmensweiten Umbrella Monitoring.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
JCON 2018, Düsseldorf: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaQAware GmbH
Mastering Kubernetes, Juli 2022, Franz Wimmer (@zalintyre, Senior Software Engineer bei QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Observability ist eine entscheidende Komponente jeder ernsthaften Kubernetes-basierten Plattform. Nur so können der zuverlässige Betrieb Cloud-nativer Anwendungen und das schnelle Debugging kniffligster Probleme, die nur in der Produktionsumgebung auftreten, durch die Entwickler gewährleistet werden.
Die wesentlichen Säulen guter Observability sind Logs, Metriken und Traces. Es gibt eine große Anzahl kommerzieller Tools und SaaS-Anbieterr, welche die Aggregation und Analyse der relevanten Diagnosedaten unterstützen.
In diesem Vortrag verwenden wir hingegen einen vollständig auf Open-Source-Bausteinen basierenden Stack: Promtail zum Weiterleiten von Logs an Loki, Prometheus zum Sammeln von Metriken und Tempo zum Empfangen von Traces. Wir zeigen zudem, wie mit der neuen Exemplars-Storage-Funktion der schnelle Übergang von Metriken zu Traces und Logs möglich wird.
CCD 2013 - Aus der Praxis: Performance-Management für ConfluenceWolfgang Gottesheim
Die Performance einer Collaboration-Platform wie Confluence ist ein offensichtliches Kriterium für hohe Akzeptanz und User-Zufriedenheit. Doch die Überwachung von Performance und Verfügbarkeit alleine aus der Rechenzentrumsperspektive ist heute nicht mehr ausreichend. Am Beispiel der Compuware APM Community – einem Self-Service Kunden-Portal mit mehr als 60000 registrierten Usern – zeigen wir, wie wichtig es ist, die Performance aus Anwenderperspektive zu betrachten, da diese auf den unterschiedlichen Endgeräten und in unterschiedlichen geographischen Regionen Einfluss auf die tatsächliche Nutzungserfahrung hat. Wir diskutieren auch jene Kennzahlen die uns helfen, Aussagen über die Nutzung unseres Portals zu gewinnen, um es ständig zu verbessern.
CCD 2013: Performancemanagement für ConfluenceCommunardo GmbH
Veranstaltung "Confluence & JIRA Community Day 2013" in Frankfurt/M. am 21. November 2013.
Eine Präsentation zum Thema "Performancemanagement mit Confluence" von Wolfgang Gottesheim, Technical Product Specialist bei Compuware.
In der Welt der Microservices ist die Anzahl der Logs-produzierenden Prozesse sehr groß und liegt durchaus im Bereich von 100-1000 Prozessen. Eine manuelle Log-Verarbeitung ist hier so gut wie undenkbar. Doch auch monolithische Services laufen oftmals dezentral und das Analysieren der Produktions-Logs ist dann häufig auch mit viel Aufwand verbunden. Mithilfe eines zentralen Loggins lässt sich eine viel bessere Übersicht über den Gesamtzustand eines Systems gewinnen, da nicht jedes Log einzeln untersucht werden muss, sondern die Logs aggregiert und somit auch leicht automatisiert ausgewertet werden können. Elasticsearch bietet die Möglichkeit, große Mengen an Logs zu speichern und zu durchsuchen. Das Ökosystem um Elasticsearch unterstützt Entwickler, DevOps usw. dabei, die Logs schnell und einfach aufzubereiten, damit diese gut analysierbar sind. In diesem Vortrag werden die Vor- und Nachteile des zentralen Loggins dargelegt und gezeigt, wie sich Elasticsearch (bzw. der ELK-Stack) in Umgebungen einbinden lässt.
Nagios Conference 2006 | SAP Monitoring I by Michael KienleNETWAYS
Der Vortrag widmet sich den eher business-orientierten Aspekten des SAP Monitorings. Bereits vor Projektbeginn sollten man sich über die Bedeutung und Notwendigkeit eines SAP-Monitorings klar werden und das Optimierungspotential hinsichtlich Stabilität und Performance evaluieren.
Da selbst ein mittelgroßes SAP R/3 System eine Vielzahl an möglichen Messwerten liefert, liegt ein Schwerpunkt des Monitoring Projektes auf der Auswahl sinnvoller Parameter. Welche davon bedingen einen echten Mehrwert und welche sind überflüssig? Wie legt man dafür sinnvolle Warnschwellen fest? Die technische Integration der SAP R/3 Überwachung ist Gegenstand eines eigenen Vortrags und wird hier nur kurz angedeutet.
In der Zusammenfassung geht es um die Frage ob Nagios den Anforderungen eines Konzerns an das SAP Monitoring genügt und welche Erfahrungen in der Praxis gemacht wurden.
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24Schlomo Schapiro
Der Vortrag gibt einen Einblick in die Betriebsautomation bei ImmobilienScout24.
Warum verfolgen wir eine 100%ige Paketierung aller Inhalte (Config, Software usw.) und welche Vorteile verschafft uns das?
Konkrete (Live Demo) Lösungen für typische Pakete: httpd, tomcat, postfix ...
Live Demo des Config SVNs und seiner Arbeitsweise
Mit welchen Tricks schaffen wir das, alles zu paketieren?
Wie hilft uns die Paketierung mit Dev und Ops und vielen Teams effizient zusammen zu arbeiten?
Continuous Live Deployment als Weg, um das Risiko von Änderungen zu minimieren und viele parallel laufende Änderungen unter einen Hut zu bekommen.
Warum modellieren wir die Abhängigkeiten zwischen Systemen, wie vereinfacht das den Job der Admins?
Generell Einblick in unsere agile Arbeitsweise - Wie sieht DevOps wirklich aus? - Geschichten aus dem wahren Leben. - Ups und Downs.
Die zentralen Tools sind als Open-Source Projekte frei verfügbar:
http://yadt-project.org und https://github.com/yadt
https://github.com/ImmobilienScout24/yum-repo-server
https://github.com/ImmobilienScout24/lab-manager-light
https://github.com/ImmobilienScout24/kickstart-debugger
https://github.com/ImmobilienScout24/kiosk-browser
https://github.com/sonatype/nexus-yum-plugin
Vortragsvideo: http://www.youtube.com/watch?v=UqIY55dc_P8
Konferenzarchiv: https://www.heinlein-support.de/slac/2013/vortrag/viele-server-wenig-arbeit-betriebsautomation-bei-immobilienscout24
Service Mesh - Kilometer 30 im Microservices-MarathonMichael Hofmann
Verteile Anwendungen wie Microservices verlagern einen Teil der Komplexität in das Zusammenspiel der Services untereinander. Ein solches Service Mesh, das bis zu dreistellige (oder mehr) Laufzeitinstanzen haben kann, wird sehr schwierig zu beherrschen. Man muss sich mit Fragen auseinander setzen wie zum Beispiel: Welcher Service wird von welchem Service in welcher Version bei welchem Request-Inhalt wie oft aufgerufen? Wie kann man das Zusammenspiel testen und wie werden einzelne Services durch neue ersetzt?
Diese und andere Fragestellungen werden in der Session beleuchtet. Dabei werden auch Werkzeuge vorgestellt, die das Leben mit dem Service Mesh vereinfachen sollen.
argvis; Maintenance Portal für SAP PM/EAMargvis GmbH
Mit dem argvis; Maintenance Portal bieten wir eine sehr benutzerfreundliche Alternative zum SAP GUI als Oberfläche für den PC-Monitor.
Sie können Meldungen/Aufträge/Rückmeldungen in diesem Portal bearbeiten. Technische Objekte inkl. Fehlerhistorie einsehen und die Wartungsintervalle verfolgen. Weitere Funktionen sind z. B. ein IoT-Monitor für die Überwachung Ihrer Maschinen und Anlagen im Live-Modus. Ein Cockpit für die Darstellung der Kennzahlen Ihrer Instandhaltung. Eine Plantafel um per Drag&Drop Aufträge/Vorgänge Ihren Teams/Mitarbeitern zuzuordnen. Für das Ersatzteilmanagement dürfen nicht natürlich die Warenbestände und Bestellanforderungen nicht fehlen.
Optional gibt es das argvis Maintenance Portal auch als mobile Instandhaltungslösung für Tablet/Smartphone. Die Instandhaltungs-App ist on/offlinefähig und beinhaltet eine Chatfunktion, Push-Benachrichtigungen, die Störungserfassung mit Foto/Video/Audio u. v. m
Scale Out isn’t easy. Especially if you want monitor your assets in an Europe-wide spreaded network based on WAN-connections. The talk would guide you through the past, present and future of building and managing such a project. From the requirements back in 2002 to the fully managed Icinga2 implementation of nowadays.
Mit dem Lösungsansatz sxOSM hat santix bei zahlreichen Kunden, wie z.B. LGT, BMW, Bank Julius Bär u.a., ein leistungsfähiges und zuverlässiges Application Management geschaffen. sxOSM enthält Lösungen für das Monitoring, Event Management und die Integration in das Incident Management. Es umfasst darüber hinaus Prozessvorgaben, Werkzeuge und Best Practices um die implementierten Technologien auch effizient zum Einsatz zu bringen.
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...NETWAYS
War es bis vor einiger Zeit ein sehr teures Unterfangen, Lösungen für modernes Systems Management zu implementieren, so gibt es heute für alle wichtigen Prozesse und Funktionen des Service Management sehr gute Open Source Tools. Der Vortrag bietet einen Überblick über die verschiedenen Lösungen in den wichtigsten Bereichen: Incident & Problem Management, Event Management, Operations Management, Service Desk und CMDB.
Make Developers Fly: Principles for Platform EngineeringQAware GmbH
CloudLand 2023, Juni 2023, Robert Hoffmann (Amazon Web Services) & Alex Krause (QAware)
How can your company help developers to fly, but not crash down? The answer is platform engineering, which is the discipline of building and operating self-service internal developer platforms (IDPs) to simplify software delivery and life cycle management for product teams. In this talk, you will learn how platform engineering evolved from the DevOps movement and what principles and best practices make a good implementation. Finally, we take a look at reference architectures that can power your platform.
BPMasters & Phactum geben einen Einblick über Prozessversionsmigrationen bei langlaufenden Prozessinstanzen und stellen Design Patterns für asynchrone Kommunikation mit Drittsystemen vor.
Vortrag anläßlich der Open RheinRuhr am 08.11.2009. Der Vortrag bot einen Überblick über Open Source Tools für ein Systemmonitoring, vergleicht Lösungen miteinander und zeigt eine mögliche Nagios Installation / Migration auf.
Nagios Conference 2007 | Business Process Monitoring mit Nagios by Michael K...NETWAYS
Nagios hatte weite Verbreitung im Bereich des IT-Infrastruktur-Monitorings gefunden. Die heutige IT konzentriert sich jedoch weniger auf Devices sondern bewegt sich eher in Richtung aktive Unterstützung der wertgenerierenden Geschäftsprozesse; in der Praxis finden sich hier oftmals komplexe Zusammenhänge. Wie können diese mit Nagios ebenfalls überwacht werden?
Digitalisierung leicht gemacht - der Weg zu zunkunftssicheren IT-Landschaften. Keynote auf dem SAP Infotag für die öffentliche Verwaltung am 8. Juli 2015.
Weitere ähnliche Inhalte
Ähnlich wie OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann
In der Welt der Microservices ist die Anzahl der Logs-produzierenden Prozesse sehr groß und liegt durchaus im Bereich von 100-1000 Prozessen. Eine manuelle Log-Verarbeitung ist hier so gut wie undenkbar. Doch auch monolithische Services laufen oftmals dezentral und das Analysieren der Produktions-Logs ist dann häufig auch mit viel Aufwand verbunden. Mithilfe eines zentralen Loggins lässt sich eine viel bessere Übersicht über den Gesamtzustand eines Systems gewinnen, da nicht jedes Log einzeln untersucht werden muss, sondern die Logs aggregiert und somit auch leicht automatisiert ausgewertet werden können. Elasticsearch bietet die Möglichkeit, große Mengen an Logs zu speichern und zu durchsuchen. Das Ökosystem um Elasticsearch unterstützt Entwickler, DevOps usw. dabei, die Logs schnell und einfach aufzubereiten, damit diese gut analysierbar sind. In diesem Vortrag werden die Vor- und Nachteile des zentralen Loggins dargelegt und gezeigt, wie sich Elasticsearch (bzw. der ELK-Stack) in Umgebungen einbinden lässt.
Nagios Conference 2006 | SAP Monitoring I by Michael KienleNETWAYS
Der Vortrag widmet sich den eher business-orientierten Aspekten des SAP Monitorings. Bereits vor Projektbeginn sollten man sich über die Bedeutung und Notwendigkeit eines SAP-Monitorings klar werden und das Optimierungspotential hinsichtlich Stabilität und Performance evaluieren.
Da selbst ein mittelgroßes SAP R/3 System eine Vielzahl an möglichen Messwerten liefert, liegt ein Schwerpunkt des Monitoring Projektes auf der Auswahl sinnvoller Parameter. Welche davon bedingen einen echten Mehrwert und welche sind überflüssig? Wie legt man dafür sinnvolle Warnschwellen fest? Die technische Integration der SAP R/3 Überwachung ist Gegenstand eines eigenen Vortrags und wird hier nur kurz angedeutet.
In der Zusammenfassung geht es um die Frage ob Nagios den Anforderungen eines Konzerns an das SAP Monitoring genügt und welche Erfahrungen in der Praxis gemacht wurden.
Viele Server - Wenig Arbeit: Betriebsautomation bei ImmobilienScout24Schlomo Schapiro
Der Vortrag gibt einen Einblick in die Betriebsautomation bei ImmobilienScout24.
Warum verfolgen wir eine 100%ige Paketierung aller Inhalte (Config, Software usw.) und welche Vorteile verschafft uns das?
Konkrete (Live Demo) Lösungen für typische Pakete: httpd, tomcat, postfix ...
Live Demo des Config SVNs und seiner Arbeitsweise
Mit welchen Tricks schaffen wir das, alles zu paketieren?
Wie hilft uns die Paketierung mit Dev und Ops und vielen Teams effizient zusammen zu arbeiten?
Continuous Live Deployment als Weg, um das Risiko von Änderungen zu minimieren und viele parallel laufende Änderungen unter einen Hut zu bekommen.
Warum modellieren wir die Abhängigkeiten zwischen Systemen, wie vereinfacht das den Job der Admins?
Generell Einblick in unsere agile Arbeitsweise - Wie sieht DevOps wirklich aus? - Geschichten aus dem wahren Leben. - Ups und Downs.
Die zentralen Tools sind als Open-Source Projekte frei verfügbar:
http://yadt-project.org und https://github.com/yadt
https://github.com/ImmobilienScout24/yum-repo-server
https://github.com/ImmobilienScout24/lab-manager-light
https://github.com/ImmobilienScout24/kickstart-debugger
https://github.com/ImmobilienScout24/kiosk-browser
https://github.com/sonatype/nexus-yum-plugin
Vortragsvideo: http://www.youtube.com/watch?v=UqIY55dc_P8
Konferenzarchiv: https://www.heinlein-support.de/slac/2013/vortrag/viele-server-wenig-arbeit-betriebsautomation-bei-immobilienscout24
Service Mesh - Kilometer 30 im Microservices-MarathonMichael Hofmann
Verteile Anwendungen wie Microservices verlagern einen Teil der Komplexität in das Zusammenspiel der Services untereinander. Ein solches Service Mesh, das bis zu dreistellige (oder mehr) Laufzeitinstanzen haben kann, wird sehr schwierig zu beherrschen. Man muss sich mit Fragen auseinander setzen wie zum Beispiel: Welcher Service wird von welchem Service in welcher Version bei welchem Request-Inhalt wie oft aufgerufen? Wie kann man das Zusammenspiel testen und wie werden einzelne Services durch neue ersetzt?
Diese und andere Fragestellungen werden in der Session beleuchtet. Dabei werden auch Werkzeuge vorgestellt, die das Leben mit dem Service Mesh vereinfachen sollen.
argvis; Maintenance Portal für SAP PM/EAMargvis GmbH
Mit dem argvis; Maintenance Portal bieten wir eine sehr benutzerfreundliche Alternative zum SAP GUI als Oberfläche für den PC-Monitor.
Sie können Meldungen/Aufträge/Rückmeldungen in diesem Portal bearbeiten. Technische Objekte inkl. Fehlerhistorie einsehen und die Wartungsintervalle verfolgen. Weitere Funktionen sind z. B. ein IoT-Monitor für die Überwachung Ihrer Maschinen und Anlagen im Live-Modus. Ein Cockpit für die Darstellung der Kennzahlen Ihrer Instandhaltung. Eine Plantafel um per Drag&Drop Aufträge/Vorgänge Ihren Teams/Mitarbeitern zuzuordnen. Für das Ersatzteilmanagement dürfen nicht natürlich die Warenbestände und Bestellanforderungen nicht fehlen.
Optional gibt es das argvis Maintenance Portal auch als mobile Instandhaltungslösung für Tablet/Smartphone. Die Instandhaltungs-App ist on/offlinefähig und beinhaltet eine Chatfunktion, Push-Benachrichtigungen, die Störungserfassung mit Foto/Video/Audio u. v. m
Scale Out isn’t easy. Especially if you want monitor your assets in an Europe-wide spreaded network based on WAN-connections. The talk would guide you through the past, present and future of building and managing such a project. From the requirements back in 2002 to the fully managed Icinga2 implementation of nowadays.
Mit dem Lösungsansatz sxOSM hat santix bei zahlreichen Kunden, wie z.B. LGT, BMW, Bank Julius Bär u.a., ein leistungsfähiges und zuverlässiges Application Management geschaffen. sxOSM enthält Lösungen für das Monitoring, Event Management und die Integration in das Incident Management. Es umfasst darüber hinaus Prozessvorgaben, Werkzeuge und Best Practices um die implementierten Technologien auch effizient zum Einsatz zu bringen.
OSDC 2010 | IT Service Management mit Open Source Software „OpenITSM“ by Juli...NETWAYS
War es bis vor einiger Zeit ein sehr teures Unterfangen, Lösungen für modernes Systems Management zu implementieren, so gibt es heute für alle wichtigen Prozesse und Funktionen des Service Management sehr gute Open Source Tools. Der Vortrag bietet einen Überblick über die verschiedenen Lösungen in den wichtigsten Bereichen: Incident & Problem Management, Event Management, Operations Management, Service Desk und CMDB.
Make Developers Fly: Principles for Platform EngineeringQAware GmbH
CloudLand 2023, Juni 2023, Robert Hoffmann (Amazon Web Services) & Alex Krause (QAware)
How can your company help developers to fly, but not crash down? The answer is platform engineering, which is the discipline of building and operating self-service internal developer platforms (IDPs) to simplify software delivery and life cycle management for product teams. In this talk, you will learn how platform engineering evolved from the DevOps movement and what principles and best practices make a good implementation. Finally, we take a look at reference architectures that can power your platform.
BPMasters & Phactum geben einen Einblick über Prozessversionsmigrationen bei langlaufenden Prozessinstanzen und stellen Design Patterns für asynchrone Kommunikation mit Drittsystemen vor.
Vortrag anläßlich der Open RheinRuhr am 08.11.2009. Der Vortrag bot einen Überblick über Open Source Tools für ein Systemmonitoring, vergleicht Lösungen miteinander und zeigt eine mögliche Nagios Installation / Migration auf.
Nagios Conference 2007 | Business Process Monitoring mit Nagios by Michael K...NETWAYS
Nagios hatte weite Verbreitung im Bereich des IT-Infrastruktur-Monitorings gefunden. Die heutige IT konzentriert sich jedoch weniger auf Devices sondern bewegt sich eher in Richtung aktive Unterstützung der wertgenerierenden Geschäftsprozesse; in der Praxis finden sich hier oftmals komplexe Zusammenhänge. Wie können diese mit Nagios ebenfalls überwacht werden?
Digitalisierung leicht gemacht - der Weg zu zunkunftssicheren IT-Landschaften. Keynote auf dem SAP Infotag für die öffentliche Verwaltung am 8. Juli 2015.
Ähnlich wie OSMC 2013 | Monitoring als Quelle der Wahrheit im Wellendeployment einer dynamischen Webseite by Thomas Lehmann (20)
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
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, ….
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
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.
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