ಸೇವೆಯಾಗಿ ಮಾನಿಟರಿಂಗ್: ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ ಮಾಡ್ಯುಲರ್ ಸಿಸ್ಟಮ್

ಇಂದು, ಏಕಶಿಲೆಯ ಕೋಡ್ ಜೊತೆಗೆ, ನಮ್ಮ ಯೋಜನೆಯು ಡಜನ್ಗಟ್ಟಲೆ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಅಗತ್ಯವಿದೆ. DevOps ಇಂಜಿನಿಯರ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅಂತಹ ಪ್ರಮಾಣದಲ್ಲಿ ಇದನ್ನು ಮಾಡುವುದು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸೇವೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ಅವರು ಸ್ವತಂತ್ರವಾಗಿ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬರೆಯಬಹುದು, ಅವುಗಳನ್ನು ಬಳಸಬಹುದು, ಅವುಗಳ ಆಧಾರದ ಮೇಲೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು ಮತ್ತು ಮಿತಿ ಮೌಲ್ಯಗಳನ್ನು ತಲುಪಿದಾಗ ಅವುಗಳಿಗೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಲಗತ್ತಿಸಬಹುದು. DevOps ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ, ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ದಾಖಲಾತಿ ಮಾತ್ರ.

ಈ ಪೋಸ್ಟ್ ನಮ್ಮೊಂದಿಗೆ ನನ್ನ ಭಾಷಣದ ಪ್ರತಿಲಿಪಿಯಾಗಿದೆ ವಿಭಾಗಗಳು RIT++ ನಲ್ಲಿ. ಅಲ್ಲಿಂದ ವರದಿಗಳ ಪಠ್ಯ ಆವೃತ್ತಿಗಳನ್ನು ಮಾಡಲು ಅನೇಕ ಜನರು ನಮ್ಮನ್ನು ಕೇಳಿದರು. ನೀವು ಕಾನ್ಫರೆನ್ಸ್‌ನಲ್ಲಿದ್ದರೆ ಅಥವಾ ವೀಡಿಯೊವನ್ನು ವೀಕ್ಷಿಸಿದ್ದರೆ, ನಿಮಗೆ ಹೊಸದೇನೂ ಕಂಡುಬರುವುದಿಲ್ಲ. ಮತ್ತು ಎಲ್ಲರೂ - ಬೆಕ್ಕಿಗೆ ಸ್ವಾಗತ. ಅಂತಹ ವ್ಯವಸ್ಥೆಗೆ ನಾವು ಹೇಗೆ ಬಂದಿದ್ದೇವೆ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನವೀಕರಿಸಲು ನಾವು ಹೇಗೆ ಯೋಜಿಸುತ್ತೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ಹಿಂದಿನದು: ಯೋಜನೆಗಳು ಮತ್ತು ಯೋಜನೆಗಳು

ಪ್ರಸ್ತುತ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ನಾವು ಹೇಗೆ ಬಂದೆವು? ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು, ನೀವು 2015 ಕ್ಕೆ ಹೋಗಬೇಕು. ಆಗ ಅದು ಹೇಗಿತ್ತು:

ನಾವು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಸುಮಾರು 24 ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ವಿಭಿನ್ನ ಕಿರೀಟಗಳು, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಡೀಮನ್‌ಗಳ ಸಂಪೂರ್ಣ ಪ್ಯಾಕ್ ಇದೆ, ಅದು ಹೇಗಾದರೂ ಏನನ್ನಾದರೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ, ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ನಾವು ಮುಂದೆ ಹೋದಂತೆ ಅಂತಹ ವ್ಯವಸ್ಥೆಯು ಕಡಿಮೆ ಕಾರ್ಯಸಾಧ್ಯವಾಗಿರುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೇವೆ. ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ: ಇದು ತುಂಬಾ ತೊಡಕಾಗಿದೆ.
ನಾವು ಇರಿಸಿಕೊಳ್ಳುವ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ನಾವು ತ್ಯಜಿಸುವ ಆ ಮೇಲ್ವಿಚಾರಣಾ ಅಂಶಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಅವುಗಳಲ್ಲಿ 19 ಇದ್ದವು. ಗ್ರ್ಯಾಫೈಟ್‌ಗಳು, ಅಗ್ರಿಗೇಟರ್‌ಗಳು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಂತೆ ಗ್ರಾಫನಾ ಮಾತ್ರ ಉಳಿದಿದೆ. ಆದರೆ ಹೊಸ ವ್ಯವಸ್ಥೆ ಹೇಗಿರಲಿದೆ? ಹೀಗೆ:

ನಾವು ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಇವು ಗ್ರ್ಯಾಫೈಟ್‌ಗಳಾಗಿವೆ, ಇದು ವೇಗದ SSD ಡ್ರೈವ್‌ಗಳನ್ನು ಆಧರಿಸಿರುತ್ತದೆ, ಇವುಗಳು ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ಕೆಲವು ಸಂಗ್ರಾಹಕಗಳಾಗಿವೆ. ಮುಂದೆ - ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಗ್ರಾಫನಾ ಮತ್ತು ಎಚ್ಚರಿಕೆಗಾಗಿ ಮೊಯಿರಾ. ನಾವು ವೈಪರೀತ್ಯಗಳನ್ನು ಹುಡುಕುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬಯಸಿದ್ದೇವೆ.

