OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz

Icinga2 Scale-Out
Monitoring großer Umgebungen
09.11.2018
Jens Schanz

Müller Holding Ltd. & Co. KG Seite 2
Jens Schanz
●Beruflich
●Teamleiter 2nd Level Support „Linux- und Filials
●Linux- / Unix-Admin seit 1999
●Senior System Engineer und Infrastructure Arch
●Privat
●Verheiratet, 2 Kinder, keine Zeit
●Smarthome-Builder
● jens@jensschanz.de
● @jensschanz
Über mich

Müller in Zahlen
Firmenname: Müller Holding Ltd. & Co. KG
Firmensitz (Verwaltung): 89081 Ulm-Jungingen,
Albstraße 92
Geschäftsführer: Erwin Müller
Zahl der Mitarbeiter: rund 35.000 (überwiegend
Fachkräfte)
Zahl der Auszubildenden: rund 950
Gesamtzahl Filialen: derzeit 828, davon 540 in
Deutschland, 55 in der Schweiz, 81 in
Österreich, 12 in Spanien, 18 in Slowenien, 36
in Ungarn, 86 in Kroatien
Filialen mit Naturshop: derzeit 210 davon 132 in
Deutschland, 8 in der Schweiz, 37 in Österreich, 8
in Slowenien 13 in Ungarn und 12 in Kroatien
Filialgröße: 400 bis über 4.500 m² Verkaufsfläche
Gesamtlagerfläche: 246.416 m², davon 17.998 m²
Lager Ungarn, 9.251 m² Lager Schweiz, 1.080 m²
Lager Spanien
Arealgröße Konzern: 546.945 m²
Abteilungen / Fachmärkte
Drogerie (ca. 50.000 Artikel)
Multi-Media (ca. 42.000 Artikel)
Parfümerie (ca. 28.000 Artikel)
Spielwaren (ca. 20.000 Artikel)
Schreibwaren (ca. 19.000 Artikel)
Haushalt und Ambiente (ca. 11.000 Artikel)
Strümpfe (ca. 7.500 Artikel)
Naturkosmetik (ca. 4.000 Artikel)
Handarbeit (ca. 2.400 Artikel)
OTC (ca. 1.500 Artikel)
Bio Nahrung (ca. 3.000 Artikel)
Sortimentsvielfalt:
ca. 188.000 Artikel

Agenda
- Müller IT in Zahlen -
- Projekt-Historie -
- Anforderungen -
- Umsetzung -
- Ausblick -

Müller IT in Zahlen
•3 Rechenzentren am Standort Ulm
–(noch) 4 getrennte Monitoring-Umgebungen
•1x Icinga
•3x Icinga2
–ca. 1800 Linux-Hosts
•~ 52.000 Service-Checks
–ca. 500 Windows-Hosts
•~ 2.200 Service-Checks
–ca. 650 aktive Netzwerkkomponenten
•~ 2700 Service-Checks

Müller IT in Zahlen
•~ 830 Filialen
–ca. 17.000 Hosts
–ca. 207.000 Services
•ca. 2.700 Systeme vom Typ „PC“
•ca. 4.300 Systeme vom Typ „Kasse“
•ca. 3.500 Systeme vom Typ „EC-Terminal“
•ca. 2.450 Systeme vom Typ „Drucker“
•ca. 1.800 Systeme vom Typ „Router“
•ca. 2.400 System vom Typ „Switch“

Historie
Historie

Historie
•2002
–Projektbeginn und Entscheidung für Nagios
•2003
–„Proof of Concept“ in 5 Filialen
•2004
–Rollout Nagios 1.2 in ca. 350 Filialen mit
selbstgeschriebenem Transport-Modul
•2008
–Umstellung von Nagios 1.2 auf Nagios 3 mit ndoutils als
DB-und „Transport“-Backend und selbstgeschriebenem
zentralen „Müller-Monitoring-Center“
•2009

