Monitoring, Logging, Tracing: Kako observability-projekti 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

Uvođenje novog APM- ili alata za logovanje, zatim se prave „za svaki slučaj“ dashboardi. Ono što nedostaje je pitanje: Koja operativna odluka treba time da postane brža ili bolja? Dashboard koji ne pomaže tokom incidenta često je u svakodnevnom radu samo dekoracija. Tipičan simptom: u slučaju kvara timovi skaču između deset prikaza, ne znajući koji od njih je pouzdan.

2) Poplava alarma i zamor od upozorenja: Sve je kritično, dakle ništa nije kritično

Ako svaki skok CPU-opterećenja, svaka pojedinačna HTTP-greška i svako upozorenje agenta završavaju kao alarm, rezultat više nije sigurnost nego otupljenje. Zamor od upozorenja znači: dežurni tim reaguje kasnije, eskalacije postaju nejasne, a stvarni kvarovi ostanu potisnuti. Za IT-upravljanje to je i rizik u pogledu usklađenosti i dokazivosti: „Wir hatten Alarme“ nije dokaz da je reagovano ciljano.

3) Nema korelacije: tiketi bez Trace-ID, logovi bez konteksta

Posebno kod softverskih rješenja bliskih procesima (workflowi povezani s ERP-om, integracijske linije, portali) incidenti se često javljaju na interfejsima: REST-APIs, message brokeri, uvozi datoteka, EDI, provajderi identiteta. Bez ID za korelaciju (jedinstvena oznaka koja se prenosi kroz lanac) pojedinačni proces se ne može pratiti od početka do kraja. Rezultat: mnogo vremena se troši na „je li to kod nas ili kod partnera?“ umjesto na analizu osnovnog uzroka.

4) Eksplozija troškova zbog volumena logova i trace-ova

Logovanje i tracing su podatkovno intenzivni. Bez strategije zadržavanja (vremenski period čuvanja), uzorkovanja (ciljani uzorci kod trace zapisa) i pravila filtriranja skladištenje i ingest brzo postanu skupi – on-prem kao i u oblaku. Često se onda u panici skraćuje ono što pogoršava kvalitetu podataka. To stvara začarani krug: manje povjerenja → više „za svaki slučaj“ logovanja → veći troškovi.

5) Sigurnosna i pitanja privatnosti se adresiraju prekasno

Logovi često sadrže lične podatke (imena, e-mail, IP, brojeve kupaca) ili zaštićene sadržaje (tokene, session-ID-e, interne URL-ove). Ako se pravna i bezbjednosna perspektiva uzmu u obzir tek nakon roll-outa, prijete dvije loše opcije: isključivanje ili „nastaviti kao i dosad“ sa rizikom. Observability mora od početka uzeti u obzir klasifikaciju podataka (potrebu zaštite), maskiranje/redakciju i koncepte pristupa.

6) Nejasna odgovornost: Ko je za koji servis „odgovoran“?

U mnogim kompanijama Tim A upravlja infrastrukturom, Tim B aplikacijom, Tim C integracijom, Tim D slojem baze podataka. Observability pokazuje probleme – ali bez jasne granice odgovornosti za servis i operativnih obaveza odgovornost ostaje razvodnjena. Tada se sve završi u chat-raspravama umjesto u urednom incident-procesu sa jasnim predajama.

SLOs kao spasilački oslonac: Šta dobro SLO postiže

SLOs su mjerljivi ciljevi za kvalitetu servisa. Izvode se iz SLIs (Service Level Indicators, mjerena metrika). Važno: SLOs nisu prvenstveno marketinške „brojke dostupnosti“, nego instrument upravljanja za operacije i prioritizaciju.

Dobro SLO odgovara za konkretan servis (npr. „unos narudžbi u portalu“, „upload dokumenata“, „noćna obrada faktura“, „API za knjiženje zaliha“) na tri pitanja:

• Šta je „dobro“ iz perspektive korisnika? (npr. „odgovor < 1,5 s“ ili „uspjeh bez grešaka“)
• Kako to objektivno mjerimo? (SLI, izvor podataka, mjerni prozor)
• Šta se dešava ako se ne ispuni? (prioriteti, zaustavljanje promjena, mjere kapaciteta)

Tako Observability prelazi iz jezera podataka u sistem koji podržava odluke: Šta je trenutno zaista kritično? Gdje ćemo sljedeće investirati? Koje rizike svjesno prihvatamo?

Od SLAs preko SLOs i Error Budgets: Praktična orijentacija za donosioce odluka

U preduzećima često postoje SLAs (Service Level Agreements, ugovorne ili interne obaveze). SLOs su čvršće vezani za tehnologiju i operacije i mogu služiti kao interna mjera upravljanja, čak i kada je SLA vrlo grubo definisan.

Jedan centralni mehanizam je Error Budget: Ako SLO npr. zahtijeva 99,9% uspjeha u 30 dana, prihvatljiv je mali „budžet“ za greške/nedostupnost. To na prvi pogled zvuči kontraintuitivno, ali je operativno vrijedno: omogućava objektivnu ravnotežu između stabilnosti i promjena (Releases, Migrationen, Performance-Optimierung).