ಪ್ರಮಾಣಿತ: ಮಾನಿಟರಿಂಗ್ 2.0

2015 ರಲ್ಲಿ ಯೋಜನೆಗಳು ಹೇಗಿದ್ದವು. ಆದರೆ ನಾವು ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಸೇವೆಯನ್ನು ಮಾತ್ರವಲ್ಲ, ಅದಕ್ಕೆ ದಾಖಲಾತಿಯನ್ನೂ ಸಿದ್ಧಪಡಿಸಬೇಕಾಗಿತ್ತು. ನಾವು ನಮಗಾಗಿ ಕಾರ್ಪೊರೇಟ್ ಮಾನದಂಡವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಮಾನಿಟರಿಂಗ್ 2.0 ಎಂದು ಕರೆಯುತ್ತೇವೆ. ವ್ಯವಸ್ಥೆಯ ಅವಶ್ಯಕತೆಗಳು ಯಾವುವು?

• ನಿರಂತರ ಲಭ್ಯತೆ;
• ಮೆಟ್ರಿಕ್ಸ್ ಶೇಖರಣಾ ಮಧ್ಯಂತರ = 10 ಸೆಕೆಂಡುಗಳು;
• ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳ ರಚನಾತ್ಮಕ ಸಂಗ್ರಹಣೆ;
• SLA > 99,99%
• ಯುಡಿಪಿ (!) ಮೂಲಕ ಈವೆಂಟ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹಣೆ

ನಮಗೆ UDP ಅಗತ್ಯವಿದೆ ಏಕೆಂದರೆ ನಾವು ಟ್ರಾಫಿಕ್ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಈವೆಂಟ್‌ಗಳ ದೊಡ್ಡ ಹರಿವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನೀವು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಬಾರಿಗೆ ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಬರೆದರೆ, ಸಂಗ್ರಹವು ಕುಸಿಯುತ್ತದೆ. ನಾವು ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಮೊದಲ ಹಂತದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಸಹ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ.

ಪ್ರತಿಯೊಂದು ಪೂರ್ವಪ್ರತ್ಯಯವು ಕೆಲವು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ. ಸರ್ವರ್‌ಗಳು, ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಕಂಟೈನರ್‌ಗಳು, ಸಂಪನ್ಮೂಲಗಳು, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇತ್ಯಾದಿಗಳಿಗೆ ಮೆಟ್ರಿಕ್‌ಗಳಿವೆ. ಸ್ಪಷ್ಟ, ಕಟ್ಟುನಿಟ್ಟಾದ, ಟೈಪ್ ಮಾಡಿದ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಅಳವಡಿಸಲಾಗಿದೆ, ಅಲ್ಲಿ ನಾವು ಮೊದಲ ಹಂತದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಉಳಿದವುಗಳನ್ನು ಸರಳವಾಗಿ ಬಿಡುತ್ತೇವೆ. ನಾವು 2015 ರಲ್ಲಿ ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಗೆ ಯೋಜಿಸಿದ್ದೇವೆ. ವರ್ತಮಾನದಲ್ಲಿ ಏನಿದೆ?

ಪ್ರಸ್ತುತ: ಮಾನಿಟರಿಂಗ್ ಘಟಕಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ರೇಖಾಚಿತ್ರ

ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ: ನಮ್ಮ PHP ಕೋಡ್, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಮೈಕ್ರೊ ಸರ್ವೀಸ್ - ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ಬರೆಯುವ ಎಲ್ಲವೂ. ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು UDP ಮೂಲಕ ಬ್ರೂಬೆಕ್ ಅಗ್ರಿಗೇಟರ್‌ಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತವೆ (statsd, C ನಲ್ಲಿ ಪುನಃ ಬರೆಯಲಾಗಿದೆ). ಸಂಶ್ಲೇಷಿತ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಇದು ಅತ್ಯಂತ ವೇಗವಾಗಿ ಹೊರಹೊಮ್ಮಿತು. ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಒಟ್ಟುಗೂಡಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು TCP ಮೂಲಕ ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ.

ಇದು ಟೈಮರ್‌ಗಳೆಂಬ ಮೆಟ್ರಿಕ್‌ಗಳ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿದೆ. ಇದು ತುಂಬಾ ಅನುಕೂಲಕರ ವಿಷಯ. ಉದಾಹರಣೆಗೆ, ಸೇವೆಗೆ ಪ್ರತಿ ಬಳಕೆದಾರರ ಸಂಪರ್ಕಕ್ಕಾಗಿ, ನೀವು ಬ್ರೂಬೆಕ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯದೊಂದಿಗೆ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ. ಒಂದು ಮಿಲಿಯನ್ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಬಂದವು, ಆದರೆ ಸಂಗ್ರಾಹಕವು ಕೇವಲ 10 ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿದೆ. ನೀವು ಬಂದ ಜನರ ಸಂಖ್ಯೆ, ಗರಿಷ್ಠ, ಕನಿಷ್ಠ ಮತ್ತು ಸರಾಸರಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ, ಸರಾಸರಿ ಮತ್ತು 4 ಶೇಕಡಾವಾರುಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ನಂತರ ಡೇಟಾವನ್ನು ಗ್ರ್ಯಾಫೈಟ್ಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಾವು ಎಲ್ಲವನ್ನೂ ಲೈವ್ ಆಗಿ ನೋಡುತ್ತೇವೆ.

