AI એ આપણે સોફ્ટવેર કેવી રીતે બનાવીએ છીએ તે બદલી નાખ્યું છે, પરંતુ તે મશીનો વિશેના એક મૂળભૂત સત્યને બદલી શક્યું નથી. તેઓ પણ આપણી જેમ જ બિનજરૂરી માહિતી (noise) માં ડૂબી જાય છે. જ્યારે એન્જિનિયરો સૌપ્રથમ AI-સહાયિત (AI-assisted) ડિબગિંગ સાથે પ્રયોગ કરે છે, ત્યારે સહજ વૃત્તિ સરળ હોય છે: મોડેલને બધું જ આપી દેવું. રો (raw) લોગ્સ, ટ્રેસ અને મેટ્રિક્સ બધું જ કોન્ટેક્સ્ટ વિન્ડોમાં નાખી દેવામાં આવે છે. તેનું પરિણામ આંતરદૃષ્ટિ (insight) નથી, પરંતુ નિષ્ફળતા છે. ડેટાનું પ્રમાણ ખૂબ વધારે છે. સિગ્નલ (signal) નબળું પડી જાય છે. મેટ્રિક્સ એક ટૂલમાં હોય છે, ટ્રેસ બીજામાં, અને મોડેલ તેમને જોડીને એક સુસંગત વાર્તા બનાવી શકતું નથી. AI તમારા સિસ્ટમ્સનું નિરીક્ષણ કરવામાં મદદ કરી શકે તે પહેલાં, તમારે પોતે તેનું નિરીક્ષણ કરવું પડશે. તમારે પહેલા ડેટાને યોગ્ય સ્વરૂપ આપવું પડશે.

શા માટે રો (Raw) લોગ્સ AI પાઇપલાઇન્સને તોડી નાખે છે

આધુનિક સિસ્ટમ્સ એવી ઝડપે ટેલિમેટ્રી (telemetry) જનરેટ કરે છે જે કોઈ માણસ વાંચી શકતું નથી. તે તેમને આર્ટિફિશિયલ ઇન્ટેલિજન્સ માટે સંપૂર્ણ બનાવવું જોઈએ, પરંતુ તે થતું નથી. લાર્જ લેંગ્વેજ મોડેલની કોન્ટેક્સ્ટ વિન્ડો, ભલે વધતી જતી હોય, છતાં તે એક મર્યાદિત પાઇપ છે. જો તમે તેને અનફિલ્ટર્ડ પ્રોડક્શન લોગ્સથી ભરી દેશો, તો તમે વાસ્તવિક આઉટેજ (outage) ને દબાવી દેતા હોવ અને ક્રોન જોબ (cron job) હાર્ટબીટ્સ અને હેલ્થ-ચેક નોઈઝ (noise) પર ટોકન્સ વેડફી રહ્યા હશો. વધુ ખરાબ બાબત એ છે કે, રો લોગ્સમાં સંબંધોનો અભાવ હોય છે. બપોરે 2:00 વાગ્યે લેટન્સીમાં વધારો અને તે જ સમયના લોગમાં ડેટાબેઝ કનેક્શન એરર સ્પષ્ટપણે સંબંધિત છે, પરંતુ જો કોઈએ અગાઉથી તે સંબંધને સ્ટ્રક્ચર ન કર્યો હોય, તો AI એ અનુમાન લગાવવું પડે છે. અનુમાન લગાવવું એ ખર્ચાળ, ધીમું અને ઘણીવાર ખોટું હોય છે.

આનો ઉકેલ આર્કિટેક્ચરલ છે, અલ્ગોરિધમિક નથી. તમે મોડેલને પ્રોમ્પ્ટ આપો તે પહેલાં તમારે નક્કી કરવું પડશે કે શું કલેક્ટ કરવું, તેને કેવી રીતે સ્વરૂપ આપવું, અને કયું બેકએન્ડ કયા પ્રશ્નનો જવાબ આપશે.

મોનિટરિંગના ચાર અક્ષો (Axes)

