ಮತ್ತೊಂದು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆ

16 ಮೋಡೆಮ್‌ಗಳು, 4 ಸೆಲ್ಯುಲರ್ ಆಪರೇಟರ್‌ಗಳು = ಹೊರಹೋಗುವ ವೇಗ 933.45 Mbit/s

ಪರಿಚಯ

ನಮಸ್ಕಾರ! ಈ ಲೇಖನವು ನಮಗಾಗಿ ನಾವು ಹೊಸ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಬರೆದಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು. ಇದು ಹೆಚ್ಚಿನ ಆವರ್ತನ ಸಿಂಕ್ರೊನಸ್ ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಕಡಿಮೆ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳಿಂದ ಭಿನ್ನವಾಗಿದೆ. 0.1 ನ್ಯಾನೊಸೆಕೆಂಡ್‌ಗಳ ಮೆಟ್ರಿಕ್‌ಗಳ ನಡುವಿನ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ನಿಖರತೆಯೊಂದಿಗೆ ಮತದಾನದ ಪ್ರಮಾಣವು 10 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ತಲುಪಬಹುದು. ಎಲ್ಲಾ ಬೈನರಿ ಫೈಲ್‌ಗಳು 6 ಮೆಗಾಬೈಟ್‌ಗಳನ್ನು ಆಕ್ರಮಿಸುತ್ತವೆ.

ಯೋಜನೆಯ ಬಗ್ಗೆ

ನಾವು ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಡೇಟಾ ಪ್ರಸರಣ ಚಾನಲ್‌ಗಳ ಥ್ರೋಪುಟ್ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸಾರಾಂಶಕ್ಕಾಗಿ ನಾವು ಸಮಗ್ರ ಪರಿಹಾರವನ್ನು ತಯಾರಿಸುತ್ತೇವೆ. ಇದು ಹಲವಾರು ಚಾನಲ್‌ಗಳಿರುವಾಗ, ಆಪರೇಟರ್ 1 (40Mbit/s) + ಆಪರೇಟರ್ 2 (30Mbit/s)+ ಬೇರೆ ಯಾವುದೋ (5 Mbit/s) ಎಂದು ಹೇಳೋಣ, ಫಲಿತಾಂಶವು ಒಂದು ಸ್ಥಿರ ಮತ್ತು ವೇಗದ ಚಾನಲ್ ಆಗಿರುತ್ತದೆ, ಅದರ ವೇಗವು ಈ ರೀತಿ ಇರುತ್ತದೆ ಇದು: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

ಯಾವುದೇ ಒಂದು ಚಾನಲ್‌ನ ಸಾಮರ್ಥ್ಯವು ಸಾಕಷ್ಟಿಲ್ಲದಿದ್ದರೆ ಅಂತಹ ಪರಿಹಾರಗಳು ಬೇಡಿಕೆಯಲ್ಲಿವೆ. ಉದಾಹರಣೆಗೆ, ಸಾರಿಗೆ, ವೀಡಿಯೋ ಕಣ್ಗಾವಲು ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ನೈಜ-ಸಮಯದ ವೀಡಿಯೊ ಸ್ಟ್ರೀಮಿಂಗ್, ನೇರ ದೂರದರ್ಶನ ಮತ್ತು ರೇಡಿಯೊ ಪ್ರಸಾರಗಳ ಪ್ರಸಾರ, ಯಾವುದೇ ಉಪನಗರ ಸೌಲಭ್ಯಗಳು ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳಲ್ಲಿ ಕೇವಲ ಬಿಗ್ ಫೋರ್‌ನ ಪ್ರತಿನಿಧಿಗಳು ಮತ್ತು ಒಂದು ಮೋಡೆಮ್/ಚಾನೆಲ್‌ನಲ್ಲಿನ ವೇಗವು ಸಾಕಾಗುವುದಿಲ್ಲ. .
ಈ ಪ್ರತಿಯೊಂದು ಪ್ರದೇಶಗಳಿಗೆ, ನಾವು ಪ್ರತ್ಯೇಕ ಸಾಧನಗಳ ಸಾಲನ್ನು ಉತ್ಪಾದಿಸುತ್ತೇವೆ, ಆದರೆ ಅವುಗಳ ಸಾಫ್ಟ್‌ವೇರ್ ಭಾಗವು ಬಹುತೇಕ ಒಂದೇ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಅದರ ಮುಖ್ಯ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಅದರ ಸರಿಯಾದ ಅನುಷ್ಠಾನವಿಲ್ಲದೆ ಉತ್ಪನ್ನವು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಹಲವಾರು ವರ್ಷಗಳ ಅವಧಿಯಲ್ಲಿ, ನಾವು ಬಹು-ಹಂತದ, ವೇಗದ, ಅಡ್ಡ-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಹಗುರವಾದ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ಇದನ್ನೇ ನಾವು ನಮ್ಮ ಗೌರವಾನ್ವಿತ ಸಮುದಾಯದೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ.

