A user opens a ticket: the mobile app is sluggish. You check your dashboards. CPU utilization is flat. Error rates are z

ഒരു ഉപയോക്താവ് ഒരു ടിക്കറ്റ് തുറക്കുന്നു: മൊബൈൽ ആപ്പ് വളരെ മന്ദഗതിയിലാണ് പ്രവർത്തിക്കുന്നത്. നിങ്ങൾ നിങ്ങളുടെ ഡാഷ്‌ബോർഡുകൾ പരിശോധിക്കുന്നു. CPU ഉപയോഗം സാധാരണ നിലയിലാണ്. എറർ നിരക്ക് പൂജ്യമാണ്. നിങ്ങളുടെ APM ലൈറ്റുകൾ ആശ്വാസകരമായ പച്ച നിറത്തിലാണ്. എല്ലാ ദൃശ്യമായ അളവുകോലുകൾ പ്രകാരം ബാക്കെൻഡ് ആരോഗ്യകരമാണ്. എന്നാൽ ഉപയോക്താവ് പറയുന്നത് തെറ്റല്ല. ആ വേഗതക്കുറവ് യഥാർത്ഥമാണ്, അത് ഒരു Android ഉപകരണം നിങ്ങളുടെ സെർവറുമായുള്ള ദീർഘമായ, അദൃശ്യമായ പാതയിൽ എവിടെയോ സംഭവിക്കുന്നു.

മിക്ക ഒബ്സർവബിലിറ്റി ടൂളുകളും ആപ്ലിക്കേഷൻ അതിർത്തിയിൽ അവസാനിക്കുന്നു എന്നതാണ് പ്രശ്നം. നിങ്ങളുടെ ഫ്രെയിംവർക്ക് ഒരു റിക്വസ്റ്റ് പാഴ്സ് ചെയ്തതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്നാണ് അവ അളക്കുന്നത്. അവ ഡാറ്റാബേസ് ക്വറികൾ, കാഷെ ഹിറ്റുകൾ, ഡൗൺസ്ട്രീം സർവീസ് കോളുകൾ എന്നിവ ട്രാക്ക് ചെയ്യുന്നു. എന്നാൽ അവ വിട്ടുപോകുന്നത് റിക്വസ്റ്റിന്റെ യഥാർത്ഥ പ്രവർത്തനരീതിയാണ്: ഒരു OkHttp കോൾ Android HTTP സ്റ്റാക്കിനുള്ളിൽ ചെലവഴിക്കുന്ന സമയം, അസ്ഥിരമായ ഒരു മൊബൈൽ നെറ്റ്‌വർക്കിലൂടെയുള്ള യാത്ര, TLS ഹാൻഡ്‌ഷേക്ക് നെഗോഷ്യേഷൻ, നിങ്ങളുടെ കോഡ് പ്രവർത്തിക്കുന്നതിന് മുമ്പ് കർണൽ ക്യൂകൾക്കുള്ളിൽ സംഭവിക്കുന്ന നിശബ്ദമായ കാത്തിരിപ്പ് എന്നിവയെല്ലാം ഇതിൽ ഉൾപ്പെടുന്നു. നിങ്ങളുടെ APM നിശബ്ദമായിരിക്കുമ്പോൾ, ഈ വിടവുകൾ മില്ലിസെക്കൻഡുകൾ—അല്ലെങ്കിൽ മുഴുവൻ സെക്കൻഡുകൾ—തട്ടിപ്പറിച്ച് കൊണ്ടുപോകുന്നു.

