Wikonia:Work-Tools (Projekt)/Evaluierung Monitoring/Logging

1. Zielsetzung

• Unkomplizierte, wartungsarme Überwachung der Kernsysteme (Status, Fehler, Ausfälle)
• Transparenz: Öffentlich zugängliche Statusseite, die Auskunft über Systemzustand, laufende Prozesse und bekannte Störungen gibt
• Möglichkeit zur Verknüpfung mit Request-System (Phorge) für aktuelle Störungsmeldungen/Issues

• Option auf internes Logbuch mit detaillierten Einträgen (zugangsbeschränkt), ggf. auch für Eigenentwicklungen/Bots

2. Evaluierte Optionen

A) Grafana/Prometheus (Kombilösung)

• Vorteile:
  • Sehr mächtige Monitoring-/Visualisierungskette
  • Open Source, flexibel, große Community
  • Beliebig erweiterbar (Metriken, Alarme, Logs, Dashboards)
• Nachteile:
  • Komplexe Einrichtung und Wartung
  • Viele Einzelkomponenten, die aufeinander abgestimmt werden müssen
  • Für aktuelle Anforderungen deutlich überdimensioniert
• Transparenz: Kann Dashboards veröffentlichen, aber recht technisch und aufwendig in der Bedienung für Außenstehende
• Ergebnis:
  • Als zu aufwändig und überdimensioniert verworfen

B) Netdata

• Vorteile:
  • Einfache Installation, ansprechende Web-Oberfläche
  • Echtzeit-Monitoring, viele Metriken ohne Zusatzaufwand
  • Open Source, Docker-fähig
  • Wenig Pflegeaufwand, gute Defaults
• Nachteile:
  • Sehr „live“-orientiert, kaum Langzeithistorie out-of-the-box
  • Keine komplexen Alarmierungs-/Reportingfunktionen
  • Fokus auf Statusvisualisierung, weniger echte Log-Auswertung
• Transparenz: Bietet eine schnelle Statusübersicht, könnte (theoretisch) als öffentliche Statusseite genutzt werden, ist aber technisch gefärbt
• Ergebnis:
  • Im Rennen als pragmatische Monitoring-Lösung, ggf. noch in der Testphase

C) Manuelles Monitoring (Eigenbau/Automatisierung)

• Vorteile:
  • Status- und Logbuchfunktion kann exakt an eigene Anforderungen angepasst werden
  • Direkte Verknüpfung mit Phorge (z. B. automatisiertes Anlegen von Störungstickets) möglich
• Nachteile:
  • Entwicklungs- und Wartungsaufwand initial hoch
  • Eigenverantwortung für Security, Zugangsmanagement etc.
  • „Single Point of Failure“ bei Inhouse-Lösung
• Transparenz: Statusseite nach eigenen Vorstellungen realisierbar
• Ergebnis:
  • Perspektivisch als eigene Entwicklung denkbar, noch nicht entschieden

D) Nagios (klassische Enterprise-Lösung)

• Vorteile:
  • Etabliert, für große Umgebungen geeignet
  • Viele Plugins, mächtige Alarmierungsfunktionen
• Nachteile:
  • Komplexe Einrichtung, viel Overhead
  • Für kleine Projekte völlig überdimensioniert
  • Pflege- und Administrationsaufwand steht in keinem Verhältnis zum Nutzen
• Ergebnis:
  • Wegen Overkill und Aufwand ausgeschlossen

E) SaaS-Lösungen (StatusCake, UptimeRobot etc.)

• Vorteile:
  • Kein Eigenbetrieb nötig, schnelle Einrichtung
  • Alarmierung/Benachrichtigung meist inklusive
• Nachteile:
  • Daten außerhalb der eigenen Infrastruktur
  • Nur Basismonitoring (Ping, HTTP), keine echte Logauswertung
  • Kosten für sinnvolle Features, eingeschränkte Kontrolle
• Transparenz: Bieten Out-of-the-Box-Statusseiten, aber stark eingeschränkt und wenig individuell anpassbar, Integration in eigene Abläufe schwierig
• Ergebnis:
  • Kurz erwogen, aus Datenschutz- und Integrationsgründen abgelehnt

3. Entscheidung und Begründung

Komplexe und Enterprise-orientierte Monitoring-Lösungen (Nagios, Grafana/Prometheus) wurden aufgrund des hohen Pflegeaufwands und mangelnder Verhältnismäßigkeit ausgeschlossen.

Für manuelle Eigenlösungen fehlt die Zeit und Notwendigkeit einer dauerhaften Pflege.

Netdata ist aktuell technisch der favorisierte Kandidat, da es mit wenig Aufwand eine brauchbare Übersicht über den Systemzustand liefert und bei Bedarf problemlos erweiterbar ist.

SaaS-Dienste wurden abgelehnt, um Kontrolle und Datenschutz zu wahren.

Eine konkrete Entscheidung (infolgedessen auch Umsetzung) ist gegenwärtig jedoch noch nicht absehbar.