ಸಮಸ್ಯೆ ಹೇಳಿಕೆ

ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಎರಡು ಮೂಲಭೂತವಾಗಿ ವಿಭಿನ್ನ ವರ್ಗಗಳ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ: ನೈಜ-ಸಮಯದ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಎಲ್ಲಾ ಇತರ. ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಈ ಕೆಳಗಿನ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿದೆ:

1. ನೈಜ-ಸಮಯದ ಮೆಟ್ರಿಕ್‌ಗಳ ಹೈ-ಫ್ರೀಕ್ವೆನ್ಸಿ ಸಿಂಕ್ರೊನಸ್ ಸ್ವಾಧೀನ ಮತ್ತು ವಿಳಂಬವಿಲ್ಲದೆ ಸಂವಹನ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ ಅವುಗಳ ವರ್ಗಾವಣೆ.
   ವಿವಿಧ ಮೆಟ್ರಿಕ್‌ಗಳ ಹೆಚ್ಚಿನ ಆವರ್ತನ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮುಖ್ಯವಲ್ಲ, ಡೇಟಾ ಟ್ರಾನ್ಸ್‌ಮಿಷನ್ ಚಾನಲ್‌ಗಳ ಎಂಟ್ರೊಪಿಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಇದು ಅತ್ಯಗತ್ಯ. ಒಂದು ಡೇಟಾ ಪ್ರಸರಣ ಚಾನಲ್‌ನಲ್ಲಿ ಸರಾಸರಿ ವಿಳಂಬವು 30 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಾಗಿದ್ದರೆ, ಕೇವಲ ಒಂದು ಮಿಲಿಸೆಕೆಂಡ್‌ನ ಉಳಿದ ಮೆಟ್ರಿಕ್‌ಗಳ ನಡುವಿನ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನಲ್ಲಿನ ದೋಷವು ಫಲಿತಾಂಶದ ಚಾನಲ್‌ನ ವೇಗವನ್ನು ಸರಿಸುಮಾರು 5% ರಷ್ಟು ಅವನತಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನಾವು 1 ಚಾನಲ್‌ಗಳಲ್ಲಿ 4 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಷ್ಟು ಸಮಯವನ್ನು ತಪ್ಪಾಗಿಸಿದರೆ, ವೇಗದ ಅವನತಿಯು ಸುಲಭವಾಗಿ 30% ಕ್ಕೆ ಇಳಿಯಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಚಾನಲ್‌ಗಳಲ್ಲಿನ ಎಂಟ್ರೊಪಿ ಬಹಳ ಬೇಗನೆ ಬದಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಪ್ರತಿ 0.5 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆ ಬಾರಿ ಅಳತೆ ಮಾಡಿದರೆ, ವೇಗದ ಚಾನಲ್‌ಗಳಲ್ಲಿ ಸಣ್ಣ ವಿಳಂಬದೊಂದಿಗೆ ನಾವು ಹೆಚ್ಚಿನ ವೇಗದ ಅವನತಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಸಹಜವಾಗಿ, ಅಂತಹ ನಿಖರತೆಯು ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಅಲ್ಲ. ಚಾನಲ್‌ನಲ್ಲಿನ ವಿಳಂಬವು 500 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಾಗಿದ್ದಾಗ ಮತ್ತು ನಾವು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, 1 ಮಿಲಿಸೆಕೆಂಡ್‌ನ ದೋಷವು ಬಹುತೇಕ ಗಮನಿಸುವುದಿಲ್ಲ. ಅಲ್ಲದೆ, ಲೈಫ್ ಸಪೋರ್ಟ್ ಸಿಸ್ಟಂ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ, ನಾವು 2 ಸೆಕೆಂಡ್‌ಗಳ ಸಾಕಷ್ಟು ಮತದಾನ ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ದರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಸ್ವತಃ ಅಲ್ಟ್ರಾ-ಹೈ ಪೋಲಿಂಗ್ ದರಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳ ಅಲ್ಟ್ರಾ-ನಿಖರವಾದ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಶಕ್ತವಾಗಿರಬೇಕು.
2. ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲ ಬಳಕೆ ಮತ್ತು ಒಂದೇ ಸ್ಟಾಕ್.
   ಅಂತಿಮ ಸಾಧನವು ರಸ್ತೆಯಲ್ಲಿನ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಅಥವಾ ಜನರ ಬಯೋಮೆಟ್ರಿಕ್ ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ನಡೆಸುವ ಶಕ್ತಿಶಾಲಿ ಆನ್-ಬೋರ್ಡ್ ಸಂಕೀರ್ಣವಾಗಿರಬಹುದು ಅಥವಾ ವೀಡಿಯೊವನ್ನು ಪ್ರಸಾರ ಮಾಡಲು ವಿಶೇಷ ಪಡೆಗಳ ಸೈನಿಕನು ತನ್ನ ದೇಹದ ರಕ್ಷಾಕವಚದ ಅಡಿಯಲ್ಲಿ ಧರಿಸಿರುವ ಪಾಮ್ ಗಾತ್ರದ ಸಿಂಗಲ್-ಬೋರ್ಡ್ ಕಂಪ್ಯೂಟರ್ ಆಗಿರಬಹುದು. ಕಳಪೆ ಸಂವಹನ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ನೈಜ ಸಮಯ. ಅಂತಹ ವೈವಿಧ್ಯಮಯ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಮತ್ತು ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಯ ಹೊರತಾಗಿಯೂ, ನಾವು ಅದೇ ಸಾಫ್ಟ್‌ವೇರ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತೇವೆ.
3. ಅಂಬ್ರೆಲಾ ಆರ್ಕಿಟೆಕ್ಚರ್
   ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅಂತಿಮ ಸಾಧನದಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸಬೇಕು, ಸ್ಥಳೀಯವಾಗಿ ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ನೈಜ ಸಮಯದಲ್ಲಿ ಮತ್ತು ಪೂರ್ವಾವಲೋಕನದಲ್ಲಿ ದೃಶ್ಯೀಕರಿಸಬೇಕು. ಸಂಪರ್ಕವಿದ್ದರೆ, ಡೇಟಾವನ್ನು ಕೇಂದ್ರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ವರ್ಗಾಯಿಸಿ. ಯಾವುದೇ ಸಂಪರ್ಕವಿಲ್ಲದಿದ್ದಾಗ, ಕಳುಹಿಸುವ ಕ್ಯೂ ಸಂಗ್ರಹಗೊಳ್ಳಬೇಕು ಮತ್ತು RAM ಅನ್ನು ಸೇವಿಸಬಾರದು.
4. ಗ್ರಾಹಕರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಏಕೀಕರಣಕ್ಕಾಗಿ API, ಏಕೆಂದರೆ ಯಾರಿಗೂ ಹೆಚ್ಚಿನ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಗ್ರಾಹಕರು ಯಾವುದೇ ಸಾಧನಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಂದ ಒಂದೇ ಮಾನಿಟರಿಂಗ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು.