എൻക്രിപ്ഷൻ ഈ അന്ധത പൂർണ്ണമാക്കുന്നു. ആധുനിക Android ആപ്പുകൾ എല്ലാം BoringSSL വഴി റൂട്ട് ചെയ്യുന്നു. ഒരു പാക്കറ്റ് കർണൽ നെറ്റ്‌വർക്ക് സ്റ്റാക്കിൽ എത്തുമ്പോഴേക്കും HTTP ഹെഡറുകൾ എൻക്രിപ്റ്റ് ചെയ്യപ്പെട്ടതായിരിക്കും. ഒരു സാധാരണ tcpdump അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് ഹുക്ക് കാണുന്നത് അവ്യക്തമായ TLS റെക്കോർഡുകൾ മാത്രമാണ്. ട്രാഫിക് ഒഴുകുന്നുണ്ടെന്ന് നിങ്ങൾക്ക് നിരീക്ഷിക്കാനാകും, പക്ഷേ നിങ്ങൾക്ക് അത് വായിക്കാൻ കഴിയില്ല. ഒരു പ്രത്യേക കർണൽ-ലെവൽ TCP സെഗ്മെന്റിനെ ഒരു പ്രത്യേക ഉപയോക്താവിന്റെ API കോളുമായി ബന്ധിപ്പിക്കാൻ നിങ്ങൾക്ക് തീർച്ചയായും കഴിയില്ല. നിങ്ങൾക്ക് ആവശ്യമുള്ള ട്രേസ് കോൺടെക്സ്റ്റ് (trace context) സൈഫർടെക്സ്റ്റിനുള്ളിൽ കുടുങ്ങിക്കിടക്കുന്നു.

eBPF ഈ സമവാക്യം മാറ്റുന്നു, കാരണം നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ് മാറ്റാതെ തന്നെ സിസ്റ്റത്തെ ഉള്ളിൽ നിന്ന് പുറത്തേക്ക് ഇൻസ്ട്രുമെന്റ് ചെയ്യാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. നിങ്ങളുടെ ആപ്പ് അതിന്റെ ലേറ്റൻസി റിപ്പോർട്ട് ചെയ്യാൻ ആവശ്യപ്പെടുന്നതിന് പകരം, നിങ്ങൾ ചെറിയ പ്രോഗ്രാമുകൾ നേരിട്ട് കർണലിലേക്കും നിർണ്ണായകമായ യൂസർസ്പേസ് ലൈബ്രറികളിലേക്കും ഘടിപ്പിക്കുന്നു. ഈ പ്രോഗ്രാമുകൾ ഇവ സംഭവിക്കുമ്പോൾ തന്നെ നിരീക്ഷിക്കുകയും, നിങ്ങൾക്ക് ആവശ്യമുള്ളവ വേർതിരിച്ചെടുക്കുകയും, അവ ഒരു റിംഗ് ബഫറിലേക്ക് അയക്കുകയും ചെയ്യുന്നു. ഒരു ലഘുവായ ഹെഡർ അല്ലാതെ നിങ്ങളുടെ Android APK-യിൽ മറ്റ് SDK ബ്ലോട്ടുകളും (SDK bloat) ഇല്ല, കൂടാതെ നിങ്ങളുടെ ബാക്കെൻഡ് ക്ലാസുകൾ മാറ്റിയെഴുതുന്ന ഇൻസ്ട്രുമെന്റേഷൻ ഏജന്റുകളും ഇല്ല.

നാല് ഘട്ടങ്ങളുള്ള സജ്ജീകരണം

ഈ പൈപ്പ്‌ലൈൻ നിർമ്മിക്കുന്നതിന് നിരീക്ഷണത്തിന്റെ നാല് വ്യത്യസ്ത പാളികൾ ആവശ്യമാണ്.

1. traceparent ആങ്കർ. Android ഉപകരണത്തിൽ, ഓരോ ഔട്ട്‌ബൗണ്ട് റിക്വസ്റ്റിലേക്കും ഒരു W3C traceparent ഹെഡർ ഇൻജക്റ്റ് ചെയ്യുന്ന ഒരു OkHttp interceptor നിങ്ങൾ ചേർക്കുന്നു. മൊബൈൽ ഭാഗത്ത് ആവശ്യമായ ഏക മാറ്റം ഇതാണ്, ഇത് വളരെ കുറഞ്ഞതാണ്. ഈ ഹെഡർ എൻക്രിപ്റ്റ് ചെയ്ത പേലോഡിനുള്ളിൽ നിങ്ങളുടെ ബാക്കെൻഡ് വരെ സഞ്ചരിക്കുന്നു. ഇത് HTTP ലെയറിനുള്ളിൽ ഇരിക്കുന്നതിനാൽ, TLS എഞ്ചിൻ ഒടുവിൽ വെളിപ്പെടുത്തുന്ന പ്ലെയിൻടെക്സ്റ്റിനുള്ളിൽ ഇത് നിലനിൽക്കുന്നു.

