ಒಬ್ಬ ಬಳಕೆದಾರ ಟಿಕೆಟ್ ತೆರೆಯುತ್ತಾರೆ: ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಮಂದಗತಿಯಾಗಿದೆ (sluggish). ನೀವು ನಿಮ್ಮ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೀರಿ. CPU ಬಳಕೆ ಸ್ಥಿರವಾಗಿದೆ. ದೋಷದ ಪ್ರಮಾಣ (Error rates) ಶೂನ್ಯವಾಗಿದೆ. ನಿಮ್ಮ APM ಲೈಟ್‌ಗಳು ಭರವಸೆಯ ಹಸಿರು ಬಣ್ಣದಲ್ಲಿವೆ. ಎಲ್ಲಾ ದೃಶ್ಯ ಮಾಪನಗಳ ಪ್ರಕಾರ ಬ್ಯಾಕೆಂಡ್ ಆರೋಗ್ಯಕರವಾಗಿದೆ. ಆದರೆ ಬಳಕೆದಾರರು ತಪ್ಪುಲ್ಲ. ಆ ನಿಧಾನಗತಿಯು ನಿಜವಾಗಿದೆ, ಮತ್ತು ಅದು Android ಸಾಧನ ಮತ್ತು ನಿಮ್ಮ ಸರ್ವರ್ ನಡುವಿನ ಉದ್ದವಾದ, ಕತ್ತಲೆಯಾದ ಹಾದಿಯಲ್ಲಿ ಎಲ್ಲೋ ಸಂಭವಿಸುತ್ತಿದೆ.

ಸಮಸ್ಯೆಯೆಂದರೆ ಹೆಚ್ಚಿನ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (observability) ಪರಿಕರಗಳು ಅಪ್ಲಿಕೇಶನ್ ಗಡಿಯಲ್ಲೇ ನಿಂತುಬಿಡುತ್ತವೆ. ನಿಮ್ಮ ಫ್ರೇಮ್‌ವರ್ಕ್ ಒಂದು ವಿನಂತಿಯನ್ನು (request) ಪಾರ್ಸ್ ಮಾಡಿದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅವು ಮಾತ್ರ ಅಳೆಯುತ್ತವೆ. ಅವು ಡೇಟಾಬೇಸ್ ಕ್ವೇರಿಗಳು, ಕ್ಯಾಶ್ ಹಿಟ್‌ಗಳು ಮತ್ತು ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸರ್ವಿಸ್ ಕರೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತವೆ. ಆದರೆ ಅವು ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ವಿಷಯವೆಂದರೆ ವಿನಂತಿಯ ಯಾಂತ್ರಿಕತೆ (mechanics): ಒಂದು OkHttp ಕರಲ್ Android HTTP ಸ್ಟ್ಯಾಕ್‌ನ ಒಳಗೆ ಕಳೆಯುವ ಸಮಯ, ಅಸ್ಥಿರ ಮೊಬೈಲ್ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಸಂಚಾರ, TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನೆಗೋಷಿಯೇಷನ್, ಮತ್ತು ನಿಮ್ಮ ಕೋಡ್ ರನ್ ಆಗುವ ಮೊದಲೇ ಕರ್ನಲ್ ಕ್ಯೂಗಳಲ್ಲಿ (kernel queues) ನಡೆಯುವ ಮೌನ ಕಾಯುವಿಕೆ. ನಿಮ್ಮ APM ಸುಮ್ಮನಿದ್ದರೂ, ಈ ಅಂತರಗಳು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು—ಅಥವಾ ಇಡೀ ಸೆಕೆಂಡ್‌ಗಳನ್ನು—ಕಬಳಿಸುತ್ತವೆ.

ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಈ ಅಂಧತೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ. ಆಧುನಿಕ Android ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಎಲ್ಲವನ್ನೂ BoringSSL ಮೂಲಕ ರೌಟ್ ಮಾಡುತ್ತವೆ. ಒಂದು ಪ್ಯಾಕೆಟ್ ಕರ್ನಲ್ ನೆಟ್‌ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್‌ಗೆ ತಲುಪುವ ಹೊತ್ತಿಗೆ, HTTP ಹೆಡರ್‌ಗಳು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುತ್ತವೆ. ಸಾಮಾನ್ಯ tcpdump ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಹುಕ್ ಕೇವಲ ಅಸ್ಪಷ್ಟವಾದ (opaque) TLS ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಹರಿಯುತ್ತಿದೆ ಎಂದು ನೀವು ಗಮನಿಸಬಹುದು, ಆದರೆ ಅದನ್ನು ಓದಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿರ್ದಿಷ್ಟ ಕರ್ನಲ್-ಮಟ್ಟದ TCP ಸೆಗ್ಮೆಂಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ API ಕರಲ್‌ಗೆ ಜೋಡಿಸಲು ನಿಮಗೆ ಖಂಡಿತವಾಗಿಯೂ ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮಗೆ ಬೇಕಾದ ಟ್ರೇಸ್ ಕಾನ್ಟೆಕ್ಸ್ (trace context) ಸೈಫರ್‌ಟೆಕ್ಸ್ಟ್‌ನ (ciphertext) ಒಳಗೆ ಸಿಲುಕಿಕೊಂಡಿರುತ್ತದೆ.

eBPF ಈ ಸಮೀಕರಣವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸದೆ ಒಳಗಿನಿಂದಲೇ ಸಿಸ್ಟಮ್ ಅನ್ನು instrument ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಆದ ವಿಳಂಬವನ್ನು (latency) ವರದಿ ಮಾಡಲು ಕೇಳುವ ಬದಲಿಗೆ, ನೀವು ಕರ್ನಲ್ ಮತ್ತು ನಿರ್ಣಾಯಕ ಯೂಸರ್ಸ್‌ಪೇಸ್ ಲೈಬ್ರರಿಗಳಿಗೆ ನೇರವಾಗಿ ಸಣ್ಣ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಅಂಟಿಸುತ್ತೀರಿ. ಈ ಪ್ರೋಗ್ರಾಂಗಳು ಘಟನೆಗಳು ಸಂಭವಿಸಿದ ತಕ್ಷಣ ಅವುಗಳನ್ನು ಗಮನಿಸುತ್ತವೆ, ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಹೊರತೆಗೆಯುತ್ತವೆ ಮತ್ತು ಅದನ್ನು ರಿಂಗ್ ಬಫರ್‌ಗೆ (ring buffer) ಕಳುಹಿಸುತ್ತವೆ. ನಿಮ್ಮ Android APK ಒಳಗೆ ಲಘುವಾದ ಹೆಡರ್ ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ SDK bloat ಇರುವುದಿಲ್ಲ, ಮತ್ತು ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಕ್ಲಾಸ್‌ಗಳನ್ನು ಮರುಬರೆಯುವ ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಏಜೆಂಟ್ ಕೂಡ ಇರುವುದಿಲ್ಲ.

ನಾಲ್ಕು ಹಂತಗಳ ಸೆಟಪ್

ಈ ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ವೀಕ್ಷಣೆಯ ನಾಲ್ಕು ವಿಭಿನ್ನ ಪದರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

1. traceparent ಆಂಕರ್. Android ಸಾಧನದಲ್ಲಿ, ನೀವು ಪ್ರತಿ ಹೊರಹೋಗುವ ವಿನಂತಿಗೆ W3C traceparent ಹೆಡರ್ ಅನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡುವ OkHttp ಇಂಟರ್ಸೆಪ್ಟರ್ ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ಮೊಬೈಲ್ ಕಡೆಯಿಂದ ಅಗತ್ಯವಿರುವ ಏಕೈಕ ಬದಲಾವಣೆ ಇದಾಗಿದೆ ಮತ್ತು ಇದು ಅತ್ಯಲ್ಪವಾಗಿದೆ. ಈ ಹೆಡರ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆದ ಪೇಲೋಡ್‌ನ ಒಳಗೆ ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ವರೆಗೆ ಪ್ರಯಾಣಿಸುತ್ತದೆ. ಇದು HTTP ಲೇಯರ್‌ನ ಒಳಗೆ ಇರುವುದರಿಂದ, TLS ಇಂಜಿನ್ ಅಂತಿಮವಾಗಿ ಪ್ರದರ್ಶಿಸುವ ಪ್ಲೇನ್‌ಟೆಕ್ಸ್ಟ್‌ನ (plaintext) ಒಳಗೆ ಇದು ಉಳಿಯುತ್ತದೆ.

