Monitoring, Logging, Tracing: Kako projekti observabilnosti propadaju i kako ih spasiti jasnim SLO-ovima

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 novi APM- ili log-alat, pa se „za svaki slučaj“ izrade dashboardi. Ono što nedostaje je pitanje: Koja operativna odluka time treba brže ili bolje postati? Dashboard koji ne pomaže tijekom incidenta u svakodnevnom radu često je samo dekoracija. Tipični simptom: u slučaju poteškoće timovi skaču između deset prikaza, ne znajući koji je od njih pouzdan.

2) Alarmna poplava i Alert Fatigue: Sve je kritično, dakle ništa nije kritično

Ako svaki CPU-pik, svaka pojedina HTTP-greška i svako upozorenje agenta završe kao alarm, rezultat više nije sigurnost nego otupjelost. Alert Fatigue znači: On-Call reagira kasnije, eskalacije postaju nejasne, a stvarni kvarovi prolaze neopaženo. Za IT‑vodstvo to je i rizik u smjeru usklađenosti i dokazivosti: „Imali smo alarma“ nije dokaz da je reagirano ciljano.

3) Keine Korrelation: Tickets ohne Trace-IDs, Logs ohne Kontext

Pogotovo kod softverskih rješenja bliskih procesima (ERP‑srodni workflowi, integracijske staze, portali) incidenti se često javljaju na sučeljima: REST-APIs, message brokeri, uvozi datoteka, EDI, identity provideri. Bez ID‑a za korelaciju (jedinstveni identifikator koji se prenosi kroz lanac) pojedinačni je proces nemoguće pratiti end‑to‑end. Rezultat: puno vremena se troši na „je li to kod nas ili kod partnera?“ umjesto na analizu osnovnog uzroka.

4) Kostenexplosion durch Log- und Trace-Volumen

Logging i tracing generiraju velike količine podataka. Bez strategije zadržavanja (perioda čuvanja), uzorkovanja (sampling, ciljano uzorkovanje trace‑ova) i pravila filtriranja, pohrana i ingest brzo postaju skupi – on‑prem kao i u cloudu. Često se potom u panici smanjuje obim podataka, što pogoršava kvalitetu podataka. To stvara začarani krug: manje povjerenja → više logiranja „za svaki slučaj“ → veći troškovi.

5) Sicherheits- und Datenschutzthemen werden zu spät adressiert

Logovi lako sadrže osobne podatke (imena, e‑mail, IP, brojevi kupaca) ili osjetljiv sadržaj (tokeni, Session‑ID‑e, interne URL‑ove). Ako se pravna i security‑perspektiva uključe tek nakon rollouta, prijete dvije loše opcije: gašenje ili „nastavak kao prije“ s rizikom. Observability mora od početka uključivati klasifikaciju podataka (potrebu zaštite), maskiranje/redakciju i koncepte pristupa.

6) Unklare Ownership: Wer ist für welchen Service „on the hook“?

U mnogim tvrtkama tim A upravlja infrastrukturom, tim B aplikacijom, tim C integracijom, tim D baznim slojem. Observability pokazuje probleme – ali bez jasne granice servisa i operativnih obveza odgovornost ostaje razvodnjena. U tom slučaju završava se u chat‑diskusijama umjesto u urednom incident‑procesu s jasnom predajom.

SLOs als Rettungsanker: Was ein gutes SLO leistet

SLO‑ovi su mjerljivi ciljevi za kvalitetu usluge. Izvode se iz SLI‑eva (Service Level Indicators, mjerena metrika). Važno: SLO‑ovi nisu primarno marketinški „brojevi dostupnosti“, već instrument upravljanja za operacije i prioritizaciju.

Dobar SLO odgovara za konkretan servis (npr. „Auftragserfassung im Portal“, „Dokumenten‑Upload“, „Nachtlauf Faktura“, „API für Lagerbuchungen“) na tri pitanja:

• Što je „dobro“ iz perspektive korisnika? (npr. „Antwort < 1,5 s“ ili „uspjeh bez grešaka“)
• Kako to objektivno mjerimo? (SLI, izvor podataka, mjerno razdoblje)
• Što se događa ako se ne ispuni? (prioriteti, change‑stop, mjere kapaciteta)

