Observability oder Prozess-Monitoring: Systeme gegen Geschäftsfälle

Was Observability abdeckt

Observability-Plattformen sammeln Metriken, Logs und Traces aus deinen Anwendungen und deiner Infrastruktur und alarmieren, wenn etwas falsch aussieht. In Datadog kann ein Monitor auch melden, wenn eine Metrik ausbleibt: Die Option, NO DATA anzuzeigen und zu benachrichtigen, greift, wenn erwartete Daten fehlen, sofern der Monitor vorher schon Daten ausgewertet hat.

Incident-Tools wie PagerDuty setzen darauf auf. Events aus Monitoring-Tools werden zu Alerts, Alerts zu Incidents, und Incidents werden an die Person in Rufbereitschaft geleitet und eskaliert, mit Benachrichtigung per Telefon, SMS, E-Mail und Push.

Manche Observability-Anbieter gehen weiter in Geschäftsprozesse. Dynatrace Business Flow überwacht Prozessabläufe aus Business Events, die eine Korrelations-ID wie order_id teilen, und zeigt Verzögerungen, abgebrochene und unvollständige Abläufe sowie Geschäftskennzahlen. Die Dokumentation nennt auch Grenzen: höchstens fünf Verzweigungen pro Schritt, fünf Business Events pro Schritt und 20 Knoten pro Prozess. Alarme auf Kennzahlen gibt es nur, wenn ein Prozess im Schnitt kürzer als 30 Minuten dauert, weil die Anomalie-Erkennung ein rollierendes Fenster von 60 Minuten auswertet.

Was Prozess-Monitoring abdeckt

Prozess-Monitoring behandelt jede Bestellung, jedes Ticket und jede Erstattung als Fall mit Schritten und Fristen. tiqline verknüpft Events über eine ID, etwa die Bestellnummer, zu einem Fall und prüft jeden Schritt gegen seine Zeitgrenze. Ein Schritt kann Minuten, Stunden oder Tage dauern; die Frist ist der Zeitpunkt, zu dem der Fall den Schritt erreicht hat, plus die Zeitgrenze.

Verstreicht die Frist ohne das nächste Event, wird der Fall als hängend markiert. Alle hängenden Fälle eines Schritts teilen sich einen Vorfall, und ein Alarm geht an Slack oder per E-Mail, mit Prozess, Schritt, Zeitgrenze und Link zu den Fällen.

Die wichtigsten Unterschiede

• Objekt: Observability beobachtet Dienste und Hosts. Prozess-Monitoring beobachtet Fälle wie Bestellungen.
• Signal: Observability reagiert auf Fehler, Latenz und fehlende Daten. Prozess-Monitoring reagiert auf einen Geschäftsschritt, der nicht rechtzeitig passiert ist.
• Zeitskala: Systemalarme drehen sich meist um Sekunden und Minuten. Geschäftsschritte dauern oft Stunden oder Tage, etwa eine Erstattung innerhalb von zwei Tagen.
• Wer handelt: Systemalarme gehen an Entwicklerinnen und Entwickler in Rufbereitschaft. Prozessalarme gehen an Operations, Kundenservice oder das Lager.
• Einrichtung: Observability braucht Agents oder Instrumentierung. tiqline braucht Events pro Schritt und eine Prozessbeschreibung.

Nebeneinander

Wann Observability reicht

Geht jede verspätete Bestellung auf ein ausgefallenes System zurück, fängt Observability sie schon ab. Ein Webhook-Endpunkt, der Fehler liefert, oder eine Warteschlange, die nicht mehr abläuft, zeigt sich in deinen Metriken. Ein Datadog-Monitor, der bei fehlenden Daten meldet, erkennt auch den Moment, in dem gar keine Bestellungen mehr fließen.

Wann du Prozess-Monitoring brauchst

Du brauchst es, wenn die Systeme laufen, die Arbeit aber nicht. Ein Lager mit zu wenig Personal, eine Zahlung, die auf manuelle Prüfung wartet, eine Erstattung, die niemand freigegeben hat: Kein Fehler wird geworfen, keine Metrik schlägt aus. Das einzige Signal ist, dass für eine bestimmte Bestellung ein Event nicht rechtzeitig kam. Diese Lücke füllt tiqline.