ನಾವು ಹಾರ್ಡ್‌ವೇರ್, ಸಾಫ್ಟ್‌ವೇರ್, ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ನಮ್ಮ ಹಳೆಯ ಮುನಿನ್ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ (ಇದು 2015 ರವರೆಗೆ ನಮಗೆ ಕೆಲಸ ಮಾಡಿದೆ) ಮೇಲಿನ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯನ್ನು ಸಹ ಹೊಂದಿದ್ದೇವೆ. C's CollectD ಡೀಮನ್ ಮೂಲಕ ನಾವು ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ (ಇದು ವಿಭಿನ್ನ ಪ್ಲಗ್‌ಇನ್‌ಗಳ ಸಂಪೂರ್ಣ ಗುಂಪನ್ನು ಹೊಂದಿದೆ, ಇದು ಸ್ಥಾಪಿಸಲಾದ ಹೋಸ್ಟ್ ಸಿಸ್ಟಮ್‌ನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪೋಲ್ ಮಾಡಬಹುದು, ಡೇಟಾವನ್ನು ಎಲ್ಲಿ ಬರೆಯಬೇಕೆಂದು ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿ) ಮತ್ತು ಅದರ ಮೂಲಕ ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯಿರಿ. ಇದು ಪೈಥಾನ್ ಪ್ಲಗಿನ್‌ಗಳು ಮತ್ತು ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಕಸ್ಟಮ್ ಪರಿಹಾರಗಳನ್ನು ಬರೆಯಬಹುದು: CollectD ಈ ಡೇಟಾವನ್ನು ಸ್ಥಳೀಯ ಅಥವಾ ರಿಮೋಟ್ ಹೋಸ್ಟ್‌ನಿಂದ ಸಂಗ್ರಹಿಸುತ್ತದೆ (ಕರ್ಲ್ ಅನ್ನು ಊಹಿಸಿ) ಮತ್ತು ಅದನ್ನು ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ.

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

ಕಾರ್ಬನ್-ಸಿ-ರಿಲೇ ನಂತರ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಗ್ರ್ಯಾಫೈಟ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳ ಮುಖ್ಯ ಸಂಗ್ರಹಣೆಯಾಗಿ Go ನಲ್ಲಿ ಪುನಃ ಬರೆಯಲಾದ ಕಾರ್ಬನ್-ಸಂಗ್ರಹವನ್ನು ಬಳಸುತ್ತೇವೆ. ಗೋ-ಕಾರ್ಬನ್, ಅದರ ಮಲ್ಟಿಥ್ರೆಡಿಂಗ್‌ನಿಂದಾಗಿ, ಕಾರ್ಬನ್-ಸಂಗ್ರಹವನ್ನು ಮೀರಿಸುತ್ತದೆ. ಇದು ದತ್ತಾಂಶವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಪಿಸುಮಾತು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡಿಸ್ಕ್‌ಗಳಿಗೆ ಬರೆಯುತ್ತದೆ (ಪ್ರಮಾಣಿತ, ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ). ನಮ್ಮ ಸಂಗ್ರಹಣೆಗಳಿಂದ ಡೇಟಾವನ್ನು ಓದಲು, ನಾವು ಗ್ರ್ಯಾಫೈಟ್ API ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಪ್ರಮಾಣಿತ ಗ್ರ್ಯಾಫೈಟ್ ವೆಬ್‌ಗಿಂತ ಹೆಚ್ಚು ವೇಗವಾಗಿದೆ. ಮುಂದಿನ ಡೇಟಾಗೆ ಏನಾಗುತ್ತದೆ?

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

