Monitoring, Logging, Tracing: Како пројекти observability-а пропадају и како их спасити јасним SLO-овима

Пројекат Observability почиње у многим предузећима са добрим импулсом: открити отказе брже, јасно сузити узроке, растеретити подршку, учинити релизе сигурнијим. У пракси, међутим, иницијатива често прелази у супротно: превише контролних табли без смисла, превише аларма без приоритета, растући трошкови складиштења и лиценцирања, а на крају остаје отворено питање да ли је операција заиста боља.

Основни недостатак ретко је у одсутном алату. Чешће недостаје стручно јасна дефиниција циља: шта треба поуздано да функционише за коју сервисну или процесну нит – и како то меримо? Управо ту помажу SLOs (Service Level Objectives, мерљиви циљеви за услугу) као водиље. SLOs повезују техничку телеметрију (Monitoring, Logging, Tracing) са реалношћу операција, одговорностима и путем до одлука.

Овај чланак сврстава типичне моделе неуспеха и показује како да вратите Observability на прави курс помоћу јасних SLOs – са фокусом на операције, администрацију, податке, интерфејсе, одржавање, безбедност и rollout.

Monitoring, Logging, Tracing: шта је шта – и зашто „више података“ није довољно?

Observability се често користи као збирни појам. За оперативу је важно јасно разлучити три врсте сигнала:

• Monitoring/Metrike: сабијене временске серије (нпр. времена одговора, стопе грешака, дужине редова). Предност: брзо, економично, лако за алармирање. Ризик: без контекста тешко се објашњавају.
• Logging: догађаји са контекстом (нпр. налог креиран, валидација није успела, спољашњи API враћа 503). Предност: детаљно и аудитабилно. Ризик: количине података, заштита података, „супа од логова“ без структуре.
• Tracing: распоређене трагове извршавања преко више компонената (Distributed Tracing). Предност: показује где се губи време и која зависност блокира. Ризик: инструментовање, стратегија узорковања, корелација међу системима.

Честа заблуда: ако само сакупимо довољно логова и траса, инциденти ће се готово сами решити. У стварности, сложеност прво расте. Без циљне визије и критеријума релевантности, Observability постаје складиште података – а не инструмент за управљање.

Зашто Observability-пројекти пропадају: најчешћи узорци из оперативне праксе

Следећи узорци појављују се посебно често у развијеним корпоративним окружењима – тамо где су бизнис-софвер, интерфејси и инфраструктура расла годинама и у којима је укључено више тимова.

1) Tool-first уместо Service-first: контролне табле без оперативне одлуке

Uvodи se novi APM- ili log-alat, zatim se „za svaki slučaj“ prave dashboard-i. Ono što nedostaje je pitanje: Koja operativna odluka treba da se donosi brže ili bolje zahvaljujući tome? Dashboard koji pri incidentu ne pomaže u svakodnevnom radu često je samo dekoracija. Tipični simptom: u slučaju kvara timovi skaču između deset pogleda, ne znajući koji od njih je pouzdan.

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

Ako svako opterećenje CPU, svaka pojedinačna HTTP-greška i svako upozorenje agenta završi kao alarm, rezultat nije veća sigurnost već otupljivanje pažnje. Alert Fatigue znači: on-call reaguje sporije, eskalacije postaju nejasne, a stvarni kvarovi ostaju neprimećeni. Za IT-upravljanje to je i rizik u pogledu usklađenosti i dokazivosti: „Imali smo alarme“ nije dokaz da je bilo ciljano reagovano.

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

Posebno kod procesno-približnih softverskih rešenja (ERP-srodni workflow-i, integracione linije, portali) incidenti često nastaju na interfejsima: REST-APIs, message broker-i, uvozi datoteka, EDI, identity-provider-i. Bez ID-a za korelaciju (jedinstvena oznaka koja teče kroz ceo lanac) pojedinačan zahtev se ne može pratiti end-to-end. Ishod: mnogo vremena otiđe na „da li je to kod nas ili kod partnera?“ umesto na analizu uzroka (Root Cause Analysis).

4) Eksplozija troškova zbog obima log-ova i trace-ova

