Monitoring, Logging, Tracing: Kako observability-projekti propadejo in kako jih z jasnimi SLO-ji rešiti

Ein Observability-Projekt beginnt in vielen Unternehmen mit einem guten Impuls: Ausfälle schneller erkennen, Ursachen sauber eingrenzen, Support entlasten, Releases sicherer machen. In der Praxis kippt die Initiative jedoch häufig in das Gegenteil: zu viele Dashboards ohne Aussage, zu viele Alarme ohne Priorität, steigende Storage- und Lizenzkosten, und am Ende bleibt die Frage offen, ob der Betrieb damit wirklich besser wird.

Der Kernfehler ist selten ein fehlendes Tool. Meist fehlt die fachlich klare Zieldefinition: Was soll für welche Service- oder Prozesskette zuverlässig funktionieren – und wie messen wir das? Genau hier helfen SLOs (Service Level Objectives, messbare Zielwerte für einen Service) als Leitplanken. SLOs verbinden technische Telemetrie (Monitoring, Logging, Tracing) mit Betriebsrealität, Verantwortlichkeiten und Entscheidungswegen.

Dieser Beitrag ordnet typische Failure-Muster ein und zeigt, wie Sie Observability mit klaren SLOs wieder auf Kurs bringen – mit Blick auf Betrieb, Administration, Daten, Schnittstellen, Wartung, Sicherheit und Rollout.

Monitoring, Logging, Tracing: Was ist was – und warum reicht „mehr Daten“ nicht?

Observability wird oft als Sammelbegriff genutzt. Für den Betrieb ist wichtig, die drei Signalarten sauber zu trennen:

• Monitoring/Metriken: verdichtete Zeitreihen (z. B. Antwortzeiten, Fehlerraten, Queue-Längen). Vorteil: schnell, günstig, gut alarmierbar. Risiko: ohne Kontext schwer zu erklären.
• Logging: Ereignisse mit Kontext (z. B. Auftrag angelegt, Validierung fehlgeschlagen, externe API antwortet 503). Vorteil: detailliert und auditierbar. Risiko: Datenmengen, Datenschutz, „Log-Suppe“ ohne Struktur.
• Tracing: verteilte Ablaufspuren über mehrere Komponenten (Distributed Tracing). Vorteil: zeigt, wo Zeit verloren geht und welche Abhängigkeit klemmt. Risiko: Instrumentierung, Sampling-Strategie, Korrelation über Systeme hinweg.

Ein häufiger Irrtum: Wenn wir nur genug Logs und Traces sammeln, lösen sich Incidents quasi von selbst. In der Realität steigt zunächst die Komplexität. Ohne Zielbild und Kriterien für Relevanz wird Observability zur Datensammelstelle – nicht zum Steuerungsinstrument.

Warum Observability-Projekte scheitern: Die häufigsten Muster aus dem Betriebsalltag

Die folgenden Muster treten in gewachsenen Unternehmenslandschaften besonders häufig auf – also dort, wo Business-Software, Schnittstellen und Infrastruktur über Jahre gewachsen sind und mehrere Teams beteiligt sind.

1) Tool-first statt Service-first: Dashboards ohne Betriebsentscheidung

Uvede se novo APM- ali orodje za logiranje, nato se ‚za vsak primer‘ zgradijo nadzorne plošče. Pogreša se vprašanje: Katero obratovalno odločitev naj bi to naredilo hitreje ali bolje? Nadzorna plošča, ki pri incidentu ne pomaga, je v vsakdanjem delu pogosto le dekoracija. Tipični simptom: ob motnji ekipe skačejo med desetimi pogledi, ne da bi vedeli, kateri je zanesljiv.

2) Poplava alarmov in Alert Fatigue: Vse je kritično, torej nič ni kritično