Tako Observability prelazi iz jezera podataka u sustav koji podržava donošenje odluka: Što je trenutno doista kritično? U što ćemo sljedeće ulagati? Koje rizike svjesno prihvaćamo?

Od SLAs do SLOs i Error Budgets: praktična orijentacija za donositelje odluka

U poduzećima često postoje SLAs (Service Level Agreements, ugovorne ili interne obveze). SLOs su čvršće ukorijenjeni u tehnologiji i operacijama te mogu poslužiti kao interna upravljačka varijabla, čak i ako je SLA vrlo grub.

Jedan središnji mehanizam je Error Budget: Ako SLO npr. zahtijeva 99,9% uspjeha u 30 dana, prihvatljiv je mali „budžet“ pogrešaka/neudostupnosti. To zvuči na početku kontraintuitivno, ali je operativno vrijedno: omogućuje racionalnu ravnotežu između stabilnosti i promjena (izdanja, migracije, optimizacija performansi).

Važno za praksu: Error Budgets funkcioniraju samo ako je mjerenje pošteno i organizacija je spremna izvući posljedice. Inače to postaje samo još jedan pokazatelj.

Definiranje SLOs koji zaista upravljaju Monitoring, Logging und Tracing

Najčešća pogreška kod SLOs je da su previše generički („99,9% dostupnosti aplikacije“). Smislenija je SLO-struktura duž korisničkih radnji i integracijskih točaka. Pragmatski pristup:

Schritt 1: Servicegrenzen entlang der Prozesskette schneiden

Ne definirajte „servise“ prema organigramu, već prema učinku: npr. „kreiranje narudžbe“, „obrada plaćanja“, „knjiženje komisioniranja“, „sučelje prema dostavnoj službi“. Posebno u okruženjima s prilagođenim poslovnim softverom te su granice presudne, jer podrška i poslovna strana razmišljaju u tim jedinicama.

Schritt 2: Pro Service 1–3 SLIs, die Nutzerwirkung abbilden

Dokazano su korisni SLIs poput:

• Erfolgsrate transakcije (npr. HTTP 2xx/3xx, ili „Business Success“ iz logike aplikacije)
• Latenz na kritičnom putu (p95/p99 umjesto prosjeka)
• Freshness kod data pipelinea („Koliko su stari podaci u DWH/Reporting?“)

Poanta: Nije svaka sistemska metrika SLI. Visok CPU je simptom, ali ne rezultat za korisnika. Koristite sistemske metrike za dijagnostiku, ne kao cilj.

Schritt 3: Messfenster, Ausschlüsse und Abhängigkeiten sauber festlegen

SLO bez mjernog prozora je bezvrijedan. Odredite: 28 dana rotirajuće? Mjesečno? Samo u radnom vremenu? I razjasnite koje se ovisnosti uključuju: Ako vanjska partnerska API zakaže, računa li se to u vaš SLO? Za operacije i eskalaciju ta jasnoća vrijedi zlata.

Schritt 4: Alerting an SLO-Burn-Rate koppeln

Umjesto „Alarm bei Fehler > X in 5 Minuten“ u praksi često bolje djeluje pristup po Burn-Rate-u: Koliko brzo se troši Error Budget? Time prioritizirate alarme prema riziku za ostvarenje cilja – ne prema glasnoći pojedinih metrika. Rezultat: manje alarma, ali relevantnijih.

Architekturfolgen: Was Sie für belastbare Observability technisch einplanen müssen

SLO-ovi su upravljanje, ali trebaju tehničku osnovu. U naslijeđenim okruženjima to rijetko znači „samo konfigurirati“. Tipične arhitekturne komponente:

Telemetrijska Pipeline: prikupljanje, transformacija, pohrana, isporuka

Bilo on-prem ili Cloud: trebate jasnu sekvencu kako telemetrija ulazi u sustav. To uključuje Agenten/Collector, transport (Queue/Buffer), obradu (parsiranje, obogaćivanje, maskiranje), pohranu i pristup. Posebno kod Logging i Tracing važan je pufor kako bi se ublažile vršne opterećenja i u slučaju pogrešaka ne opteretili produkcijski sustavi.