ಏನಾಯಿತು

ಈಗಾಗಲೇ ಪ್ರಭಾವಶಾಲಿ ದೀರ್ಘ ಓದುವಿಕೆಗೆ ಹೊರೆಯಾಗದಂತೆ, ನಾನು ಎಲ್ಲಾ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳ ಉದಾಹರಣೆಗಳು ಮತ್ತು ಅಳತೆಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ. ಇದು ಮತ್ತೊಂದು ಲೇಖನಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. 1 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಿಂತ ಕಡಿಮೆ ದೋಷದೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ ಮತ್ತು ಅದು 64 MB RAM ಜೊತೆಗೆ ARM ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಮತ್ತು 86 ನೊಂದಿಗೆ x64_32 ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಸಮಾನವಾಗಿ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. GB RAM. ಆದ್ದರಿಂದ, ನಾವು ನಮ್ಮದೇ ಆದದನ್ನು ಬರೆಯಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಅದು ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು. ನಮಗೆ ಸಿಕ್ಕಿದ್ದು ಇಲ್ಲಿದೆ:

ವಿಭಿನ್ನ ನೆಟ್‌ವರ್ಕ್ ಟೋಪೋಲಜಿಗಳಿಗಾಗಿ ಮೂರು ಚಾನಲ್‌ಗಳ ಥ್ರೋಪುಟ್ ಅನ್ನು ಸಾರಾಂಶಗೊಳಿಸುವುದು

ಕೆಲವು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳ ದೃಶ್ಯೀಕರಣ

ವಾಸ್ತುಶಿಲ್ಪ

ನಾವು ಸಾಧನದಲ್ಲಿ ಮತ್ತು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಗೋಲಾಂಗ್ ಅನ್ನು ಮುಖ್ಯ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಾಗಿ ಬಳಸುತ್ತೇವೆ. ಇದು ಬಹುಕಾರ್ಯಕಗಳ ಅನುಷ್ಠಾನ ಮತ್ತು ಪ್ರತಿ ಸೇವೆಗೆ ಸ್ಥಿರವಾಗಿ ಲಿಂಕ್ ಮಾಡಲಾದ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಬೈನರಿ ಫೈಲ್ ಅನ್ನು ಪಡೆಯುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಿತು. ಪರಿಣಾಮವಾಗಿ, ಸಾಧನಗಳನ್ನು ಅಂತ್ಯಗೊಳಿಸಲು, ಅಭಿವೃದ್ಧಿ ಸಮಯ ಮತ್ತು ಕೋಡ್ ಡೀಬಗ್ ಮಾಡಲು ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸಲು ನಾವು ಸಂಪನ್ಮೂಲಗಳು, ವಿಧಾನಗಳು ಮತ್ತು ದಟ್ಟಣೆಯಲ್ಲಿ ಗಮನಾರ್ಹವಾಗಿ ಉಳಿಸುತ್ತೇವೆ.

ಕ್ಲಾಸಿಕ್ ಮಾಡ್ಯುಲರ್ ತತ್ವದ ಪ್ರಕಾರ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹಲವಾರು ಉಪವ್ಯವಸ್ಥೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

1. ಮೆಟ್ರಿಕ್ಸ್ ನೋಂದಣಿ.
   ಪ್ರತಿಯೊಂದು ಮೆಟ್ರಿಕ್ ತನ್ನದೇ ಆದ ಥ್ರೆಡ್‌ನಿಂದ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಚಾನಲ್‌ಗಳಾದ್ಯಂತ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ. ನಾವು 10 ನ್ಯಾನೊಸೆಕೆಂಡ್‌ಗಳವರೆಗೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ನಿಖರತೆಯನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಯಿತು.
2. ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣೆ
   ಸಮಯ ಸರಣಿಗಾಗಿ ನಮ್ಮ ಸ್ವಂತ ಸಂಗ್ರಹಣೆಯನ್ನು ಬರೆಯುವುದು ಅಥವಾ ಈಗಾಗಲೇ ಲಭ್ಯವಿರುವ ಯಾವುದನ್ನಾದರೂ ಬಳಸುವುದನ್ನು ನಾವು ಆರಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ನಂತರದ ದೃಶ್ಯೀಕರಣಕ್ಕೆ ಒಳಪಟ್ಟಿರುವ ರೆಟ್ರೋಸ್ಪೆಕ್ಟಿವ್ ಡೇಟಾಗೆ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿದೆ. ಅಂದರೆ, ಇದು ಪ್ರತಿ 0.5 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಚಾನಲ್‌ನಲ್ಲಿನ ವಿಳಂಬ ಅಥವಾ ಸಾರಿಗೆ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ದೋಷ ರೀಡಿಂಗ್‌ಗಳ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರತಿ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಪ್ರತಿ 500 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ವೇಗವಿರುತ್ತದೆ. ಕ್ರಾಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಕಡಿಮೆ ಸಂಪನ್ಮೂಲ ಬಳಕೆಗೆ ಹೆಚ್ಚಿನ ಅವಶ್ಯಕತೆಗಳ ಜೊತೆಗೆ, ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗುವುದು ಬಹಳ ಮುಖ್ಯ. ಡೇಟಾವನ್ನು ಎಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಇದು ಅಗಾಧವಾದ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸುತ್ತದೆ. ನಾವು 2016 ರಿಂದ ಈ ಯೋಜನೆಯಲ್ಲಿ Tarantool DBMS ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ ನಾವು ಹಾರಿಜಾನ್‌ನಲ್ಲಿ ಅದರ ಬದಲಿಯನ್ನು ಕಾಣುತ್ತಿಲ್ಲ. ಹೊಂದಿಕೊಳ್ಳುವ, ಸೂಕ್ತವಾದ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯೊಂದಿಗೆ, ಸಾಕಷ್ಟು ತಾಂತ್ರಿಕ ಬೆಂಬಲಕ್ಕಿಂತ ಹೆಚ್ಚು. Tarantool ಸಹ GIS ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಅಳವಡಿಸುತ್ತದೆ. ಸಹಜವಾಗಿ, ಇದು ಪೋಸ್ಟ್‌ಜಿಐಎಸ್‌ನಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿಲ್ಲ, ಆದರೆ ಕೆಲವು ಸ್ಥಳ-ಸಂಬಂಧಿತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು (ಸಾರಿಗೆಗೆ ಸಂಬಂಧಿಸಿದ) ಸಂಗ್ರಹಿಸುವ ನಮ್ಮ ಕಾರ್ಯಗಳಿಗೆ ಇದು ಸಾಕಾಗುತ್ತದೆ.
3. ಮೆಟ್ರಿಕ್‌ಗಳ ದೃಶ್ಯೀಕರಣ
   ಇಲ್ಲಿ ಎಲ್ಲವೂ ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿದೆ. ನಾವು ಗೋದಾಮಿನಿಂದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ನೈಜ ಸಮಯದಲ್ಲಿ ಅಥವಾ ಹಿಂದಿನದನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತೇವೆ.