2. TCP വരവ് സമയം (TCP arrival timing). ബാക്കെൻഡ് ഹോസ്റ്റിൽ, നിങ്ങൾ നെറ്റ്‌വർക്ക് ഇന്റർഫേസുമായി ഘടിപ്പിച്ച eBPF Traffic Control ഹുക്കുകൾ ഉപയോഗിക്കുന്നു. ഓരോ TCP സെഗ്മെന്റുകളും എത്തുമ്പോൾ ഈ പ്രോഗ്രാമുകൾ പ്രവർത്തിക്കുന്നു. അവ എഡ്ജിൽ വെച്ച് സീക്വൻസ് നമ്പറുകളും ടൈംസ്റ്റാമ്പുകളും ക്യാപ്ചർ ചെയ്യുന്നു. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരു ബൈറ്റ് പോലും വായിക്കുന്നതിന് വളരെ മുമ്പ്, ബിറ്റുകൾ വയറിൽ നിന്ന് നിങ്ങളുടെ മെഷീനിലേക്ക് എത്തിയത് എപ്പോഴാണെന്ന് ഇപ്പോൾ നിങ്ങൾക്ക് കൃത്യമായി അറിയാം.

3. ഡീക്രിപ്ഷൻ പ്രോബുകൾ (Decryption probes). നിങ്ങളുടെ ബാക്കെൻഡ് OpenSSL അല്ലെങ്കിൽ BoringSSL ഉപയോഗിച്ച് TLS അവസാനിപ്പിക്കുന്നു. ഇവിടെയാണ് ആർക്കിടെക്ചർ രസകരമാകുന്നത്. uprobes—ഡൈനാമിക് യൂസർസ്പേസ് പ്രോബുകൾ—ഉപയോഗിച്ച്, നിങ്ങൾ TLS ലൈബ്രറിക്കുള്ളിലെ SSL_write, SSL_read എന്നിവയുമായി ബന്ധപ്പെടുന്നു. പ്ലെയിൻടെക്സ്റ്റ് ഡാറ്റ എൻക്രിപ്ഷൻ എഞ്ചിനിലൂടെ കടന്നുപോകുന്ന നിമിഷം തന്നെ ഈ ഫംഗ്ഷനുകൾ പ്രവർത്തിക്കുന്നു. നിങ്ങളുടെ eBPF പ്രോഗ്രാം ആ ഡീക്രിപ്റ്റ് ചെയ്ത ബഫർ വായിക്കുകയും, traceparent ഹെഡറിനായി തിരയുകയും, അത് വേർതിരിച്ചെടുക്കുകയും ചെയ്യുന്നു. ഒരു കസ്റ്റം ടൂളിൽ സർട്ടിഫിക്കറ്റുകളോ കീകളോ കൈകാര്യം ചെയ്യാതെ തന്നെ, ഒരു റോ പ്ലെയിൻ TCP ഫ്ലോയും ഒരു പ്രത്യേക മൊബൈൽ റിക്വസ്റ്റും തമ്മിലുള്ള നേരിട്ടുള്ള മാപ്പിംഗ് ഇപ്പോൾ കർണലിന് ലഭിക്കുന്നു.

4. കർണൽ ക്യൂയിംഗ് (Kernel queueing). ഡാറ്റ ഡീക്രിപ്റ്റ് ചെയ്ത് തയ്യാറായ ശേഷവും, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അത് ഉടൻ ഉപയോഗിച്ചേക്കില്ല. സോക്കറ്റ് ബഫറുകളും ഷെഡ്യൂളിംഗ് ഇവന്റുകളും കൈകാര്യം ചെയ്യുന്ന പ്രസക്തമായ കർണൽ ഫംഗ്ഷനുകളിൽ നിങ്ങൾ kprobes ഘടിപ്പിക്കുന്നു. ഇത് ക്യൂയിംഗ് ലേറ്റൻസി (queueing latency) അളക്കുന്നു: നിങ്ങളുടെ പ്രോസസ്സ് CPU-വിനായി മത്സരിക്കുകയോ അല്ലെങ്കിൽ read() വിളിച്ചില്ലായിരിക്കുകയോ കാരണം റിക്വസ്റ്റുകൾ കർണൽ ലാൻഡിൽ കാത്തുനിൽക്കുന്ന സമയം ഇതാണ്.

