Telegram kao watchdog: zašto svaka kritična akcija mora poslati poruku

Monitoriranje infrastrukture je kao da čuvaš nuklearni reaktor s dva pijetla i jednim psom koji spava. Većina timova koristi Slack ili Discord za alerte — i to je u redu dok ne shvatiš da ti je aplikacija pala prije dvadeset minuta, a ti si tek sad dobio notifikaciju jer je Slack odlučio grupirati poruke. To nije fail-safe. To je kozmetički flaster na otvorenu ranu. Telegram je, s druge strane, dizajniran kao messaging sistem bez milosti: brz, pouzdan, i neće ti uštedjeti na drami kad stvarno trebaš znati da je nešto crklo. Mi smo u RiNET Engineeringu proveli mjesece testirajući razne pattern-e za async notifikacije, i Telegram je izašao kao pobjednik iz svakog stresa. Ne zato što je moderan, nego zato što je brutalan u svojoj jednostavnosti.

Kada kažem da Telegram radi kao watchdog, mislim doslovno: svaka kritična akcija u našem sovereign AI operativnom sustavu mora poslati poruku. To nije opcija, to je zakon. Od trenutka kad LLM model završi inferenciju, preko trenutka kad se dogodi failover na backup node, pa sve do trenutka kad neki deployment prođe bez greške — sve mora imati svoj digitalni otisak u chatu. Zašto? Zato što observability nije samo o metrici i grafovima. To je o povjerenju. A povjerenje se gradi na transparentnosti: ako ne vidiš poruku, ne znaš da se dogodilo. I obrnuto — ako vidiš poruku u roku od dvije sekunde, znaš da je sustav živ. Telegram API, s limitom od 4096 znakova po poruci, nudi dovoljno prostora za detalj, ali i testira tvoju sposobnost da budeš koncizan.

Problem s većinom monitoring alata je što su dizajnirani za dashboard, ne za ljudski mozak. Grafana ti pokaže spike, ali ne kaže zašto. PagerDuty te probudi, ali ne daje kontekst. Telegram, s druge strane, omogućuje da u jednoj poruci pošalješ strukturirani JSON sa svim relevantnim podacima: vrijeme, servis, error code, stack trace, čak i prijedlog rješenja ako imaš RAG pipeline. I to sve unutar 3500 znakova — safety buffer ispod 4096 limita, jer ne želiš da ti se poruka odsiječe na pola riječi. Mi smo razvili helper funkciju koja automatski splita poruku na chunkove od 3500 znakova, dodaje sequence number u svaki chunk, i brine se da ni jedan bit informacije ne izgubi. To nije rocket science, ali je inženjerska disciplina.

Zašto Slack i Discord nisu dovoljno brzi za infrastrukturne alerte? Zato što su dizajnirani za ljude, ne za strojeve. Slack ima rate limiting koji ti može uskratiti poruke ako previše puta u sekundi šalješ alert. Discord ima WebSocket koji zna kasniti kad je opterećen. Oba su izvrsna za timsku komunikaciju, ali nisu napravljena za high-frequency, low-latency notifikacije koje zahtijeva kritična infrastruktura. Telegram je, s druge strane, izgrađen na MTProto protokolu koji prioritizira brzinu i pouzdanost. U testovima smo mjerili latenciju ispod 200 milisekundi za 99% poruka, čak i kad smo slali stotine notifikacija u sekundi. To je razlika između toga da znaš da je server pao dok još gledaš u terminal i da saznaš pet minuta kasnije iz pogrešnog loga.

Arhitektura koju koristimo je deceptivno jednostavna. Svaka komponenta u sustavu — bilo da je to LLM inferencija, RAG pretraživanje, ili monitoring agent — ima ugrađeni Telegram bot klijent. Kada se dogodi kritični event, komponenta poziva helper funkciju koja formatira poruku, provjerava duljinu, splita ako treba, i šalje na predefinirani chat ID. Ne koristimo nikakav centralizirani queue jer bi to uvelo single point of failure. Svaka komponenta je autonomna u slanju poruka. Ako centralni server padne, agenti i dalje šalju alerte direktno na Telegram. To je zero-trust pattern za notifikacije: ne vjeruj ničemu, provjeri sve, i pošalji poruku prije nego što bilo tko drugi stigne reagirati.

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

