AI మనం సాఫ్ట్‌వేర్‌ను నిర్మించే విధానాన్ని మార్చింది, కానీ యంత్రాల గురించి ఒక ప్రాథమిక సత్యాన్ని అది మార్చలేదు. మనం ఎలాగైతే అనవసరమైన సమాచారంలో (noise) మునిగిపోతామో, అవి కూడా అలాగే మునిగిపోతాయి. ఇంజనీర్లు మొదటిసారి AI-అసిస్టెడ్ డీబగ్గింగ్‌తో ప్రయోగాలు చేసినప్పుడు, వారి ఆలోచన చాలా సరళంగా ఉంటుంది: మోడల్‌కు ప్రతిదీ అందించడం. రా (Raw) లాగ్స్, ట్రేసెస్ మరియు మెట్రిక్స్‌ను అన్నీ కాంటెక్స్ట్ విండోలోకి పడేస్తారు. దీని ఫలితం అవగాహన (insight) కాదు, వైఫల్యం మాత్రమే. డేటా పరిమాణం చాలా ఎక్కువగా ఉంటుంది. దీనివల్ల ముఖ్యమైన సమాచారం (signal) దెబ్బతింటుంది. మెట్రిక్స్ ఒక టూల్‌లో, ట్రేసెస్ మరొక దానిలో ఉంటాయి, మరియు మోడల్ వాటిని ఒక సమగ్రమైన కథగా జోడించలేదు. AI మీ సిస్టమ్స్‌ను గమనించడంలో మీకు సహాయపడకముందే, మీరు వాటిని స్వయంగా గమనించాలి. మీరు మొదట డేటాను క్రమబద్ధీకరించాలి.

రా (Raw) లాగ్స్ ఎందుకు AI పైప్‌లైన్‌లను దెబ్బతీస్తాయి

ఆధునిక వ్యవస్థలు మనుషులు చదవలేనంత వేగంతో టెలిమెట్రీని ఉత్పత్తి చేస్తాయి. ఇది వాటిని ఆర్టిఫిషియల్ ఇంటెలిజెన్స్‌కు అనువైనవిగా చేయాలి, కానీ అలా కాదు. లార్జ్ లాంగ్వేజ్ మోడల్ యొక్క కాంటెక్స్ట్ విండో పెరుగుతున్నప్పటికీ, అది ఇంకా పరిమితమైనదే. ఫిల్టర్ చేయని ప్రొడక్షన్ లాగ్స్‌తో దాన్ని నింపితే, అసలైన అవుట్‌టేజ్ (outage) సమాచారాన్ని కప్పివేస్తూ, క్రోన్ జాబ్ హార్ట్‌బీట్‌లు మరియు హెల్త్-చెక్ నాయిస్‌పై మీరు టోకెన్లను వృథా చేస్తారు. అంతకంటే దారుణం ఏమిటంటే, రా లాగ్స్‌లో సంబంధాలు (relationships) ఉండవు. మధ్యాహ్నం 2:00 గంటలకు లేటెన్సీ పెరగడం మరియు అదే సమయంలో లాగ్‌లో డేటాబేస్ కనెక్షన్ ఎర్రర్ రావడం స్పష్టంగా సంబంధం కలిగి ఉంటాయి, కానీ ఎవరైనా ఆ సంబంధాన్ని ముందే స్ట్రక్చర్ చేయకపోతే, AI ఊహించాల్సి వస్తుంది. ఊహించడం అనేది ఖరీదైనది, నెమ్మదిగా ఉంటుంది మరియు తరచుగా తప్పుగా ఉంటుంది.

దీనికి పరిష్కారం ఆర్కిటెక్చరల్, అల్గారిథమిక్ కాదు. మీరు మోడల్‌కు ప్రాంప్ట్ ఇచ్చే ముందే, ఏమి సేకరించాలి, అది ఎలా ఉండాలి మరియు ఏ బ్యాకెండ్ ఏ ప్రశ్నకు సమాధానం ఇవ్వాలి అనేది మీరు నిర్ణయించుకోవాలి.

మానిటరింగ్ యొక్క నాలుగు అక్షాలు (Four Axes)