2. TCP ಆಗಮನದ ಸಮಯ. ಬ್ಯಾಕೆಂಡ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ನೀವು ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅಂಟಿಸಲಾದ eBPF Traffic Control ಹುಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತೀರಿ. ವೈಯಕ್ತಿಕ TCP ಸೆಗ್ಮೆಂಟ್‌ಗಳು ಬಂದಾಗ ಈ ಪ್ರೋಗ್ರಾಂಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು ಎಡ್ಜ್‌ನಲ್ಲಿ ಸೀಕ್ವೆನ್ಸ್ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಕ್ಯಾಪ್ಚರ್ ಮಾಡುತ್ತವೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಬೈಟ್ ಅನ್ನು ಓದುವ ಮೊದಲೇ, ಬಿಟ್‌ಗಳು ವೈರ್‌ನಿಂದ ಹೊರಬಂದು ನಿಮ್ಮ ಯಂತ್ರಕ್ಕೆ ಪ್ರವೇಶಿಸಿದ ಸಮಯವನ್ನು ನೀವು ಈಗ ನಿಖರವಾಗಿ ತಿಳಿಯಬಹುದು.

3. ಡೀಕ್ರಿಪ್ಶನ್ ಪ್ರೋಬ್‌ಗಳು. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ OpenSSL ಅಥವಾ BoringSSL ಬಳಸಿ TLS ಅನ್ನು ಟರ್ಮಿನೇಟ್ ಮಾಡುತ್ತದೆ. ಇಲ್ಲೇ ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತದೆ. uprobes—ಡೈನಾಮಿಕ್ ಯೂಸರ್ಸ್‌ಪೇಸ್ ಪ್ರೋಬ್‌ಗಳನ್ನು—ಬಳಸಿ, ನೀವು TLS ಲೈಬ್ರರಿಯ ಒಳಗಿರುವ SSL_write ಮತ್ತು SSL_read ಗೆ ಅಂಟಿಕೊಳ್ಳುತ್ತೀರಿ. ಪ್ಲೇನ್‌ಟೆಕ್ಸ್ಟ್ ಡೇಟಾ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಇಂಜಿನ್ ಮೂಲಕ ಹಾದುಹೋದ ತಕ್ಷಣ ಈ ಫಂಕ್ಷನ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ನಿಮ್ಮ eBPF ಪ್ರೋಗ್ರಾಂ ಆ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಬಫರ್ ಅನ್ನು ಓದುತ್ತದೆ, traceparent ಹೆಡರ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ. ನೀವು ಯಾವುದೇ ಕಸ್ಟಮ್ ಟೂಲ್‌ನಲ್ಲಿ ಸರ್ಟಿಫಿಕೇಟ್‌ಗಳು ಅಥವಾ ಕೀಗಳನ್ನು ನಿರ್ವಹಿಸದೆ, ಕರ್ನಲ್ ಈಗ ರಾಗ್‌ TCP ಫ್ಲೋ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಮೊಬೈಲ್ ವಿನಂತಿಯ ನಡುವೆ ನೇರವಾದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ.

4. ಕರ್ನಲ್ ಕ್ಯೂಯಿಂಗ್. ಡೇಟಾ ಡೀಕ್ರಿಪ್ಟ್ ಆಗಿ ಸಿದ್ಧವಾಗಿದ್ದರೂ ಸಹ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ತಕ್ಷಣವೇ ಬಳಸದಿರಬಹುದು. ನೀವು ಸಾಕೆಟ್ ಬಫರ್‌ಗಳು ಮತ್ತು ಶೆಡ್ಯೂಲಿಂಗ್ ಘಟನೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಂಬಂಧಿತ ಕರ್ನಲ್ ಫಂಕ್ಷನ್‌ಗಳಿಗೆ kprobes ಅನ್ನು ಅಂಟಿಸುತ್ತೀರಿ. ಇದು ಕ್ಯೂಯಿಂಗ್ ವಿಳಂಬವನ್ನು (queueing latency) ಅಳೆಯುತ್ತದೆ: ನಿಮ್ಮ ಪ್ರೊಸೆಸ್ CPU ಗಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತಿರುವುದರಿಂದ ಅಥವಾ ಕೇವಲ read() ಅನ್ನು ಇನ್ನೂ ಕರೆಯದ ಕಾರಣ ವಿನಂತಿಗಳು ಕರ್ನಲ್ ಪ್ರದೇಶದಲ್ಲಿ ಕಾಯುವ ಸಮಯವಿದು.