4. ಕೇಂದ್ರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಡೇಟಾದ ಸಿಂಕ್ರೊನೈಸೇಶನ್.
   ಕೇಂದ್ರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಎಲ್ಲಾ ಸಾಧನಗಳಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಇತಿಹಾಸದೊಂದಿಗೆ ಅದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು API ಮೂಲಕ ಗ್ರಾಹಕರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಕ್ಲಾಸಿಕ್ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಂತಲ್ಲದೆ, ಇದರಲ್ಲಿ "ತಲೆ" ಸುತ್ತಲೂ ನಡೆದು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ನಾವು ವಿರುದ್ಧವಾದ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸಂಪರ್ಕವಿರುವಾಗ ಸಾಧನಗಳು ಸ್ವತಃ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತವೆ. ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ಅಂಶವಾಗಿದೆ, ಏಕೆಂದರೆ ಸಾಧನವು ಲಭ್ಯವಿಲ್ಲದ ಅವಧಿಗೆ ಸಾಧನದಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಸಾಧನವು ಲಭ್ಯವಿಲ್ಲದಿರುವಾಗ ಚಾನಲ್‌ಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ. ನಾವು ಇನ್‌ಫ್ಲಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಸರ್ವರ್ ಅನ್ನು ಕೇಂದ್ರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿ ಬಳಸುತ್ತೇವೆ. ಅದರ ಅನಲಾಗ್‌ಗಳಂತಲ್ಲದೆ, ಇದು ರೆಟ್ರೋಸ್ಪೆಕ್ಟಿವ್ ಡೇಟಾವನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳಬಹುದು (ಅಂದರೆ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ ಕ್ಷಣಕ್ಕಿಂತ ವಿಭಿನ್ನವಾದ ಸಮಯದ ಸ್ಟ್ಯಾಂಪ್‌ನೊಂದಿಗೆ). ಸಂಗ್ರಹಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಗ್ರಾಫಾನಾದಿಂದ ದೃಶ್ಯೀಕರಿಸಲಾಗುತ್ತದೆ, ಫೈಲ್‌ನೊಂದಿಗೆ ಮಾರ್ಪಡಿಸಲಾಗಿದೆ. ಈ ಪ್ರಮಾಣಿತ ಸ್ಟಾಕ್ ಅನ್ನು ಸಹ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಯಾವುದೇ ಗ್ರಾಹಕ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಸಿದ್ಧ-ಸಿದ್ಧ API ಸಂಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದೆ.
5. ಕೇಂದ್ರ ಸಾಧನ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್.
   ಸಾಧನ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯು ಝೀರೋ ಟಚ್ ಪ್ರಾವಿಶನಿಂಗ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ (ಫರ್ಮ್‌ವೇರ್, ಕಾನ್ಫಿಗರೇಶನ್, ಇತ್ಯಾದಿಗಳನ್ನು ನವೀಕರಿಸುವುದು) ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿ, ಪ್ರತಿ ಸಾಧನಕ್ಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಮಾತ್ರ ಪಡೆಯುತ್ತದೆ. ಇವುಗಳು ಆನ್-ಬೋರ್ಡ್ ಹಾರ್ಡ್‌ವೇರ್ ವಾಚ್‌ಡಾಗ್ ಸೇವೆಗಳ ಕಾರ್ಯಾಚರಣೆಗೆ ಮತ್ತು ಲೈಫ್ ಸಪೋರ್ಟ್ ಸಿಸ್ಟಮ್‌ಗಳ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಪ್ರಚೋದಕಗಳಾಗಿವೆ: ಸಿಪಿಯು ಮತ್ತು ಎಸ್‌ಎಸ್‌ಡಿ ತಾಪಮಾನ, ಸಿಪಿಯು ಲೋಡ್, ಫ್ರೀ ಸ್ಪೇಸ್ ಮತ್ತು ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಸ್ಮಾರ್ಟ್ ಆರೋಗ್ಯ. ಉಪವ್ಯವಸ್ಥೆಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಹ Tarantool ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಸಾವಿರಾರು ಸಾಧನಗಳಲ್ಲಿ ಸಮಯ ಸರಣಿಯನ್ನು ಒಟ್ಟುಗೂಡಿಸುವಲ್ಲಿ ಇದು ನಮಗೆ ಗಮನಾರ್ಹ ವೇಗವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಈ ಸಾಧನಗಳೊಂದಿಗೆ ಡೇಟಾವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸುತ್ತದೆ. ಟ್ಯಾರಂಟೂಲ್ ಅತ್ಯುತ್ತಮ ಕ್ಯೂಯಿಂಗ್ ಮತ್ತು ಗ್ಯಾರಂಟಿ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದೆ. ನಾವು ಬಾಕ್ಸ್‌ನಿಂದ ಈ ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಅದ್ಭುತವಾಗಿದೆ!