airCloset માં, એન્જિનિયરિંગ ટીમે ઓબ્ઝર્વેબિલિટી (observability) ને એક સિંગલ ફાયરહોઝ (firehose) તરીકે જોવાનું બંધ કર્યું. તેઓએ મોનિટરિંગને ચાર અલગ અક્ષોમાં વિભાજિત કર્યું. દરેકનો પોતાનો એક ચોક્કસ આકાર છે અને તે એક ચોક્કસ પ્રશ્નનો જવાબ આપે છે.

  • Application: લોગ્સ અને ટ્રેસ "અત્યારે શું થઈ રહ્યું છે?" તેનો જવાબ આપે છે.
  • Infrastructure: મેટ્રિક્સ "શું આપણી પાસે પૂરતા સંસાધનો છે?" તેનો જવાબ આપે છે.
  • CI: લોગ્સ અને એલર્ટ્સ "શું તૂટ્યું અને ક્યારે?" તેનો જવાબ આપે છે.
  • LLM: મેટ્રિક્સ અને સ્ટ્રક્ચર્ડ રેકોર્ડ્સ "આપણે કેટલો ખર્ચ કરી રહ્યા છીએ?" તેનો જવાબ આપે છે.

આ વિભાજન મહત્વનું છે કારણ કે રિયલ-ટાઇમ લેટન્સી ગ્રાફ માટેનો યોગ્ય આકાર પોસ્ટ-હોક (post-hoc) ખર્ચ વિશ્લેષણ માટે નકામો છે. ચારેય ડોમેન્સમાં એક જ સ્કીમા (schema) લાગુ કરવાથી બરાબર એવો જ નોઈઝ (noise) પેદા થાય છે જે AI સહાયને નકામી બનાવે છે.

CI Observability: પુલ (Pull) કરો, પુશ (Push) નહીં

કન્ટિન્યુઅસ ઇન્ટિગ્રેશન (Continuous integration) એ જગ્યા છે જ્યાં કોડ વાસ્તવિકતા સાથે મળે છે. જ્યારે બિલ્ડ નિષ્ફળ જાય છે, ત્યારે ડેવલપર્સને ઝડપથી માહિતીની જરૂર હોય છે. એક સરળ અભિગમ એ છે કે CI રનર ચાલતું હોય ત્યારે તે સીધા તમારા ઓબ્ઝર્વેબિલિટી બેકએન્ડમાં લોગ્સ પુશ કરે. તે કાર્યક્ષમ લાગે છે, પરંતુ તે ખરેખર જોખમી છે.

airCloset માં, તેઓએ આ મોડેલને ઉલટાવી દીધું. CI રનર ઓબ્ઝર્વેબિલિટી સ્ટેકને સ્પર્શ કરતું નથી. GitHub Actions વર્કફ્લો પૂરો થયા પછી, તેઓ GitHub API માંથી લોગ્સ પુલ કરે છે અને તેને Loki માં ઇન્જેસ્ટ (ingest) કરે છે.

આ પુલ આર્કિટેક્ચર ત્રણ નક્કર ફાયદા આપે છે.

Decoupling. જો ઇન્જેશન પાઇપલાઇનમાં કોઈ સમસ્યા આવે અથવા Grafana સુધી પહોંચી ન શકાય, તો ટેસ્ટ રન પોતે અસ્પૃશ્ય રહે છે. બિલ્ડ તેના પોતાના ગુણો પર પાસ અથવા ફેઇલ થાય છે. ઓબ્ઝર્વેબિલિટીની નિષ્ફળતાને કારણે ક્યારેય ડિપ્લોયમેન્ટ અટકવું જોઈએ નહીં.

Security. CI વર્કફ્લોને ક્યારેય Grafana API કીની જરૂર પડતી નથી. ટેસ્ટ કોડ એવા સિક્રેટ્સ (secrets) ને સ્પર્શ કરવા માટે જાણીતો છે જે તેને ન કરવા જોઈએ, અને તે એક્સપોઝર દૂર કરવાથી જો કોઈ ડિપેન્ડન્સી (dependency) સાથે છેડછાડ થાય તો તેની અસર મર્યાદિત રહે છે.

Cross-querying. એકવાર CI