Historie
•2011
–Migration auf Icinga
•2014/2015
–Migration auf Icinga2
•Umstellung aller 800 Filialen
•Migration den zentralen Icinga-Server auf Icinga2
•2015/2016
–Umstellung auf „Top-Down-Config-Sync“ auf den Filial-
Systemen
•2018
–Scale-Out auf mehrere Satelliten

Anforderungen
Anforderungen
an
ein Monitoring-System

Anforderungen (fachlich)
„Wir müssen merken,
wenn etwas nicht funktioniert
NICHT der Kunde!“
•Monitoring möglichst aller an den Business-Prozessen
beteiligten Komponenten und Services
•Verfügbarkeitsauswertung einzelner Komponenten
•Erkennung fehlerhafter Komponenten die mehrfach
Störungen aufweisen
•Hilfe liefern bei der Beseitigung von Incidents
•„Three-green“-Philosophie bei Software-Auslieferungen

Anforderungen (technisch)
Keep it Simple!
•Hoher Automatisierungsgrad
–ca. 17.000 Hosts (Assets)
–ca. 200.000 Service-Checks
•Erweiterbar, Skalierbar und Flexibel
–7 Länder
–>800 Filialen
–Zentrales Management
–(instabile) WAN-Abindung über DSL, LTE, etc.
•Einfach zu verwalten und zu betreiben
–Kein qualifizierter Zugriff vor Ort möglich

Umsetzung
Umsetzung (fachlich)

Monitoring möglichst aller an den Business-Prozessen
•„Manage Infrastructures NOT Servers“
•Klassifizierung der Systeme in Klassen
–PCs, Kassen, Switche, Router, etc.
•CMS / CMDBs als (gemeinsame) Quelle möglichst aller
Assets
•Automatisiertes anlegen und entfernen von Assets
–Saisonkassen, Switchaustauch (2x 24 Port gegen 1x 48
Port) → Soll-Zustand abbilden und überwachen

Monitoring möglichst aller an den Business-Prozessen

Verfügbarkeitsauswertung einzelner Komponenten
•Aufgrund der Menge Hosts und Services kein klassisches
SLA-Monitoring möglich
•Daten sammeln um Fehler und Ursachen erklärbar zu
machen
•Anomalien sichtbar machen

Verfügbarkeitsauswertung einzelner Komponenten

Erkennung fehlerhafter Komponenten die mehrfach
•Schnelle Identifizierung und Beseitigung wiederkehrender
Hardware-Probleme über die Historie im Icingweb2
•Schnelles Erkennen von Software-Problemen (z.B.
Druckerfehler, Scannerfehler, …)
•Gruppierung von Fehlern (nach Hardware, etc.) um
problematische Komponenten zu erkennen

Erkennung fehlerhafter Komponenten die mehrfach

Hilfe liefern bei der Beseitigung von Incidents
•Anbindung Ticket-System an Icingaweb2
–Verlinkung ins Ticket-System über „icingaweb2-module-
generictts“
•Anzeige des Icinga2 Host- und Servicestatus der CMDB-
Komponente im Ticketsystem (aktuell noch über iframe,
künftig direkt über API und JSON)
•Hilfestellung bieten bei den Service-Checks

•„Standard“-Plugins entsprechend so mit Informationen
erweitern, dass ein(e) Nicht-Techniker(in) im User-Helpdesk
die Ausgabe versteht und handeln kann.
•check_smart vs. check_smart_extended

•Bemerkungsfeld im Icingaweb2 nutzen und Hilfestellung zur
Bearbeitung oder Beseitigung des Fehlers geben

„Three-green“-Philosophie bei Software-Auslieferungen
•Servicegruppen bauen und prüfen ob Änderungen die
gewünschte Wirkung haben.

Herausforderungen
•Informations-Overkill ...