ಮುಂದೆ ಹೋಗೋಣ: ಎಚ್ಚರಿಕೆ. ಇದು ಬಲವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಆಯೋಜಿಸಲಾಗಿದೆ - ಮೊಯಿರಾ. ಇದು ಸ್ವತಂತ್ರವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಹುಡ್ ಅಡಿಯಲ್ಲಿ ತನ್ನದೇ ಆದ ಗ್ರ್ಯಾಫೈಟ್ ಅನ್ನು ಹೊಂದಿದೆ. SKB "ಕೊಂಟೂರ್" ನ ಹುಡುಗರಿಂದ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಪೈಥಾನ್ ಮತ್ತು ಗೋದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಸಂಪೂರ್ಣವಾಗಿ ತೆರೆದ ಮೂಲವಾಗಿದೆ. ಮೊಯಿರಾ ಗ್ರ್ಯಾಫೈಟ್‌ಗಳಿಗೆ ಹೋಗುವ ಅದೇ ಹರಿವನ್ನು ಪಡೆಯುತ್ತದೆ. ಕೆಲವು ಕಾರಣಗಳಿಂದ ನಿಮ್ಮ ಸಂಗ್ರಹಣೆಯು ಸತ್ತರೆ, ನಿಮ್ಮ ಎಚ್ಚರಿಕೆಯು ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ನಾವು ಮೊಯಿರಾವನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಿದ್ದೇವೆ; ಇದು ರೆಡಿಸ್ ಸರ್ವರ್‌ಗಳ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮುಖ್ಯ ಡೇಟಾಬೇಸ್‌ನಂತೆ ಬಳಸುತ್ತದೆ. ಫಲಿತಾಂಶವು ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಯಾಗಿತ್ತು. ಇದು ಮೆಟ್ರಿಕ್‌ಗಳ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಟ್ರಿಗ್ಗರ್‌ಗಳ ಪಟ್ಟಿಯೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ: ಅದರಲ್ಲಿ ಯಾವುದೇ ಉಲ್ಲೇಖಗಳಿಲ್ಲದಿದ್ದರೆ, ಅದು ಮೆಟ್ರಿಕ್ ಅನ್ನು ಬಿಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಇದು ನಿಮಿಷಕ್ಕೆ ಗಿಗಾಬೈಟ್‌ಗಳ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಜೀರ್ಣಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ನಾವು ಅದಕ್ಕೆ ಕಾರ್ಪೊರೇಟ್ LDAP ಅನ್ನು ಸಹ ಲಗತ್ತಿಸಿದ್ದೇವೆ, ಅದರ ಸಹಾಯದಿಂದ ಕಾರ್ಪೊರೇಟ್ ಸಿಸ್ಟಮ್‌ನ ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ (ಅಥವಾ ಹೊಸದಾಗಿ ರಚಿಸಲಾದ) ಟ್ರಿಗ್ಗರ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಸ್ವತಃ ಅಧಿಸೂಚನೆಗಳನ್ನು ರಚಿಸಬಹುದು. ಮೊಯಿರಾ ಗ್ರ್ಯಾಫೈಟ್ ಅನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಇದು ಅದರ ಎಲ್ಲಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ನೀವು ಮೊದಲು ಸಾಲನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಗ್ರಾಫಾನಾಗೆ ನಕಲಿಸಿ. ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೇಗೆ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ತದನಂತರ ನೀವು ಅದೇ ಸಾಲನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಮೊಯಿರಾಗೆ ನಕಲಿಸಿ. ನೀವು ಅದನ್ನು ಮಿತಿಗಳೊಂದಿಗೆ ಸ್ಥಗಿತಗೊಳಿಸಿ ಮತ್ತು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಎಚ್ಚರಿಕೆಯನ್ನು ಪಡೆಯಿರಿ. ಇದನ್ನು ಮಾಡಲು, ನಿಮಗೆ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಜ್ಞಾನದ ಅಗತ್ಯವಿಲ್ಲ. ಮೊಯಿರಾ SMS, ಇಮೇಲ್, ಜಿರಾ, ಸ್ಲಾಕ್ ಮೂಲಕ ಎಚ್ಚರಿಸಬಹುದು... ಇದು ಕಸ್ಟಮ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ. ಒಂದು ಪ್ರಚೋದಕ ಅವಳಿಗೆ ಸಂಭವಿಸಿದಾಗ, ಮತ್ತು ಅವಳು ಕಸ್ಟಮ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ಬೈನರಿಗೆ ಚಂದಾದಾರಳಾದಾಗ, ಅವಳು ಅದನ್ನು ರನ್ ಮಾಡುತ್ತಾಳೆ ಮತ್ತು ಈ ಬೈನರಿಗಾಗಿ stdin ಗೆ JSON ಅನ್ನು ಕಳುಹಿಸುತ್ತಾಳೆ. ಅದರಂತೆ, ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಂ ಅದನ್ನು ಪಾರ್ಸ್ ಮಾಡಬೇಕು. ಈ JSON ನೊಂದಿಗೆ ನೀವು ಏನು ಮಾಡುತ್ತೀರಿ ಎಂಬುದು ನಿಮಗೆ ಬಿಟ್ಟದ್ದು. ನಿಮಗೆ ಬೇಕಾದರೆ, ಅದನ್ನು ಟೆಲಿಗ್ರಾಮ್‌ಗೆ ಕಳುಹಿಸಿ, ನಿಮಗೆ ಬೇಕಾದರೆ, ಜಿರಾದಲ್ಲಿ ಕಾರ್ಯಗಳನ್ನು ತೆರೆಯಿರಿ, ಏನು ಬೇಕಾದರೂ ಮಾಡಿ.