Jedan od najvažnijih aspekata je formatiranje poruke. Telegram podržava Markdown, HTML, pa čak i inline keyboarde, ali mi smo se odlučili za čisti tekst s minimalnim formatiranjem. Zašto? Zato što kad ti server gori, ne želiš da ti bot šalje animirane GIF-ove. Trebaš sirovi podatak: ime servisa, timestamp, severity level, i akciju koju treba poduzeti. Naš format izgleda otprilike ovako: CRITICAL: inference-node-3 down at 2024-11-20T14:32:17Z. Suggested action: restart with `kubectl rollout restart deployment inference-node-3`. To je sve. Bez suvišnog teksta, bez emojija. Samo informacija koju možeš kopirati i izvršiti u roku od pet sekundi. Ako trebaš više detalja, RAG pipeline može poslati follow-up poruku sa stack traceom.

Testirali smo ovaj pattern na više od 50.000 notifikacija u produkciji. Prosječna latencija od eventa do prikaza poruke na Telegramu bila je 180 milisekundi. Najgori slučaj je bio 1.2 sekunde, i to zbog network congestiona. Nitko nije propustio alert. Nitko nije rekao "nisam vidio poruku". To je moć asinkrone notifikacije koja je dizajnirana za strojeve, ne za ljude. Ljudi će uvijek naći izgovor zašto nisu vidjeli poruku na Slacku. Telegram ih nema. Poruka je tu, u chatu, i ne možeš je ignorirati jer ti bot šalje notifikaciju direktno na mobitel. To je psihološka prednost: kad znaš da će ti svaki kritični event pokucati na džep, ozbiljnije shvaćaš monitoring.

Naravno, postoje i izazovi. Telegram ima limit od 30 poruka u sekundi po botu, što znači da moraš pažljivo throttlati ako imaš stotine komponenti koje šalju alerte istovremeno. Tu smo implementirali fallback: ako bot detektira da se približava rate limitu, automatski prebacuje na batch poruke — umjesto 30 zasebnih poruka, pošalje jednu summary poruku s listom eventova. To nije idealno, ali je bolje nego da izgubiš poruke. Također, moraš paziti na sigurnost chat ID-a. Ako netko dobije pristup bot tokenu, može čitati sve poruke. Zato koristimo environment varijable i rotiramo tokene svakih 30 dana. Nema mjesta za lijenost kad je infrastruktura u pitanju.

Ono što me najviše iznenađuje je koliko ljudi još uvijek ignorira ovaj pattern. Vidim timove koji koriste isključivo Grafana alerts i čude se zašto im je mean time to recovery 45 minuta. Zato što dashboard nije notifikacija. Dashboard ti kaže "nešto nije u redu" kad već sjedneš za stol. Telegram ti kaže "nešto nije u redu" dok si još u krevetu, na putu do posla, ili na ručku. To je razlika između reaktivnog i proaktivnog monitoringa. Mi smo u RiNET Engineeringu odlučili da nećemo čekati da korisnici prijave problem. Želimo da svaki problem bude prijavljen prije nego što ga itko primijeti. A to je moguće samo ako svaka kritična akcija pošalje poruku.

Na kraju dana, Telegram kao watchdog nije tehnologija. To je filozofija. To je odluka da svojoj infrastrukturi daš glas — glas koji neće šutjeti kad nešto krene po zlu. I dok se drugi timovi bude u 3 ujutro na poziv PagerDutyja, mi ćemo već znati što je palo, zašto je palo, i kako to popraviti. Jer poruka je stigla prije nego što je itko stigao nazvati.

Ako te zanima ovakva arhitektura ili gradiš nešto slično za svoju instituciju — javi se preko rinet.one.