airClosetలో, ఇంజనీరింగ్ టీమ్ అబ్జర్వబిలిటీని ఒకే ఫైర్‌హోస్‌లా చూడటం మానేసింది. వారు మానిటరింగ్‌ను నాలుగు విభిన్న అక్షాలుగా విభజించారు. ప్రతి అక్షం ఒక నిర్దిష్ట రూపాన్ని కలిగి ఉంటుంది మరియు ఒక నిర్దిష్ట ప్రశ్నకు సమాధానం ఇస్తుంది.

  • Application: లాగ్స్ మరియు ట్రేసెస్ "ప్రస్తుతం ఏమి జరుగుతోంది?" అనే ప్రశ్నకు సమాధానం ఇస్తాయి.
  • Infrastructure: మెట్రిక్స్ "మన దగ్గర తగినంత వనరులు ఉన్నాయా?" అనే ప్రశ్నకు సమాధానం ఇస్తాయి.
  • CI: లాగ్స్ మరియు అలర్ట్స్ "ఏమి విఫలమైంది మరియు ఎప్పుడు?" అనే ప్రశ్నకు సమాధానం ఇస్తాయి.
  • LLM: మెట్రిక్స్ మరియు స్ట్రక్చర్డ్ రికార్డ్స్ "మనం ఎంత ఖర్చు చేస్తున్నాము?" అనే ప్రశ్నకు సమాధానం ఇస్తాయి.

ఈ విభజన చాలా ముఖ్యం, ఎందుకంటే రియల్-టైమ్ లేటెన్సీ గ్రాఫ్‌కు సరిపోయే డేటా రూపం, పోస్ట్-హాక్ (post-hoc) ఖర్చు విశ్లేషణకు ఉపయోగపడదు. నాలుగు డొమైన్‌లన్నింటికీ ఒకే స్కీమాను బలవంతంగా వాడటం వల్ల అనవసరమైన నాయిస్ (noise) ఏర్పడుతుంది, ఇది AI సహాయాన్ని నిరుపయోగం చేస్తుంది.

CI అబ్జర్వబిలిటీ: పుల్ (Pull) చేయండి, పుష్ (Push) చేయకండి

కంటిన్యూయస్ ఇంటిగ్రేషన్ (CI) అనేది కోడ్ వాస్తవ ప్రపంచంతో కలిసే చోటు. బిల్డ్ విఫలమైనప్పుడు, డెవలపర్‌లకు ఆ వివరాలు వేగంగా కావాలి. ఒక సాధారణ పద్ధతి ఏమిటంటే, CI రన్నర్ నడుస్తున్నప్పుడు లాగ్స్‌ను నేరుగా మీ అబ్జర్వబిలిటీ బ్యాకెండ్‌కు పుష్ చేయడం. ఇది సమర్థవంతంగా అనిపించవచ్చు, కానీ నిజానికి ఇది ప్రమాదకరం.

airClosetలో, వారు ఈ విధానాన్ని మార్చారు. CI రన్నర్ అబ్జర్వబిలిటీ స్టాక్‌ను తాకదు. GitHub Actions వర్క్‌ఫ్లో పూర్తయిన తర్వాత, వారు GitHub API నుండి లాగ్స్‌ను పుల్ చేసి, వాటిని Lokiలోకి ఇంజెస్ట్ చేస్తారు.

ఈ పుల్ ఆర్కిటెక్చర్ మూడు స్పష్టమైన ప్రయోజనాలను అందిస్తుంది.

Decoupling. ఒకవేళ ఇంజెషన్ పైప్‌లైన్‌లో అంతరాయం కలిగినా లేదా Grafana అందుబాటులో లేకపోయినా, టెస్ట్ రన్ ప్రభావితం కాదు. బిల్డ్ దాని స్వంత మెరిట్ ఆధారంగా పాస్ లేదా ఫెయిల్ అవుతుంది. అబ్జర్వబిలిటీ వైఫల్యం వల్ల డిప్లాయ్‌మెంట్ ఆగిపోకూడదు.

Security. CI వర్క్‌ఫ్లోకు ఎప్పుడూ Grafana API కీ అవసరం లేదు. టెస్ట్ కోడ్ అనవసరమైన సీక్రెట్స్‌ను తాకడం వల్ల సమస్యలు వచ్చే అవకాశం ఉంది, ఆ రిస్క్‌ను తగ్గించడం వల్ల ఏదైనా డిపెండెన్సీ దెబ్బతింటే దాని ప్రభావం (blast radius) తక్కువగా ఉంటుంది.

Cross-querying. ఒకసారి CI