ಎಚ್ಚರಿಕೆಗಾಗಿ ನಾವು ನಮ್ಮ ಸ್ವಂತ ಅಭಿವೃದ್ಧಿಯನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ - ಇಮಾಗೋಟ್ಯಾಗ್. ಸಾಮಾನ್ಯವಾಗಿ ಅಂಗಡಿಗಳಲ್ಲಿ ಎಲೆಕ್ಟ್ರಾನಿಕ್ ಬೆಲೆಯ ಟ್ಯಾಗ್‌ಗಳಿಗಾಗಿ ಬಳಸಲಾಗುವ ಫಲಕವನ್ನು ನಾವು ನಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ಸರಿಹೊಂದುವಂತೆ ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಅದಕ್ಕೆ ಮೊಯಿರಾದಿಂದ ಟ್ರಿಗರ್‌ಗಳನ್ನು ತಂದಿದ್ದೇವೆ. ಅವು ಯಾವ ಸ್ಥಿತಿಯಲ್ಲಿವೆ ಮತ್ತು ಅವು ಯಾವಾಗ ಸಂಭವಿಸಿದವು ಎಂಬುದನ್ನು ಇದು ಸೂಚಿಸುತ್ತದೆ. ಕೆಲವು ಅಭಿವೃದ್ಧಿ ವ್ಯಕ್ತಿಗಳು ಈ ಫಲಕದ ಪರವಾಗಿ ಸ್ಲಾಕ್ ಮತ್ತು ಇಮೇಲ್‌ನಲ್ಲಿ ಅಧಿಸೂಚನೆಗಳನ್ನು ತ್ಯಜಿಸಿದ್ದಾರೆ.

ಒಳ್ಳೆಯದು, ನಾವು ಪ್ರಗತಿಪರ ಕಂಪನಿಯಾಗಿರುವುದರಿಂದ, ನಾವು ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇವೆ. ನಾವು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ ಹೀಪ್‌ಸ್ಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಸೇರಿಸಿದ್ದೇವೆ, ಅದು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಮಾನಿಟರಿಂಗ್ ಘಟಕಗಳು

ಈ ಕಾರ್ಯಕ್ಕಾಗಿ ನಾವು ಬಳಸಿದ ಘಟಕಗಳಿಗೆ ಲಿಂಕ್‌ಗಳ ಪಟ್ಟಿ ಇಲ್ಲಿದೆ. ಅವೆಲ್ಲವೂ ಓಪನ್ ಸೋರ್ಸ್.

ಗ್ರ್ಯಾಫೈಟ್:

• ಗೋ-ಕಾರ್ಬನ್: github.com/lomik/go-carbon
• ಪಿಸುಮಾತು: github.com/graphite-project/whisper
• ಗ್ರ್ಯಾಫೈಟ್-ಎಪಿಐ: github.com/brutasse/graphite-api

ಕಾರ್ಬನ್-ಸಿ-ರಿಲೇ:

github.com/grobian/carbon-c-relay

ಬ್ರೂಬೆಕ್:

github.com/github/brubeck

ಸಂಗ್ರಹಿಸಲಾಗಿದೆ:

ಸಂಗ್ರಹಿಸಿದ.org

ಮೊಯಿರಾ:

github.com/moira-alert

ಗ್ರಾಫನಾ:

grafana.com

ಹೆಪ್ಸ್ಟರ್:

github.com/kubernetes/heapster

Статистика

ಮತ್ತು ಸಿಸ್ಟಮ್ ನಮಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ಸಂಖ್ಯೆಗಳು ಇಲ್ಲಿವೆ.

ಅಗ್ರಿಗೇಟರ್ (ಬ್ರೂಬೆಕ್)

ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಖ್ಯೆ: ~300/ಸೆಕೆಂಡು
ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಳುಹಿಸಲು ಮಧ್ಯಂತರ: 30 ಸೆಕೆಂಡು
ಸರ್ವರ್ ಸಂಪನ್ಮೂಲ ಬಳಕೆ: ~ 6% CPU (ನಾವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಸರ್ವರ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ); ~ 1 ಜಿಬಿ RAM; ~3 Mbps LAN

ಗ್ರ್ಯಾಫೈಟ್ (ಗೋ-ಕಾರ್ಬನ್)

ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಖ್ಯೆ: ~ 1 / ನಿಮಿಷ
ಮೆಟ್ರಿಕ್ಸ್ ನವೀಕರಣ ಮಧ್ಯಂತರ: 30 ಸೆಕೆಂಡು
ಮೆಟ್ರಿಕ್ಸ್ ಸ್ಟೋರೇಜ್ ಸ್ಕೀಮ್: 30ಸೆಕೆಂಡು 35ಡಿ, 5ನಿಮಿ 90ಡಿ, 10ನಿಮಿ 365ಡಿ (ದೀರ್ಘಕಾಲದವರೆಗೆ ಸೇವೆಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಿಮಗೆ ತಿಳುವಳಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ)
ಸರ್ವರ್ ಸಂಪನ್ಮೂಲ ಬಳಕೆ: ~10% CPU; ~ 20 ಜಿಬಿ RAM; ~30 Mbps LAN

ಹೊಂದಿಕೊಳ್ಳುವಿಕೆ

