ಮೂರು ಕೋಡ್ಬೇಸ್ಗಳ ವಿಮರ್ಶೆಯು ಕೇವಲ OpenTelemetry (OTel) ಅನ್ನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡುವುದು AI-ಸಹಾಯದ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳಿಗಾಗಿ ಫೀಡ್ಬ್ಯಾಕ್ ಲೂಪ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದಿಲ್ಲ ಎಂದು ತಿಳಿಸುತ್ತದೆ. ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಲೂಪ್ ಇಲ್ಲದಿದ್ದರೆ, ಟೆಲಿಮೆಟ್ರಿಯು ಏಜೆಂಟ್ ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡಲಾರದು ಮತ್ತು ಡೆವಲಪರ್ಗಳು ಮಾಡೆಲ್ಗೆ ಎಂದಿಗೂ ಸಂವಹನ ನಡೆಸದ ಸಾಧನವನ್ನು ಸೇರಿಸಲು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತಾರೆ.
“observability-first” ಮನೋಭಾವ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
ಅನೇಕ ತಂಡಗಳು observability ಅನ್ನು ಕೇವಲ ಒಂದು ಚೆಕ್ಬಾಕ್ಸ್ ಎಂದು ಪರಿಗಣಿಸುತ್ತವೆ: ಒಂದು tracing library ಅನ್ನು ಸೇರಿಸಿ, dashboard ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ಮತ್ತು ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತವೆ. ಆದರೆ ವಾಸ್ತವವು ಮೂರು ಹಂತಗಳ ಏಣಿಯಂತಿದೆ:
- ಒಂದು observability ಕಾರ್ಯವಿಧಾನ ಅಸ್ತಿತ್ವದಲ್ಲಿರಬೇಕು.
- ಸಿಸ್ಟಮ್ ವಾಸ್ತವವಾಗಿ telemetry ಅನ್ನು ಉತ್ಪಾದಿಸಬೇಕು.
- ಒಂದು AI ಏಜೆಂಟ್ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲು ಆ telemetry ಅನ್ನು ಬಳಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಬೇಕು.
ಹೆಚ್ಚಿನ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಹಂತ 1 ರಲ್ಲೇ ನಿಂತುಹೋಗುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಎಂದಿಗೂ ಬಳಸದಿದ್ದರೆ, ಪರಿಪೂರ್ಣವಾಗಿ instrumented ಮಾಡಲಾದ middleware ಯಾವುದೇ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸದೆ ಸುಮ್ಮನೆ ಕುಳಿತಿರುತ್ತದೆ. ಸೋರ್ಸ್ ಕೋಡ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುವ AI ಏಜೆಂಟ್, tracing ಕೋಡ್ ಅನ್ನು ನೋಡಿ ಸಿಸ್ಟಮ್ observable ಆಗಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ, ಆದರೆ ನಂತರ ರನ್ಟೈಮ್ನಲ್ಲಿ ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲದಿರುವುದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ. “ಸಾಧನವನ್ನು ಹೊಂದಿರುವುದು” ಮತ್ತು “ಲೂಪ್ ಅನ್ನು ಹೊಂದಿರುವುದು” ನಡುವಿನ ಅಂತರವೇ ಪ್ರಯತ್ನವು ವಿಫಲವಾಗುವ ಸ್ಥಳವಾಗಿದೆ.
ಬಳಕೆಗೆ ಯೋಗ್ಯವಾದ ಡೇಟಾಕ್ಕಾಗಿ ಆರು ಷರತ್ತುಗಳು
ರೊ (raw) traces ಗಳನ್ನು AI ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಇನ್ಪುಟ್ ಆಗಿ ಪರಿವರ್ತಿಸಲು, telemetry ಈ ಆರು ಪ್ರಾಯೋಗಿಕ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಬೇಕು:
- Standardization. ಏಜೆಂಟ್ ಯಾವುದೇ ವಿಶೇಷ ಮ್ಯಾಪಿಂಗ್ ಇಲ್ಲದೆ ಡೇಟಾವನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಅನುಕೂಲವಾಗುವಂತೆ ಸ್ಥಿರವಾದ attribute ಹೆಸರುಗಳು ಮತ್ತು ಪ್ರಕಾರಗಳನ್ನು ಬಳಸಿ.
- Propagation. ಎಲ್ಲಾ ಸರ್ವಿಸಸ್ ಮತ್ತು ಭಾಷಾ ಮಿತಿಗಳಾದ್ಯಂತ ಒಂದೇ trace identifier ಅನ್ನು ಕೊಂಡೊಯ್ಯಿರಿ, ಇದರಿಂದ ಏಜೆಂಟ್ ಸಂಪೂರ್ಣ (end-to-end) ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪುನರ್ರಚಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
- Discoverability. ಮಾಡೆಲ್ ಕೈಯಾರೆ ಹುಡುಕದೆ ಡೇಟಾವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಅನುಕೂಲವಾಗುವಂತೆ, ಕೋಡ್-ಮಟ್ಟದ hooks ಅಥವಾ ಸರಳ CLI commands ಮೂಲಕ ಡೇಟಾವನ್ನು ಪ್ರದರ್ಶಿಸಿ.
- Controllability. ಏಜೆಂಟ್ ಅನಗತ್ಯ spans ಗಳ ಅಬ್ಬರಕ್ಕೆ ಸಿಲುಕದಂತೆ ತಡೆಯಲು, ಸಮಯದ ವ್ಯಾಪ್ತಿ ಅಥವಾ ಫಲಿತಾಂಶದ ಸಂಖ್ಯೆಯ ಮೂಲಕ ಕ್ವೇರಿಗಳನ್ನು ಮಿತಿಗೊಳಿಸಲು ಏಜೆಂಟ್ಗೆ ಅನುಮತಿಸಿ.
- Accessibility. ಏಜೆಂಟ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಅದೇ ಸೆಶನ್ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಓದಬಲ್ಲ ರೀತಿಯಲ್ಲಿ ಇರಿಸಿ, ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಸ್ಥಳೀಯ ಫೈಲ್ ಅಥವಾ stdout stream ಮೂಲಕ ಇರಲಿ.
- Comparability. ಏಜೆಂಟ್ ಬದಲಾವಣೆಯ ಪರಿಣಾಮವನ್ನು ಅಳೆಯಲು ಅನುಕೂಲವಾಗುವಂತೆ, ಒಂದೇ ರೀತಿಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ “ಮೊದಲು” ಮತ್ತು “ನಂತರ”ದ ಸ್ನ್ಯಾಪ್ಶಾಟ್ಗಳನ್ನು ಪಡೆಯುವ ವಿಧಾನವನ್ನು ಒದಗಿಸಿ.
ಈ ಪಿಲ್ಲರ್ಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಒಂದು ಇಲ್ಲದಿದ್ದರೆ, ಫೀಡ್ಬ್ಯಾಕ್ ಲೂಪ್ ಮುರಿದುಹೋಗುತ್ತದೆ ಮತ್ತು AI ಏಜೆಂಟ್ ಕೇವಲ ಊಹಾಪೋಹಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುತ್ತದೆ.
ಡೆವಲಪ್ಮೆಂಟ್ಗಾಗಿ ಕ್ಲೌಡ್ಗಿಂತ ಲೋಕಲ್ ಪೈಪ್ಲೈನ್ಗಳು ಉತ್ತಮ
ಪ್ರೊಡಕ್ಷನ್ ಪರಿಸರಗಳು ಕ್ಲೌಡ್ ಆಧಾರಿತ telemetry collectors, aggregation services ಮತ್ತು dashboards ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿವೆ. ದೊಡ್ಡ ಮಟ್ಟದ ಮಾನಿಟರಿಂಗ್ಗೆ ಆ ಪೈಪ್ಲೈನ್ಗಳು ಅತ್ಯಗತ್ಯ, ಆದರೆ ಅವು ನಿಮಿಷಗಟ್ಟಲೆ ವಿಳಂಬವನ್ನು (latency) ಉಂಟುಮಾಡುತ್ತವೆ. ಡೇಟಾಕ್ಕಾಗಿ ನಿಮಿಷಗಟ್ಟಲೆ ಕಾಯುವ AI ಏಜೆಂಟ್, ಸೆಕೆಂಡುಗಳಲ್ಲಿ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಡೆವಲಪ್ಮೆಂಟ್ ಲೂಪ್ನಲ್ಲಿ ಭಾಗವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಇದಕ್ಕೆ ಪ್ರಾಯೋಗಿಕ ಪರ್ಯಾಯವೆಂದರೆ local telemetry pipeline:
- telemetry ಅನ್ನು ಸ್ಥಳೀಯ ಫೈಲ್ಗಳು ಅಥವಾ stdout ಗೆ ಬರೆಯಿರಿ. OTel એ JSON ಅಥವಾ plain-text spans ಗಳನ್ನು ನೇರವಾಗಿ ಡೆವಲಪರ್ನ ವರ್ಕ್ಸ್ಪೇಸ್ಗೆ ಹಾಕುವ exporters ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
- ಸರಳ ಪರಿಕರಗಳ ಮೂಲಕ ಡೇಟಾವನ್ನು ಪ್ರದರ್ಶಿಸಿ. ಒಂದು ಕನಿಷ್ಠ HTTP server, command-line query interface ಅಥವಾ ಲೈಟ್ವೇಟ್ SQL wrapper ಮೂಲಕ ಅಗತ್ಯವಿದ್ದಾಗ ಏಜೆಂಟ್ಗೆ traces ಗಳನ್ನು ಒದಗಿಸಬಹುದು.
- ಏಜೆಂಟ್ ಅನ್ನು ರೊ (raw) ಔಟ್ಪುಟ್ ಓದಲು ಬಿಡಿ. JSON ಅಥವಾ Markdown ರೂಪಗಳು ಭಾಷಾ ಮಾಡೆಲ್ಗಳಿಗೆ ಒಂದೇ ಎಡಿಟ್ ಸೆಶನ್ನಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡಲು ಮತ್ತು ಹೋಲಿಸಲು ಸುಲಭವಾಗಿರುತ್ತವೆ.
ದೊಡ್ಡ ಮಟ್ಟದ auto-instrumentation ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಕೇವಲ ಗೊಂದಲವನ್ನು (noise) ಹೆಚ್ಚಿಸುತ್ತದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ, ನಿರ್ಣಾಯಕ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಪಾತ್ ಅನ್ನು ಆರಿಸಿ—ಉದಾಹರಣೆಗೆ request handling routine ಅಥವಾ build step—ಮತ್ತು ಅದನ್ನು end-to-end instrument ಮಾಡಿ. ಈ ಸರಪಳಿಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ: Generate → Propagate → Store → Query → Compare. ಒಮ್ಮೆ ಆ ಲೂಪ್ ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ಅದನ್ನು ಹಂತ ಹಂತವಾಗಿ ವಿಸ್ತರಿಸಿ.
ತಂಡಗಳು ಮುಂದೆ ಏನು ಮಾಡಬೇಕು
- ಅತ್ಯಂತ ಮೌಲ್ಯಯುತವಾದ ಫ್ಲೋ ಅನ್ನು ಗುರುತಿಸಿ. ಬದಲಾವಣೆಯು ಅಳೆಯಬಹುದಾದ ಕಾರ್ಯಕ್ಷಮತೆ ಅಥವಾ ನಿಖರತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಕೋಡ್ ಅನ್ನು ಆರಿಸಿ.
- ಆ ಫ್ಲೋ ಅನ್ನು OTel ಮೂಲಕ instrument ಮಾಡಿ. spans ರಚಿಸಲು, ಪ್ರಮಾಣೀಕೃತ attributes ಗಳನ್ನು ಜೋಡಿಸಲು ಮತ್ತು trace context ಅನ್ನು ಪ್ರಸಾರ ಮಾಡಲು ಭಾಷೆ-ನಿರ್ದಿಷ್ಟ API ಅನ್ನು ಬಳಸಿ.
- ಸ್ಥಳೀಯವಾಗಿ ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿ. ಪ್ರಾಜೆಕ್ಟ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲರುವ ಫೈಲ್ಗೆ JSON ಲೈನ್ಗಳನ್ನು ಬರೆಯಲು ಅಥವಾ ಕನ್ಸೋಲ್ಗೆ ಪ್ರಿಂಟ್ ಮಾಡಲು exporter ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ.
- ಕ್ವೇರಿ ಇಂಟರ್ಫೇಸ್ ಒದಗಿಸಿ. trace ID ಮತ್ತು ಸಮಯದ ವಿಂಡೋ ಮೂಲಕ ಫೈಲ್ ಅನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ಒಂದು ಸಣ್ಣ ಸ್ಕ್ರಿಪ್ಟ್ ಏಜೆಂಟ್ ಸರಿಯಾದ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ಸಾಕಾಗುತ್ತದೆ.
- ಡೇಟಾವನ್ನು AI ಏಜೆಂಟ್ಗೆ ನೀಡಿ. ಮಾಡೆಲ್ಗೆ “ಮೊದಲು”ನ trace ಅನ್ನು ಪ್ರಾಂಪ್ಟ್ ಮಾಡಿ, ಬದಲಾವಣೆ ಕೇಳಿ, ನಂತರ ಅಪ್ಡೇಟ್ ಮಾಡಿದ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡಿ ಮತ್ತು ಹೋಲಿಕೆಗಾಗಿ “ನಂತರ”ದ trace ಅನ್ನು ಸಂಗ್ರಹಿಸಿ.
- ಪುನರಾವರ್ತಿಸಿ (Iterate). ಪ್ರತಿ ಯಶಸ್ವಿ ಲೂಪ್ ಆರು ಷರತ್ತುಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು observable surface area ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ.
ಸಾರಾಂಶ
OpenTelemetry ನಿಮ್ಮ ಕೋಡ್ಗೆ ಟ್ರೇಸಿಂಗ್ಗಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಭಾಷೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಡೇಟಾವು ಆರು ನಿರ್ದಿಷ್ಟ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಪೂರೈಸಿದಾಗ ಮತ್ತು ಒಂದು ಬಿಗಿಯಾದ ಫೀಡ್ಬ್ಯಾಕ್ ಲೂಪ್ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಲಭ್ಯವಿರುವಾಗ ಮಾತ್ರ ಆ ಭಾಷೆಯು ಉಪಯುಕ್ತವಾಗುತ್ತದೆ. ಸಣ್ಣದಾಗಿ ಪ್ರಾರಂಭಿಸಿ, ಒಂದು ಸಿಂಗಲ್ ಫ್ಲೋ ಅನ್ನು ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡಿ, ಫೈಲ್ಗೆ ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿ ಮತ್ತು AI ಏಜೆಂಟ್ ಟ್ರೇಸ್ಗಳನ್ನು ಸ್ಥಳದಲ್ಲೇ ಓದಿ ಮತ್ತು ಹೋಲಿಸಲು ಬಿಡಿ. "ನನ್ನ ಬಳಿ observability ಇದೆ" ಎಂಬ ಹಂತದಿಂದ "ನನ್ನ AI assistant ನಿಜವಾಗಿಯೂ ನನ್ನ ಕೋಡ್ ಅನ್ನು ಸುಧಾರಿಸಬಹುದು" ಎಂಬ ಹಂತಕ್ಕೆ ತಲುಪಲು ಇದೇ ಪ್ರಾಯೋಗಿಕ ಹಾದಿ.