Važno za praksu: Error Budgets funkcionišu samo ako je mjerenje pošteno i organizacija spremna da povuče posljedice. Inače to postane samo još jedna metrika.

Definisanje SLOs koji zaista upravljaju monitoringom, loggingom i tracingom

Najčešća greška kod SLOs je da su previše generički („99,9% dostupnosti aplikacije“). Praktičnije je strukturirati SLO po korisničkim akcijama i tačkama integracije. Pragmatičan pristup:

Korak 1: Odredite granice servisa duž lanca procesa

Ne definišite „Services“ prema organigramu, nego prema učinku: npr. „kreiranje narudžbe“, „obrada uplate“, „knjiženje komisioniranja“, „interfejs prema dobavljaču usluga dostave“. Posebno u individualnim pejzažima poslovnog softvera ove granice su presudne, jer podrška i poslovni odjel razmišljaju unutar tih jedinica.

Korak 2: Po servisu 1–3 SLIs koji odražavaju utjecaj na korisnika

Pokazali su se SLIs poput:

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

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

Korak 3: Jasno definirajte interval mjerenja, izuzetke i zavisnosti

SLO bez prozora mjerenja je bezvrijedan. Odredite: 28 dana rollierend? Mjesečno? Samo u poslovnom vremenu? I razjasnite koje zavisnosti uključiti: Ako se vanjska partner-API sruši, uračunava li se to u vaše SLO? Za operacije i eskalaciju ta jasnost je izuzetno vrijedna.

Korak 4: Povežite Alerting s SLO-Burn-Rate

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

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

SLOs su dio upravljanja, ali trebaju tehničku osnovu. U etabliranim pejzažima rijetko je riječ o „samo konfigurirati“. Tipične arhitekturne komponente:

Telemetry-Pipeline: Sammeln, transformieren, speichern, ausspielen

Bilo on-prem ili Cloud: potrebna vam je jasna lančana obrada kako telemetrija ulazi u sustav. To obuhvata agente/collectore, transport (red/pufer), obradu (parsiranje, obogaćivanje, redakcija), pohranu i pristup. Posebno za logiranje i tracing važan je međuspremnik kako bi se uhvatile vršne opterećenja i u slučaju poremećaja ne opteretili produkcijski sustavi.

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

Podaci za observability često su osjetljivi. Planirajte uloge i koncepte tenanata: operacije vide infrastrukturne metrike, support vidi korelirane transakcije, poslovna jedinica dobiva samo agregirane poglede na servise. Dopunite to audit-logovima za pristup logovima/traces kada su regulatorni zahtjevi relevantni.

Datenhygiene im Logging: Struktur, Redaction, Retention

„Logiramo sve“ nije plan. Preporučljivo su strukturirani logovi (strojno čitljivi), definirana polja (npr. servis, okruženje, korrelacijski ID, klasa greške) i dosljedna maskiranja. Odredite retention prema namjeni: kratko za debug (npr. 7–14 dana), duže za sigurnosne događaje ili audit-zahtjeve – ali odvojeno, kako bi troškovi i pristupna prava ostali upravljivi.

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

Distribuirano praćenje je posebno vrijedno na integracijskim linijama i kod problema performansi. Opsežno 100%-praćenje rijetko je isplativo i često nije potrebno. Postavite pravila uzorkovanja (npr. više trace-ova pri greškama ili pri nesvakidašnjoj latenciji) i fokusirajte se na kritične puteve: Login/SSO, upload, spremanje naloga, poziv prema sučelju, obrada u redu.

Konkrete Beispiele: SLOs für typische Unternehmenssoftware-Szenarien

Da SLOs ne ostanu teorija, ovdje su tri primjera koja se često javljaju u procesno-posredovanim softverskim rješenjima. Brojevi su svjesno navedeni kao pokazatelji – ciljni vrijednosti moraju se prilagoditi upotrebi, profilu opterećenja i riziku procesa.

Beispiel A: Kundenportal „Auftrag anlegen“

• SLI Erfolgsrate: Udio uspješno dovršenih kreiranja narudžbi (Business Success) u razdoblju od 30 dana.
• SLI Latenz: p95 end-to-end vremena za kreiranje narudžbe (uključujući DB-Commit i odgovor s potvrdom).
• Diagnose-Signale: DB-deadlockovi/timeouti, dužine redova (Queue) za naknadnu obradu, klase grešaka u aplikacijskom logu (validacija vs. infrastruktura).

Važno: SLO bi trebao mjeriti tok korisnika, a ne samo „HTTP 200“. U suprotnom mogli biste previdjeti slučajeve u kojima je zahtjev tehnički bio uspješan, ali je poslovno obustavljen.

Primjer B: Sučelje prema pružatelju usluga dostave (REST/EDI)

• SLI: Udio prijava pošiljaka koje su uspješno potvrđene unutar X minuta (uključujući ponovne pokušaje).
• Ovisnosti: vanjski Endpoint, mrežni put, certifikati, Rate-Limits.
• Dijagnoza: kodovi grešaka po kategorijama, udio ponovnih pokušaja, Dead-Letter-Queue (spremište za poruke koje nakon više pokušaja nisu obrađene).