Herausforderungen
•Informations-Overkill durch …
–… volatile Hosts und Services
–… Services die nicht im eigenen Zuständigkeitsbereich
liegen, aber wichtig für die Business-Prozesse sind (z.B.
Fiskalisierung, Kartenzahlungsprovider, …)
–… die Menge an Hosts und Services. Multiplizierung der
Probleme.
–… 24x7 Betrieb mit nicht 24x7-Komponenten und „alte“
Hardware

Herausforderungen
–Wirklich wichtige Dinge herausfiltern, welche unmittelbar
Auswirkungen auf den Geschäftsbetrieb haben (z.B.
Kassensystem nicht erreichbar, Kassensoftware läuft nicht,
etc.).
–Den Rest nur als Information nutzen, wenn ein Incident
gemeldet wird ...
•„Alle Festplattenfehler auf allen Systemen zu beseitigen ist
ein Ding der Unmöglichkeit“
–Nur unbedingt notwendige Dinge automatisiert ins Ticket-
System übernehmen
–Automatische Alarmierung nur für kritische Komponenten
(z.B. Router, Switche, …)

Umsetzung
Umsetzung (technisch)

Software-Stack
•Kein Feenstaub, nur 5 Komponenten:
–Icinga2 (Core-Komponente, Server und Agent gleichzeitig)
–Icingaweb2 (Visualisierung)
–Idoutils (Historie)
–InfluxDB (Metriken)
–Grafana (Metriken)

Hoher Automatisierungsgrad
•Anbindung eines CMS / mehrerer CMDBs an Icinga2 über
Icingaweb2-Director
–Möglichkeiten der Importquellen (SQL, LDAP, Fileshipper,
…) nutzen
–Unpassende Daten mit „Modifikatoren“ manipulieren
–Konsolidierung der Importquellen über
Synchronisationsregel

•Möglichkeit der Importquellen und Synchronisationsregel
vollständig ausnutzen

•Modifikatoren im Import-Prozess nutzen um Daten
anzupassen oder anzureichern

•„Manage Infrastructures
NOT Servers“
•Möglichst Host-Templates in
unterschiedlicher
Ausprägung generieren (und
vererben).
•Custom-Vars intensiv nutzen
und Host-Objekte anreichern
object Host "Kasse 1" {
import "template-host-linux-kasse"
Address = "127.0.0.1"
notes = "Filiale 1334 | Blaubeurerstr. 95 | 89077 Ulm | +49 731 /
93299-0"
groups = [ "F1334", "Umgebung 1" ]
vars.adress_city = "Ulm"
vars.contact_mail = "...@mueller.de"
vars.country_long = "Deutschland"
vars.country_short = "DE"
vars.dependencies = [
"Switch 1",
"Switch 2",
"Switch 3"
]
vars.store = "1334"
vars.vmcode = "KASSE01"
}

•Host-Templates „vererben“
möglich → Vorsicht!
–z.B. Variablen die für alle
Host-Checks benötigt
werden, wie z.B. Ping /
ICMP-Check

•Service-Sets anstelle
einzelner Zuweisungen
verwenden
•Evtl. Service-Sets in
unterschiedlicher
Ausprägung „stapeln“ und
kombinieren
•Apply-Regeln nutzen und
Service-Sets zuweisen
apply Service "Kasse - Fiskalisierung: Modul" {
• import "pos-at-fiscal-module"
assign where match("kasse.*.domain.tld", host.name)
&&
host.vars.country_long == "Österreich"
import DirectorOverrideTemplate
}

Erweiterbar, Skalierbar und Flexibel
•Icinga2-Stack ausnutzen
–Master
–Satelliten
–Agents
•Aber → High-Availability über Virtualisierungsmittel oder
Infrastruktur umsetzen
•Top-Down-Config-Sync nutzen

https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/
Filialen
Kroatien
Zone AT Zone DEZone CH Zone ES Zone HU Zone SI Zone HRZone ST
Zone AT Zone DEZone CH Zone ES Zone HU Zone SI Zone HRZone ST
director
ido
influx
Icingaweb2
Icingaweb2
Load-Balancer
Grafana
Filialen
Staging
Filialen
Österreich
Filialen
Schweiz
Filialen
Spanien
Filialen
Deutschland
Filialen
Ungarn
Filialen
Slowenien
Icinga2
Master