എല്ലാ സിഗ്നൽ സ്രോതസ്സുകളും ഒരു eBPF റിംഗ് ബഫറിലേക്ക് ഇവന്റുകൾ എഴുതുന്നു. യൂസർസ്പേസിൽ പ്രവർത്തിക്കുന്ന ഒരു സൈഡകാർ പ്രോസസ്സ് ഈ ബഫർ ഉപയോഗിക്കുകയും, traceparent ID ഉപയോഗിച്ച് ഇവന്റുകളെ പരസ്പരം ബന്ധിപ്പിക്കുകയും, ഓരോ റിക്വസ്റ്റിനും ഒരൊറ്റ, വ്യക്തമായ ടൈംലൈൻ പുനർനിർമ്മിക്കുകയും ചെയ്യുന്നു. മുമ്പ് വിച്ഛേദിക്കപ്പെട്ട കർണൽ നോയിസ് ആയിരുന്നവ ഇപ്പോൾ ഒരു ഘടനാപരമായ ട്രേസ് ആയി മാറുന്നു.

മുഴുവൻ പാതയും വായിക്കുക

സംയോജിപ്പിച്ച ഔട്ട്‌പുട്ട് സാധാരണയായി ഒരു ഫ്ലെയിം ഗ്രാഫ് (flame graph) അല്ലെങ്കിൽ ലേറ്റൻസിയെ നാല് ഭാഗങ്ങളായി തിരിക്കുന്ന ഒരു സ്ട്രക്ചേർഡ് സ്പാൻ ട്രീ (structured span tree) ആയി കാണിക്കുന്നു:

• Network transit time: ആൻഡ്രോയിഡ് റേഡിയോ റിക്വസ്റ്റിന്റെ അവസാന ബൈറ്റ് അയക്കുന്ന സമയം മുതൽ ബാക്കെൻഡ് NIC അത് സ്വീകരിക്കുന്നത് വരെയുള്ള ദൈർഘ്യം. സെല്ലുലാർ കണക്ഷനുകളിലെ അസ്ഥിരത (volatility) പ്രധാനമായും ഇവിടെയാണ് അനുഭവപ്പെടുന്നത്.
• TLS handshake duration: എൻക്രിപ്റ്റഡ് ടണൽ രൂപീകരിക്കുന്നതിനായി ചെലവഴിക്കുന്ന സമയം. മോശം നെറ്റ്‌വർക്കുകളിൽ, ഇത് യഥാർത്ഥ ഡാറ്റാ ട്രാൻസ്ഫറിനേക്കാൾ വളരെ കൂടുതലായേക്കാം.
• Kernel queueing latency: ഒരു സെഗ്മെന്റ് എത്തിയതിന് ശേഷം അത് യൂസർസ്പേസ് (userspace) ഉപയോഗിക്കുന്നതിന് മുമ്പ് കേർണൽ ബഫറുകളിലും ഷെഡ്യൂളർ ക്യൂകളിലും ചെലവഴിക്കുന്ന സമയം.
• Application processing time: നിങ്ങളുടെ ബാക്കെൻഡ് ഫ്രെയിംവർക്കും ബിസിനസ് ലോജിക്കും യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന സമയം.

ഒരു 800ms മൊബൈൽ റിക്വസ്റ്റിൽ നിങ്ങളുടെ JSON പാഴ്സറിനുള്ളിൽ വെറും 40ms മാത്രമേ ചെലവഴിക്കുന്നുള്ളൂ എന്ന് നിങ്ങൾ കണ്ടേക്കാം. ഡാറ്റ നഷ്ടപ്പെടുന്ന (lossy) ഒരു കണക്ഷനിലൂടെയുള്ള തടസ്സപ്പെട്ട TLS ഹാൻഡ്‌ഷേക്കിൽ മറ്റൊരു 200ms നഷ്ടപ്പെടുന്നു. ഓവർ സബ്‌സ്‌ക്രൈബ്ഡ് ആയ ഒരു ഹോസ്റ്റിലെ കേർണൽ ബാക്ക്‌ലോഗിൽ (kernel backlog) മറ്റൊരു 300ms അപ്രത്യക്ഷമാകുന്നു. നിങ്ങളുടെ APM റിപ്പോർട്ട് ചെയ്തിരുന്നത് വെറും 40ms മാത്രമാണ്. കേർണൽ തലത്തിലുള്ള കാഴ്ചപ്പാട് (visibility) ഇല്ലാതെ, നിങ്ങൾ തെറ്റായ കാര്യമാണ് ഒപ്റ്റിമൈസ് ചെയ്തിട്ടുണ്ടാകുകയേ ഉണ്ടൂ.