Logging i tracing stvaraju velike količine podataka. Bez strategije zadržavanja (Retention-Strategie), uzorkovanja (Sampling, ciljna uzorka kod trace-ova) i pravila filtriranja, storage i ingest brzo postaju skupi — kako on-prem, tako i u cloudu. Često se tada panično seče, što pogoršava kvalitet podataka. To stvara začarani krug: manje poverenja → više „za svaki slučaj“ logovanja → veći troškovi.

5) Bezbednosna i pitanja zaštite podataka se adresiraju prekasno

Logovi brzo sadrže lične podatke (imena, e‑mail, IP, brojevi kupaca) ili osetljiv sadržaj (tokens, session‑ID‑je, interne URL‑ove). Ako pravna i security‑perspektiva dođu tek posle roll‑out‑a, prete dve loše opcije: isključiti ili „nastaviti kako je“ sa rizikom. Observability mora od početka da uključi klasifikaciju podataka (nivo zaštite), maskiranje/redaction i koncepte pristupa.

6) Nejasna odgovornost: Ko je za koji servis „on the hook“?

U mnogim kompanijama tim A održava infrastrukturu, tim B aplikaciju, tim C integraciju, tim D stack baze podataka. Observability ukaže na probleme — ali bez jasno definisanih servisa i operativnih obaveza odgovornost ostaje razvodnjena. Tada se završava u chat‑diskusijama umesto u čistom incident procesu sa jasnim predajama.

SLOs kao oslonac: Šta dobro SLO omogućava

SLOs su merljivi ciljevi kvaliteta servisa. Izvode se iz SLIs (Service Level Indicators, izmerena metrika). Važno: SLOs nisu primarno marketinške „brojke dostupnosti“, već upravljački instrument za operacije i prioritizaciju.

Dobar SLO odgovara za konkretan servis (npr. „unos porudžbine u portalu“, „upload dokumenata“, „noćni batch faktura“, „API za knjiženje zaliha“) na tri pitanja:

• Šta je iz korisničkog ugla „dobro“? (npr. „odgovor < 1,5 s“ ili „uspeh bez grešaka“)
• Kako to objektivno merimo? (SLI, izvor podataka, merni prozor)
• Šta se dešava ako se ne ispuni? (prioriteti, Change‑Stop, mere za kapacitet)

Тиме се обсервабилност претвара из језера података у систем који подржава одлучивање: шта је тренутно заиста критично? Где ћемо улагати следеће? Које ризике свесно прихватамо?

Од SLA до SLO и Error Budget-а: практична оријентација за доносиоце одлука

У предузећима често постоје SLAs (Service Level Agreements, уговорне или интерне обавезе). SLOs су ближе техници и операцијама и могу служити као унутрашња контролна величина, чак и када је SLA веома грубо дефинисан.

Један централни механизам је Error Budget: ако SLO нпр. захтева 99,9% успеха у 30 дана, мали „буџет“ грешака/недоступности је прихватљив. То на први поглед делује контраинтуитивно, али је оперативно корисно: омогућава објективну равнотежу између стабилности и промена (releases, миграције, оптимизација перформанси).

Важно за праксу: Error Budgets функционишу само ако је мерење поштено и организација спремна да изведе последице. У супротном, то остаје само још једна метрика.

Дефинисање SLOs који заиста усмеравају мониторинг, логовање и трасинг

Најчешћа грешка код SLOs је да су превише генераички („99,9% доступности апликације“). Корисније је структурирање SLO-ова дуж корисничких акција и тачака интеграције. Прагматичан приступ:

Корак 1: Одредите границе сервиса дуж процесног ланца

Не дефинишите „Services“ по органиграму, већ по ефекту: нпр. „креирање наруџбине“, „обрада плаћања“, „евидентирање комисионирања“, „интерфејс ка сервису за испоруку“. Посебно у окружењима са индивидуалним пословним софтвером ове границе су пресудне, јер подршка и пословна јединица размишљају у тим јединицама.

Корак 2: По сервису 1–3 SLIs који одражавају утицај на корисника

Показали су се корисним следећи SLI-ји:

• Стопа успеха трансакције (нпр. HTTP 2xx/3xx, или „Business Success“ из апликационе логике)
• Латенција на критичном путу (p95/p99 уместо просека)
• Freshness код data-pipeline-ова („Колико су подаци стари у DWH/извештавању?“)

Поента: није свака системска метрика SLI. Високо оптерећење CPU је симптом, али не резултат за корисника. Користите системске метрике као дијагнозу, не као циљ.