Avito ನಲ್ಲಿ ನಾವು ನಮ್ಮ ಮೇಲ್ವಿಚಾರಣಾ ಸೇವೆಯಲ್ಲಿ ನಮ್ಯತೆಯನ್ನು ನಿಜವಾಗಿಯೂ ಗೌರವಿಸುತ್ತೇವೆ. ಅವನು ನಿಜವಾಗಿಯೂ ಈ ರೀತಿ ಏಕೆ ತಿರುಗಿದನು? ಮೊದಲನೆಯದಾಗಿ, ಅದರ ಘಟಕಗಳು ಪರಸ್ಪರ ಬದಲಾಯಿಸಲ್ಪಡುತ್ತವೆ: ಎರಡೂ ಘಟಕಗಳು ಮತ್ತು ಅವುಗಳ ಆವೃತ್ತಿಗಳು. ಎರಡನೆಯದಾಗಿ, ಬೆಂಬಲ. ಸಂಪೂರ್ಣ ಯೋಜನೆಯು ತೆರೆದ ಮೂಲವಾಗಿರುವುದರಿಂದ, ನೀವು ಕೋಡ್ ಅನ್ನು ನೀವೇ ಸಂಪಾದಿಸಬಹುದು, ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಲಭ್ಯವಿಲ್ಲದ ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯ ಸ್ಟ್ಯಾಕ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಮುಖ್ಯವಾಗಿ ಗೋ ಮತ್ತು ಪೈಥಾನ್, ಆದ್ದರಿಂದ ಇದನ್ನು ಸರಳವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ.

ನಿಜವಾದ ಸಮಸ್ಯೆಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ. ಗ್ರ್ಯಾಫೈಟ್‌ನಲ್ಲಿ ಮೆಟ್ರಿಕ್ ಒಂದು ಫೈಲ್ ಆಗಿದೆ. ಅದಕ್ಕೊಂದು ಹೆಸರಿದೆ. ಫೈಲ್ ಹೆಸರು = ಮೆಟ್ರಿಕ್ ಹೆಸರು. ಮತ್ತು ಅಲ್ಲಿಗೆ ಹೋಗಲು ಒಂದು ಮಾರ್ಗವಿದೆ. Linux ನಲ್ಲಿ ಫೈಲ್ ಹೆಸರುಗಳು 255 ಅಕ್ಷರಗಳಿಗೆ ಸೀಮಿತವಾಗಿವೆ. ಮತ್ತು ನಾವು ಡೇಟಾಬೇಸ್ ವಿಭಾಗದಿಂದ ("ಆಂತರಿಕ ಗ್ರಾಹಕರು") ಹುಡುಗರನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅವರು ನಮಗೆ ಹೇಳುತ್ತಾರೆ: “ನಾವು ನಮ್ಮ SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ಮತ್ತು ಅವು 255 ಅಕ್ಷರಗಳಲ್ಲ, ಆದರೆ ಪ್ರತಿಯೊಂದೂ 8 MB. ನಾವು ಅವುಗಳನ್ನು ಗ್ರಾಫನಾದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲು ಬಯಸುತ್ತೇವೆ, ಈ ವಿನಂತಿಗಾಗಿ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನೋಡಿ, ಮತ್ತು ಇನ್ನೂ ಉತ್ತಮವಾಗಿ, ನಾವು ಅಂತಹ ವಿನಂತಿಗಳ ಮೇಲ್ಭಾಗವನ್ನು ನೋಡಲು ಬಯಸುತ್ತೇವೆ. ಅದನ್ನು ನೈಜ ಸಮಯದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಿದರೆ ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ಅವರನ್ನು ಎಚ್ಚರಿಕೆಯಲ್ಲಿ ಇರಿಸಲು ಇದು ನಿಜವಾಗಿಯೂ ತಂಪಾಗಿರುತ್ತದೆ.

SQL ಪ್ರಶ್ನೆಯ ಉದಾಹರಣೆಯನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಸೈಟ್ postgrespro.ru

