Loki, Grafana i pgvector audit: tri sloja observabilityja za AI sustav

Kad gradite sustav koji samostalno donosi odluke u stvarnom vremenu, monitoring nije opcija – on je jedini način da uopće smijete pustiti taj sustav u produkciju. Većina inženjera misli da je observability samo pitanje dashboarda i alarma. To je kao reći da je kirurgija samo pitanje skalpela. Istina je složenija i puno konkretnija: trebate tri potpuno različita sloja promatranja, od kojih svaki rješava bitno drugačiji problem. Naš sovereign AI operativni sustav koristi Loki za logove, Grafanu i Prometheus za metrike te PostgreSQL s pgvectorom za audit chain. Zvuči kao standardni stack, ali način na koji smo ih povezali nije baš standardan.

Prvi sloj su metrike. Ovdje Prometheus vuče podatke iz svakog čvora, svakog modela i svakog API poziva. Grafana crta stvarne brojke: latenciju, protok tokena, stopu grešaka, iskorištenost GPU memorije. To je ono što vidite u realnom vremenu, ono što vam treba da znate je li sustav živ ili je u konvulzijama. Ako vam latencija skoči sa 200 na 2000 milisekundi u minuti, ne želite čekati log analizu. Želite alarm koji će probuditi inženjera u tri ujutro. Prometheus s Alertmanagerom to radi besprijekorno, ali samo ako ste dobro definirali pragove. Problem s metricama je što vam govore da nešto nije u redu, ali vam ne govore zašto.

Drugi sloj su logovi, i tu dolazi Loki. Za razliku od klasičnih log agregatora poput Elasticsearcha, Loki ne indeksira sadržaj logova, već samo metapodatke – oznake poput imena servisa, razine ozbiljnosti ili ID-a zahtjeva. To ga čini nevjerojatno brzim i jeftinim za pohranu, što je ključno kad vaš AI sustav generira gigabajte logova na sat. Loki je naš prvi odgovor kad metrike pokažu anomaliju. Otvorite Grafanu, prebacite se na Explore, upišete upit za taj vremenski prozor i vidite što se točno dogodilo. Je li model vratio nonsense output? Je li RAG pipeline promašio context window? Je li došlo do timeouta na vektorskoj bazi? Loki daje kontekst koji metrikama nedostaje.

Treći sloj je audit chain, i tu smo napravili nešto što rijetko viđate u standardnim observability stackovima. Koristimo PostgreSQL s pgvector ekstenzijom za pohranu svake značajne odluke koju AI sustav donese. To nisu logovi u klasičnom smislu – to su strukturirani zapisi koji uključuju input, output, confidence score, vrijeme izvršenja, verziju modela i referencu na relevantne dokumente iz vektorske baze. Svaki takav zapis ima svoj vektorski embedding, što znači da kasnije možete raditi semantičku pretragu po audit trailu. Trebate naći sve slučajeve gdje je model odbio zahtjev s confidenceom ispod 0.3? To je jednostavan SQL upit s vektorskom sličnošću.

Zašto vam trebaju tri sloja, a ne jedan? Zato što svaki sloj rješava bitno drugačiji problem s različitim zahtjevima za latencijom i retencijom. Metrike su za real-time alerting: podaci stari pet minuta su beskorisni. Logovi su za forensic replay: trebate ih čuvati tjednima ili mjesecima, ali vam ne trebaju za automatske reakcije. Audit chain je za compliance proof: podaci moraju biti nepromjenjivi, potpisani i čuvani godinama, a moraju podržavati i naknadne revizije koje uključuju semantičku analizu. Pomiješati te zahtjeve u jednu bazu je recept za katastrofu – ili ćete platiti bogatstvo za storage, ili ćete žrtvovati brzinu.

Konkretno, u našem sustavu metrike idu na Prometheus s retencijom od 30 dana. Loki čuva logove 90 dana, s tim da ih arhiviramo u cold storage nakon 30. Audit chain u PostgreSQLu je zauvijek. Svaki unos u audit tablicu ima vremenski pečat, digitalni potpis i embedding. To znači da možete povući bilo koju odluku iz prošlosti i dokazati da je baš taj input generirao baš taj output, bez mogućnosti naknadne manipulacije. Za regulirane industrije poput financija ili zdravstva, to nije luksuz – to je uvjet za dobivanje dozvole za rad.