Корак 3: Јасно утврдите мерни прозор, изузећа и зависности

SLO без мерног прозора је безвредан. Утврдите: 28 дана ролујуће? По месецима? Само у радном времену пословања? И разјасните које зависности се укључују: ако спољни партнерски API падне, да ли се то рачуна у ваш SLO? За оперативу и ескалацију ова јасноћа је изузетно вредна.

Корак 4: Повежите alerting са SLO burn-rate-ом

Уместо „Alarm bei Fehler > X in 5 Minuten“ у пракси често боље функционише burn-rate приступ: колико брзо се троши Error Budget? На тај начин приоритетизујете аларме према ризику за испуњење циља – не према јачини појединачних метрика. Резултат: мање аларма, али релевантнији.

Последице за архитектуру: шта морате технички планирати за поуздану обсервабилност

SLO-ови су управљање (Governance), али им је потребна техничка основа. У развијеним окружењима то ретко значи „само конфигурисати“. Типични архитектонски елементи:

Телеметријска линија: прикупљање, трансформисање, складиштење, издавање

Било on-prem или у облаку: требате јасан ланац којим телеметрија улази у систем. У то спадају агенти/collector, транспорт (ред/бафер), обрада (парсирање, обогаћивање, редакција/маскирање), складиштење и приступ. Посебно код логовања и трасирања бафер је важан да би се пригушили вршни оптерећења и у случају прекидања не оптерећивали продуктивни системи.

Идентитети и приступи: ко сме да види које податке?

Подаци о observability су често осетљиви. Планирајте роле и концепте višetenantnosti: оперативни тим види метрике инфраструктуре, подршка види корелиране догађаје, пословни одсек добија само агрегиране погледе сервиса. Допуните audit-logове за приступ логовима/trace-овима када су релевантни регулаторни захтеви.

Хигијена података при логовању: структура, редакција, ретенција

„Beležimo sve“ није план. Смислено су структурирани логови (strojno читљиви), дефинисана поља (нпр. сервис, окружење, корелациони ID, класа грешке) и доследно маскирање. Одредите ретенцију према сврси: кратко за дебаг (нпр. 7–14 дана), дуже за безбедносне догађаје или захтеве за ревизију – али одвојено, како би трошкови и права приступа остали контролисани.

Tracing циљано, не широм: узорковање и критични путеви

Distributed Tracing је посебно вредан на интеграционим трасама и код проблемâ са перформансама. Међутим, свеобухватно 100% tracing ретко је исплативо и често није потребно. Уведите правила узорковања (нпр. више trace-ова при грешкама или при необичној латенци) и фокусирајте се на критични пут: Login/SSO, upload, чување налога, позив интерфејса, обрада реда (queue).

Конкретни примери: SLO-ови за типичне сценарије пословног софтвера

Да SLO-ови не остану теорија, ево три примера који се често појављују у процесно близим софтверским решењима. Подаци су намерно дати као плејсхолдери – циљне вредности морају одговарати употреби, профилу оптерећења и ризику процеса.

Пример A: Кориснички портал „Креирање налога“

• SLI стопа успеха: Удео успешно завршених креирања налога (poslovni uspeh) у периоду од 30 дана.
• SLI латенција: p95 крај-по-крај времена за креирање налога (укљ. DB-commit и потврдна реплику/одговор).
• Дијагностички сигнали: DB-deadlock-ови/timeout-ови, дужине редова (queue) за накнадну обраду, класе грешака у апликационом логу (валидација против инфраструктуре).

Важно: SLO би требало да мери ток корисника, не само „HTTP 200“. У супротном можете пропустити случајеве у којима је захтев технички успешан, али је пословно прекинут.

Пример B: Интерфејс ка добављачу услуга доставе (REST/EDI)

• SLI: удел пријава пошиљки које су успешно потврђене у року од X минута (укључујући поновне покушаје).
• Зависности: екстерни endpoint, мрежни пут, сертификати, rate-limits.
• Дијагностика: шифре грешака по категоријама, стопа поновних покушаја, Dead-Letter-Queue (спремиште за поруке које након више покушаја нису могле бити обрађене).

Овде се види додата вредност SLO-а за операције: можете јасно раздвојити да ли инцидент утиче на сопствену обраду (нпр. истекао сертификат) или примарно на партнера (нпр. 5xx грешке). То смањује време у War Room-u и побољшава комуникацију са пословним одељењем и партнерима.