ನಾಲ್ಕೂ ಸಿಗ್ನಲ್ ಮೂಲಗಳು ಘಟನೆಗಳನ್ನು eBPF ರಿಂಗ್ ಬಫರ್‌ಗೆ ಬರೆಯುತ್ತವೆ. ಯೂಸರ್ಸ್‌ಪೇಸ್‌ನಲ್ಲಿ ಚಲಿಸುವ ಸೈಡ್‌ಕಾರ್ ಪ್ರೊಸೆಸ್ ಈ ಬಫರ್ ಅನ್ನು ಖಾಲಿ ಮಾಡುತ್ತದೆ, traceparent ID ಮೂಲಕ ಘಟನೆಗಳನ್ನು ಸಂಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಗಾಗಿ ಒಂದೇ, ಸುಸಂಬದ್ಧ ಟೈಮ್‌ಲೈನ್ ಅನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತದೆ. ಈ ಮೊದಲು ಕೇವಲ ವಿಭಿನ್ನವಾದ ಕರ್ನಲ್ ಶಬ್ದಗಳಾಗಿದ್ದವು, ಈಗ ಒಂದು ರಚನಾತ್ಮಕ ಟ್ರೇಸ್ ಆಗಿ ಬದಲಾಗುತ್ತವೆ.

ಪೂರ್ಣ ಹಾದಿಯನ್ನು ಓದುವುದು

ಸಂಗ್ರಹಿಸಿದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಫ್ಲೇಮ್ ಗ್ರಾಫ್ (flame graph) ಅಥವಾ ರಚನಾತ್ಮಕ ಸ್ಪಾನ್ ಟ್ರೀ (structured span tree) ಆಗಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ, ಇದು ವಿಳಂಬವನ್ನು ನಾಲ್ಕು ನಿರ್ದಿಷ್ಟ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ:

  • Network transit time: Android ರೇಡಿಯೋ ವಿನಂತಿಯ ಕೊನೆಯ ಬೈಟ್ ಅನ್ನು ಕಳುಹಿಸುವುದರಿಂದ ಹಿಡಿದು ಬ್ಯಾಕೆಂಡ್ NIC ಅದನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗಿನ ಅವಧಿ. ಸೆಲ್ಯುಲರ್ ಅಸ್ಥಿರತೆ (cellular volatility) ಇಲ್ಲೇ ಇರುತ್ತದೆ.
  • TLS handshake duration: ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಟನಲ್ ಅನ್ನು ಮಾತುಕತೆ (negotiating) ನಡೆಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯ. ಅಸ್ಥಿರ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ, ಇದು ನಿಜವಾದ ಡೇಟಾ ವರ್ಗಾವಣೆಯಿಗಿಂತಲೂ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
  • Kernel queueing latency: ಸೆಗ್ಮೆಂಟ್ ಬಂದ ನಂತರ ಆದರೆ ಯೂಸರ್ ಸ್ಪೇಸ್ (userspace) ಅದನ್ನು ಬಳಸುವ ಮೊದಲು ಕರ್ನಲ್ ಬಫರ್‌ಗಳು ಮತ್ತು ಶೆಡ್ಯೂಲರ್ ಕ್ಯೂಗಳಲ್ಲಿ ಕಳೆಯುವ ಸಮಯ.
  • Application processing time: ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಮತ್ತು ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ವಾಸ್ತವವಾಗಿ ಬಳಸುವ ಸಮಯದ ಭಾಗ.

800ms ಮೊಬೈಲ್ ವಿನಂತಿಯು ನಿಮ್ಮ JSON ಪಾರ್ಸರ್‌ನಲ್ಲಿ ಕೇವಲ 40ms ಅನ್ನು ಮಾತ್ರ ಕಳೆಯುತ್ತದೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯಬಹುದು. ಮತ್ತೊಂದು 200ms ನಷ್ಟದ ಸಂಪರ್ಕದ (lossy connection) ಕಾರಣದಿಂದಾಗಿ ಸ್ಥಗಿತಗೊಂಡ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಲ್ಲಿ ವ್ಯರ್ಥವಾಗುತ್ತದೆ. ಮತ್ತೊಂದು 300ms ಅತಿಯಾದ ಲೋಡ್ ಇರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕರ್ನಲ್ ಬ್ಯಾಕ್‌ಲಾಗ್‌ನಲ್ಲಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ APM ಕೇವಲ 40ms ಅನ್ನು ಮಾತ್ರ ವರದಿ ಮಾಡುತ್ತಿತ್ತು. ಕರ್ನಲ್ ಮಟ್ಟದ ದೃಶ್ಯೀಕರಣ (visibility) ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪು ವಿಷಯವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುತ್ತಿದ್ದಿರಿ.