യഥാർത്ഥത്തിൽ സ്കെയിൽ ചെയ്യാവുന്ന ഓവർഹെഡ് (Overhead That Actually Scales)

പരമ്പരാഗത APM ഏജന്റുകൾ നിങ്ങളുടെ ലാംഗ്വേജ് റൺടൈമിനുള്ളിലെ കോളുകൾ ഇന്റർസെപ്റ്റ് ചെയ്തുകൊണ്ടാണ് അവയുടെ വിസിബിലിറ്റി നേടുന്നത്. അവ മെത്തേഡുകൾ റാപ്പ് ചെയ്യുന്നു, സ്പാൻ ഒബ്‌ജക്റ്റുകൾ അലോക്കേറ്റ് ചെയ്യുന്നു, കൂടാതെ നിങ്ങളുടെ പ്രോസസ്സ് ഹീപ്പിനുള്ളിൽ ടെലിമെട്രി ഡാറ്റ സീരിയലൈസ് ചെയ്യുന്നു. ലോഡ് കൂടുമ്പോൾ, ഈ ഓവർഹെഡ് വേഗത്തിൽ വർദ്ധിക്കുന്നു. സീരിയലൈസേഷൻ ചെലവ് കൂടുന്നു. ഗാർബേജ് കളക്ഷൻ പ്രഷർ വർദ്ധിക്കുന്നു. നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ തന്നെ റിസോഴ്സുകൾ ഉപയോഗിച്ചാണ് നിങ്ങൾ വിസിബിലിറ്റിക്ക് പകരമായി നൽകുന്നത്.

eBPF പ്രോഗ്രാമുകൾ ഒരു കേർണൽ വിർച്വൽ മെഷീനുള്ളിൽ പ്രവർത്തിക്കുന്നു കൂടാതെ അവ നേറ്റീവ് മെഷീൻ ഇൻസ്ട്രക്ഷനുകളിലേക്ക് JIT-കംപൈൽ ചെയ്യപ്പെടുന്നു. അവ ലോഡ് ചെയ്യുന്നതിന് മുമ്പ് ഒരു വെരിഫയർ അവയുടെ സുരക്ഷ പരിശോധിക്കുന്നു. ഓരോ പ്രോബും (probe) പാത്തിൽ മൈക്രോസെക്കൻഡുകൾ മാത്രമേ കൂട്ടിച്ചേർക്കുന്നുള്ളൂ, മില്ലിസെക്കൻഡുകളല്ല. ഇവന്റുകൾ മാച്ച് ചെയ്യുന്നതിനും ഗ്രാഫുകൾ റെൻഡർ ചെയ്യുന്നതിനുമുള്ള കഠിനമായ ജോലികൾ നിങ്ങളുടെ സർവീസിന്റെ ഹോട്ട് പാത്തിന് (hot path) പുറത്തുള്ള സൈഡ്കാറിൽ (sidecar) ആണ് നടക്കുന്നത്. നിങ്ങൾ ഹീപ്പ് അലോക്കേഷനുകൾ വർദ്ധിപ്പിക്കുന്നില്ല. റിക്വസ്റ്റ് ഹാൻഡ്‌ലിംഗിനുള്ളിൽ സീരിയലൈസേഷൻ ടാക്സുകൾ നിങ്ങൾ ചേർക്കുന്നില്ല. സെക്കൻഡിൽ ആയിരക്കണക്കിന് റിക്വസ്റ്റുകൾ കൈകാര്യം ചെയ്യുന്ന സർവീസുകളെ സംബന്ധിച്ചിടത്തോളം, ഈ വ്യത്യാസം വളരെ പ്രധാനമാണ്.

ഇത് പ്രവർത്തിപ്പിക്കാൻ ആവശ്യമായവ (What It Takes to Run)