ನಾವು ರೆಡಿಸ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಸಂಗ್ರಹಿಸಿದ ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಅದು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಗ್ರ್ಯಾಫೈಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಆದರೆ ನಾವು ಮೆಟ್ರಿಕ್ ಹೆಸರನ್ನು ಹ್ಯಾಶ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ. ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಅದೇ ಹ್ಯಾಶ್ ಅನ್ನು Redis ಗೆ ಕೀಲಿಯಾಗಿ ಮತ್ತು ಸಂಪೂರ್ಣ SQL ಪ್ರಶ್ನೆಯನ್ನು ಮೌಲ್ಯವಾಗಿ ಕಳುಹಿಸುತ್ತೇವೆ. ನಾವು ಮಾಡಬೇಕಾಗಿರುವುದು ಗ್ರಾಫನಾ ರೆಡಿಸ್‌ಗೆ ಹೋಗಿ ಈ ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದೆಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು. ನಾವು ಗ್ರ್ಯಾಫೈಟ್ API ಅನ್ನು ತೆರೆಯುತ್ತಿದ್ದೇವೆ ಏಕೆಂದರೆ... ಗ್ರ್ಯಾಫೈಟ್‌ನೊಂದಿಗಿನ ಎಲ್ಲಾ ಮಾನಿಟರಿಂಗ್ ಘಟಕಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಗೆ ಇದು ಮುಖ್ಯ ಇಂಟರ್ಫೇಸ್ ಆಗಿದೆ, ಮತ್ತು ನಾವು ಅಲ್ಲಿ ಅಲಿಯಾಸ್‌ಬೈಹ್ಯಾಶ್ () ಎಂಬ ಹೊಸ ಕಾರ್ಯವನ್ನು ನಮೂದಿಸುತ್ತೇವೆ - ಗ್ರಾಫಾನಾದಿಂದ ನಾವು ಮೆಟ್ರಿಕ್‌ನ ಹೆಸರನ್ನು ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ರೆಡಿಸ್‌ಗೆ ಕೀಲಿಯಾಗಿ ವಿನಂತಿಯಲ್ಲಿ ಬಳಸುತ್ತೇವೆ. ಪ್ರತಿಕ್ರಿಯೆ ನಾವು ಕೀಲಿಯ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಅದು ನಮ್ಮ "SQL ಪ್ರಶ್ನೆ" " ಹೀಗಾಗಿ, ನಾವು SQL ಪ್ರಶ್ನೆಯ ಪ್ರದರ್ಶನವನ್ನು ಗ್ರಾಫಾನಾದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಿದ್ದೇವೆ, ಸಿದ್ಧಾಂತದಲ್ಲಿ ಅದರ ಮೇಲಿನ ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ (ಕರೆಗಳು, ಸಾಲುಗಳು, ಒಟ್ಟು_ಸಮಯ, ...) ಪ್ರದರ್ಶಿಸಲು ಅಸಾಧ್ಯವಾಗಿತ್ತು.

ಫಲಿತಾಂಶಗಳು

ಲಭ್ಯತೆ ನಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಸೇವೆಯು ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಯಾವುದೇ ಕೋಡ್‌ನಿಂದ 24/7 ಲಭ್ಯವಿದೆ. ನೀವು ಶೇಖರಣಾ ಸೌಲಭ್ಯಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಸೇವೆಗೆ ಡೇಟಾವನ್ನು ಬರೆಯಬಹುದು. ಭಾಷೆ ಮುಖ್ಯವಲ್ಲ, ನಿರ್ಧಾರಗಳು ಮುಖ್ಯವಲ್ಲ. ಸಾಕೆಟ್ ಅನ್ನು ಹೇಗೆ ತೆರೆಯುವುದು, ಅಲ್ಲಿ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಹಾಕುವುದು ಮತ್ತು ಸಾಕೆಟ್ ಅನ್ನು ಮುಚ್ಚುವುದು ಹೇಗೆ ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು.

ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಲ್ಲಾ ಘಟಕಗಳು ದೋಷ-ಸಹಿಷ್ಣು ಮತ್ತು ನಮ್ಮ ಹೊರೆಗಳನ್ನು ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸುತ್ತವೆ.

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

ಸ್ವಾತಂತ್ರ್ಯ. DevOps ಇಂಜಿನಿಯರ್‌ಗಳ ಸಹಾಯವಿಲ್ಲದೆ ನೀವು ಎಲ್ಲವನ್ನೂ ನೀವೇ ಮಾಡಬಹುದು. ಮತ್ತು ಇದು ಒಂದು ಪ್ರಯೋಜನವಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಇದೀಗ ನಿಮ್ಮ ಯೋಜನೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು, ನೀವು ಯಾರನ್ನೂ ಕೇಳಬೇಕಾಗಿಲ್ಲ - ಕೆಲಸವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅಥವಾ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು.

ನಾವು ಏನು ಗುರಿ ಹೊಂದಿದ್ದೇವೆ?

ಕೆಳಗೆ ಪಟ್ಟಿ ಮಾಡಲಾದ ಎಲ್ಲವೂ ಕೇವಲ ಅಮೂರ್ತ ಆಲೋಚನೆಗಳಲ್ಲ, ಆದರೆ ಕನಿಷ್ಠ ಮೊದಲ ಹೆಜ್ಜೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ.