Če vsaka vrh uporabe CPU, vsaka posamezna HTTP-napaka in vsako opozorilo agenta konča kot alarm, rezultat ni varnost, temveč otopelost. Alert Fatigue pomeni: On-Call reagira pozneje, eskalacije postanejo nejasne in resni izpadi ostanejo spregledani. Za IT-vodstvo je to tudi tveganje glede skladnosti in dokazljivosti: „Imeli smo alarme“ ni dokaz, da se je ukrepalo ciljno.

3) Brez korelacije: Tickets ohne Trace-IDs, Logs ohne Kontext

Še zlasti pri procesno bližnjih programski rešitvah (ERP-podobni delovni tokovi, integracijske poti, portali) se incidenti pogosto pojavijo na vmesnikih: REST-APIs, Message Broker, uvozi datotek, EDI, Identity-Provider. Brez korelacijske ID (edinstvena oznaka, ki teče skozi verigo) ni mogoče enega postopka slediti od začetka do konca. Posledica: veliko časa se porabi za vprašanje »Ali je to pri nas ali pri partnerju?« namesto za analizo osnovnega vzroka.

4) Eksplozija stroškov zaradi obsega logov in trace-ov

Logiranje in tracing sta podatkovno intenzivna. Brez strategije hrambe (doba hrambe), vzorčenja (ciljna vzorčna izbira pri traces) in pravil filtriranja postaneta shramba in ingest hitro draga – on-prem kot v oblaku. Pogosto se potem panično skrajša, kar poslabša kakovost podatkov. To ustvari začaran krog: manj zaupanja → več ‚za vsak primer‘ logiranja → višji stroški.

5) Vprašanja varnosti in varstva podatkov se obravnavajo prepozno

Logi pogosto vsebujejo osebne podatke (imena, e-pošta, IP, številke kupcev) ali varovane vsebine (Tokens, Session-IDs, interni URL-ji). Če se pravna in varnostna perspektiva obravnavata šele po uvajanju, grozita dve slabi možnosti: izklop ali »kar naprej« z rizikom. Observability mora od začetka upoštevati Klasifikacija podatkov (potreba po zaščiti), maskiranje/redakcijo in koncepte dostopa.

6) Nejasna odgovornost: Kdo je za kateri servis odgovoren?

V mnogih podjetjih ekipa A upravlja infrastrukturo, ekipa B aplikacijo, ekipa C integracijo, ekipa D podatkovni sklad. Observability pokaže težave – vendar brez jasnih meja storitve in obveznosti obratovanja ostane odgovornost razpršena. Nato se konča v chat-diskusijah namesto v urejenem incidentnem procesu z jasno predajo.

SLOs kot rešilni steber: kaj doseže dobro SLO

SLOs so merljive ciljane vrednosti za kakovost storitve. Izvajajo se iz SLIs (Service Level Indicators, merjena metrika). Pomembno: SLOs niso primarno marketinške „razpoložljivostne številke“, temveč instrument za upravljanje obratovanja in določanje prioritet.

Dobro SLO odgovori za konkreten servis (npr. „vnos naročila v portal“, „nalaganje dokumentov“, „nočni zagon faktur“, „API za knjiženje zalog“) tri vprašanja:

• Kaj je „dobro“ z vidika uporabnika? (npr. „odziv < 1,5 s“ ali „uspeh brez napak“)
• Kako to objektivno merimo? (SLI, vir podatkov, merilno okno)
• Kaj se zgodi, če se ne izpolni? (prioritete, zaustavitev sprememb, ukrepi za kapacitete)

Tako Observability preide iz jezera podatkov v sistem, ki podpira odločitve: Kaj je trenutno resnično kritično? Kam bomo naslednje vlagali? Katera tveganja bomo zavestno sprejeli?

Od SLAs do SLOs in Error Budgets: praktična umestitev za odločevalce

V podjetjih pogosto obstajajo SLAs (Service Level Agreements, pogodbeno ali interno obvezovanje). SLOs so tesneje povezani s tehnologijo in obratovanjem ter lahko služijo kot notranji kontrolni parameter, tudi če je SLA precej grob.

