Administration & Konfiguration
Die gesamte otwatch-Konfiguration wird als Code in einer Versionsverwaltung gepflegt und über eine Pipeline ausgerollt. Änderungen werden geprüft, in QA getestet und dann in die Produktion übernommen. Jede Änderung ist mit Autor, Zeitpunkt und Inhalt nachvollziehbar.
Checks und Schwellenwerte
Jeder Check hat eine feste Check-ID. Die ID verbindet Alarmregel, Alarm, Dashboard-Panel und Runbook mit Bedeutung, wahrscheinlichen Ursachen und ersten Massnahmen. Check-Katalog und Runbooks stehen Kunden im otwatch HID-Portal zur Verfügung.
- Schwellenwerte werden pro Check festgelegt und können je Umgebung (z. B. PROD strenger als TEST) und je Kunde abweichen.
- Ein Fehler muss während einer definierten Dauer (typischerweise 1–2 Minuten) bestehen, bevor ein Alarm ausgelöst wird. So werden Fehlalarme vermieden.
- Checks können gestuft sein, z. B. Warnung bei 80 % und Kritisch bei 95 % Speicherbelegung.
Schweregrad und Prioritäten
| Schweregrad | Priorität | Bedeutung | Benachrichtigung |
|---|---|---|---|
| Kritisch | P1 / P2 | Produktion beeinträchtigt oder unmittelbar gefährdet | Sofort, Bereitschaft (Push, SMS, Anruf), wiederholt bis zur Quittierung |
| Warnung | P3 / P4 | Funktion beeinträchtigt, Workaround vorhanden, oder Schwellenwert nähert sich | Ticket und E-Mail während der Servicezeiten |
| Information | P5 / P6 | Auffälliges Ereignis ohne direkte Auswirkung | Dashboards und Berichte |
Alarm-Routing und Kanäle
Alertmanager leitet Alarme nach Schweregrad, Umgebung, Komponente, Team und Zeit weiter. Unterstützte Kanäle:
- Jira Service Management (Tickets, Bereitschaftspläne, Eskalation, Quittierung)
- E-Mail und Microsoft Teams
- Webhooks / REST an ITSM- und Event-Management-Plattformen (z. B. ServiceNow, Jira, Splunk)
Zusammengehörige Alarme werden gebündelt und dedupliziert. Abhängigkeitsregeln unterdrücken Folgealarme (z. B. Content-Server-Alarme, während die Datenbank ausgefallen ist). So wird zuerst die Ursache gemeldet. Ein Watchdog-Alarm meldet einen Ausfall des Monitorings selbst.
Wartungsfenster
- Einmalig: eine Stummschaltung (Silence) mit Start- und Endzeit, im Voraus oder ad hoc erstellt.
- Wiederkehrend: Zeitintervalle nach Wochentag, Uhrzeit und Tag im Monat (z. B. jeden Montag 06:00–08:00).
- Geltungsbereich: eine ganze Umgebung, ein Server, eine Komponente oder einzelne Checks.
Während eines Wartungsfensters werden Benachrichtigungen unterdrückt, Metriken aber weiter erfasst. Alarme, die nach dem Fenster noch aktiv sind, werden normal gemeldet. Jedes Fenster wird mit Autor, Grund und Dauer protokolliert.
Benutzer und Rollen
| Rolle | Berechtigungen |
|---|---|
| Viewer | Dashboards, Alarme und Berichte anzeigen |
| Editor | Dashboards erstellen und ändern, Metriken und Logs untersuchen, Wartungsfenster verwalten |
| Admin | Benutzer, Teams, Datenquellen und Konfiguration |
Benutzer melden sich per Single Sign-on an (Microsoft Entra ID, OTDS oder Active Directory). Rollen werden über Verzeichnisgruppen zugewiesen. Die Multi-Faktor-Authentifizierung wird vom Identity Provider durchgesetzt.
Dashboards und Berichte
- Vorgefertigte Dashboards pro OpenText-Komponente, anpassbar pro Kunde und Rolle.
- Drill-down von der Serviceübersicht zu Komponenten, Knoten, Prozessen, Alarmen und Logs.
- Periodische Berichte (Verfügbarkeit, Performance, Kapazität, SLA) als PDF, Excel oder CSV, per E-Mail verteilt.
Datenaufbewahrung
Metriken und Logs werden mindestens 12 Monate aufbewahrt. Die Aufbewahrungsdauer ist pro Bereitstellung und Log-Quelle konfigurierbar.
Weiterführende Informationen
- Alarmregeln in Prometheus
- Alertmanager
- PromQL-Grundlagen
- Benutzer, Teams und Berechtigungen in Grafana
handel gmbh · otwatch Dokumentation · Zuletzt aktualisiert am 19. Oktober 2026