ServiceNow-Integration für Incidents und CMDB
Verbinden Sie Obseria über Automation-Workflows und die ServiceNow REST API: Probleme werden zu Incidents mit Ursachenkontext, CIs werden aus der CMDB angereichert, und der Status bleibt synchron.
Warum ServiceNow mit Obseria überwachen
Incidents mit Kontext
Jeder Incident enthält betroffenen Service, Auswirkung, wahrscheinliche Ursache und einen Verweis auf die Beweiskette in Obseria.
Weniger Rauschen in der Queue
Nur korrelierte Probleme erzeugen Tickets, nicht jeder einzelne Alert. Zuständige Gruppen sehen einen Incident pro Problem.
Status in beide Richtungen
Updates und Lösungen aus ServiceNow fließen zurück zu Obseria, und Obseria aktualisiert das Ticket, sobald sich ein Problem erholt.
Was die ServiceNow-Integration abdeckt
- Incident-Erstellung. Obseria-Automation-Workflows legen beim Öffnen eines Problems Incidents über die ServiceNow Table API an.
- Updates und Abschluss. Work Notes, Änderungen der Schwere und die Erholung werden über die Correlation ID in denselben Incident geschrieben.
- Bidirektionaler Status. Eine Business Rule oder ein Flow in ServiceNow ruft die Obseria-API auf, damit Bestätigungen und Abschlüsse in Obseria erscheinen.
- CMDB-Anreicherung. Configuration Items aus der CMDB werden nachgeschlagen, damit Incidents auf das richtige CI, den Owner und die Zuweisungsgruppe verweisen.
- Change-Korrelation. Change Requests aus ServiceNow lassen sich als Deployment-Events neben der Telemetrie an Obseria senden.
- Routing und Priorität. Impact und Urgency ergeben sich aus Service-Kritikalität und SLO-Burn, sodass die Priorität der fachlichen Auswirkung folgt.
Was synchronisiert wird
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Incidents anlegen
Wandelt erkannte Probleme in klare Tickets mit kurzer Zusammenfassung und ausführlicher Beschreibung um, ganz ohne manuelles Kopieren.
Priorität und Zuständigkeit
Legt geschäftliche Auswirkung und Dringlichkeit fest und leitet jeden Incident an das richtige Team weiter, damit nichts liegen bleibt.
Kontext und Verknüpfung
Verbindet jeden Incident mit dem betroffenen System und zugehörigen Alerts, damit Dubletten vermieden und Ursachen klar werden.
Aktueller Bearbeitungsstand
Hält Tickets mit Fortschrittsnotizen aktuell und schließt sie automatisch, sobald das Problem behoben ist.
Alle 9 Metriken im Detail anzeigen
| Feld | Typ | Inhalt |
|---|---|---|
short_description | field | Incident-Titel aus Problem-Zusammenfassung und betroffenem Service. |
description | field | Ursachen-Zusammenfassung, Beweiskette und betroffene Entitäten aus Obseria Intelligence. |
impact | field | Abgeleitet aus Anzahl betroffener Nutzer oder Services und der Service-Kritikalität. |
urgency | field | Abgeleitet aus SLO-Burn-Rate oder Schwere des Problems. |
assignment_group | field | Zuständiges Team, ermittelt aus dem Service-Katalog oder dem CMDB-CI. |
cmdb_ci | field | Verweis auf das Configuration Item, das zur betroffenen Obseria-Entität passt. |
correlation_id | field | Problem-ID aus Obseria, um denselben Incident zu aktualisieren und zu schließen. |
work_notes | field | Zeitliche Updates, die Obseria während des Problemverlaufs schreibt. |
state | field | Incident-Status; Änderungen werden zurück zu Obseria synchronisiert. |
ServiceNow-Monitoring in wenigen Minuten einrichten
- Schritt 1
Integrationsuser anlegen
Legen Sie in ServiceNow einen User mit nur den nötigen Rollen für Incident- und CMDB-Tabellen an und hinterlegen Sie die Zugangsdaten als Secret in Obseria.
- Schritt 2
Automation-Workflow bauen
Lösen Sie bei Öffnen, Aktualisieren und Schließen eines Problems einen Obseria-Automation-Workflow aus, der die ServiceNow Table API aufruft.
- Schritt 3
Rückweg aktivieren
Ergänzen Sie in ServiceNow eine Business Rule oder einen Flow, der Statusänderungen an die Obseria-API sendet.
# Request, den ein Obseria-Automation-Workflow beim Öffnen eines Problems sendet
# (ServiceNow Table API, Tabelle incident)
curl -s -X POST \
"https://${SN_INSTANCE}.service-now.com/api/now/table/incident" \
-u "${SN_USER}:${SN_PASSWORD}" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{
"short_description": "checkout-api: Fehlerrate über SLO",
"description": "Wahrscheinliche Ursache: erschöpfter Connection Pool auf orders-db",
"impact": "2",
"urgency": "1",
"cmdb_ci": "checkout-api",
"assignment_group": "Checkout Team",
"correlation_id": "obseria-problem-4711"
}'Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Offene Incidents je Service und Priorität
- Probleme ohne verknüpften Incident
- Zeit von Erkennung bis Incident
- Incidents je CMDB-CI
- Sync-Fehler zwischen Obseria und ServiceNow
ServiceNow-Monitoring: Darauf kommt es an
Warum Observability und ServiceNow zusammengehören
In vielen Unternehmen ist ServiceNow das führende System für Incidents, Changes und Configuration Items. Observability-Plattformen sind dagegen der Ort, an dem Probleme erkannt und analysiert werden. Sind beide getrennt, kopieren Engineers Alert-Details von Hand in Tickets, Incidents fehlt der technische Kontext, und der Ticketstatus sagt wenig darüber aus, ob sich das System tatsächlich erholt hat. Eine ServiceNow-Integration schließt diese Lücke: Erkannte Probleme werden automatisch zu Incidents mit den Informationen, die das Team braucht, und beide Werkzeuge bleiben bis zur Lösung abgestimmt.
Ziel ist nicht, für jeden Alert ein Ticket anzulegen. Eine gute ServiceNow-Incident-Integration erzeugt einen Incident pro echtem Problem, leitet ihn an das richtige Team und aktualisiert ihn, während sich die Lage entwickelt. Das reduziert Rauschen im Service Desk und verkürzt die Zeit bis zur Lösung.
So fließen die Daten
Von Obseria zu ServiceNow
Obseria fasst zusammengehörige Alerts zu einem Problem zusammen und ermittelt die wahrscheinliche Ursache. Ein Obseria-Automation-Workflow, als Code geschrieben, reagiert auf Problem-Events und ruft die ServiceNow Table API auf. Beim Öffnen legt er einen Incident mit Kurzbeschreibung, Beschreibung, Impact, Urgency, Zuweisungsgruppe und Configuration Item an. Die Problem-ID aus Obseria landet im Feld correlation_id, damit spätere Updates und der Abschluss denselben Datensatz treffen.
Von ServiceNow zu Obseria
Für den bidirektionalen Status sendet eine Business Rule oder ein Flow in ServiceNow Statusänderungen, Zuweisungen und Lösungsnotizen an die Obseria-API. Wer in Obseria arbeitet, sieht, ob der Incident bestätigt wurde und wem er gehört, ohne das Werkzeug zu wechseln.
CMDB-Anreicherung
Eine ServiceNow-CMDB-Integration ordnet Obseria-Entitäten wie Services, Hosts oder Datenbanken den Configuration Items zu. Der Workflow sucht das CI über den Namen oder eine andere Kennung und übernimmt Owner und Zuweisungsgruppe aus der CMDB. TopoGraph ergänzt die aktuellen Abhängigkeiten, die der CMDB womöglich fehlen. So sehen Responder sowohl das registrierte CI als auch seinen aktuellen Laufzeitkontext.
Typische Fallstricke vermeiden
- Ticketfluten: Incidents aus einzelnen Alerts überfordern den Service Desk. Lösen Sie stattdessen bei korrelierten Problemen aus.
- Doppelte Incidents: Ohne stabile Correlation ID erzeugen Retries oder flatternde Probleme neue Tickets. Aktualisieren Sie immer über
correlation_id. - Veraltete Tickets: Incidents, die nach der Erholung offen bleiben, verdecken echte Probleme. Lassen Sie Obseria Erholungsnotizen schreiben und den Abschluss vorschlagen.
- Falsches Routing: Veraltete CMDB-Daten leiten Incidents an das falsche Team. Vergleichen Sie CMDB-Beziehungen mit der von Obseria erkannten Topologie und markieren Sie Abweichungen.
- Zu weitreichende Rechte: Der Integrationsuser sollte nur auf die benötigten Tabellen zugreifen.
Change-Korrelation
Viele Incidents folgen auf eine Änderung. Gelangen Change Requests aus ServiceNow als Deployment-Events zu Obseria, kann Obseria Intelligence sie als mögliche Ursache gewichten, und die Incident-Beschreibung kann die zugehörige Change-Nummer direkt nennen. Das erspart Respondern die manuelle Suche im Change-Kalender und beschleunigt die Entscheidung, ob ein Rollback sinnvoll ist. Gleichzeitig entsteht eine belastbare Datengrundlage, um die Erfolgsquote von Changes im Zeitverlauf auszuwerten.
Best Practices für die ITSM-Integration
- Legen Sie vor dem Go-live fest, wie Problemschwere und SLO-Burn auf Impact und Urgency in ServiceNow abgebildet werden.
- Schreiben Sie eine kurze Ursachen-Zusammenfassung und die betroffenen Services in die Beschreibung, keine rohen Metrikdaten.
- Senden Sie Change Requests aus ServiceNow als Deployment-Events an Obseria, damit Änderungen neben der betroffenen Telemetrie erscheinen.
- Überwachen Sie die Integration selbst: Fehlgeschlagene API-Aufrufe und Sync-Verzögerungen sollten jemanden alarmieren.
- Prüfen Sie geschlossene Incidents regelmäßig, um festzulegen, welche Probleme ein Ticket öffnen sollen.
So unterstützt Obseria
Obseria Automation führt Workflows als Code aus. Die ServiceNow-Integration ist damit versioniert, prüfbar und testbar wie jeder andere Code. Obseria Intelligence liefert Ursache und Beweiskette für die Incident-Beschreibung, der Service-Katalog die Zuständigkeiten. Da API-Zugriff, Automatisierung und Alerting in jedem Obseria-Tarif enthalten sind, braucht die Anbindung von ServiceNow kein zusätzliches Modul. Das Ergebnis sind weniger, aber bessere Incidents und ein kürzerer Weg von der Erkennung bis zur Lösung, was die MTTR direkt verbessert.
Verwandte Integrationen
Passende Funktionen
Incident Management
Steuern Sie Incidents in der Plattform, die sie erkannt hat: Alarmierung, Koordination und Auswertung mit On-Call-Plänen, Eskalation, Live-Timeline und Post-Mortems.
Mehr erfahrenService-Katalog
Jeder Service, sein Owner, seine Abhängigkeiten und SLOs an einem Ort – automatisch aus Traces und Topologie erkannt und um die Metadaten Ihrer Teams ergänzt.
Mehr erfahrenDeployment Tracking
Erfassen Sie jedes Deployment und jede Konfigurationsänderung, sehen Sie Release-Marker in jedem Chart und lassen Sie Obseria vorher und nachher vergleichen – in Minuten wissen Sie, ob ein Release hilft oder schadet.
Mehr erfahrenMehr erfahren
Was ist MTTR (Mean Time to Recovery)?
Was ist MTTR? Die vier Bedeutungen von MTTR, Berechnung von MTTR, MTTD, MTTA und MTBF mit Beispielen und bewährte Wege, die Recovery-Zeit zu senken.
Was ist AIOps?
Was ist AIOps? Wie KI im IT-Betrieb Anomalien erkennt, Alerts korreliert, Ursachen findet und Behebung automatisiert – und welche Fehler Sie vermeiden sollten.
Häufige Fragen zum ServiceNow-Monitoring
Über Obseria-Automation-Workflows, die die ServiceNow REST API aufrufen, vor allem die Table API für Incident- und CMDB-Tabellen. Der Rückweg nutzt eine Business Rule oder einen Flow in ServiceNow, der die Obseria-API aufruft.
Nein. Sie bestimmen den Auslöser. Empfohlen ist, Incidents nur für korrelierte Probleme anzulegen, sodass ein Problem genau einen Incident ergibt.
Ja, sobald Sie den Rückweg einrichten. Obseria aktualisiert den Incident über seine Correlation ID, und ServiceNow sendet Statusänderungen an die Obseria-API.
Ja. Der Workflow sucht das passende Configuration Item und setzt cmdb_ci sowie die Zuweisungsgruppe, damit Incidents beim richtigen Team landen.
Ein eigener Integrationsuser mit Lese- und Schreibzugriff auf die Incident-Tabelle und Lesezugriff auf die genutzten CMDB-Tabellen. Vermeiden Sie Admin-Rollen.
Starten Sie heute mit dem ServiceNow-Monitoring
Binden Sie ServiceNow in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.