Ključni mehanizem je Error Budget: če SLO npr. zahteva 99,9% uspeha v 30 dneh, je sprejemljiv majhen „proračun“ za napake/nedosegljivost. To se sprva zdi kontraintuitivno, a je operativno koristno: omogoča objektivno ravnotežje med stabilnostjo in spremembami (izdaje, migracije, optimizacija zmogljivosti).

Pomembno za prakso: Error Budgets delujejo le, če je merjenje pošteno in je organizacija pripravljena izvesti posledice. Sicer ostane le še ena merilna metrika.

Določanje SLO-jev, ki dejansko usmerjajo Monitoring, Logging in Tracing

Najpogostejša napaka pri SLO-jih je, da so preveč generični („99,9% razpoložljivost aplikacije“). Smiselnejša je struktura SLO-jev vzdolž uporabniških akcij in integracijskih točk. Pragmatičen postopek:

Korak 1: Določite mejne točke servisov vzdolž procesne verige

Ne definirajte „servisov“ po organigramu, temveč po učinku: npr. „ustvari naročilo“, „obdelaj plačilo“, „knjiži komisioniranje“, „vmesnik do prevoznega ponudnika“. Še posebej pri individualnih korporativnih programskih okoljih so te meje odločilne, saj podporne službe in poslovni oddelki razmišljajo v takih enotah.

Korak 2: Na servis 1–3 SLI-jev, ki odražajo vpliv na uporabnika

Učinkoviti SLIs so na primer:

• Stopnja uspeha transakcije (npr. HTTP 2xx/3xx ali „Business Success“ iz aplikacijske logike)
• Latenca na kritični poti (p95/p99 namesto povprečja)
• Freshness pri podatkovnih cevovodih („Kako stari so podatki v DWH/poročilih?“)

Ključ: Ni vsaka sistemska metrika SLI. Visoka obremenitev CPU je simptom, ne rezultat za uporabnika. Sistemskih metrik uporabite za diagnostiko, ne kot ciljno vrednost.

Korak 3: Jasno določite merilna okna, izključitve in odvisnosti

SLO brez merilnega okna je brez vrednosti. Določite: 28 dni tekoče? Po mesecih? Samo v poslovnem časovnem oknu? In razjasnite, katere odvisnosti se vključijo: če preneha delovati zunanja partnerska API, se to šteje v vaš SLO? Za obratovanje in eskalacijo je ta jasnost izjemno dragocena.

Korak 4: Povežite alarmiranje z SLO burn-rate

Namesto „alarm ob napakah > X v 5 minutah“ v praksi pogosto bolje deluje pristop burn-rate: kako hitro se porablja Error Budget? Tako prioritizirate alarme glede na tveganje za doseganje ciljev – ne glede na glasnost posameznih metrik. Rezultat: manj alarmov, a bolj relevantnih.

Posledice za arhitekturo: kaj morate tehnično načrtovati za zanesljivo Observability

SLOs sind Governance, aber sie brauchen eine technische Basis. In gewachsenen Landschaften ist das selten „nur konfigurieren“. Typische Architektur-Bausteine:

Telemetry-Pipeline: Sammeln, transformieren, speichern, ausspielen

Ob on-prem oder Cloud: Sie brauchen eine klare Kette, wie Telemetrie ins System kommt. Dazu gehören Agenten/Collector, Transport (Queue/Buffer), Verarbeitung (Parsing, Enrichment, Redaction), Speicherung und Zugriff. Gerade bei Logging und Tracing ist ein predpomnilnik wichtig, um Lastspitzen abzufangen und bei Störungen nicht die Produktivsysteme zu belasten.

Identitäten und Zugriffe: Wer darf welche Daten sehen?

Observability-Daten sind oft sensibel. Planen Sie Rollen und Mandantenkonzepte: Betrieb sieht Infrastrukturmetriken, Support sieht korrelierte Vorgänge, Fachbereich bekommt nur aggregierte Service-Sichten. Ergänzen Sie Audit-Logs für den Zugriff auf Logs/Traces, wenn regulatorische Anforderungen relevant sind.