1. ಅಸಂಗತತೆ ಪತ್ತೆಕಾರಕ. ನಾವು ನಮ್ಮ ಗ್ರ್ಯಾಫೈಟ್ ಸಂಗ್ರಹಣೆಗಳಿಗೆ ಹೋಗುವ ಸೇವೆಯನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ವಿವಿಧ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ನಾವು ವೀಕ್ಷಿಸಲು ಬಯಸುವ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಈಗಾಗಲೇ ಇವೆ, ಡೇಟಾ ಇದೆ, ಅದರೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ನಮಗೆ ತಿಳಿದಿದೆ.
2. ಮೆಟಾಡೇಟಾ. ನಮ್ಮಲ್ಲಿ ಹಲವಾರು ಸೇವೆಗಳಿವೆ, ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಜನರಂತೆ ಅವರು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುತ್ತಾರೆ. ದಸ್ತಾವೇಜನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರಂತರವಾಗಿ ನಿರ್ವಹಿಸುವುದು ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಈಗ ನಮ್ಮ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಲ್ಲಿ ಮೆಟಾಡೇಟಾವನ್ನು ಎಂಬೆಡ್ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದವರು, ಅದು ಸಂವಹನ ನಡೆಸುವ ಭಾಷೆಗಳು, SLA ಅವಶ್ಯಕತೆಗಳು, ಎಲ್ಲಿ ಮತ್ತು ಯಾರಿಗೆ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸಬೇಕು ಎಂದು ಅದು ಹೇಳುತ್ತದೆ. ಸೇವೆಯನ್ನು ನಿಯೋಜಿಸುವಾಗ, ಎಲ್ಲಾ ಘಟಕದ ಡೇಟಾವನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ರಚಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನೀವು ಎರಡು ಲಿಂಕ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ - ಒಂದು ಟ್ರಿಗ್ಗರ್‌ಗಳಿಗೆ, ಇನ್ನೊಂದು ಗ್ರಾಫಾನಾದಲ್ಲಿ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿಗೆ.
3. ಪ್ರತಿ ಮನೆಯಲ್ಲೂ ನಿಗಾ. ಎಲ್ಲಾ ಅಭಿವರ್ಧಕರು ಅಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಬೇಕೆಂದು ನಾವು ನಂಬುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಮ್ಮ ಸಂಚಾರ ಎಲ್ಲಿದೆ, ಅದಕ್ಕೆ ಏನಾಗುತ್ತದೆ, ಅದು ಎಲ್ಲಿ ಬೀಳುತ್ತದೆ, ಅದರ ದೌರ್ಬಲ್ಯಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದನ್ನು ನೀವು ಯಾವಾಗಲೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ಏನಾದರೂ ಬಂದು ನಿಮ್ಮ ಸೇವೆಯನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಿದರೆ, ನೀವು ಅದರ ಬಗ್ಗೆ ವ್ಯವಸ್ಥಾಪಕರ ಕರೆ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ, ಆದರೆ ಎಚ್ಚರಿಕೆಯಿಂದ ಕಲಿಯುವಿರಿ ಮತ್ತು ನೀವು ತಕ್ಷಣ ಇತ್ತೀಚಿನ ಲಾಗ್‌ಗಳನ್ನು ತೆರೆಯಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ನೋಡಬಹುದು.
4. ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ. ನಮ್ಮ ಯೋಜನೆಯು ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ ಮತ್ತು ಇಂದು ಇದು ನಿಮಿಷಕ್ಕೆ ಸುಮಾರು 2 ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಒಂದು ವರ್ಷದ ಹಿಂದೆ, ಈ ಅಂಕಿ ಅಂಶವು 000 ಆಗಿತ್ತು. ಮತ್ತು ಬೆಳವಣಿಗೆಯು ಮುಂದುವರಿಯುತ್ತದೆ ಮತ್ತು ಇದರರ್ಥ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಗ್ರ್ಯಾಫೈಟ್ (ಪಿಸುಮಾತು) ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯನ್ನು ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಘಟಕಗಳ ಪರಸ್ಪರ ಬದಲಾಯಿಸುವಿಕೆಯಿಂದಾಗಿ ಈ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಸಾಕಷ್ಟು ಸಾರ್ವತ್ರಿಕವಾಗಿದೆ. ಯಾರೋ ನಿರ್ದಿಷ್ಟವಾಗಿ ಗ್ರ್ಯಾಫೈಟ್‌ಗಾಗಿ ತಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ ಮತ್ತು ನಿರಂತರವಾಗಿ ವಿಸ್ತರಿಸುತ್ತಾರೆ, ಆದರೆ ನಾವು ಬೇರೆ ಮಾರ್ಗದಲ್ಲಿ ಹೋಗಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ: ಬಳಸಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ನಮ್ಮ ಮೆಟ್ರಿಕ್‌ಗಳ ಭಂಡಾರವಾಗಿ. ಈ ಪರಿವರ್ತನೆಯು ಬಹುತೇಕ ಪೂರ್ಣಗೊಂಡಿದೆ, ಮತ್ತು ಶೀಘ್ರದಲ್ಲೇ ಇದನ್ನು ಹೇಗೆ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೇಳುತ್ತೇನೆ: ಯಾವ ತೊಂದರೆಗಳು ಇದ್ದವು ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ನಿವಾರಿಸಲಾಗಿದೆ, ವಲಸೆ ಪ್ರಕ್ರಿಯೆಯು ಹೇಗೆ ಹೋಯಿತು, ಬೈಂಡಿಂಗ್ ಮತ್ತು ಅವುಗಳ ಸಂರಚನೆಗಳಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾದ ಘಟಕಗಳನ್ನು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು! ವಿಷಯದ ಕುರಿತು ನಿಮ್ಮ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ, ನಾನು ಇಲ್ಲಿ ಅಥವಾ ಕೆಳಗಿನ ಪೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಉತ್ತರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಬಹುಶಃ ಯಾರಾದರೂ ಇದೇ ರೀತಿಯ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವ ಅನುಭವವನ್ನು ಹೊಂದಿರಬಹುದು ಅಥವಾ ಇದೇ ರೀತಿಯ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಬದಲಾಯಿಸಬಹುದು - ಅದನ್ನು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಿ.

ಮೂಲ: www.habr.com