ವಾಸ್ತವವಾಗಿ ಸ್ಕೇಲ್ ಆಗುವ ಓವರ್‌ಹೆಡ್ (Overhead That Actually Scales)

ಸಾಂಪ್ರದಾಯಿಕ APM ಏಜೆಂಟ್‌ಗಳು ನಿಮ್ಮ ಭಾಷೆಯ ರನ್‌ಟೈಮ್‌ನೊಳಗೆ ಕರೆಗಳನ್ನು ಅಡ್ಡಿಪಡಿಸುವ ಮೂಲಕ (intercepting) ದೃಶ್ಯೀಕರಣವನ್ನು ಪಡೆಯುತ್ತವೆ. ಅವು ಮೆಥಡ್‌ಗಳನ್ನು ಸುತ್ತುವರಿಯುತ್ತವೆ (wrap), span ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡುತ್ತವೆ ಮತ್ತು ನಿಮ್ಮ ಪ್ರೊಸೆಸ್ ಹೀಪ್‌ನೊಳಗೆ ಟೆಲಿಮೆಟ್ರಿ ಡೇಟಾವನ್ನು ಸೀರಿಯಲೈಸ್ ಮಾಡುತ್ತವೆ. ಲೋಡ್ ಹೆಚ್ಚಾದಾಗ, ಆ ಓವರ್‌ಹೆಡ್ ವೇಗವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಸೀರಿಯಲೈಸೇಶನ್ ವೆಚ್ಚಗಳು ಏರುತ್ತವೆ. ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಒತ್ತಡ ಹೆಚ್ಚಾಗುತ್ತದೆ. ನೀವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಸಂಪನ್ಮೂಲಗಳ ಮೂಲಕವೇ ದೃಶ್ಯೀಕರಣಕ್ಕಾಗಿ ಬೆಲೆ ತೆರುತ್ತಿದ್ದೀರಿ.

eBPF ಪ್ರೋಗ್ರಾಂಗಳು ಕರ್ನಲ್ ವರ್ಚುವಲ್ ಮೆಷಿನ್‌ನೊಳಗೆ ಚಲಿಸುತ್ತವೆ ಮತ್ತು JIT-ಕಂಪೈಲ್ ಆಗಿ ನೇಟಿವ್ ಮೆಷಿನ್ ಇನ್ಸ್ಟ್ರಕ್ಷನ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿತವಾಗುತ್ತವೆ. ಅವು ಲೋಡ್ ಆಗುವ ಮೊದಲು ವೆರಿಫೈಯರ್ ಅವುಗಳ ಸುರಕ್ಷತೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಪ್ರತಿ ಪ್ರೋಬ್ (probe) ಮಾರ್ಗಕ್ಕೆ ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸುತ್ತದೆ, ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಲ್ಲ. ಇವೆಂಟ್‌ಗಳನ್ನು ಹೊಂದಾಣಿಕೆ ಮಾಡುವುದು ಮತ್ತು ಗ್ರಾಫ್‌ಗಳನ್ನು ರೆಂಡರ್ ಮಾಡುವ ಭಾರೀ ಕೆಲಸವು ಸೈಡ್‌ಕಾರ್‌ನಲ್ಲಿ (sidecar), ನಿಮ್ಮ ಸೇವೆಯ ಹಾಟ್ ಪಾತ್‌ನ ಹೊರಗೆ ನಡೆಯುತ್ತದೆ. ನೀವು ಹೀಪ್ ಅಲೋಕೇಶನ್‌ಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತಿಲ್ಲ. ನೀವು ರಿಕ್ವೆಸ್ಟ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್‌ನೊಳಗೆ ಸೀರಿಯಲೈಸೇಶನ್ ತೆರಿಗೆಯನ್ನು (serialization taxes) ಸೇರಿಸುತ್ತಿಲ್ಲ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರಾರು ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಸೇವೆಗಳಿಗೆ, ಈ ವ್ಯತ್ಯಾಸವು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.

ಚಾಲನೆ ಮಾಡಲು ಬೇಕಾದುವುಗಳು