Datenhygiene im Logging: Struktur, Redaction, Retention

„Wir loggen alles“ ist kein Plan. Sinnvoll sind strukturierte Logs (maschinenlesbar), definierte Felder (z. B. Service, Umgebung, Korrelations-ID, Fehlerklasse) und konsequente Maskierung. Legen Sie Retention nach Zweck fest: Kurz für Debug (z. B. 7–14 Tage), länger für Security-Events oder Audit-Anforderungen – aber getrennt, damit Kosten und Zugriffsrechte steuerbar bleiben.

Tracing gezielt, nicht flächig: Sampling und kritische Pfade

Distributed Tracing ist besonders wertvoll bei Integrationsstrecken und Performance-Problemen. Flächendeckendes 100%-Tracing ist aber selten bezahlbar und oft nicht nötig. Setzen Sie Sampling-Regeln (z. B. mehr Traces bei Fehlern oder bei ungewöhnlicher Latenz) und fokussieren Sie den kritischen Pfad: Login/SSO, Upload, Auftrag speichern, Schnittstellen-Call, Queue-Verarbeitung.

Konkrete Beispiele: SLOs für typische Unternehmenssoftware-Szenarien

Damit SLOs nicht theoretisch bleiben, hier drei Beispiele, die in prozessnahen Softwarelösungen häufig vorkommen. Die Zahlen sind bewusst als Platzhalter zu verstehen – Zielwerte müssen zu Nutzung, Lastprofil und Prozessrisiko passen.

Beispiel A: Kundenportal „Auftrag anlegen“

• SLI Erfolgsrate: Anteil erfolgreich abgeschlossener Auftragserstellungen (Business Success) pro 30 Tage.
• SLI Latenz: p95 der End-to-End-Zeit für Auftragserstellung (inkl. DB-Commit und Bestätigungsantwort).
• Diagnose-Signale: DB-Deadlocks/Timeouts, Queue-Längen für nachgelagerte Verarbeitung, Fehlerklassen im Applikationslog (Validierung vs. Infrastruktur).

Pomembno: SLO naj meri uporabniški tok, ne samo „HTTP 200“. Drugače spregledate primere, kjer je bila zahteva tehnično uspešna, a je bila strokovno prekinjena.

Primer B: Vmesnik do dostavne službe (REST/EDI)

• SLI: delež prijav pošiljk, ki so znotraj X minut uspešno potrjene (vključno z ponovnimi poizkusi).
• Odvisnosti: zunanji endpoint, mrežna pot, certifikati, rate-limiti.
• Diagnostika: kode napak po kategorijah, delež ponovnih poizkusov, Dead-Letter-Queue (shramba za sporočila, ki jih po več poskusih ni bilo mogoče obdelati).

Tukaj se pokaže dodana vrednost SLO-jev za obratovanje: jasno ločite, ali incident zadeva lastno obdelavo (npr. potekel certifikat) ali je primarno pri partnerju (npr. 5xx-napaka). To skrajša čas v War Roomu in izboljša komunikacijo s stroko in partnerji.

Primer C: Nočni zagon „Faktura/Batch-Verarbeitung“

• SLI: delež batch-jobov, ki so uspešno zaključeni do definiranega časovnega preseka.
• SLI: število ročnih posegov na zagon (operacije, ki sprožijo Runbooks).
• Diagnostika: vzorci zaklepanja/deadlockov v podatkovni bazi, ozka grla virov, časi čakanja I/O, odstopanja v delnih opravilih.

Batch-procesi so tipični „blind spoti“: uporabniki težave opazijo šele zjutraj. SLO s časovnim presekom postavi jasna pričakovanja in omogoči ciljano alarmiranje, ki ne eskalira vsake manjše zamude, a zgodaj signalizira resna tveganja.

Rollout in obratovanje: tako model SLO ostane živ v praksi

