ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಮಯ ಸರಣಿಯ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ವೇಗವಾದ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಡಿಬಿಎಂಎಸ್ ಆಗಿದೆ (ರೆಕಾರ್ಡ್ ಈ ಸಮಯಕ್ಕೆ ಅನುಗುಣವಾದ ಸಮಯ ಮತ್ತು ಮೌಲ್ಯಗಳ ಗುಂಪನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಸಂವೇದಕಗಳ ಸ್ಥಿತಿಯ ಆವರ್ತಕ ಮತದಾನದ ಮೂಲಕ ಪಡೆಯಲಾಗುತ್ತದೆ ಅಥವಾ ಮಾಪನಗಳ ಸಂಗ್ರಹ).
ನನ್ನ ಹೆಸರು ಕೊಲೊಬೇವ್ ಪಾವೆಲ್. DevOps, SRE, LeroyMerlin, ಎಲ್ಲವೂ ಕೋಡ್‌ನಂತೆ - ಇದು ನಮ್ಮ ಬಗ್ಗೆ: ನನ್ನ ಬಗ್ಗೆ ಮತ್ತು ಇತರ LeroyMerlin ಉದ್ಯೋಗಿಗಳ ಬಗ್ಗೆ.
OpenStack ಆಧಾರಿತ ಕ್ಲೌಡ್ ಇದೆ. ತಾಂತ್ರಿಕ ರಾಡಾರ್‌ಗೆ ಸಣ್ಣ ಲಿಂಕ್ ಇದೆ.
ಇದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಜೊತೆಗೆ OpenStack ಮತ್ತು ಲಾಗಿಂಗ್‌ಗಾಗಿ ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಸೇವೆಗಳಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ.
ಇದು ನಾವು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿದ್ದ ಯೋಜನೆಯಾಗಿದೆ. ನಾವು ಇದನ್ನೆಲ್ಲ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವಾಗ, K8s ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿಯೇ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ Prometheus ಆಪರೇಟರ್ ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಅವನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ಕ್ರಬ್ ಮಾಡಬೇಕಾದುದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ ಅದನ್ನು ಅವನ ಕಾಲುಗಳ ಕೆಳಗೆ ಇಡುತ್ತಾನೆ.
ನಾವು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಹೊರಗೆ ಸರಿಸಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ, ಏನು ಮತ್ತು ಎಲ್ಲಿ ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಮೊದಲ ಪರಿಹಾರವೆಂದರೆ ನಾವು ಮೂರನೇ-ಪಕ್ಷದ ಪ್ರೊಮೆಥಿಯಸ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ, ನಾವು ಫೆಡರೇಶನ್ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೋದಾಗ ನಾವು ಫೆಡರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.
ಆದರೆ ಇಲ್ಲಿ ಕೆಲವು ಸಣ್ಣ ಸಮಸ್ಯೆಗಳಿವೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು 250 ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹೊಂದಿರುವಾಗ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾದವು ಮತ್ತು 000 ಮೆಟ್ರಿಕ್‌ಗಳು ಇದ್ದಾಗ, ನಾವು ಹಾಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ನಾವು ಸ್ಕ್ರಾಪ್_ಟೈಮ್ಔಟ್ ಅನ್ನು 400 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೆಚ್ಚಿಸಿದ್ದೇವೆ.
ನಾವು ಇದನ್ನು ಏಕೆ ಮಾಡಬೇಕಾಗಿತ್ತು? ಪ್ರಮೀತಿಯಸ್ ಬೇಲಿಯ ಆರಂಭದಿಂದ ಸಮಯಾವಧಿಯನ್ನು ಎಣಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ. ಡೇಟಾ ಇನ್ನೂ ಹರಿಯುತ್ತಿದೆ ಎಂಬುದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. ಈ ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ವಿಲೀನಗೊಳಿಸದಿದ್ದರೆ ಮತ್ತು ಸೆಷನ್ ಅನ್ನು http ಮೂಲಕ ಮುಚ್ಚದಿದ್ದರೆ, ಸೆಷನ್ ವಿಫಲವಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಡೇಟಾವು ಪ್ರಮೀಥಿಯಸ್ಗೆ ಬರುವುದಿಲ್ಲ.
ಕೆಲವು ಡೇಟಾ ಕಳೆದುಹೋದಾಗ ನಾವು ಪಡೆಯುವ ಗ್ರಾಫ್‌ಗಳೊಂದಿಗೆ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಪರಿಚಿತವಾಗಿದೆ. ವೇಳಾಪಟ್ಟಿಗಳು ಹರಿದಿವೆ ಮತ್ತು ನಾವು ಇದರಿಂದ ಸಂತೋಷವಾಗಿಲ್ಲ.
ಮುಂದಿನ ಆಯ್ಕೆಯು ಒಂದೇ ಫೆಡರೇಶನ್ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಎರಡು ವಿಭಿನ್ನ ಪ್ರಮೀಥಿಯಸ್ ಅನ್ನು ಆಧರಿಸಿ ಶರ್ಡಿಂಗ್ ಆಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ಅವುಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅವುಗಳನ್ನು ಹೆಸರಿನಿಂದ ಚೂರು ಮಾಡಿ. ಇದನ್ನು ಸಹ ಬಳಸಬಹುದು, ಆದರೆ ನಾವು ಮುಂದುವರಿಯಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ನಾವು ಈಗ ಈ ಚೂರುಗಳನ್ನು ಹೇಗಾದರೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗಿದೆ. ನೀವು ಪ್ರಾಮ್ಕ್ಸಿ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಅದು ಚೂರು ಪ್ರದೇಶಕ್ಕೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಗುಣಿಸುತ್ತದೆ. ಇದು ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದುವಾಗಿ ಎರಡು ಚೂರುಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದನ್ನು ಪ್ರಾಮ್ಕ್ಸಿ ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು, ಆದರೆ ಇದು ಇನ್ನೂ ತುಂಬಾ ಕಷ್ಟ.
ಮೊದಲ ಆಯ್ಕೆಯು ನಾವು ಫೆಡರೇಶನ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ತ್ಯಜಿಸಲು ಬಯಸುತ್ತೇವೆ ಏಕೆಂದರೆ ಅದು ತುಂಬಾ ನಿಧಾನವಾಗಿದೆ.
ಪ್ರಮೀತಿಯಸ್ ಡೆವಲಪರ್‌ಗಳು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತಿದ್ದಾರೆ, "ಗೈಸ್, ವಿಭಿನ್ನ ಟೈಮ್‌ಸ್ಕೇಲ್‌ಡಿಬಿ ಬಳಸಿ ಏಕೆಂದರೆ ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳ ದೀರ್ಘಾವಧಿಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ." ಇದು ಅವರ ಕಾರ್ಯವಲ್ಲ.
ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸದಂತೆ ನಾವು ಇನ್ನೂ ಹೊರಗೆ ಇಳಿಸಬೇಕಾದ ಕಾಗದದ ಮೇಲೆ ಬರೆಯುತ್ತೇವೆ.
ಎರಡನೇ ನ್ಯೂನತೆಯೆಂದರೆ ಮೆಮೊರಿ ಬಳಕೆ. ಹೌದು, 2020 ರಲ್ಲಿ ಒಂದೆರಡು ಗಿಗಾಬೈಟ್ ಮೆಮೊರಿಗೆ ಒಂದು ಪೈಸೆ ಖರ್ಚಾಗುತ್ತದೆ ಎಂದು ಹಲವರು ಹೇಳುತ್ತಾರೆ, ಆದರೆ ಇನ್ನೂ.
ಈಗ ನಾವು dev ಮತ್ತು prod ಪರಿಸರವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ದೇವ್‌ನಲ್ಲಿ ಇದು 9 ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಸುಮಾರು 350 ಗಿಗಾಬೈಟ್ಗಳು. ಉತ್ಪನ್ನದಲ್ಲಿ ಇದು 000 ಗಿಗಾಬೈಟ್ಗಳು ಮತ್ತು 14 ಮೆಟ್ರಿಕ್‌ಗಳಿಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಧಾರಣ ಸಮಯ ಕೇವಲ 780 ನಿಮಿಷಗಳು. ಇದು ಕೆಟ್ಟದ್ದು. ಮತ್ತು ಈಗ ನಾನು ಏಕೆ ವಿವರಿಸುತ್ತೇನೆ.
ನಾವು ಲೆಕ್ಕಾಚಾರವನ್ನು ಮಾಡುತ್ತೇವೆ, ಅಂದರೆ, ಒಂದೂವರೆ ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ, ಮತ್ತು ನಾವು ಈಗಾಗಲೇ ಅವರಿಗೆ ಹತ್ತಿರವಾಗಿದ್ದೇವೆ, ವಿನ್ಯಾಸ ಹಂತದಲ್ಲಿ ನಾವು 35-37 ಗಿಗಾಬೈಟ್ ಮೆಮೊರಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಆದರೆ ಈಗಾಗಲೇ 4 ಮಿಲಿಯನ್ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಸುಮಾರು 90 ಗಿಗಾಬೈಟ್ ಮೆಮೊರಿ ಅಗತ್ಯವಿದೆ. ಅಂದರೆ, ಪ್ರಮೀತಿಯಸ್ ಡೆವಲಪರ್‌ಗಳು ಒದಗಿಸಿದ ಸೂತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗಿದೆ. ನಾವು ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ಕೇವಲ ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಸರ್ವರ್‌ಗಾಗಿ ಒಂದೆರಡು ಮಿಲಿಯನ್‌ಗಳನ್ನು ಪಾವತಿಸಲು ನಾವು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ಅರಿತುಕೊಂಡೆವು.
ನಾವು ಯಂತ್ರಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಾತ್ರ ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ, ನಾವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ಹೆಚ್ಚು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು, ವಿವಿಧ ರೀತಿಯ ಹೆಚ್ಚಿನ ಮೆಟ್ರಿಕ್‌ಗಳು, ಇತ್ಯಾದಿ. ಮೆಟ್ರಿಕ್‌ಗಳ ವಿಷಯದಲ್ಲಿ ನಾವು ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ ವಿಶೇಷ ಬೆಳವಣಿಗೆಯನ್ನು ಹೊಂದಿರುತ್ತೇವೆ.
ಡಿಸ್ಕ್ ಸ್ಥಳದೊಂದಿಗೆ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಕೆಟ್ಟದ್ದಲ್ಲ, ಆದರೆ ನಾನು ಅದನ್ನು ಸುಧಾರಿಸಲು ಬಯಸುತ್ತೇನೆ. ನಾವು 15 ದಿನಗಳಲ್ಲಿ ಒಟ್ಟು 120 ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ, ಅದರಲ್ಲಿ 100 ಸಂಕುಚಿತ ಡೇಟಾ, 20 ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾ, ಆದರೆ ನಾವು ಯಾವಾಗಲೂ ಕಡಿಮೆ ಬಯಸುತ್ತೇವೆ.
ಅಂತೆಯೇ, ನಾವು ಇನ್ನೂ ಒಂದು ಅಂಶವನ್ನು ಬರೆಯುತ್ತೇವೆ - ಇದು ಸಂಪನ್ಮೂಲಗಳ ದೊಡ್ಡ ಬಳಕೆಯಾಗಿದೆ, ನಾವು ಇನ್ನೂ ಉಳಿಸಲು ಬಯಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ನಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಕ್ಲಸ್ಟರ್ ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವುದನ್ನು ನಾವು ಬಯಸುವುದಿಲ್ಲ.
ಪ್ರಮೀತಿಯಸ್‌ನ ಮತ್ತೊಂದು ನ್ಯೂನತೆಯಿದೆ, ಅದನ್ನು ನಾವು ನಮಗಾಗಿ ಗುರುತಿಸಿದ್ದೇವೆ, ಇದು ಕನಿಷ್ಠ ಕೆಲವು ರೀತಿಯ ಮೆಮೊರಿ ಮಿತಿಯಾಗಿದೆ. ಪ್ರಮೀತಿಯಸ್ನೊಂದಿಗೆ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ಹೆಚ್ಚು ಕೆಟ್ಟದಾಗಿದೆ, ಏಕೆಂದರೆ ಅದು ಅಂತಹ ತಿರುವುಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಡಾಕರ್‌ನಲ್ಲಿ ಮಿತಿಯನ್ನು ಬಳಸುವುದು ಸಹ ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಿಮ್ಮ RAF ಬಿದ್ದರೆ ಮತ್ತು 20-30 ಗಿಗಾಬೈಟ್‌ಗಳಿದ್ದರೆ, ಅದು ಏರಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಪ್ರಮೀತಿಯಸ್ ನಮಗೆ ಸೂಕ್ತವಲ್ಲ ಎಂಬುದಕ್ಕೆ ಇದು ಮತ್ತೊಂದು ಕಾರಣವಾಗಿದೆ, ಅಂದರೆ ನಾವು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಅಂತಹ ಯೋಜನೆಯೊಂದಿಗೆ ಬರಲು ಸಾಧ್ಯವಿದೆ. HA ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಘಟಿಸಲು ನಮಗೆ ಈ ಯೋಜನೆ ಅಗತ್ಯವಿದೆ. ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೂ ಸಹ, ನಮ್ಮ ಮೆಟ್ರಿಕ್‌ಗಳು ಯಾವಾಗಲೂ ಮತ್ತು ಎಲ್ಲೆಡೆ ಲಭ್ಯವಿರಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಹೀಗಾಗಿ ನಾವು ಅಂತಹ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗಿದೆ.
ಈ ಯೋಜನೆಯು ನಾವು ಚೂರುಗಳ ನಕಲುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ವೆಚ್ಚಗಳ ನಕಲು ಮಾಡುವುದಾಗಿ ಹೇಳುತ್ತದೆ. ಇದನ್ನು ಬಹುತೇಕ ಅಡ್ಡಲಾಗಿ ಅಳೆಯಬಹುದು, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯು ನರಕಯಾತಕವಾಗಿರುತ್ತದೆ.
ಅನಾನುಕೂಲಗಳನ್ನು ನಾವು ನಮಗಾಗಿ ಬರೆದ ರೂಪದಲ್ಲಿ ಕ್ರಮವಾಗಿ:
- ಬಾಹ್ಯವಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ.
- ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲ ಬಳಕೆ.
- ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.
- HA ನ ಸಂಕೀರ್ಣ ಮತ್ತು ಸಂಪನ್ಮೂಲ-ತೀವ್ರ ಅನುಷ್ಠಾನ.
ನಮಗಾಗಿ, ನಾವು ಶೇಖರಣಾ ಸೌಲಭ್ಯವಾಗಿ ಪ್ರಮೀತಿಯಸ್‌ನಿಂದ ದೂರ ಹೋಗುತ್ತಿದ್ದೇವೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ನಮಗೆ ಅಗತ್ಯವಿರುವ ಹೆಚ್ಚುವರಿ ಅವಶ್ಯಕತೆಗಳನ್ನು ನಾವು ಗುರುತಿಸಿದ್ದೇವೆ. ಇದು:
- ಇದು promql ಬೆಂಬಲವಾಗಿದೆ, ಏಕೆಂದರೆ ಪ್ರಮೀತಿಯಸ್‌ಗಾಗಿ ಈಗಾಗಲೇ ಬಹಳಷ್ಟು ವಿಷಯಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ: ಪ್ರಶ್ನೆಗಳು, ಎಚ್ಚರಿಕೆಗಳು.
- ತದನಂತರ ನಾವು ಗ್ರಾಫಾನಾವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದು ಈಗಾಗಲೇ ಪ್ರಮೀತಿಯಸ್‌ಗೆ ಬ್ಯಾಕೆಂಡ್‌ನಂತೆ ಅದೇ ರೀತಿಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ನಾನು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಪುನಃ ಬರೆಯಲು ಬಯಸುವುದಿಲ್ಲ.
- ನಾವು ಸಾಮಾನ್ಯ HA ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಬಯಸುತ್ತೇವೆ.
- ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ.
- ಮತ್ತೊಂದು ಸಣ್ಣ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ. ನಾವು ವಿವಿಧ ರೀತಿಯ ಕ್ಲೌಡ್ ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಈ ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿ ಏನು ಬೀಳುತ್ತದೆ ಎಂಬುದು ನಮಗೆ ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ. ಮತ್ತು ಅಲ್ಲಿ ಏನು ಬೇಕಾದರೂ ಹಾರಬಲ್ಲದರಿಂದ, ನಾವು ಸ್ಥಳೀಯ ನಿಯೋಜನೆಗೆ ನಮ್ಮನ್ನು ಮಿತಿಗೊಳಿಸಬೇಕು.
ಸ್ವಲ್ಪ ಆಯ್ಕೆ ಇತ್ತು. ನಮಗೆ ಅನುಭವವಿರುವ ಎಲ್ಲವನ್ನೂ ನಾವು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. ನಾವು ಏಕೀಕರಣ ವಿಭಾಗದಲ್ಲಿ ಪ್ರಮೀತಿಯಸ್ ಪುಟವನ್ನು ನೋಡಿದ್ದೇವೆ, ಲೇಖನಗಳ ಗುಂಪನ್ನು ಓದಿದ್ದೇವೆ ಮತ್ತು ಅಲ್ಲಿ ಏನಿದೆ ಎಂದು ನೋಡಿದೆವು. ಮತ್ತು ನಮಗಾಗಿ, ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಪ್ರಮೀಥಿಯಸ್ಗೆ ಬದಲಿಯಾಗಿ ಆರಿಸಿದ್ದೇವೆ.
ಏಕೆ? ಏಕೆಂದರೆ:
- promql ಮಾಡಬಹುದು.
- ಮಾಡ್ಯುಲರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಇದೆ.
- ಗ್ರಾಫನಾಗೆ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿಲ್ಲ.
- ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ನಾವು ಬಹುಶಃ ನಮ್ಮ ಕಂಪನಿಯೊಳಗೆ ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಸೇವೆಯಾಗಿ ಒದಗಿಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ವಿವಿಧ ರೀತಿಯ ನಿರ್ಬಂಧಗಳ ಕಡೆಗೆ ಮುಂಚಿತವಾಗಿ ನೋಡುತ್ತಿದ್ದೇವೆ ಇದರಿಂದ ಬಳಕೆದಾರರು ಕ್ಲಸ್ಟರ್‌ನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕೆಲವು ಸೀಮಿತ ರೀತಿಯಲ್ಲಿ ಬಳಸಬಹುದು, ಏಕೆಂದರೆ ಅವಕಾಶವಿದೆ ಅದು ಬಹುತ್ವವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಮೊದಲ ಹೋಲಿಕೆ ಮಾಡೋಣ. ನಾವು ಕ್ಲಸ್ಟರ್ ಒಳಗೆ ಅದೇ ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಬಾಹ್ಯ ಪ್ರಮೀತಿಯಸ್ ಅದಕ್ಕೆ ಹೋಗುತ್ತಾನೆ. ರಿಮೋಟ್ ರೈಟ್ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಮೂಲಕ ಸೇರಿಸಿ.
ಇಲ್ಲಿ ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಿಂದ CPU ಬಳಕೆಯಲ್ಲಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚಳವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಎಂದು ನಾನು ತಕ್ಷಣವೇ ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ. ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ವಿಕಿ ನಿಮಗೆ ಯಾವ ನಿಯತಾಂಕಗಳು ಉತ್ತಮವೆಂದು ಹೇಳುತ್ತದೆ. ನಾವು ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ. ಅವರು ಸಿಪಿಯು ಬಳಕೆಯನ್ನು ಚೆನ್ನಾಗಿ ಕಡಿಮೆ ಮಾಡಿದ್ದಾರೆ.
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರಮೀತಿಯಸ್‌ನ ಮೆಮೊರಿ ಬಳಕೆ ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಗಲಿಲ್ಲ.
ನಾವು ಒಂದೇ ಡೇಟಾದ ಎರಡು ಡೇಟಾ ಮೂಲಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ. ಪ್ರಮೀತಿಯಸ್‌ನಲ್ಲಿ ನಾವು ಅದೇ ಕಾಣೆಯಾದ ಡೇಟಾವನ್ನು ನೋಡುತ್ತೇವೆ. ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.
ಡಿಸ್ಕ್ ಸ್ಪೇಸ್ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳು. ನಾವು ಪ್ರಮೀತಿಯಸ್‌ನಲ್ಲಿ ಒಟ್ಟು 120 ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. VictoriaMetrics ನಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ದಿನಕ್ಕೆ 4 ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ನಾವು ಪ್ರಮೀತಿಯಸ್‌ನಲ್ಲಿ ನೋಡಿದಕ್ಕಿಂತ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದ ಕಾರ್ಯವಿಧಾನವಿದೆ. ಅಂದರೆ, ಡೇಟಾವನ್ನು ಈಗಾಗಲೇ ಒಂದು ದಿನದಲ್ಲಿ, ಅರ್ಧ ಗಂಟೆಯಲ್ಲಿ ಚೆನ್ನಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ. ಡೇಟಾ ನಂತರವೂ ಕಳೆದುಹೋಗುತ್ತದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅವುಗಳನ್ನು ಈಗಾಗಲೇ ಅರ್ಧ ಗಂಟೆಯಲ್ಲಿ ಒಂದು ದಿನದಲ್ಲಿ ಚೆನ್ನಾಗಿ ಕೊಯ್ಯಲಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಡಿಸ್ಕ್ ಜಾಗದಲ್ಲಿ ಉಳಿಸಿದ್ದೇವೆ.
ನಾವು ಮೆಮೊರಿ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಸಹ ಉಳಿಸುತ್ತೇವೆ. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ನಿಯೋಜಿಸಿದ್ದೇವೆ - 8 ಕೋರ್ಗಳು, 24 ಗಿಗಾಬೈಟ್ಗಳು. ಪ್ರಮೀತಿಯಸ್ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ತಿನ್ನುತ್ತಾನೆ. ಅವನು OOM ಕಿಲ್ಲರ್ ಮೇಲೆ ಬಿದ್ದನು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೇವಲ 900 ಸಕ್ರಿಯ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಅದರಲ್ಲಿ ಸುರಿಯಲಾಯಿತು. ಇದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 000-25 ಮೆಟ್ರಿಕ್‌ಗಳು.
ನಾವು VictoriaMetrics ಅನ್ನು 8 ಗಿಗಾಬೈಟ್ RAM ಹೊಂದಿರುವ ಡ್ಯುಯಲ್-ಕೋರ್ ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ನಡೆಸಿದ್ದೇವೆ. 8GB ಗಣಕದಲ್ಲಿ ಕೆಲವು ವಿಷಯಗಳೊಂದಿಗೆ ಸುತ್ತಾಡುವ ಮೂಲಕ ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ಮಾಡಿದ್ದೇವೆ. ಕೊನೆಯಲ್ಲಿ, ನಾವು ಅದನ್ನು 7 ಗಿಗಾಬೈಟ್‌ಗಳಿಗೆ ಇರಿಸಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ವಿಷಯದ ವಿತರಣೆಯ ವೇಗ, ಅಂದರೆ ಮೆಟ್ರಿಕ್‌ಗಳು, ಪ್ರಮೀಥಿಯಸ್‌ಗಿಂತ ಹೆಚ್ಚಿನದಾಗಿತ್ತು.
ಪ್ರಮೀತಿಯಸ್‌ಗೆ ಹೋಲಿಸಿದರೆ CPU ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿದೆ. ಇಲ್ಲಿ ಪ್ರಮೀತಿಯಸ್ 2,5 ಕೋರ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಕೇವಲ 0,25 ಕೋರ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಪ್ರಾರಂಭದಲ್ಲಿ - 0,5 ಕೋರ್ಗಳು. ಅದು ವಿಲೀನಗೊಳ್ಳುತ್ತಿದ್ದಂತೆ, ಅದು ಒಂದು ಕೋರ್ ಅನ್ನು ತಲುಪುತ್ತದೆ, ಆದರೆ ಇದು ಅತ್ಯಂತ ಅಪರೂಪದ ಸಂಗತಿಯಾಗಿದೆ.
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಪಷ್ಟ ಕಾರಣಗಳಿಗಾಗಿ ಆಯ್ಕೆಯು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಮೇಲೆ ಬಿದ್ದಿತು; ನಾವು ಹಣವನ್ನು ಉಳಿಸಲು ಬಯಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಮಾಡಿದೆವು.
ಈಗಿನಿಂದಲೇ ಎರಡು ಅಂಶಗಳನ್ನು ದಾಟೋಣ - ಮೆಟ್ರಿಕ್‌ಗಳ ಅಪ್‌ಲೋಡ್ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಹೆಚ್ಚಿನ ಬಳಕೆ. ಮತ್ತು ನಾವು ಇನ್ನೂ ನಮಗಾಗಿ ಉಳಿದಿರುವ ಎರಡು ಅಂಶಗಳನ್ನು ನಿರ್ಧರಿಸಬೇಕು.
ಇಲ್ಲಿ ನಾನು ಈಗಿನಿಂದಲೇ ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ, ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹವೆಂದು ಪರಿಗಣಿಸುತ್ತೇವೆ. ಆದರೆ ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಎಲ್ಲಾ ಲೆರಾಯ್‌ಗಳಿಗೆ ಸಂಗ್ರಹಣೆಯಾಗಿ ಒದಗಿಸುವುದರಿಂದ, ಈ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬಳಸುವವರನ್ನು ನಾವು ಮಿತಿಗೊಳಿಸಬೇಕಾಗಿದೆ ಆದ್ದರಿಂದ ಅವರು ಅದನ್ನು ನಮಗೆ ನೀಡುವುದಿಲ್ಲ.
ಸಮಯದ ಮೂಲಕ, ಡೇಟಾದ ಪರಿಮಾಣದ ಮೂಲಕ ಮತ್ತು ಮರಣದಂಡನೆಯ ಸಮಯದ ಮೂಲಕ ಮಿತಿಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಅದ್ಭುತ ಪ್ಯಾರಾಮೀಟರ್ ಇದೆ.
ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ನಮಗೆ ಅನುಮತಿಸುವ ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯೂ ಇದೆ, ಇದರಿಂದಾಗಿ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣಾ ವೇಗ ಮತ್ತು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಪಡೆಯಲು ನಮಗೆ ಅನುಮತಿಸುವ ಸಮತೋಲನವನ್ನು ನಾವು ಕಾಣಬಹುದು.
ಮೈನಸ್ ಇನ್ನೊಂದು ಪಾಯಿಂಟ್, ಅಂದರೆ ಪಾಯಿಂಟ್ ಅನ್ನು ದಾಟಿ - ನೀವು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಮೊದಲ ಪುನರಾವರ್ತನೆಗಳಲ್ಲಿ, ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಿಂಗಲ್ ನೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ಮುಂದೆ ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆವೃತ್ತಿಗೆ ಹೋಗುತ್ತೇವೆ.
ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನಲ್ಲಿ ವಿವಿಧ ಸೇವೆಗಳನ್ನು ಅವರು ಚಲಾಯಿಸುತ್ತಾರೆ ಮತ್ತು ಅವರು ಯಾವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಪ್ರತ್ಯೇಕಿಸಲು ಇಲ್ಲಿ ನಾವು ಮುಕ್ತ ಹಸ್ತವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದು ತುಂಬಾ ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಅನುಕೂಲಕರ ಪರಿಹಾರವಾಗಿದೆ. ನಾವು ಇದನ್ನು ನಮ್ಮ ಮೇಲೆ ಬಳಸಿದ್ದೇವೆ.
ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆವೃತ್ತಿಯ ಮುಖ್ಯ ಅಂಶಗಳು vmssorage. ಅವುಗಳಲ್ಲಿ N ಸಂಖ್ಯೆ ಇರಬಹುದು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇಲ್ಲಿಯವರೆಗೆ ಅವುಗಳಲ್ಲಿ 2 ಇವೆ.
ಮತ್ತು vminsert ಇದೆ. ಇದು ನಮಗೆ ಅನುಮತಿಸುವ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಆಗಿದೆ: ನಾವು ಹೇಳಿದ ಎಲ್ಲಾ ಸ್ಟೋರೇಜ್‌ಗಳ ನಡುವೆ ಶಾರ್ಡಿಂಗ್ ವ್ಯವಸ್ಥೆ ಮಾಡಿ ಮತ್ತು ಇದು ಪ್ರತಿಕೃತಿಯನ್ನು ಸಹ ಅನುಮತಿಸುತ್ತದೆ, ಅಂದರೆ ನೀವು ಶಾರ್ಡಿಂಗ್ ಮತ್ತು ಪ್ರತಿಕೃತಿ ಎರಡನ್ನೂ ಹೊಂದಿರುತ್ತೀರಿ.
Vminsert OpenTSDB, Graphite, InfluxDB ಮತ್ತು Prometheus ನಿಂದ ರಿಮೋಟ್‌ರೈಟ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
ವಿಎಂಸೆಲೆಕ್ಟ್ ಕೂಡ ಇದೆ. ಇದರ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ vmstorage ಗೆ ಹೋಗುವುದು, ಅವರಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವುದು, ಈ ಡೇಟಾವನ್ನು ಡಿಡಪ್ಲಿಕೇಟ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡುವುದು.
vmagent ಎಂಬ ಅದ್ಭುತ ವಿಷಯವಿದೆ. ನಾವು ಅವಳನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುತ್ತೇವೆ. ಇದು ಪ್ರಮೀತಿಯಸ್‌ನಂತೆಯೇ ನಿಖರವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಇನ್ನೂ ಪ್ರಮೀತಿಯಸ್‌ನಂತೆಯೇ ಎಲ್ಲವನ್ನೂ ಮಾಡಿ. ಅಂದರೆ, ಇದು ವಿವಿಧ ಘಟಕಗಳು ಮತ್ತು ಸೇವೆಗಳಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು vminsert ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ನಂತರ ಎಲ್ಲವೂ ನಿಮ್ಮ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
ಮತ್ತೊಂದು ಉತ್ತಮ ಸೇವೆ vmalert ಆಗಿದೆ, ಇದು ನಿಮಗೆ VictoriaMetrics ಅನ್ನು ಬ್ಯಾಕೆಂಡ್ ಆಗಿ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ, vminsert ನಿಂದ ಸಂಸ್ಕರಿಸಿದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿ ಮತ್ತು ಅದನ್ನು vmselect ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಇದು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ವತಃ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಹಾಗೆಯೇ ನಿಯಮಗಳನ್ನು. ಎಚ್ಚರಿಕೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಎಚ್ಚರಿಕೆಯ ನಿರ್ವಾಹಕರ ಮೂಲಕ ನಾವು ಎಚ್ಚರಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ.
wmauth ಅಂಶವಿದೆ. ಕ್ಲಸ್ಟರ್‌ಗಳ ಮಲ್ಟಿಟೆನೆನ್ಸಿ ಆವೃತ್ತಿಗೆ ನಾವು ಇದನ್ನು ದೃಢೀಕರಣ ವ್ಯವಸ್ಥೆಯಾಗಿ ಬಳಸಬಹುದು ಅಥವಾ ಬಳಸದೇ ಇರಬಹುದು (ನಾವು ಇದನ್ನು ಇನ್ನೂ ನಿರ್ಧರಿಸಿಲ್ಲ). ಇದು Prometheus ಗಾಗಿ remoteWrite ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು url ಅಥವಾ ಅದರ ಎರಡನೆಯ ಭಾಗವನ್ನು ಆಧರಿಸಿ ಅಧಿಕೃತಗೊಳಿಸಬಹುದು, ಅಲ್ಲಿ ನೀವು ಬರೆಯಬಹುದು ಅಥವಾ ಬರೆಯಬಾರದು.
vmbackup, vmrestore ಸಹ ಇದೆ. ಇದು ಮೂಲಭೂತವಾಗಿ, ಎಲ್ಲಾ ಡೇಟಾದ ಮರುಸ್ಥಾಪನೆ ಮತ್ತು ಬ್ಯಾಕ್ಅಪ್ ಆಗಿದೆ. S3, GCS, ಫೈಲ್ ಮಾಡಬಹುದು.
ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ ಮೊದಲ ಪುನರಾವರ್ತನೆಯನ್ನು ಕ್ವಾರಂಟೈನ್ ಸಮಯದಲ್ಲಿ ಮಾಡಲಾಯಿತು. ಆ ಸಮಯದಲ್ಲಿ, ಯಾವುದೇ ಪ್ರತಿಕೃತಿ ಇರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ನಮ್ಮ ಪುನರಾವರ್ತನೆಯು ಎರಡು ವಿಭಿನ್ನ ಮತ್ತು ಸ್ವತಂತ್ರ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು, ಅದರಲ್ಲಿ ನಾವು ರಿಮೋಟ್‌ರೈಟ್ ಮೂಲಕ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಿಂಗಲ್ ನೋಡ್‌ನಿಂದ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆವೃತ್ತಿಗೆ ಬದಲಾಯಿಸಿದಾಗ, ನಾವು ಇನ್ನೂ ಅದೇ ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಉಳಿದಿದ್ದೇವೆ, ಅಂದರೆ ಮುಖ್ಯವಾದದ್ದು ಮೆಮೊರಿ ಎಂದು ಇಲ್ಲಿ ನಾನು ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ. ನಮ್ಮ ಡೇಟಾ, ಅಂದರೆ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಸರಿಸುಮಾರು ಹೇಗೆ ವಿತರಿಸಲಾಗಿದೆ.
ಪ್ರತಿಕೃತಿಯನ್ನು ಈಗಾಗಲೇ ಇಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ. ನಾವು ಇದೆಲ್ಲವನ್ನೂ ಒಂದು ತುಲನಾತ್ಮಕವಾಗಿ ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಆಗಿ ಸಂಯೋಜಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಹಂಚಲಾಗಿದೆ ಮತ್ತು ಪುನರಾವರ್ತಿಸಲಾಗಿದೆ.
ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ N ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ ಪ್ರೊಮಿತಿಯಸ್ HAPROXY ಮೂಲಕ ಡೇಟಾವನ್ನು ಸೇರಿಸಬಹುದು. ಇಲ್ಲಿ ನಾವು ಈ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಈ ಪ್ರವೇಶ ಬಿಂದುವಿನ ಮೂಲಕ ನೀವು ಗ್ರಾಫನಾದಿಂದ ಲಾಗ್ ಇನ್ ಮಾಡಬಹುದು.
ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿಗಳು ಆಯ್ಕೆ ಮಾಡುವ, ಸೇರಿಸುವ ಮತ್ತು ಇತರ ಸೇವೆಗಳ ಏಕೈಕ ಪೋರ್ಟ್ HAPROXY ಆಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದು ವಿಳಾಸವನ್ನು ಮಾಡುವುದು ಅಸಾಧ್ಯ; ನಾವು ಹಲವಾರು ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು, ಏಕೆಂದರೆ VictoriaMetrics ಕ್ಲಸ್ಟರ್ ಚಾಲನೆಯಲ್ಲಿರುವ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಒಂದೇ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ವಿವಿಧ ವಲಯಗಳಲ್ಲಿವೆ, ಅಂದರೆ ನಮ್ಮ ಮೋಡದ ಒಳಗೆ ಅಲ್ಲ, ಆದರೆ ಹೊರಗೆ. .
ನಮಗೆ ಎಚ್ಚರಿಕೆ ಇದೆ. ನಾವು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು Prometheus ನಿಂದ ಎಚ್ಚರಿಕೆಯ ನಿರ್ವಾಹಕವನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಓಪ್ಸ್ಜೆನಿ ಮತ್ತು ಟೆಲಿಗ್ರಾಮ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯ ವಿತರಣಾ ಚಾನಲ್ ಆಗಿ ಬಳಸುತ್ತೇವೆ. ಟೆಲಿಗ್ರಾಮ್‌ನಲ್ಲಿ ಅವರು ದೇವ್‌ನಿಂದ ಸುರಿಯುತ್ತಾರೆ, ಪ್ರಾಡ್‌ನಿಂದ ಏನಾದರೂ ಆಗಿರಬಹುದು, ಆದರೆ ಹೆಚ್ಚಾಗಿ ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಅಂಕಿಅಂಶಗಳು. ಮತ್ತು Opsgenie ನಿರ್ಣಾಯಕ. ಇವು ಕರೆಗಳು, ಘಟನೆ ನಿರ್ವಹಣೆ.
ಶಾಶ್ವತ ಪ್ರಶ್ನೆ: "ಯಾರು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ?" ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಮಾನಿಟರಿಂಗ್ ಮಾನಿಟರ್‌ಗಳು ಸ್ವತಃ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತವೆ, ಏಕೆಂದರೆ ನಾವು ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ vmagent ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಮತ್ತು ನಮ್ಮ ನೋಡ್‌ಗಳನ್ನು ಒಂದೇ ಪೂರೈಕೆದಾರರ ವಿವಿಧ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿರುವುದರಿಂದ, ಪ್ರತಿ ಡೇಟಾ ಕೇಂದ್ರವು ತನ್ನದೇ ಆದ ಚಾನಲ್ ಅನ್ನು ಹೊಂದಿದೆ, ಅವು ಸ್ವತಂತ್ರವಾಗಿರುತ್ತವೆ ಮತ್ತು ವಿಭಜಿತ ಮೆದುಳು ಬಂದರೂ ಸಹ, ನಾವು ಇನ್ನೂ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಹೌದು, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಇರುತ್ತದೆ, ಆದರೆ ಯಾವುದಕ್ಕೂ ಹೆಚ್ಚಿನ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು ಉತ್ತಮ.
ನಾವು ನಮ್ಮ ಪಟ್ಟಿಯನ್ನು HA ಅನುಷ್ಠಾನದೊಂದಿಗೆ ಕೊನೆಗೊಳಿಸುತ್ತೇವೆ.
ಮತ್ತು ಮತ್ತಷ್ಟು ನಾನು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಸಮುದಾಯದೊಂದಿಗೆ ಸಂವಹನದ ಅನುಭವವನ್ನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಇದು ತುಂಬಾ ಧನಾತ್ಮಕವಾಗಿ ಹೊರಹೊಮ್ಮಿತು. ಹುಡುಗರು ಸ್ಪಂದಿಸುತ್ತಾರೆ. ಅವರು ನೀಡುವ ಪ್ರತಿಯೊಂದು ಪ್ರಕರಣವನ್ನು ಪರಿಶೀಲಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ನಾನು GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದೆ. ಅವುಗಳನ್ನು ಬಹಳ ಬೇಗನೆ ಪರಿಹರಿಸಲಾಯಿತು. ಸಂಪೂರ್ಣವಾಗಿ ಮುಚ್ಚಿಲ್ಲದ ಇನ್ನೂ ಒಂದೆರಡು ಸಮಸ್ಯೆಗಳಿವೆ, ಆದರೆ ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಕೋಡ್‌ನಿಂದ ನೋಡಬಹುದು.
ಪುನರಾವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ ನನಗೆ ಮುಖ್ಯವಾದ ನೋವು ಏನೆಂದರೆ, ನಾನು ನೋಡ್ ಅನ್ನು ಮುಚ್ಚಿದರೆ, ಮೊದಲ 30 ಸೆಕೆಂಡುಗಳವರೆಗೆ vminsert ಬ್ಯಾಕೆಂಡ್ ಇಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದನ್ನು ಈಗ ನಿರ್ಧರಿಸಲಾಗಿದೆ. ಮತ್ತು ಅಕ್ಷರಶಃ ಒಂದು ಸೆಕೆಂಡ್ ಅಥವಾ ಎರಡರಲ್ಲಿ, ಡೇಟಾವನ್ನು ಉಳಿದಿರುವ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯು ಕಾಣೆಯಾದ ನೋಡ್‌ಗಾಗಿ ಕಾಯುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
ಕೆಲವು ಹಂತದಲ್ಲಿ ನಾವು VictoriaMetrics ಅನ್ನು VictoriaMetrics ಆಪರೇಟರ್ ಆಗಬೇಕೆಂದು ಬಯಸಿದ್ದೇವೆ. ನಾವು ಅವನಿಗಾಗಿ ಕಾಯುತ್ತಿದ್ದೆವು. ನಾವು ಈಗ ಸಕ್ರಿಯವಾಗಿ VictoriaMetrics ಆಪರೇಟರ್ ಎಲ್ಲಾ ಪೂರ್ವ ಲೆಕ್ಕಾಚಾರದ ನಿಯಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಚೌಕಟ್ಟನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ, ಇತ್ಯಾದಿ. Prometheus, ನಾವು ಸಾಕಷ್ಟು ಸಕ್ರಿಯವಾಗಿ Prometheus ಆಪರೇಟರ್ ಜೊತೆ ಬರುವ ನಿಯಮಗಳನ್ನು ಬಳಸುವುದರಿಂದ.
ಕ್ಲಸ್ಟರ್ ಅನುಷ್ಠಾನವನ್ನು ಸುಧಾರಿಸಲು ಪ್ರಸ್ತಾವನೆಗಳಿವೆ. ನಾನು ಅವುಗಳನ್ನು ಮೇಲೆ ವಿವರಿಸಿದ್ದೇನೆ.
ಮತ್ತು ನಾನು ನಿಜವಾಗಿಯೂ ಕಡಿಮೆ ಮಾಡಲು ಬಯಸುತ್ತೇನೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಟ್ರೆಂಡ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಲು ಪ್ರತ್ಯೇಕವಾಗಿ ಡೌನ್‌ಸ್ಯಾಂಪ್ಲಿಂಗ್ ಅಗತ್ಯವಿದೆ. ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ದಿನದಲ್ಲಿ ನನಗೆ ಒಂದು ಮೆಟ್ರಿಕ್ ಸಾಕು. ಈ ಪ್ರವೃತ್ತಿಗಳು ಒಂದು ವರ್ಷ, ಮೂರು, ಐದು, ಹತ್ತು ವರ್ಷಗಳವರೆಗೆ ಅಗತ್ಯವಿದೆ. ಮತ್ತು ಒಂದು ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯವು ಸಾಕಷ್ಟು ಸಾಕು.
- ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ಬಳಸುವಾಗ ನಮ್ಮ ಕೆಲವು ಸಹೋದ್ಯೋಗಿಗಳಂತೆ ನಾವು ನೋವನ್ನು ತಿಳಿದಿದ್ದೇವೆ.
- ನಾವು ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ನಮಗಾಗಿ ಆರಿಸಿಕೊಂಡಿದ್ದೇವೆ.
- ಇದು ಲಂಬವಾಗಿ ಮತ್ತು ಅಡ್ಡಡ್ಡಲಾಗಿ ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ಅಳೆಯುತ್ತದೆ.
- ನಾವು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯ ನೋಡ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಘಟಕಗಳನ್ನು ವಿತರಿಸಬಹುದು, ಅವುಗಳನ್ನು ಮೆಮೊರಿಯಿಂದ ಮಿತಿಗೊಳಿಸಬಹುದು, ಮೆಮೊರಿಯನ್ನು ಸೇರಿಸಬಹುದು, ಇತ್ಯಾದಿ.
ನಾವು ಮನೆಯಲ್ಲಿ ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಟ್ಟಿದ್ದೇವೆ. ಇದ್ದದ್ದು ಮತ್ತು ಆಗಿರುವುದು ಇದೇ.
VictoriaMetrics ಚಾಟ್, ನನ್ನ ಸಂಪರ್ಕಗಳು, LeroyMerlin ತಾಂತ್ರಿಕ ರಾಡಾರ್‌ಗಾಗಿ ಒಂದೆರಡು QR ಕೋಡ್‌ಗಳು.
ಮೂಲ: www.habr.com