ನೆಟ್‌ವರ್ಕ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆ

ಮುಂದೆ ಏನು

ಇಲ್ಲಿಯವರೆಗೆ, ನಮ್ಮ ದುರ್ಬಲ ಲಿಂಕ್ ಕೇಂದ್ರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಇದನ್ನು ಪ್ರಮಾಣಿತ ಸ್ಟಾಕ್‌ನಲ್ಲಿ 99.9% ಅಳವಡಿಸಲಾಗಿದೆ ಮತ್ತು ಹಲವಾರು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ:

1. ವಿದ್ಯುತ್ ಕಳೆದುಹೋದಾಗ InfluxDB ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ನಿಯಮದಂತೆ, ಗ್ರಾಹಕರು ಸಾಧನಗಳಿಂದ ಬರುವ ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸ್ವತಃ 5 ನಿಮಿಷಗಳಿಗಿಂತ ಹಳೆಯ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ಇದು ನೋವು ಆಗಬಹುದು.
2. ಗ್ರಾಫನಾವು ಡೇಟಾ ಒಟ್ಟುಗೂಡುವಿಕೆ ಮತ್ತು ಅದರ ಪ್ರದರ್ಶನದ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನೊಂದಿಗೆ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಡೇಟಾಬೇಸ್ 2:00:00 ರಿಂದ ಪ್ರಾರಂಭವಾಗುವ 00 ಸೆಕೆಂಡುಗಳ ಮಧ್ಯಂತರದೊಂದಿಗೆ ಸಮಯ ಸರಣಿಯನ್ನು ಹೊಂದಿರುವಾಗ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯಾಗಿದೆ ಮತ್ತು ಗ್ರಾಫನಾ +1 ಸೆಕೆಂಡ್‌ನಿಂದ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ತೋರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಬಳಕೆದಾರರು ನೃತ್ಯ ಗ್ರಾಫ್ ಅನ್ನು ನೋಡುತ್ತಾರೆ.
3. ಥರ್ಡ್-ಪಾರ್ಟಿ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ API ಏಕೀಕರಣಕ್ಕಾಗಿ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಕೋಡ್. ಇದನ್ನು ಹೆಚ್ಚು ಕಾಂಪ್ಯಾಕ್ಟ್ ಮಾಡಬಹುದು ಮತ್ತು ಸಹಜವಾಗಿ ಗೋದಲ್ಲಿ ಪುನಃ ಬರೆಯಬಹುದು)

ಗ್ರಾಫನಾ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವೆಲ್ಲರೂ ಸಂಪೂರ್ಣವಾಗಿ ನೋಡಿದ್ದೀರಿ ಮತ್ತು ನಾನು ಇಲ್ಲದೆ ಅದರ ಸಮಸ್ಯೆಗಳನ್ನು ತಿಳಿದಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದ್ದರಿಂದ ನಾನು ಚಿತ್ರಗಳೊಂದಿಗೆ ಪೋಸ್ಟ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ.

ತೀರ್ಮಾನಕ್ಕೆ

ನಾನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ವಿವರಿಸಲಿಲ್ಲ, ಆದರೆ ಈ ವ್ಯವಸ್ಥೆಯ ಮೂಲ ವಿನ್ಯಾಸವನ್ನು ಮಾತ್ರ ವಿವರಿಸಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಸಿಸ್ಟಮ್ ಅನ್ನು ತಾಂತ್ರಿಕವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸಲು, ಇನ್ನೊಂದು ಲೇಖನದ ಅಗತ್ಯವಿದೆ. ಎರಡನೆಯದಾಗಿ, ಪ್ರತಿಯೊಬ್ಬರೂ ಇದರಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವುದಿಲ್ಲ. ನೀವು ಯಾವ ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ತಿಳಿಯಲು ಬಯಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ.

ಈ ಲೇಖನದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿ ಯಾರಾದರೂ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ನನಗೆ a.rodin @ qedr.com ನಲ್ಲಿ ಬರೆಯಬಹುದು

ಮೂಲ: www.habr.com