Пример C: Ноћни циклус „Фактура/Batch-обрада“

• SLI: удел batch послова који су успешно завршени до дефинисаног времена пресека.
• SLI: број мануелних интервенција по извршавању (операције које покрећу runbook-ове).
• Дијагностика: узорци lock-/deadlock-а у бази података, уска грла у ресурсима, IO времена чекања, одступања у подзадатцима.

Посебно су batch процеси класичне „blind spots“: корисници уочавају проблеме тек ујутру. SLO са временом пресека поставља јасна очекивања и омогућава циљано alert-овање које не ескалира свако мало Kašnjenje, али рано сигнализира стварне ризике.

Rollout и операције: Како SLO-модел остаје жив у свакодневном раду

Најтежи део није прва дефиниција, већ утврђивање. Observability често не успева због оперативних процеса, а не због технике.

Улоге и одговорности (без додатног overhead-а)

Не треба вам велика SRE-организација, али су потребне јасне надлежности:

• Service Owner: одговоран функционално/технички за циљне вредности и приоритизацију.
• Ops/Plattform: управља telemetry-pipeline-ом, приступом, retention-ом, контролом трошкова.
• On-Call/Support: користи alert-е, runbook-ове, ескалационе путеве; даје повратну информацију о квалитету аларма.

Важно је имати обавезан ритам (месечно или на сваких две недеље): SLO-review, топ alert-и, трошкови/обим, отворене непознанице.

Повезивање runbook-ова и процеса инцидента са Observability

Аларм без пута деловања је бука. Повежите свако критично правило за alert са runbook-ом (кратка упутства за поступање): Шта проверити? Који dashboard-и/вјуови су релевантни? Како се ескалира? Које хитне мере су дозвољене (нпр. искључити функционалност, ограничити обраду реда, режим само за читање)?

За IT-менаџмент то је и полуга за скалирање: добри runbook-ови смањују зависност од појединаца и скраћују средње време решавања (MTTR) без „херојисања“.

Release- и Change-Management: SLO-ови као знак заустављања, а не декорација

Ако је Error Budget ограничен, ризичне промене треба одложити или их имплементирати уз додатне заштитне мере (нпр. Canary, Feature Flags, уско monitoring-подручје). То није циљ сам по себи: спречава да стабилност постане важна тек након пада система.

Садржајно се овде може добро надоградити на постојеће стандарде release-management-а и повезати интерне линкове ка чланцима о rollout-у, пријему и плановима за rollback.

Контролна листа: Упозоравајући сигнали да ваш Observability-пројекат излази из контроле

• Аларми се редовно утишaвају или игноришу.
• Дашборди су бројни, али нико не зна који је кључан у инциденту.
• Обим логова расте брже од користи; ретенција се скраћује „по осећају“.
• Питања безбедности/заштите података расправљају се тек после rollout-а у вези садржаја у логовима.
• Инциденти често заврше са „није могло да се репродукује“ или „нејасно ко је задужен“.
• Трејсинг постоји, али без доследног корелационог ID кроз интерфејсе.

Ако се односи више тачака, скоро увек има смисла направити reset помоћу SLOs: приоритетизовати неколико сервиса, дефинисати јасне SLIs, циљано усмерити телеметрију, радикално поједноставити алармирање.

Закључак: SLOs чине Observability поново управљивом – и оперативно искреном

Monitoring, Logging и Tracing су неопходни, али сами по себи не решавају оперативни проблем. Пројекат Observability обично не пропада због недостатка података, већ због нејасне циљности, лошег квалитета аларма, неконтролисаних количина података и нејасне одговорности. SLOs враћају иницијативу на оно што у пословној свакодневици вреди: поуздани сервиси дуж процесног ланца, јасни приоритети у инциденту и прозрачне одлуке између стабилности, трошкова и промена.

Ако желите да прилагодите Observability у вашој средини или прагматично стабилизујете заглављену конфигурацију, вреди структуриран преглед граница сервиса, SLIs, телеметријске пајплајн и оперативних процеса. За прву процену и чист почетак пројекта — архитектура & сарадња контактирајте нас преко .

Разговарајте о пројекту или намери за модернизацију са Net-Base.