Identiteti i pristupi: Tko smije vidjeti koje podatke?

Podaci observability često su osjetljivi. Planirajte uloge i koncepte višekorisničnosti: operacije vide infrastrukturne metrike, support vidi korelirane događaje, poslovna jedinica dobiva samo agregirane prikaze servisa. Dopunite audit‑logove za pristup logovima/trace-ovima gdje su regulatorni zahtjevi relevantni.

Higijena podataka pri logiranju: struktura, maskiranje, retencija

„Sve logiramo“ nije plan. Smisleno su strukturirani logovi (strojno čitljivi), definirana polja (npr. servis, okruženje, korelacijski ID, klasa pogreške) i dosljedno maskiranje. Odredite retenciju prema svrsi: kratko za debug (npr. 7–14 dana), dulje za sigurnosne događaje ili audit‑zahtjeve – ali odvojeno, kako bi troškovi i prava pristupa ostali upravljivi.

Ciljano tracing, ne pokrivenost svega: Sampling i kritični putevi

Distribuirano Tracing posebno je vrijedno na integracijskim dionicama i kod problema s performansama. Poprčano 100% tracing pokrivanje rijetko je isplativo i često nije potrebno. Postavite pravila za sampling (npr. više trace-ova pri greškama ili neobičnoj latenciji) i fokusirajte se na kritični put: Login/SSO, upload, spremanje narudžbe, poziv sučelja, obrada reda (Queue).

Konkretni primjeri: SLO-ovi za tipične scenarije poslovnog softvera

Da SLO-ovi ne ostanu teorija, evo tri primjera koja se često pojavljuju u procesno povezanim softverskim rješenjima. Brojevi su namjerno zamjenski – ciljane vrijednosti moraju odgovarati korištenju, profilu opterećenja i riziku procesa.

Primjer A: Kundenportal „Auftrag anlegen“

• SLI Stopa uspjeha: Udio uspješno dovršenih kreiranja narudžbi (poslovni uspjeh) u razdoblju od 30 dana.
• SLI Latencija: p95 end-to-end vremena za kreiranje narudžbe (uključujući DB-commit i potvrdni odgovor).
• Signali za dijagnostiku: DB-deadlockovi/Timeouts, duljine reda (Queue) za naknadnu obradu, klase grešaka u aplikacijskim logovima (validacija vs. infrastruktura).

Važno: SLO bi trebao mjeriti tok korisnika, ne samo „HTTP 200“. Inače ćete previdjeti slučajeve u kojima je zahtjev bio tehnički uspješan, ali je funkcionalno prekinut.

Primjer B: Sučelje prema dostavnoj službi (REST/EDI)

• SLI: Udio prijava pošiljaka koje su u roku od X minuta uspješno potvrđene (uključujući ponovne pokušaje).
• Ovisnosti: vanjski endpoint, mrežni put, certifikati, rate-limiti.
• Dijagnostika: kodovi pogrešaka po kategorijama, udio ponovnih pokušaja, Dead-Letter-Queue (spremište za poruke koje nakon nekoliko pokušaja nisu obrađene).

Ovdje se pokazuje dodana vrijednost SLO-ova za operacije: možete jasno razlikovati utječe li incident na vlastitu obradu (npr. istekli certifikat) ili je prvenstveno problem partnera (npr. 5xx pogreške). To smanjuje vrijeme u War Roomu i poboljšava komunikaciju s poslovnim područjem i partnerima.

Primjer C: Noćni rad „Faktura/Batch-obrada“

• SLI: Udio batch-jobova koji su do definiranog cutoff-vremena uspješno završeni.
• SLI: Broj ručnih intervencija po pokretanju (operacije koje pokreću runbookove).
• Dijagnostika: obrasci lock-/deadlocka u bazi podataka, uska grla u resursima, IO-vremena čekanja, odstupanja u podzadacima.

Batch-procesi su klasične „slijepe točke“: korisnici primijete probleme tek ujutro. SLO s cutoff-vremenom postavlja jasna očekivanja i omogućava ciljano alertiranje koje ne eskalira zbog svake male kašnjenja, ali rano signalizira stvarne rizike.