ಇದು ಯಾವುದೋ ಮ್ಯಾಜಿಕ್ ಬುಲೆಟ್ ಅಲ್ಲ, ಮತ್ತು ನೀವು ಸುಲಭವಾಗಿ ಆನ್ ಮಾಡಬಹುದಾದ ಮ್ಯಾನೇಜ್ಡ್ SaaS ಕೂಡ ಅಲ್ಲ. ನಿಮ್ಮ ಪ್ರೋಬ್‌ಗಳು ಕರ್ನಲ್ ರಚನೆಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಚರಿಸಲು BTF ಟೈಪ್ ಮಾಹಿತಿಯೊಂದಿಗೆ ಆಧುನಿಕ eBPF ಬೆಂಬಲವಿರುವ ಬ್ಯಾಕೆಂಡ್ ಕರ್ನಲ್ ನಿಮಗೆ ಬೇಕು. ನಿಮ್ಮ TLS ಲೈಬ್ರರಿಯು uprobes ಗುರಿಯಾಗಬಹುದಾದ ಸಿಂಬಲ್‌ಗಳನ್ನು (symbols) ಪ್ರದರ್ಶಿಸಬೇಕು; ನೀವು ಸ್ಟ್ರಿಪ್ ಮಾಡಲಾದ ಅಥವಾ ಹೆಚ್ಚು ಕಸ್ಟಮೈಸ್ ಮಾಡಲಾದ OpenSSL ಬಿಲ್ಡ್‌ನೊಂದಿಗೆ ಸ್ಟ್ಯಾಟಿಕ್ಲಿ ಲಿಂಕ್ ಮಾಡಲಾದ ಬೈನರಿಯನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಪರಿಗಣಿಸಬೇಕಾಗುತ್ತದೆ. ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್ ಮತ್ತು TLS ಟರ್ಮಿನೇಷನ್ ಪಾಯಿಂಟ್ ನಡುವಿನ ಯಾವುದೇ ಪ್ರೊಕ್ಸಿಗಳು ಅಥವಾ ಎಡ್ಜ್ ಗೇಟ್‌ವೇಗಳ ಮೂಲಕ ನಿಮ್ಮ traceparent ಹೆಡರ್ ಸುರಕ್ಷಿತವಾಗಿ ದಾಟುತ್ತದೆಯೇ ಎಂದು ನೀವು ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ.

ಆದರೆ "ಮೊಬೈಲ್ ನಿಧಾನವಾಗಿದೆ" ಎಂಬ ಮೂಲ ಕಾರಣ ವಿಶ್ಲೇಷಣೆಗೆ (root-cause analysis) ಸಿಗದ ಟಿಕೆಟ್‌ಗಳಿಂದ ದಣಿದಿರುವ ತಂಡಗಳಿಗೆ, ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕೇವಲ ಊಹಾಪೋಹಗಳ ಬದಲಿಗೆ ನಿಖರವಾದ ಸಿಗ್ನಲ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ನೀವು ನೆಟ್‌ವರ್ಕ್ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ನಿರ್ದಿಷ್ಟ ಪೈಪ್‌ಗಳ ಮೂಲಕ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಗಳನ್ನು ಅಳೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.

ನಿಜವಾದ ಸಾರಾಂಶ

ನೀವು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಮೊಬೈಲ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿಮ್ಮ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ ತಲುಪಿದ ತಕ್ಷಣ ಮ್ಯಾಜಿಕಲ್ ಆಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಅಸ್ಪಷ್ಟ ಸ್ಟ್ರೀಮ್ ಎಂದು ಪರಿಗಣಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಒಂದು ಸರಳ OkHttp ಹೆಡರ್ ಅನ್ನು ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಕಾರ್ಯತಂತ್ರದ ರೀತಿಯಲ್ಲಿ ಇರಿಸಲಾದ eBPF ಪ್ರೋಬ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ನೀವು ನಿಮ್ಮ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮರುಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ APM ಬಯಸುವ ರೀತಿಯಲ್ಲಿ ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಕೋಡ್ ಅನ್ನು ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡದೆಯೇ, ಒಂದು ಆಂಡ್ರಾಯ್ಡ್ ಸಾಧನದಿಂದ TLS ಡೀಕ್ರಿಪ್ಶನ್, ಕರ್ನಲ್ ಕ್ಯೂಗಳು ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್ ವರೆಗೆ ಒಂದೇ ವಿನಂತಿಯನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು. ಇದು ಕೇವಲ ಸಣ್ಣ ಸುಧಾರಣೆಯಲ್ಲ. ಇದು ಸಂಪೂರ್ಣ ಎಂಡ್-ಟು-ಎಂಡ್ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (end-to-end observability) ಆಗಿದೆ.