Najtežji del ni prva definicija, temveč trajnost. Observability pogosto spodleti zaradi operativnih procesov, ne zaradi tehnologije.

Vloge in odgovornosti (brez overheada)

Za veliko SRE-organizacijo ne potrebujete, potrebne so pa jasne odgovornosti:

• Service Owner: strokovno/tehnično odgovoren za ciljne vrednosti in določanje prioritet.
• Ops/Plattform: upravlja telemetrični cevovod, dostop, retencijo, nadzor stroškov.
• On-Call/Support: uporablja alarme, Runbooks, poti eskalacije; daje povratne informacije o kakovosti alarmov.

Pomemben je zavezujoč ritem (mesečno ali na dva tedna): SLO-review, top-alarmi, stroški/volumen, odprte neznanke.

Povezati Runbooks in proces incidentov z Observability

Alarm brez poti ukrepanja je hrup. Povežite vsako kritično pravililo za alarm z Runbookom (kratka navodila): kaj preveriti? Kateri dashboardi/ognjišča so relevantni? Kako se eskalira? Kateri takojšnji ukrepi so dovoljeni (npr. onemogočiti feature, omejiti queue, način samo za branje)?

Za IT-vodstvo je to tudi poluga za skaliranje: dobri Runbooki zmanjšajo odvisnost od posameznikov in skrajšajo povprečni čas rešitve (MTTR) brez »junakovanja«.

Release- in Change-Management: SLO kot signal za prekinitev, ne kot dekoracija

Če je Error Budget omejen, naj se tvegane spremembe prestavijo ali uvedejo z dodatnimi zaščitami (npr. Canary, Feature Flags, ozko spremljanje v časovnem oknu). To ni sebi namen: preprečuje, da stabilnost postane pomembna šele po izpadu.

Vsebinsko lahko tu dobro gradite na obstoječih standardih release-managementa in dodate interne povezave do prispevkov o rolloutu, odobritvah in načrtu vračanja.

Kontrolni seznam: opozorilni znaki, da vaš Observability-projekt uhaja iz nadzora

• Alarme werden regelmäßig stummgeschaltet oder ignoriert.
• Dashboards sind zahlreich, aber niemand weiß, welches im Incident entscheidend ist.
• Log-Volumen wächst schneller als Nutzen; Retention wird „nach Gefühl“ gekürzt.
• Security/Datenschutz diskutiert erst nach dem Rollout über Inhalte in Logs.
• Incidents enden häufig mit „konnte nicht reproduziert werden“ oder „unklar, wer zuständig ist“.
• Tracing existiert, aber ohne durchgängige Korrelations-ID über Schnittstellen.

Wenn mehrere Punkte zutreffen, lohnt sich fast immer ein Reset über SLOs: wenige Services priorisieren, klare SLIs definieren, Telemetrie gezielt ausrichten, Alarmierung radikal vereinfachen.

Fazit: SLOs machen Observability wieder steuerbar – und betrieblich ehrlich

Monitoring, Logging und Tracing sind unverzichtbar, aber sie lösen alleine kein Betriebsproblem. Ein Observability-Projekt scheitert typischerweise nicht an fehlenden Daten, sondern an fehlender Zielklarheit, schlechter Alarmqualität, unbeherrschten Datenmengen und unklarer Ownership. SLOs bringen die Initiative zurück auf das, was im Unternehmensalltag zählt: verlässliche Services entlang der Prozesskette, klare Prioritäten im Incident, und nachvollziehbare Entscheidungen zwischen Stabilität, Kosten und Veränderung.

Wenn Sie Observability in Ihrer Landschaft neu ausrichten oder ein festgefahrenes Setup pragmatisch stabilisieren möchten, lohnt sich ein strukturierter Blick auf Servicegrenzen, SLIs, Telemetrie-Pipeline und Betriebsprozesse. Für eine erste Einordnung und einen sauberen Projektstart — Architektur & Zusammenarbeit erreichen Sie uns über .

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.