•Herausforderungen
–Hardware
•CPU, RAM und Disk-I/O
–Software
•MariaDB → Tuning für möglichst viele Queries/Second
(qps) → Netzwerk-Traffic beachten!
•Icingaweb2 → ido-Schema → Abfragen / Index
–Fachlich
•Anzahl Service-Checks pro Minute → Inserts, Updates und
Deletes auf der DB → Performance

•Herausforderungen
–Anzahl Verbindungen zum Master
•Not all Endpoints can't reconnect due to "Client TLS
handshake failed" error after "reload or restart" #6517
(https://github.com/Icinga/icinga2/issues/6517)
•→ Fixed in 2.10.0!
–Maximal 2 „Kommando-Endpunkte“ pro Zone möglich
•>2 ergibt Warnung im Logfile und ziemlich wirres Zeugs
–Check-Scheduling bei SNMP-Checks (u.a.
check_nwc_health)

Herausforderungen
•Endpoint → logduration → Bandbreite!
object Endpoint "icinga2-client1.localdomain" {
host = "192.168.56.111"
port = 5665
log_duration = 1d
}
Optional. Duration for keeping replay logs on connection loss. Defaults to 1d
(86400 seconds). Attribute is specified in seconds. If log_duration is set to 0,
replaying logs is disabled. You could also specify the value in human readable
format like 10m for 10 minutes or 1h for one hour.
•Abwärts- und Inkompatibilität(en)
•Agent lassen sich ggf. auf alten Systemen nicht mehr
kompilieren
•Icinga2 vs. Icingaweb2-Director

Herausforderungen
•Notifications
–Checks laufen 24x7
–Notifications nur zu Servicedesk-Zeiten zwischen 06:00
und 22:00 Uhr oder nur für Tagschicht zwischen 06:00 und
15:30 Uhr oder Freitag irgendwas komplett anderes ...
•Aber auch nur wenn Host länger als 3 Stunden im Status
DOWN
apply Notification "Servicedesk - Host: Kasse (Nicht erreichbar)" to Host {
• import "notification-host-by-icinga2-valuemation-template"
• times = {
• begin = 3h
• }
• period = "Servicedesk (Tag-Schicht) - [Mo-Do: 06:00 - 15:30, Fr: 06:00 - 13:00]"
• assign where match("kassen*.*.domain.tld", host.name)

Einfach zu verwalten und zu betreiben
•Automatisierung Client-Installation
–Minimale Agent-Konfiguration
•Minimale Features aktivieren
–Api
–Checker
–Mainlog
•Api-User anlegen
•Enpunkt(e) und (Director-)Zone(n) konfigurieren

Einfach zu verwalten und zu betreiben
•Keine lokale und seperate Konfiguration auf den Clients
vorhalten
–Keine zusätzlichen conf-Dateien
–Kein NRPE!

Herausforderung
•(Eigene) Monitoring-Plugins
–Installation über Repository → Apt und Zypper nutzen
–Build-Prozess aufsetzen und eigene RPM- oder Deb-
Pakete aus VCS-Projekt erstellen und im Repository
bereitstellen
•Abhängigkeiten (Router, Switches)
–Dependency über Custom-Vars und Conf-Datei
–apply Dependency "host-to-parent-router" for (parent in host.vars.dependencies) to Host {
– parent_host_name = parent
– disable_notifications = true
– ignore_soft_states = false
– assign where host.vars.dependencies && match("router.*.domain.tld", host.name)

Fazit

Gegenwart

Zukunft

Fragen?
- Danke für die Aufmerksamkeit -
… Fragen?

OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz

Ähnlich wie OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz (20)

OSMC 2018 | Icinga2 Scale-Out – Monitoring großer Umgebungen by Jens Schanz