AI imebadilisha jinsi tunavyotengeneza programu, lakini haijabadilisha ukweli wa msingi kuhusu mashine. Zinazama kwenye kelele kama sisi. Wahandisi wanapojaribu kwa mara ya kwanza kutumia AI kusaidia kurekebisha makosa (debugging), hisia ya kwanza ni rahisi: kulisha modeli kila kitu. Logi ghafi, traces, na metrics zote hutiwa kwenye context window. Matokeo si ufahamu, bali ni kushindwa. Kiasi ni kikubwa mno. Ishara (signal) inaporomoka. Metrics zinakaa kwenye kifaa kimoja, traces kwenye kingine, na modeli haiwezi kuzichanganya kuwa simulizi inayoeleweka. Kabla ya AI kukusaidia kuchunguza mifumo yako, lazima uichunguze mwenyewe. Lazima uandae data kwanza.

Kwa nini Logi Ghafi Huharibu Pipelines za AI

Mifumo ya kisasa inazalisha telemetry kwa kasi ambayo binadamu hawezi kusoma. Hilo linapaswa kuifanya iwe bora kwa akili mnemba (AI). Hali iko tofauti. Context window ya modeli kubwa ya lugha (LLM), ingawa inakua, bado ni bomba lenye ukomo. Ijae na logi ghafi za uzalishaji (production logs) na utapoteza tokens kwenye taarifa za cron job na kelele za health-check huku ukificha hitilafu halisi. Mbaya zaidi, logi ghafi hukosa uhusiano. Ongezeko la latency saa 8:00 mchana na hitilafu ya muunganisho wa database kwenye logi katika muda huo huo zina uhusiano wa wazi, lakini isipokuwa mtu awe ameuandaa uhusiano huo mapema, AI itabidi ikisia. Kukisia ni gharama kubwa, polepole, na mara nyingi ni makosa.

Suluhisho ni la kimitandao (architectural), si la kialgorithmi. Unahitaji kuamua nini kinakusanywa, jinsi kinavyoundwa, na ni backend ipi inayojibu swali gani kabla ya kuanza kutoa maelekezo (prompt) kwa modeli.

Misingi Minne ya Ufuatiliaji

Katika airCloset, timu ya uhandisi iliacha kuchukulia observability kama bomba moja kubwa la data. Waligawanya ufuatiliaji katika misingi minne tofauti. Kila moja ina umbo maalum na inajibu swali maalum.

  • Application: Logi na traces zinajibu "Nini kinaendelea sasa hivi?"
  • Infrastructure: Metrics zinajibu "Je, tuna rasilimali za kutosha?"
  • CI: Logi na alerts zinajibu "Nini kimeharibika na lini?"
  • LLM: Metrics na rekodi zilizopangwa zinajibu "Tunatumia kiasi gani?"

Mgawanyo huu ni muhimu kwa sababu umbo sahihi kwa grafu ya latency ya wakati halisi (real-time) halina manufaa kwa uchambuzi wa gharama wa baada ya tukio (post-hoc). Kulazimisha schema moja katika nyanja zote nne kunazalisha aina ile ile ya kelele inayofanya msaada wa AI usiwe na manufaa.

CI Observability: Vuta, Usisukume

Continuous integration ndipo kodi inapokutana na uhalisia. Build inapofeli, watengenezaji wanahitaji simulizi hiyo haraka. Njia rahisi ni kuwa na CI runner inayotumia kusukuma (push) logi moja kwa moja kwenye observability backend yako wakati inafanya kazi. Inaonekana kuwa na ufanisi. Kwa kweli ni hatari.

Katika airCloset, walibadilisha mfumo huo. CI runner haigusi observability stack. Baada ya GitHub Actions workflow kumalizika, wanavuta (pull) logi kutoka kwenye GitHub API na kuziingiza (ingest) kwenye Loki.

Muundo huu wa kuvuta (pull architecture) unaleta faida tatu madhubuti.

Kutenganisha (Decoupling). Ikiwa pipeline ya uingizaji (ingestion pipeline) itapata hitilafu au Grafana isipatikane, mwenendo wa jaribio wenyewe hautaguswa. Build inapita au kufeli kwa sifa zake mwenyewe. Kufeli kwa observability kusipapaswa kamwe kuzuia deployment.

Usalama (Security). CI workflow haihitaji kamwe Grafana API key. Kadi ya majaribio (test code) inajulikana kwa kugusa siri ambazo hazipaswi, na kuondoa uwezekano huo hupunguza eneo la athari (blast radius) ikiwa utegemezi (dependency) utavamiwa.

Uulizaji wa maswali ya mwingiliano (Cross-querying). Mara tu CI