Gradimo ovo svaki dan. Ako tvoja institucija troši mjesece na taj problem — razgovaraj s nama.

Integracija između slojeva je ono gdje većina sustava padne. Metrika vam kaže da je latencija porasla. Log vam kaže da je jedan worker node počeo vraćati greške. Audit chain vam kaže da je taj node obrađivao zahtjeve s dokumentima iz specifične domene. Tek kad spojite sva tri podatka, dobijete cjelovitu sliku: problem je u vektorskim embeddingima za pravne dokumente, jer je novi model loše generalizirao na tom podskupu. Da imate samo metrike, mislili biste da vam treba više GPU snage. Da imate samo logove, mislili biste da je greška u kodu. Audit chain vam je dao uzrok.

Alarmiranje smo postavili u tri razine. Prva razina su automatske reakcije: ako latencija prijeđe prag, sustav sam prebaci promet na backup model. Druga razina su notifikacije inženjerima: ako stopa grešaka poraste iznad 1%, šalje se summary s linkom na relevantne logove u Lokiju. Treća razina su tjedni izvještaji koji kombiniraju metrike s audit chainom i pokazuju trendove: koji modeli najčešće padaju, koji tipovi zahtjeva generiraju najviše low-confidence outputa, gdje treba retrenirati. Bez ove hijerarhije, ili vas alarmi zatrpaju do te mjere da ih ignorirate, ili propustite kritične signale.

Najzanimljiviji dio je korištenje pgvectora za audit pretragu. Zamislite da vam stigne zahtjev iz regulatornog tijela: "Pokažite nam sve slučajeve u zadnjih šest mjeseci gdje je sustav odbio kreditnu prijavu osobi starijoj od 65 godina." Klasični SQL upit po metapodacima bi funkcionirao, ali što ako je odbijanje bilo implicitno – model je vratio nisku ocjenu, a ne eksplicitnu poruku o odbijanju? S pgvectorm možete napraviti semantičku pretragu: nađite sve audite gdje je embedding outputa sličan embeddingu koncepta "odbijanje kredita starijim osobama". To je forenzika koju klasični logovi ne mogu pružiti.

Postavljanje ovog trostrukog sustava nije trivijalno. Svaki sloj zahtijeva različite resurse i različitu konfiguraciju. Loki treba dovoljno RAM-a za ingestere, Prometheus treba pažljivo definiran scrape interval, a PostgreSQL s pgvectorm treba dobro indeksiranje da upiti ne traju vječnost. Greška koju smo vidjeli kod drugih timova je što pokušavaju sve strpati u jedan cluster. Rezultat je da vam metrike kasne jer Loki troši CPU, ili vam audit upiti traju sekunde jer Prometheus drži previše podataka u memoriji. Odvojite resurse po sloju i skalirajte nezavisno.

Još jedna stvar koju smo naučili na teži način: logovi i auditi nisu isto. Logovi su dijagnostički – oni vam pomažu naći grešku. Auditi su dokazni – oni moraju biti nepromjenjivi i potpisani. Ako miješate te dvije svrhe, riskirate da vam netko ospori integritet audita jer ste slučajno obrisali stari log da uštedite prostor. U našem sustavu, logovi idu u Loki i mogu se brisati po politici retencije. Auditi idu u PostgreSQL i brišu se samo po sudskom nalogu. To nije tehnička odluka, to je compliance odluka koju smo morali donijeti prije prvog deploymenta.

Kad sve tri komponente rade zajedno, dobit ćete nešto što je više od pukog monitoringa. Dobićete sposobnost da razumijete zašto se vaš AI sustav ponaša onako kako se ponaša, čak i mjesecima nakon događaja. To je razlika između sustava koji samo radi i sustava kojem možete vjerovati. A u svijetu gdje AI odluke sve više ulaze u regulirane procese, ta razlika vrijedi više od bilo koje optimizacije latencije.