Ovdje se pokazuje dodana vrijednost SLO-ova za operativu: možete jasno razlučiti da li incident pogađa vlastitu obradu (npr. istek certifikata) ili primarno partnera (npr. 5xx greške). To smanjuje War-Room-vrijeme i poboljšava komunikaciju s poslovnim odjelom i partnerima.

Primjer C: Noćno izvođenje „Faktura/Batch-obrada“

• SLI: Udio batch-jobova koji su uspješno završeni do definirane vremena preseka.
• SLI: Broj ručnih intervencija po pokretanju (operacije koje pokreću Runbooks).
• Dijagnoza: obrasci zaključavanja/deadlocka u bazi podataka, resursna uska grla, I/O vremena čekanja, odskoci u podzadatcima.

Batch-procesi su klasične „blind spots“: korisnici primijete probleme tek ujutro. SLO s vremenom preseka postavlja jasna očekivanja i omogućava ciljano obavještavanje koje ne eskalira svako manje kašnjenje, ali rano signalizira stvarne rizike.

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

Najteži dio nije prva definicija, nego njeno ustaljivanje. Observability često ne uspije zbog operativnih procesa, a ne zbog tehnologije.

Uloge i odgovornosti (bez nepotrebnog overheada)

Ne trebate veliku SRE-organizaciju, ali jasne odgovornosti:

• Service Owner: stručno/tehnički odgovoran za ciljane vrijednosti i prioritetizaciju.
• Ops/Plattform: upravlja Telemetry-Pipelineom, pristupima, retencijom, kontrolom troškova.
• On-Call/Support: koristi alarme, Runbooks, puteve eskalacije; pruža povratnu informaciju o kvaliteti alarma.

Važno je uspostaviti obavezan ritam (mjesečno ili svaka dva tjedna): SLO-pregled, najvažniji alarmi, troškovi/volumen, otvorene nepoznanice.

Povezati Runbooks i incident-proces s Observability

Alarm bez uputstva za postupanje je buka. Povežite svako kritično pravilo alarma s Runbookom (kratke upute): Što provjeriti? Koji dashboardi/pogledi su relevantni? Kako se eskalira? Koje su dopustive hitne mjere (npr. onemogućiti funkciju, ograničiti queue, režim samo za čitanje)?

Za IT-upravljanje to je i poluga za skaliranje: dobri Runbookovi smanjuju ovisnost o pojedincima i skraćuju srednje vrijeme rješavanja (MTTR) bez „herojstva“.

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

Ako je Error Budget ograničen, rizične promjene treba odgoditi ili ih uvesti uz dodatne zaštitne mjere (npr. Canary, Feature Flags, usko nadzorno razdoblje). To nije cilj samo po sebi: sprječava situaciju da stabilnost postane važna tek nakon incidenta.

Sadržajno se ovdje može dobro nasloniti na postojeće standarde release-managementa i povezati interne veze na sadržaje o rolloutu, prihvatu i planiranju povratka.

Kontrolna lista: Upozoravajući signali da vaš Observability-Projekt izlazi iz kontrole

• Alarmi se redovno utišavaju ili ignorišu.
• Dashboards su brojni, ali niko ne zna koji je presudan u incidentu.
• Obim logova raste brže od koristi; retention se skraćuje „po osjećaju“.
• Sigurnost i zaštita podataka se raspravlja tek nakon puštanja u rad o sadržaju logova.
• Incidenti često završavaju s „nije se moglo reproducirati“ ili „nije jasno ko je odgovoran“.
• Tracing postoji, ali bez jedinstvenog korelacionog ID‑a preko sučelja.

Ako se više stavki poklapa, gotovo uvijek se isplati reset putem SLOs: prioritizirati mali broj servisa, definirati jasne SLIs, ciljano usmjeriti telemetriju i radikalno pojednostaviti alarmiranje.

Zaključak: SLOs ponovo čine Observability upravljivom – i operativno iskrenom

Monitoring, Logging und Tracing su neophodni, ali sami po sebi ne rješavaju operativni problem. Observability‑projekt obično ne propada zbog nedostatka podataka, već zbog nedostatka jasnoće ciljeva, lošeg kvaliteta alarma, nekontrolisanih količina podataka i nejasne odgovornosti. SLOs vraćaju inicijativu na ono što u svakodnevnom radu vrijedi: pouzdani servisi duž procesnog lanca, jasni prioriteti tokom incidenta i razumljive odluke između stabilnosti, troškova i promjena.

Ako želite Observability u vašem okruženju ponovno usmjeriti ili pragmatično stabilizirati zaglavljeni setup, vrijedi strukturiran pogled na granice servisa, SLIs, telemetrijsku pipeline i operativne procese. Za prvu procjenu i čist Početak projekta — arhitektura i suradnja možete nas kontaktirati putem .

Razgovarajte o projektu ili modernizaciji sa Net-Base.