ഇതൊരു മാന്ത്രിക പരിഹാരമല്ല (magic bullet), കൂടാതെ നിങ്ങൾക്ക് എളുപ്പത്തിൽ ഓൺ ചെയ്യാവുന്ന ഒരു മാനേജ്ഡ് SaaS ഉം അല്ല. നിങ്ങളുടെ പ്രോബുകൾക്ക് കേർണൽ സ്ട്രക്ചറുകളിലൂടെ സുരക്ഷിതമായി സഞ്ചരിക്കാൻ BTF ടൈപ്പ് ഇൻഫർമേഷൻ ഉൾപ്പെടെയുള്ള ആധുനിക eBPF സപ്പോർട്ട് ഉള്ള ഒരു ബാക്കെൻഡ് കേർണൽ ആവശ്യമാണ്. നിങ്ങളുടെ TLS ലൈബ്രറി uprobes ലക്ഷ്യമിടാൻ കഴിയുന്ന സിംബലുകൾ (symbols) എക്സ്പോസ് ചെയ്യണം; നിങ്ങൾ സ്ട്രിപ്പ് ചെയ്തതോ അല്ലെങ്കിൽ കസ്റ്റമൈസ് ചെയ്തതോ ആയ OpenSSL ബിൽഡുകളുള്ള ഒരു സ്റ്റാറ്റിക്കലി ലിങ്ക്ഡ് ബൈനറിയാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, നിങ്ങൾ അത് കണക്കിലെടുക്കേണ്ടതുണ്ട്. മൊബൈൽ ക്ലയന്റും TLS ടെർമിനേഷൻ പോയിന്റും ഇടയിലുള്ള പ്രോക്സികൾക്കോ എഡ്ജ് ഗേറ്റ്‌വേകൾക്കോ ഇടയിൽ നിങ്ങളുടെ traceparent ഹെഡർ നിലനിൽക്കുന്നുണ്ടെന്ന് നിങ്ങൾ പരിശോധിക്കേണ്ടതുണ്ട്.

എന്നാൽ "മൊബൈൽ പതുക്കെയാണ്" എന്ന തരത്തിലുള്ള, റൂട്ട് കോസ് അനാലിസിസ് ചെയ്യാൻ കഴിയാത്ത ടിക്കറ്റുകൾ കൊണ്ട് തളർന്ന ടീമുകൾക്ക്, ഈ ആർക്കിടെക്ചർ ഊഹങ്ങൾക്ക് പകരം കൃത്യമായ സിഗ്നലുകൾ നൽകുന്നു. നിങ്ങൾ നെറ്റ്‌വർക്ക് കാലാവസ്ഥയെക്കുറിച്ച് ഊഹിക്കുന്നത് നിർത്തുകയും പ്രത്യേക പൈപ്പുകളിലൂടെയുള്ള പ്രത്യേക റിക്വസ്റ്റുകൾ അളക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു.

യഥാർത്ഥ പാഠം (The Real Takeaway)

എൻക്രിപ്റ്റ് ചെയ്ത മൊബൈൽ ട്രാഫിക്കിനെ നിങ്ങളുടെ ഫ്രെയിംവർക്കിൽ എത്തുമ്പോൾ മാന്ത്രികമായി ദൃശ്യമാകുന്ന ഒരു അജ്ഞാത സ്ട്രീം (opaque stream) ആയി നിങ്ങൾ കാണേണ്ടതില്ല. ഒരു ലളിതമായ OkHttp ഹെഡറും ബാക്കെൻഡിൽ തന്ത്രപരമായി സ്ഥാപിച്ച eBPF പ്രോബുകളും സംയോജിപ്പിക്കുന്നതിലൂടെ, നിങ്ങളുടെ മൊബൈൽ ആപ്പ് വീണ്ടും എഴുതാതെയും പരമ്പരാഗത APM ആവശ്യപ്പെടുന്നതുപോലെ നിങ്ങളുടെ ബാക്കെൻഡ് കോഡ് ഇൻസ്ട്രുമെന്റ് ചെയ്യാതെയും, ഒരു ആൻഡ്രോയിഡ് ഉപകരണത്തിൽ നിന്നുള്ള ഒരു റിക്വസ്റ്റിനെ TLS ഡീക്രിപ്ഷൻ, കേർണൽ ക്യൂകൾ എന്നിവയിലൂടെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ലോജിക്കിലേക്ക് പിന്തുടരാൻ നിങ്ങൾക്ക് കഴിയും. ഇത് വെറുമൊരു ചെറിയ പുരോഗതിയല്ല. ഇത് എക്സ്ടെൻഡഡ് എൻഡ്-ടു-എൻഡ് ഒബ്സർവബിലിറ്റിയാണ് (end-to-end observability).