Rollout i operacije: Kako SLO-model ostaje živ u svakodnevnom radu

Najteži dio nije prva definicija, nego ustaljivanje. Observability često zapne na operativnim procesima, a ne na tehnologiji.

Uloge i odgovornosti (bez preopterećenja)

Ne trebate veliku SRE-organizaciju, ali trebate jasne nadležnosti:

• Service Owner: stručno/tehnički odgovoran za ciljane vrijednosti i prioritetizaciju.
• Ops/Plattform: upravlja telemetrijskom pipelineom, pristupom, zadržavanjem podataka (retention), kontrolom troškova.
• On-Call/Support: koristi alertove, runbookove, putove eskalacije; daje povratnu informaciju o kvaliteti alarma.

Važno je uspostaviti obvezujući ritam (mjesečno ili svakih dva tjedna): SLO-pregled, top-alerti, troškovi/volumen, otvorene ’nepoznanice‘.

Povezivanje runbookova i incident-procesa s observabilityjem

Alarm bez puta djelovanja je buka. Povežite svako kritično pravilo za alert s runbookom (kratki vodič za postupanje): Što provjeriti? Koji dashboardi/vidici su relevantni? Kako se eskalira? Koje su dopustive hitne mjere (npr. onemogućiti značajku, ograničiti queue, samo za čitanje)?

Za vodstvo IT-a to je i poluga skaliranja: dobri runbookovi smanjuju ovisnost o pojedincima i skraćuju prosječno vrijeme rješavanja (MTTR) bez „junaštva“.

Release i Change-Management: SLO-ovi kao znak zaustavljanja, a ne dekoracija

Ako je error budget ograničen, rizične promjene bi trebale biti odgođene ili uvođene uz dodatne zaštitne mjere (npr. Canary, feature flagovi, usko monitoring-razdoblje). To nije svrha sama sebi: sprječava da stabilnost postane važna tek nakon incidenta.

Sadržajno se ovdje može dobro nadograditi na postojeće standarde release-managementa i povezati interne linkove na članke o rolloutu, prihvatu i planiranju povratka.

Kontrolna lista: Upozoravajući signali da vaš observability-projekt izmiče kontroli

• Alarmi se redovito utišavaju ili ignoriraju.
• Dashboardi su brojni, ali nitko ne zna koji je ključan u incidentu.
• Volumen logova raste brže od koristi; retencija se skraćuje „po osjećaju“.
• Sigurnost/zaštita podataka raspravlja se tek nakon puštanja u rad o sadržaju logova.
• Incidenti često završavaju s „nije se moglo reproducirati“ ili „nije jasno tko je odgovoran“.
• Tracing postoji, ali bez dosljednog ID-a korelacije preko sučelja.

Ako se više točaka poklapa, gotovo uvijek se isplati reset putem SLOs: prioritizirati nekoliko servisa, definirati jasne SLIs, ciljano usmjeriti telemetriju, radikalno pojednostaviti alarmiranje.

Zaključak: SLOs ponovno čine observabilnost upravljivom — i operativno iskrenom

Monitoring, Logging i Tracing su neizostavni, ali sami po sebi ne rješavaju operativni problem. Projekt observabilnosti tipično ne propada zbog manjka podataka, već zbog nedostatka jasnih ciljeva, loše kvalitete alarma, nekontroliranih količina podataka i nejasne odgovornosti. SLOs vraćaju inicijativu na ono što u svakodnevnom poslovanju zaista vrijedi: pouzdani servisi duž procesnog lanca, jasne prioritete u incidentu i razumljive odluke između stabilnosti, troškova i promjena.

Ako želite observabilnost u svojem okruženju ponovno usmjeriti ili pragmatično stabilizirati zacementirani setup, isplati se strukturirani pregled granica servisa, SLIs, telemetrijske pipeline i operativnih procesa. Za početnu procjenu i čist Početak projekta — arhitektura & suradnja dosegnite nas preko .

Razgovarajte o projektu ili modernizacijskom pothvatu s Net-Base.