Beides kombinieren

Behalte deinen Observability-Stack für die Systemgesundheit und ergänze tiqline für die Geschäftsschritte. Schick Events aus deinen Diensten über die track-API an den Stellen, an denen ein Geschäftsschritt abgeschlossen ist, und gib deine trace_id mit. Hängt eine Bestellung, zeigt die Fall-Timeline in tiqline jedes Event mit seiner trace_id. Ist die Ursache technisch, springt jemand aus der Entwicklung direkt zum passenden Trace.

Leite die beiden Alarmarten an verschiedene Leute. System-Incidents gehen an die Rufbereitschaft. Prozessalarme von tiqline gehen an den Slack-Kanal oder die E-Mail-Adressen des Teams, das die Bestellung bewegen kann.

Beispiel: alles grün, trotzdem zu spät

Alle Zahlen in diesem Beispiel sind erfunden. Ein Shop bearbeitet 500 Bestellungen am Tag. Seine APM-Dashboards sind den ganzen Montag grün. Am Nachmittag fällt eine Abholung des Versanddienstleisters aus, und das Lager hört auf, Bestellungen als gepickt zu melden.

In tiqline hat der Pick-Schritt eine Zeitgrenze von 5 Stunden. Um 16:10 Uhr haben 37 Bestellungen diese Zeitgrenze überschritten. Eine Slack-Nachricht nennt den Schritt und sagt, dass 37 Fälle warten, und die E-Mail listet die Fälle auf. Die Lagerleitung ruft beim Versanddienstleister an. Kein Systemalarm hat ausgelöst, weil kein System ausgefallen ist.

So richtest du es in tiqline ein

• Schick an jeder Stelle, an der ein Geschäftsschritt abgeschlossen ist, ein Event über die track-API und gib die trace_id mit, wenn du eine hast.
• Wähle das ID-Feld, das Events einem Fall zuordnet, zum Beispiel die Bestellnummer.
• Beschreibe die Schritte im Prozess-Editor und setze für jeden Schritt nach dem ersten eine Zeitgrenze. Wo sich Fälle aufteilen, etwa in versendet oder storniert, fügst du eine Verzweigung ein.
• Prüfe den Entwurf in der Vorschau an deinen echten Fällen, bevor du ihn veröffentlichst. So siehst du, welche Fälle heute hängen würden.
• Wähle die Alarmkanäle: einen Slack-Kanal über einen Incoming Webhook, bis zu 20 E-Mail-Adressen oder beides.
• Veröffentliche den Prozess. Änderst du später eine Zeitgrenze, gilt sie sofort, auch für laufende Fälle, und die Änderung landet im Audit-Log.

Welche Events du schicken solltest

Fang mit den Übergaben an, an denen Arbeit den Besitzer wechselt: Zahlung bestätigt, Auftrag ans Lager übergeben, gepickt, versendet, Erstattung freigegeben. Jede Übergabe ist ein Schritt, und jeder Schritt bekommt ein Event mit derselben Fall-ID. Interne Zwischenstände, die niemand verantwortet, brauchst du nicht.

Schick das Event an der Stelle im Code, an der der Schritt wirklich abgeschlossen ist, nicht dort, wo er angestoßen wird. Ein Event wird einmal gespeichert, ein Wiederholungsversuch zählt also nicht doppelt. Mehr Daten zu einem Fall kannst du als Eigenschaften mitschicken und später für eine Verzweigung nutzen.

Grenzen von tiqline

tiqline ist kein Observability-Tool. Es sammelt keine Metriken, Logs oder Traces, überwacht keine Verfügbarkeit und erkennt keine Anomalien. Es gibt keine Bereitschaftspläne, keine Eskalationsregeln und keine Alarme per Telefon oder SMS; Alarme gehen an Slack und per E-Mail. tiqline kennt nur, was als Event ankommt. Ein Schritt, der nichts schickt, lässt sich nicht beobachten.