ಕೊನೆಯಲ್ಲಿ ನಾವು ಸೇವೆ ಮೆಶ್ ಇಸ್ಟಿಯೊದ ಮೂಲ ಘಟಕಗಳನ್ನು ನೋಡಿದ್ದೇವೆ, ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ ಪರಿಚಯವಾಯಿತು ಮತ್ತು ಇಸ್ಟಿಯೊದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ಭವಿಸುವ ಮುಖ್ಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿದ್ದೇವೆ. ಈ ಭಾಗದಲ್ಲಿ ನಾವು ಜಾಲಬಂಧದ ಮೂಲಕ ಪತ್ತೆಹಚ್ಚುವ ಮಾಹಿತಿಯ ಸಂಗ್ರಹವನ್ನು ಹೇಗೆ ಸಂಘಟಿಸುವುದು ಎಂದು ನೋಡೋಣ.
ಸೇವೆ ಮೆಶ್ ಟ್ರೇಸಿಂಗ್ ಎಂಬ ಪದಗಳನ್ನು ಕೇಳಿದಾಗ ಅನೇಕ ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಿಗೆ ಮನಸ್ಸಿಗೆ ಬರುವ ಮೊದಲ ವಿಷಯ. ವಾಸ್ತವವಾಗಿ, ಎಲ್ಲಾ TCP ಟ್ರಾಫಿಕ್ ಹಾದುಹೋಗುವ ಪ್ರತಿಯೊಂದು ನೆಟ್‌ವರ್ಕ್ ನೋಡ್‌ಗೆ ನಾವು ವಿಶೇಷ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್ ಸಂವಹನಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸುಲಭವಾಗಿ ಕಳುಹಿಸಲು ಈಗ ಸಾಧ್ಯವಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ವಾಸ್ತವದಲ್ಲಿ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಅನೇಕ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ. ಅವುಗಳನ್ನು ನೋಡೋಣ.
ತಪ್ಪು ಕಲ್ಪನೆ ನಂಬರ್ ಒನ್: ನಾವು ಆನ್‌ಲೈನ್ ಹೈಕಿಂಗ್ ಡೇಟಾವನ್ನು ಉಚಿತವಾಗಿ ಪಡೆಯಬಹುದು.
ವಾಸ್ತವವಾಗಿ, ತುಲನಾತ್ಮಕವಾಗಿ ಉಚಿತವಾಗಿ, ನಾವು ನಮ್ಮ ಸಿಸ್ಟಂನ ನೋಡ್‌ಗಳನ್ನು ಬಾಣಗಳಿಂದ ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಸೇವೆಗಳ ನಡುವೆ ಹಾದುಹೋಗುವ ಡೇಟಾ ದರವನ್ನು ಮಾತ್ರ ಪಡೆಯಬಹುದು (ವಾಸ್ತವವಾಗಿ, ಸಮಯದ ಪ್ರತಿ ಘಟಕಕ್ಕೆ ಬೈಟ್‌ಗಳ ಸಂಖ್ಯೆ ಮಾತ್ರ). ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಮ್ಮ ಸೇವೆಗಳು HTTP, gRPC, Redis, ಇತ್ಯಾದಿಗಳಂತಹ ಕೆಲವು ರೀತಿಯ ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಮತ್ತು, ಸಹಜವಾಗಿ, ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾಹಿತಿಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಾವು ಬಯಸುತ್ತೇವೆ; ನಾವು ವಿನಂತಿಯ ದರವನ್ನು ನೋಡಲು ಬಯಸುತ್ತೇವೆ, ಡೇಟಾ ದರವಲ್ಲ. ನಮ್ಮ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ವಿನಂತಿಗಳ ಸುಪ್ತತೆಯನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ. ಅಂತಿಮವಾಗಿ, ನಮ್ಮ ಸಿಸ್ಟಮ್‌ಗೆ ಲಾಗಿನ್ ಆಗುವುದರಿಂದ ಬಳಕೆದಾರರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುವವರೆಗೆ ವಿನಂತಿಯು ತೆಗೆದುಕೊಳ್ಳುವ ಸಂಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ನಾವು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನು ಮುಂದೆ ಪರಿಹರಿಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ.
ಮೊದಲಿಗೆ, ಇಸ್ಟಿಯೊದಲ್ಲಿನ ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಕೋನದಿಂದ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. ಮೊದಲ ಭಾಗದಿಂದ ನಾವು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವಂತೆ, ಇಸ್ಟಿಯೊ ಟೆಲಿಮೆಟ್ರಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಮಿಕ್ಸರ್ ಎಂಬ ಪ್ರತ್ಯೇಕ ಘಟಕವನ್ನು ಹೊಂದಿದೆ. ಆದಾಗ್ಯೂ, ಪ್ರಸ್ತುತ ಆವೃತ್ತಿ 1.0.* ನಲ್ಲಿ, ಕಳುಹಿಸುವಿಕೆಯನ್ನು ನೇರವಾಗಿ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳಿಂದ ಮಾಡಲಾಗುತ್ತದೆ, ಅವುಗಳೆಂದರೆ, ಪ್ರತಿನಿಧಿ ಪ್ರಾಕ್ಸಿಯಿಂದ. ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಜಿಪ್ಕಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಎನ್ವಾಯ್ ಪ್ರಾಕ್ಸಿ ಬೆಂಬಲಿಸುತ್ತದೆ. ಇತರ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಿದೆ, ಆದರೆ ಪ್ಲಗಿನ್ ಮೂಲಕ ಮಾತ್ರ. Istio ನೊಂದಿಗೆ ನಾವು ತಕ್ಷಣವೇ ಜೋಡಿಸಲಾದ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಪ್ರತಿನಿಧಿ ಪ್ರಾಕ್ಸಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಇದು ಜಿಪ್ಕಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ. ನಾವು ಬಳಸಲು ಬಯಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ಜೇಗರ್ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು UDP ಮೂಲಕ ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು, ನಂತರ ನಾವು ನಮ್ಮ ಸ್ವಂತ istio-proxy ಇಮೇಜ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗುತ್ತದೆ. istio-proxy ಗಾಗಿ ಕಸ್ಟಮ್ ಪ್ಲಗಿನ್‌ಗಳಿಗೆ ಬೆಂಬಲವಿದೆ, ಆದರೆ ಇದು ಇನ್ನೂ ಆಲ್ಫಾ ಆವೃತ್ತಿಯಲ್ಲಿದೆ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕಸ್ಟಮ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಲ್ಲದೆಯೇ ನಾವು ಮಾಡಲು ಬಯಸಿದರೆ, ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಸ್ವೀಕರಿಸಲು ಬಳಸುವ ತಂತ್ರಜ್ಞಾನಗಳ ವ್ಯಾಪ್ತಿಯು ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಮುಖ್ಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಈಗ ನೀವು ಜಿಪ್ಕಿನ್ ಅಥವಾ ಜೇಗರ್ ಅನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಜಿಪ್ಕಿನ್ ಹೊಂದಾಣಿಕೆಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲವನ್ನೂ ಕಳುಹಿಸಬಹುದು (ಇದು ಕಡಿಮೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ). ಜಿಪ್ಕಿನ್ ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಃ HTTP ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸಂಗ್ರಹಕಾರರಿಗೆ ಎಲ್ಲಾ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ಸಾಕಷ್ಟು ದುಬಾರಿಯಾಗಿದೆ.
ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಬಯಸುತ್ತೇವೆ. ಇದರರ್ಥ ಪ್ರತಿ ಸೇವೆಯ ಪಕ್ಕದಲ್ಲಿ ನಿಂತಿರುವ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳು ಈಗ ಯಾವ ರೀತಿಯ ಸಂವಹನ ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, Istio ಎಲ್ಲಾ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸರಳ TCP ಎಂದು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ, ಅಂದರೆ ಯಾವುದೇ ಕುರುಹುಗಳನ್ನು ಕಳುಹಿಸಲಾಗುವುದಿಲ್ಲ. ಕುರುಹುಗಳನ್ನು ಕಳುಹಿಸಲು, ನೀವು ಮೊದಲು, ಈ ಆಯ್ಕೆಯನ್ನು ಮುಖ್ಯ ಜಾಲರಿ ಸಂರಚನೆಯಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು ಮತ್ತು ಬಹಳ ಮುಖ್ಯವಾದುದೆಂದರೆ, ಸೇವೆಯಲ್ಲಿ ಬಳಸಲಾಗುವ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಅನುಗುಣವಾಗಿ ಕುಬರ್ನೆಟ್ ಸೇವಾ ಘಟಕಗಳ ಎಲ್ಲಾ ಪೋರ್ಟ್‌ಗಳನ್ನು ಹೆಸರಿಸಬೇಕು. ಅಂದರೆ, ಉದಾಹರಣೆಗೆ, ಈ ರೀತಿ:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxನೀವು http-ಮ್ಯಾಜಿಕ್ ನಂತಹ ಸಂಯುಕ್ತ ಹೆಸರುಗಳನ್ನು ಸಹ ಬಳಸಬಹುದು (ಇಸ್ಟಿಯೊ http ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಆ ಪೋರ್ಟ್ ಅನ್ನು http ಎಂಡ್ ಪಾಯಿಂಟ್ ಎಂದು ಗುರುತಿಸುತ್ತದೆ). ಸ್ವರೂಪವು: ಪ್ರೊಟೊ-ಹೆಚ್ಚುವರಿ.
ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿರ್ಧರಿಸಲು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡದಿರಲು, ನೀವು ಕೊಳಕು ಪರಿಹಾರವನ್ನು ಬಳಸಬಹುದು: ಪೈಲಟ್ ಘಟಕವನ್ನು ಕ್ಷಣದಲ್ಲಿ ಪ್ಯಾಚ್ ಮಾಡಿ . ಕೊನೆಯಲ್ಲಿ, ಸಹಜವಾಗಿ, ಈ ತರ್ಕವನ್ನು ಪ್ರಮಾಣಿತಕ್ಕೆ ಬದಲಾಯಿಸಲು ಮತ್ತು ಎಲ್ಲಾ ಪೋರ್ಟ್‌ಗಳಿಗೆ ಹೆಸರಿಸುವ ಸಂಪ್ರದಾಯಕ್ಕೆ ಬದಲಾಯಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಸರಿಯಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಯಾವುದೇ ಸೈಡ್‌ಕಾರ್ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಹೋಗಬೇಕು ಮತ್ತು ಸ್ಥಳ / config_dump ನೊಂದಿಗೆ ರಾಯಭಾರಿ ಇಂಟರ್ಫೇಸ್‌ನ ನಿರ್ವಾಹಕ ಪೋರ್ಟ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ ಸಂರಚನೆಯಲ್ಲಿ, ನೀವು ಬಯಸಿದ ಸೇವೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಕ್ಷೇತ್ರವನ್ನು ನೋಡಬೇಕು. ಇದನ್ನು ಇಸ್ಟಿಯೊದಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಎಲ್ಲಿ ಮಾಡಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಗುರುತಿಸುವಿಕೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಇಸ್ಟಿಯೊದಲ್ಲಿ ಈ ಪ್ಯಾರಾಮೀಟರ್‌ನ ಮೌಲ್ಯವನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು (ನಾವು ಅದನ್ನು ನಮ್ಮ ಟ್ರೇಸಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ನೋಡುತ್ತೇವೆ), ಸೈಡ್‌ಕಾರ್ ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಹಂತದಲ್ಲಿ ಸೇವಾಕ್ಲಸ್ಟರ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು ಅವಶ್ಯಕ. ಉದಾಹರಣೆಗೆ, ಕೆಳಮುಖವಾದ ಕುಬರ್ನೆಟ್ಸ್ API ನಿಂದ ಪಡೆದ ವೇರಿಯೇಬಲ್‌ಗಳಿಂದ ಇದನ್ನು ಈ ರೀತಿ ಲೆಕ್ಕ ಹಾಕಬಹುದು:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
ರಾಯಭಾರಿಯಲ್ಲಿ ಟ್ರೇಸಿಂಗ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಉತ್ತಮ ಉದಾಹರಣೆ .
ಟ್ರೇಸಿಂಗ್ ಸ್ಪ್ಯಾನ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಅಂತಿಮ ಬಿಂದುವನ್ನು ಸಹ ಪ್ರತಿನಿಧಿ ಪ್ರಾಕ್ಸಿ ಲಾಂಚ್ ಫ್ಲ್ಯಾಗ್‌ಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು, ಉದಾಹರಣೆಗೆ: --zipkinAddress tracing-collector.tracing:9411
ತಪ್ಪು ತಿಳುವಳಿಕೆ ಸಂಖ್ಯೆ ಎರಡು: ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಸಿಸ್ಟಮ್ ಮೂಲಕ ವಿನಂತಿಗಳ ಸಂಪೂರ್ಣ ಕುರುಹುಗಳನ್ನು ನಾವು ಅಗ್ಗವಾಗಿ ಪಡೆಯಬಹುದು
ದುರದೃಷ್ಟವಶಾತ್, ಅದು ಅಲ್ಲ. ಅನುಷ್ಠಾನದ ಸಂಕೀರ್ಣತೆಯು ನೀವು ಈಗಾಗಲೇ ಸೇವೆಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಅದು ಏಕೆ?
ಸತ್ಯವೆಂದರೆ, ಅದೇ ಸೇವೆಯನ್ನು ತೊರೆಯುವವರೊಂದಿಗೆ ಸೇವೆಗೆ ಒಳಬರುವ ವಿನಂತಿಗಳ ಪತ್ರವ್ಯವಹಾರವನ್ನು ಇಸ್ಟಿಯೊ-ಪ್ರಾಕ್ಸಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು ಸರಳವಾಗಿ ಪ್ರತಿಬಂಧಿಸಲು ಸಾಕಾಗುವುದಿಲ್ಲ. ನೀವು ಕೆಲವು ರೀತಿಯ ಸಂವಹನ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿರಬೇಕು. HTTP ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿ ವಿಶೇಷ ಹೆಡರ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಅದರ ಮೂಲಕ ಸೇವೆಗೆ ಯಾವ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಯು ಇತರ ಸೇವೆಗಳಿಗೆ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದೂತರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಅಂತಹ ಶೀರ್ಷಿಕೆಗಳ ಪಟ್ಟಿ:
- x-request-id,
- x-b3-ಟ್ರೇಸಿಡ್,
- x-b3-ಸ್ಪೇನಿಡ್,
- x-b3-ಪೇರೆಂಟ್ಸ್ಪಾನಿಡ್,
- x-b3-ಮಾದರಿ,
- x-b3-ಧ್ವಜಗಳು,
- x-ot-span-ಸಂದರ್ಭ.
ನೀವು ಒಂದೇ ಪಾಯಿಂಟ್ ಹೊಂದಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಮೂಲಭೂತ ಕ್ಲೈಂಟ್, ಇದರಲ್ಲಿ ನೀವು ಅಂತಹ ತರ್ಕವನ್ನು ಸೇರಿಸಬಹುದು, ನಂತರ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಈ ಲೈಬ್ರರಿಯನ್ನು ನವೀಕರಿಸಲು ನೀವು ಕಾಯಬೇಕಾಗಿದೆ. ಆದರೆ ನೀವು ತುಂಬಾ ವೈವಿಧ್ಯಮಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸೇವೆಯಿಂದ ಸೇವೆಗೆ ಚಲಿಸುವಲ್ಲಿ ಯಾವುದೇ ಏಕೀಕರಣವಿಲ್ಲದಿದ್ದರೆ, ಇದು ಹೆಚ್ಚಾಗಿ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಅಂತಹ ತರ್ಕವನ್ನು ಸೇರಿಸದೆಯೇ, ಎಲ್ಲಾ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯು ಕೇವಲ "ಏಕ-ಹಂತ" ಆಗಿರುತ್ತದೆ. ಅಂದರೆ, ನಾವು ಎಲ್ಲಾ ಅಂತರ-ಸೇವಾ ಸಂವಹನಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ಆದರೆ ಅವುಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಒಂದೇ ಸರಪಳಿಗಳ ಮೂಲಕ ಅಂಟಿಸಲಾಗುವುದಿಲ್ಲ.
ತೀರ್ಮಾನಕ್ಕೆ
ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಇಸ್ಟಿಯೊ ಅನುಕೂಲಕರ ಸಾಧನವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ನೀವು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಇಸ್ಟಿಯೊ ಅನುಷ್ಠಾನದ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಪರಿಣಾಮವಾಗಿ, ಎರಡು ಮುಖ್ಯ ಅಂಶಗಳನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ: ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು (ರಾಯಭಾರಿ ಪ್ರಾಕ್ಸಿಯಿಂದ ಬೆಂಬಲಿಸಬೇಕು) ಮತ್ತು ಸೇವೆಯಿಂದ ವಿನಂತಿಗಳಿಂದ ಸೇವೆಗೆ ವಿನಂತಿಗಳ ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ಹೊಂದಿಸುವುದು (ಹೆಡರ್ಗಳನ್ನು ಬಳಸುವುದು , HTTP ಪ್ರೋಟೋಕಾಲ್ನ ಸಂದರ್ಭದಲ್ಲಿ). ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದಾಗ, ಹಲವಾರು ವಿಭಿನ್ನ ಭಾಷೆಗಳು ಮತ್ತು ಚೌಕಟ್ಟುಗಳಲ್ಲಿ ಬರೆಯಲಾದ ಅತ್ಯಂತ ವೈವಿಧ್ಯಮಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿಯೂ ಸಹ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಮಾಹಿತಿಯನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ಸಂಗ್ರಹಿಸಲು ನಮಗೆ ಅನುಮತಿಸುವ ಪ್ರಬಲ ಸಾಧನವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.
ಸರ್ವಿಸ್ ಮೆಶ್ ಕುರಿತು ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ, ನಾವು ಇಸ್ಟಿಯೊದೊಂದಿಗಿನ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದನ್ನು ನೋಡುತ್ತೇವೆ - ಪ್ರತಿ ಸೈಡ್‌ಕಾರ್ ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್‌ನಿಂದ RAM ನ ದೊಡ್ಡ ಬಳಕೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಹೇಗೆ ಎದುರಿಸಬಹುದು ಎಂಬುದನ್ನು ಚರ್ಚಿಸಿ.
ಮೂಲ: www.habr.com