SRE (ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂಜಿನಿಯರಿಂಗ್) ವೆಬ್ ಯೋಜನೆಗಳ ಲಭ್ಯತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಒಂದು ವಿಧಾನವಾಗಿದೆ. ಇದನ್ನು DevOps ಗೆ ಚೌಕಟ್ಟು ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು DevOps ಅಭ್ಯಾಸಗಳನ್ನು ಅನ್ವಯಿಸುವಲ್ಲಿ ಯಶಸ್ಸನ್ನು ಹೇಗೆ ಸಾಧಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತದೆ. ಈ ಲೇಖನದಲ್ಲಿ ಅನುವಾದ ಪುಸ್ತಕಗಳು Google ನಿಂದ. ನಾನು ಈ ಅನುವಾದವನ್ನು ನಾನೇ ಸಿದ್ಧಪಡಿಸಿದ್ದೇನೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಲ್ಲಿ ನನ್ನ ಸ್ವಂತ ಅನುಭವವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಟೆಲಿಗ್ರಾಂ ಚಾನೆಲ್‌ನಲ್ಲಿ и ನಾನು ಸೇವಾ ಮಟ್ಟದ ಗುರಿಗಳ ಬಗ್ಗೆ ಅದೇ ಪುಸ್ತಕದ ಅಧ್ಯಾಯ 4 ರ ಅನುವಾದದ ಲಿಂಕ್ ಅನ್ನು ಸಹ ಪ್ರಕಟಿಸಿದೆ.
ಬೆಕ್ಕಿನ ಅನುವಾದ. ಓದಿ ಆನಂದಿಸಿ!
Google ನ SRE ತಂಡಗಳು ಯಶಸ್ವಿ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಅಧಿಸೂಚನೆ ವ್ಯವಸ್ಥೆಗಳನ್ನು ರಚಿಸಲು ಮೂಲಭೂತ ತತ್ವಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಹೊಂದಿವೆ. ಈ ಅಧ್ಯಾಯವು ವೆಬ್ ಪುಟ ಸಂದರ್ಶಕರು ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಬಹುದು ಮತ್ತು ವೆಬ್ ಪುಟಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ಕಷ್ಟಕರವಾಗಿಸುವ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾರ್ಗದರ್ಶನವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ವ್ಯಾಖ್ಯಾನಗಳು
ಮೇಲ್ವಿಚಾರಣೆಗೆ ಸಂಬಂಧಿಸಿದ ವಿಷಯಗಳನ್ನು ಚರ್ಚಿಸಲು ಯಾವುದೇ ಒಂದೇ ಶಬ್ದಕೋಶವನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ. Google ನಲ್ಲಿ ಸಹ, ಕೆಳಗಿನ ಪದಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ನಾವು ಸಾಮಾನ್ಯ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತೇವೆ.
ಮಾನಿಟರಿಂಗ್
ಸಿಸ್ಟಮ್ ಬಗ್ಗೆ ನೈಜ ಸಮಯದಲ್ಲಿ ಪರಿಮಾಣಾತ್ಮಕ ಡೇಟಾದ ಸಂಗ್ರಹಣೆ, ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಿಕೆ, ಒಟ್ಟುಗೂಡಿಸುವಿಕೆ ಮತ್ತು ಪ್ರದರ್ಶನ: ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ವಿನಂತಿಗಳ ಪ್ರಕಾರಗಳು, ದೋಷಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ದೋಷಗಳ ಪ್ರಕಾರಗಳು, ವಿನಂತಿ ಪ್ರಕ್ರಿಯೆ ಸಮಯ ಮತ್ತು ಸರ್ವರ್ ಅಪ್‌ಟೈಮ್.
ವೈಟ್-ಬಾಕ್ಸ್ ಮೇಲ್ವಿಚಾರಣೆ
ಲಾಗ್‌ಗಳು, ಜಾವಾ ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಪ್ರೊಫೈಲಿಂಗ್ ಮೆಟ್ರಿಕ್‌ಗಳು ಅಥವಾ ಆಂತರಿಕ ಅಂಕಿಅಂಶಗಳನ್ನು ಉತ್ಪಾದಿಸುವ HTTP ಹ್ಯಾಂಡ್ಲರ್ ಮೆಟ್ರಿಕ್‌ಗಳು ಸೇರಿದಂತೆ ಆಂತರಿಕ ಸಿಸ್ಟಮ್ ಘಟಕಗಳಿಂದ ಪ್ರದರ್ಶಿಸಲಾದ ಮೆಟ್ರಿಕ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಮಾನಿಟರಿಂಗ್.
ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯ ಮೇಲ್ವಿಚಾರಣೆ
ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನದಿಂದ ಅಪ್ಲಿಕೇಶನ್ ನಡವಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ.
ಡ್ಯಾಶ್‌ಬೋರ್ಡ್
ಸೇವೆಗಳ ಪ್ರಮುಖ ಆರೋಗ್ಯ ಸೂಚಕಗಳ ಅವಲೋಕನವನ್ನು ಒದಗಿಸುವ ಇಂಟರ್ಫೇಸ್ (ಸಾಮಾನ್ಯವಾಗಿ ವೆಬ್). ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ತೋರಿಸಿರುವ ಸೂಚಕಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ ಇತ್ಯಾದಿ. ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾದ ಸೂಚಕಗಳನ್ನು ಗುರುತಿಸಲು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ತಾಂತ್ರಿಕ ಬೆಂಬಲ ಸಿಬ್ಬಂದಿಗೆ ಮಾಹಿತಿಯನ್ನು ಸಹ ಪ್ರದರ್ಶಿಸಬಹುದು: ವಿನಂತಿಗಳ ಸರತಿ, ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ದೋಷಗಳ ಪಟ್ಟಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶಕ್ಕಾಗಿ ನಿಯೋಜಿತ ಎಂಜಿನಿಯರ್.
ಎಚ್ಚರಿಕೆ (ಅಧಿಸೂಚನೆ)
ಇಮೇಲ್ ಅಥವಾ ಇತರ ವಿಧಾನಗಳ ಮೂಲಕ ವ್ಯಕ್ತಿಯು ಸ್ವೀಕರಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಅಧಿಸೂಚನೆಗಳು, ದೋಷಗಳು ಅಥವಾ ವಿನಂತಿಯ ಸರದಿಯಲ್ಲಿನ ಹೆಚ್ಚಳದಿಂದ ಪ್ರಚೋದಿಸಬಹುದು. ಅಧಿಸೂಚನೆಗಳನ್ನು ಹೀಗೆ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ: ಟಿಕೆಟ್‌ಗಳು, ಇಮೇಲ್ ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ತ್ವರಿತ ಸಂದೇಶವಾಹಕ ಸಂದೇಶಗಳು.
ಮೂಲ ಕಾರಣ
ಸಾಫ್ಟ್‌ವೇರ್ ದೋಷ ಅಥವಾ ಮಾನವ ದೋಷ, ಒಮ್ಮೆ ಸರಿಪಡಿಸಿದರೆ ಮತ್ತೆ ಸಂಭವಿಸಬಾರದು. ಸಮಸ್ಯೆಯು ಹಲವಾರು ಪ್ರಮುಖ ಕಾರಣಗಳನ್ನು ಹೊಂದಿರಬಹುದು: ಸಾಕಷ್ಟು ಪ್ರಕ್ರಿಯೆ ಯಾಂತ್ರೀಕೃತಗೊಂಡಿಲ್ಲ, ಸಾಫ್ಟ್‌ವೇರ್ ದೋಷ, ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕದ ಸಾಕಷ್ಟು ವಿಸ್ತರಣೆ. ಈ ಪ್ರತಿಯೊಂದು ಅಂಶಗಳು ಮೂಲ ಕಾರಣವಾಗಿರಬಹುದು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದನ್ನು ತೆಗೆದುಹಾಕಬೇಕು.
ನೋಡ್ ಮತ್ತು ಯಂತ್ರ (ನೋಡ್ ಮತ್ತು ಯಂತ್ರ)
ಭೌತಿಕ ಸರ್ವರ್, ವರ್ಚುವಲ್ ಗಣಕ, ಅಥವಾ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಏಕೈಕ ನಿದರ್ಶನವನ್ನು ಉಲ್ಲೇಖಿಸಲು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಪದಗಳು. ಒಂದು ಯಂತ್ರವು ಹಲವಾರು ಸೇವೆಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಬಹುದು. ಸೇವೆಗಳು ಹೀಗಿರಬಹುದು:
- ಪರಸ್ಪರ ಸಂಪರ್ಕ: ಉದಾಹರಣೆಗೆ, ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಸರ್ವರ್ ಮತ್ತು ವೆಬ್ ಸರ್ವರ್;
- ಒಂದು ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಸಂಬಂಧವಿಲ್ಲದ ಸೇವೆಗಳು: ಉದಾಹರಣೆಗೆ, ಕೋಡ್ ರೆಪೊಸಿಟರಿ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಸಿಸ್ಟಮ್‌ಗಾಗಿ ಮಾಂತ್ರಿಕ, ಉದಾಹರಣೆಗೆ ಅಥವಾ .
ಪುಶ್
ಸಾಫ್ಟ್‌ವೇರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ.
ಮೇಲ್ವಿಚಾರಣೆ ಏಕೆ ಅಗತ್ಯವಿದೆ?
ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಹಲವಾರು ಕಾರಣಗಳಿವೆ:
ದೀರ್ಘಕಾಲೀನ ಪ್ರವೃತ್ತಿಗಳ ವಿಶ್ಲೇಷಣೆ
ಡೇಟಾಬೇಸ್ ಎಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಅದು ಎಷ್ಟು ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ? ದೈನಂದಿನ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ?
ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೋಲಿಕೆ
Ajax DB 2.72 ಗೆ ಹೋಲಿಸಿದರೆ Acme ಬಕೆಟ್ ಬೈಟ್ಸ್ 3.14 ನಲ್ಲಿ ವಿನಂತಿಗಳು ವೇಗವಾಗಿವೆಯೇ? ಹೆಚ್ಚುವರಿ ನೋಡ್ ಕಾಣಿಸಿಕೊಂಡ ನಂತರ ವಿನಂತಿಗಳನ್ನು ಎಷ್ಟು ಉತ್ತಮವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ? ಕಳೆದ ವಾರಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಸೈಟ್ ನಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ?
ಎಚ್ಚರಿಕೆ (ಅಧಿಸೂಚನೆಗಳು)
ಏನೋ ಮುರಿದುಹೋಗಿದೆ ಮತ್ತು ಯಾರಾದರೂ ಅದನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ. ಅಥವಾ ಏನಾದರೂ ಶೀಘ್ರದಲ್ಲೇ ಒಡೆಯುತ್ತದೆ ಮತ್ತು ಯಾರಾದರೂ ಅದನ್ನು ಶೀಘ್ರದಲ್ಲೇ ಪರಿಶೀಲಿಸಬೇಕು.
ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ
ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಮೂಲಭೂತ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು ಮತ್ತು ಯಾವುದನ್ನಾದರೂ ಒಳಗೊಂಡಿರಬೇಕು — ವಿಳಂಬಗಳು (ಸುಪ್ತತೆ), ಸಂಚಾರ (ದಟ್ಟಣೆ), ದೋಷಗಳು (ದೋಷಗಳು) ಮತ್ತು ಲೋಡ್ ಗಾತ್ರ (ಸ್ಯಾಚುರೇಶನ್).
ರೆಟ್ರೋಸ್ಪೆಕ್ಟಿವ್ ವಿಶ್ಲೇಷಣೆ ನಡೆಸುವುದು (ಡೀಬಗ್ ಮಾಡುವುದು)
ವಿನಂತಿಯ ಪ್ರಕ್ರಿಯೆಯ ವಿಳಂಬವು ಹೆಚ್ಚಾಗಿದೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಬೇರೆ ಏನಾಯಿತು?
ಮಾನಿಟರಿಂಗ್ ವ್ಯವಸ್ಥೆಗಳು ವ್ಯಾಪಾರ ಗುಪ್ತಚರ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಡೇಟಾದ ಮೂಲವಾಗಿ ಮತ್ತು ಭದ್ರತಾ ಘಟನೆಗಳ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಸುಲಭಗೊಳಿಸಲು ಉಪಯುಕ್ತವಾಗಿವೆ. ಈ ಪುಸ್ತಕವು ಎಸ್‌ಆರ್‌ಇಗಳು ಪರಿಣತಿಯನ್ನು ಹೊಂದಿರುವ ಎಂಜಿನಿಯರಿಂಗ್ ಕ್ಷೇತ್ರಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಕಾರಣ, ನಾವು ಇಲ್ಲಿ ಮಾನಿಟರಿಂಗ್ ತಂತ್ರಗಳನ್ನು ಚರ್ಚಿಸುವುದಿಲ್ಲ.
ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳು ಸಿಸ್ಟಮ್ ಯಾವಾಗ ಮುರಿದುಹೋಗಿದೆ ಅಥವಾ ಮುರಿದುಹೋಗುತ್ತದೆ ಎಂದು ಹೇಳಲು ಅನುಮತಿಸುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ದುರಸ್ತಿ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ, ಎಚ್ಚರಿಕೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು, ಸಮಸ್ಯೆ ಇನ್ನೂ ಸಕ್ರಿಯವಾಗಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಲು, ಅದನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತು ಮೂಲ ಕಾರಣವನ್ನು ನಿರ್ಧರಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ನೀವು ಸಿಸ್ಟಮ್ ಘಟಕಗಳನ್ನು ಆಡಿಟ್ ಮಾಡದಿದ್ದರೆ, "ಏನೋ ಸ್ವಲ್ಪ ವಿಚಿತ್ರವಾಗಿ ತೋರುತ್ತದೆ" ಎಂಬ ಕಾರಣದಿಂದ ನೀವು ಎಂದಿಗೂ ಎಚ್ಚರಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.
ಅಧಿಸೂಚನೆಗಳೊಂದಿಗೆ ವ್ಯಕ್ತಿಗೆ ಹೊರೆಯಾಗುವುದು ಉದ್ಯೋಗಿಯ ಸಮಯವನ್ನು ಸಾಕಷ್ಟು ದುಬಾರಿಯಾಗಿದೆ. ಉದ್ಯೋಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಎಚ್ಚರಿಕೆಯು ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ. ಉದ್ಯೋಗಿ ಮನೆಯಲ್ಲಿದ್ದರೆ, ಎಚ್ಚರಿಕೆಯು ವೈಯಕ್ತಿಕ ಸಮಯವನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಾಯಶಃ ನಿದ್ರೆ ಮಾಡುತ್ತದೆ. ಎಚ್ಚರಿಕೆಗಳು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸಿದಾಗ, ಉದ್ಯೋಗಿಗಳು ಅವುಗಳ ಮೂಲಕ ಸ್ಕಿಮ್ ಮಾಡುತ್ತಾರೆ, ಅವುಗಳನ್ನು ಮುಂದೂಡುತ್ತಾರೆ ಅಥವಾ ಒಳಬರುವ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ. ಕಾಲಕಾಲಕ್ಕೆ ಅವರು ನಿಜವಾದ ಎಚ್ಚರಿಕೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ, ಇದು ಶಬ್ದ ಘಟನೆಗಳಿಂದ ಮರೆಮಾಚುತ್ತದೆ. ಸೇವೆಯ ಅಡೆತಡೆಗಳು ದೀರ್ಘಾವಧಿಯವರೆಗೆ ಇರುತ್ತದೆ ಏಕೆಂದರೆ ಶಬ್ದದ ಘಟನೆಗಳು ಸಮಸ್ಯೆಯನ್ನು ತ್ವರಿತವಾಗಿ ರೋಗನಿರ್ಣಯ ಮಾಡುವುದನ್ನು ಮತ್ತು ಸರಿಪಡಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಪರಿಣಾಮಕಾರಿ ಎಚ್ಚರಿಕೆ ವ್ಯವಸ್ಥೆಗಳು ಉತ್ತಮ ಸಿಗ್ನಲ್-ಟು-ಶಬ್ದ ಅನುಪಾತವನ್ನು ಹೊಂದಿವೆ.
ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸಮಂಜಸವಾದ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿಸುವುದು
ಸಂಕೀರ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸುವುದು ಸಂಕೀರ್ಣ ಎಂಜಿನಿಯರಿಂಗ್ ಕಾರ್ಯವಾಗಿದೆ. ಸಂಗ್ರಹಣೆ, ಪ್ರದರ್ಶನ ಮತ್ತು ಎಚ್ಚರಿಕೆಯ ಪರಿಕರಗಳ ಗಮನಾರ್ಹ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ, 10-12 ಸದಸ್ಯರ Google SRE ತಂಡವು ಸಾಮಾನ್ಯವಾಗಿ ಒಬ್ಬರು ಅಥವಾ ಇಬ್ಬರನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅವರ ಪ್ರಾಥಮಿಕ ಉದ್ದೇಶವು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಮತ್ತು ನಿರ್ವಹಿಸುವುದು. ನಾವು ಮೇಲ್ವಿಚಾರಣಾ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕ್ರೋಢೀಕರಿಸಿ ಮತ್ತು ಕೇಂದ್ರೀಕರಿಸಿದಂತೆ ಈ ಸಂಖ್ಯೆಯು ಕಾಲಾನಂತರದಲ್ಲಿ ಕಡಿಮೆಯಾಗಿದೆ, ಆದರೆ ಪ್ರತಿ SRE ತಂಡವು ಸಾಮಾನ್ಯವಾಗಿ ಕನಿಷ್ಠ ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಮಾತ್ರ ಮೀಸಲಿಡುತ್ತದೆ. ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ನೋಡಲು ಆಸಕ್ತಿದಾಯಕವಾಗಿದ್ದರೂ, ಸಮಸ್ಯೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಯಾರಾದರೂ ಪರದೆಯನ್ನು ನೋಡಬೇಕಾದ ಸಂದರ್ಭಗಳನ್ನು ಎಸ್‌ಆರ್‌ಇ ತಂಡಗಳು ಎಚ್ಚರಿಕೆಯಿಂದ ತಪ್ಪಿಸುತ್ತವೆ ಎಂದು ನಾವು ಹೇಳಬೇಕಾಗಿದೆ.
ಒಟ್ಟಾರೆಯಾಗಿ, Google ಸರಳವಾದ ಮತ್ತು ವೇಗದ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸೂಕ್ತವಾದ ನಂತರದ-ವಾಸ್ತವ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳೊಂದಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿದೆ. ಮಿತಿಗಳನ್ನು ಊಹಿಸಲು ಅಥವಾ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮೂಲ ಕಾರಣವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಪ್ರಯತ್ನಿಸುವ "ಮ್ಯಾಜಿಕ್" ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಾವು ತಪ್ಪಿಸುತ್ತೇವೆ. ಅಂತಿಮ-ಬಳಕೆದಾರರ ವಿನಂತಿಗಳಲ್ಲಿ ಅನಪೇಕ್ಷಿತ ವಿಷಯವನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಸಂವೇದಕಗಳು ಮಾತ್ರ ಪ್ರತಿರೂಪವಾಗಿದೆ; ಈ ಸಂವೇದಕಗಳು ಸರಳವಾಗಿ ಉಳಿಯುವವರೆಗೆ, ಅವರು ಗಂಭೀರ ವೈಪರೀತ್ಯಗಳ ಕಾರಣಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪತ್ತೆ ಮಾಡಬಹುದು. ಸಾಮರ್ಥ್ಯ ಯೋಜನೆ ಅಥವಾ ಸಂಚಾರ ಮುನ್ಸೂಚನೆಯಂತಹ ಮೇಲ್ವಿಚಾರಣೆ ಡೇಟಾವನ್ನು ಬಳಸುವ ಇತರ ಸ್ವರೂಪಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿವೆ. ಕಡಿಮೆ ಮಾದರಿ ದರದಲ್ಲಿ (ಗಂಟೆಗಳು ಅಥವಾ ದಿನಗಳು) ದೀರ್ಘಾವಧಿಯ ಅವಧಿಯಲ್ಲಿ (ತಿಂಗಳು ಅಥವಾ ವರ್ಷಗಳು) ಅವಲೋಕನವು ದೀರ್ಘಾವಧಿಯ ಪ್ರವೃತ್ತಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.
Google SRE ತಂಡವು ಸಂಕೀರ್ಣ ಅವಲಂಬನೆ ಶ್ರೇಣಿಗಳೊಂದಿಗೆ ಮಿಶ್ರ ಯಶಸ್ಸನ್ನು ಹೊಂದಿದೆ. "ಡೇಟಾಬೇಸ್ ನಿಧಾನವಾಗಿದೆ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡರೆ, ಡೇಟಾಬೇಸ್ ನಿಧಾನವಾಗಿದೆ ಎಂಬ ಎಚ್ಚರಿಕೆಯನ್ನು ನಾನು ಪಡೆಯುತ್ತೇನೆ, ಇಲ್ಲದಿದ್ದರೆ ಸೈಟ್ ನಿಧಾನವಾಗಿದೆ ಎಂಬ ಎಚ್ಚರಿಕೆಯನ್ನು ನಾನು ಪಡೆಯುತ್ತೇನೆ" ಎಂಬಂತಹ ನಿಯಮಗಳನ್ನು ನಾವು ಅಪರೂಪವಾಗಿ ಬಳಸುತ್ತೇವೆ. ಅವಲಂಬನೆ-ಆಧಾರಿತ ನಿಯಮಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯಂತಹ ನಮ್ಮ ಸಿಸ್ಟಮ್‌ನ ಬದಲಾಗದ ಭಾಗಗಳನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, "ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ, ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಲ್ಲಿನ ವಿಳಂಬಗಳ ಬಗ್ಗೆ ನನಗೆ ಎಚ್ಚರಿಕೆ ನೀಡಬೇಡಿ" ಎಂಬುದು ಡೇಟಾ ಕೇಂದ್ರದಿಂದ ಎಚ್ಚರಿಕೆಗಳಿಗೆ ಒಂದು ಸಾಮಾನ್ಯ ನಿಯಮವಾಗಿದೆ. Google ನಲ್ಲಿ ಕೆಲವು ತಂಡಗಳು ಸಂಕೀರ್ಣ ಅವಲಂಬನೆ ಶ್ರೇಣಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ ಏಕೆಂದರೆ ನಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ನಿರಂತರ ಮರುಫಲಕೀಕರಣದ ನಿರಂತರ ದರವನ್ನು ಹೊಂದಿದೆ.
ಈ ಅಧ್ಯಾಯದಲ್ಲಿ ವಿವರಿಸಿದ ಕೆಲವು ವಿಚಾರಗಳು ಇನ್ನೂ ಪ್ರಸ್ತುತವಾಗಿವೆ: ವಿಶೇಷವಾಗಿ ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ರೋಗಲಕ್ಷಣದಿಂದ ಮೂಲ ಕಾರಣಕ್ಕೆ ವೇಗವಾಗಿ ಚಲಿಸಲು ಯಾವಾಗಲೂ ಅವಕಾಶವಿದೆ. ಆದ್ದರಿಂದ, ಈ ಅಧ್ಯಾಯವು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಕೆಲವು ಗುರಿಗಳನ್ನು ಮತ್ತು ಆ ಗುರಿಗಳನ್ನು ಹೇಗೆ ಸಾಧಿಸುವುದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳು ಸರಳ ಮತ್ತು ತಂಡದ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ.
ಅಂತೆಯೇ, ಶಬ್ದದ ಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮತ್ತು ಸಿಗ್ನಲ್ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚು ಇರಿಸಿಕೊಳ್ಳಲು, ಎಚ್ಚರಿಕೆಯ ಸ್ವತ್ತುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ವಿಧಾನಗಳು ತುಂಬಾ ಸರಳ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಬೇಕು. ಜನರಿಗೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ರಚಿಸುವ ನಿಯಮಗಳು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ಸುಲಭವಾಗಿರಬೇಕು.
ಕಾರಣಗಳ ವಿರುದ್ಧ ರೋಗಲಕ್ಷಣಗಳು
ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಎರಡು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬೇಕು: "ಏನು ಮುರಿಯಿತು" ಮತ್ತು "ಅದು ಏಕೆ ಮುರಿಯಿತು."
"ಏನು ಮುರಿಯಿತು" ರೋಗಲಕ್ಷಣದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ, ಮತ್ತು "ಏಕೆ ಮುರಿಯಿತು" ಕಾರಣದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ. ಕೆಳಗಿನ ಕೋಷ್ಟಕವು ಅಂತಹ ಸಂಪರ್ಕಗಳ ಉದಾಹರಣೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.
ಒಂದು ಲಕ್ಷಣ
ಕಾರಣ
HTTP ದೋಷ 500 ಅಥವಾ 404 ಅನ್ನು ಪಡೆಯಲಾಗುತ್ತಿದೆ
ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಗಳು ಸಂಪರ್ಕಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತವೆ
ನಿಧಾನವಾದ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆಗಳು
ಹೆಚ್ಚಿನ CPU ಬಳಕೆ ಅಥವಾ ಹಾನಿಗೊಳಗಾದ ಈಥರ್ನೆಟ್ ಕೇಬಲ್
ಅಂಟಾರ್ಟಿಕಾದಲ್ಲಿ ಬಳಕೆದಾರರು ಬೆಕ್ಕು GIF ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿಲ್ಲ
ನಿಮ್ಮ CDN ವಿಜ್ಞಾನಿಗಳು ಮತ್ತು ಬೆಕ್ಕುಗಳನ್ನು ದ್ವೇಷಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೆಲವು IP ವಿಳಾಸಗಳನ್ನು ಕಪ್ಪುಪಟ್ಟಿಗೆ ಸೇರಿಸಲಾಯಿತು
ಖಾಸಗಿ ವಿಷಯವು ಎಲ್ಲೆಡೆಯಿಂದ ಲಭ್ಯವಾಗಿದೆ
ಹೊಸ ಸಾಫ್ಟ್‌ವೇರ್ ಬಿಡುಗಡೆಯ ರೋಲ್‌ಔಟ್ ಫೈರ್‌ವಾಲ್ ಎಲ್ಲಾ ACL ಗಳನ್ನು ಮರೆತು ಎಲ್ಲರನ್ನೂ ಒಳಗೆ ಬಿಡುವಂತೆ ಮಾಡಿತು
"ಏನು" ಮತ್ತು "ಏಕೆ" ಗರಿಷ್ಟ ಸಿಗ್ನಲ್ ಮತ್ತು ಕನಿಷ್ಠ ಶಬ್ದದೊಂದಿಗೆ ಉತ್ತಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲು ಕೆಲವು ಪ್ರಮುಖ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್ಸ್ಗಳಾಗಿವೆ.
ಕಪ್ಪು ಪೆಟ್ಟಿಗೆ ವಿರುದ್ಧ ಬಿಳಿ ಪೆಟ್ಟಿಗೆ
ನಿರ್ಣಾಯಕ ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ ನಾವು ವ್ಯಾಪಕವಾದ ವೈಟ್-ಬಾಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಸಾಧಾರಣ ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತೇವೆ. ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆಯನ್ನು ವೈಟ್-ಬಾಕ್ಸ್‌ಗೆ ಹೋಲಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆಯು ರೋಗಲಕ್ಷಣ-ಕೇಂದ್ರಿತವಾಗಿದೆ ಮತ್ತು ಪೂರ್ವಭಾವಿ ಮೇಲ್ವಿಚಾರಣೆಗಿಂತ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕವಾಗಿದೆ: "ಸಿಸ್ಟಮ್ ಇದೀಗ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ." ವೈಟ್-ಬಾಕ್ಸ್ ಸಿಸ್ಟಮ್‌ಗಳ ಆಂತರಿಕ ಪರಿಶೀಲನೆ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ: ಈವೆಂಟ್ ಲಾಗ್‌ಗಳು ಅಥವಾ ವೆಬ್ ಸರ್ವರ್‌ಗಳು. ಹೀಗಾಗಿ, ವೈಟ್-ಬಾಕ್ಸ್ ಮುಂಬರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ವಿನಂತಿಯ ಮರುಪ್ರಸಾರದಂತೆ ಕಂಡುಬರುವ ದೋಷಗಳು ಇತ್ಯಾದಿ.
ಬಹು-ಪದರದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಒಬ್ಬ ಎಂಜಿನಿಯರ್‌ನ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದಲ್ಲಿನ ರೋಗಲಕ್ಷಣವು ಮತ್ತೊಂದು ಎಂಜಿನಿಯರ್‌ನ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದಲ್ಲಿನ ಲಕ್ಷಣವಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆ ಕಡಿಮೆಯಾಗಿದೆ. ನಿಧಾನಗತಿಯ ಡೇಟಾಬೇಸ್ ಓದುವಿಕೆಗಳು ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಡೇಟಾಬೇಸ್ SRE ನ ಲಕ್ಷಣವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ನಿಧಾನಗತಿಯ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಗಮನಿಸುವ ಮುಂಭಾಗದ SRE ಗಾಗಿ, ಅದೇ ನಿಧಾನಗತಿಯ ಡೇಟಾಬೇಸ್ ಓದುವಿಕೆಯ ಕಾರಣವು ನಿಧಾನವಾದ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಆದ್ದರಿಂದ, ವೈಟ್-ಬಾಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಕೆಲವೊಮ್ಮೆ ರೋಗಲಕ್ಷಣ-ಕೇಂದ್ರಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಕಾರಣ-ಕೇಂದ್ರಿತವಾಗಿರುತ್ತದೆ, ಅದು ಎಷ್ಟು ವಿಸ್ತಾರವಾಗಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ.
ಡೀಬಗ್ ಮಾಡಲು ಟೆಲಿಮೆಟ್ರಿಯನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ, ವೈಟ್-ಬಾಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಅಗತ್ಯವಿದೆ. ವೆಬ್ ಸರ್ವರ್‌ಗಳು ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ನಿಧಾನವಾಗಿದ್ದರೆ, ವೆಬ್ ಸರ್ವರ್ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಎಷ್ಟು ಬೇಗನೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಮತ್ತು ಅದು ಎಷ್ಟು ಬೇಗನೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ಇಲ್ಲವಾದರೆ, ನಿಧಾನಗತಿಯ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಮತ್ತು ವೆಬ್ ಸರ್ವರ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಡುವಿನ ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಯ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಳುಹಿಸುವಾಗ ಕಪ್ಪು-ಪೆಟ್ಟಿಗೆ ಮಾನಿಟರಿಂಗ್ ಪ್ರಮುಖ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿದೆ: ಸಮಸ್ಯೆಯು ಈಗಾಗಲೇ ನಿಜವಾದ ರೋಗಲಕ್ಷಣಗಳನ್ನು ಉಂಟುಮಾಡಿದಾಗ ನೀವು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಅಧಿಸೂಚನೆಯನ್ನು ಪ್ರಚೋದಿಸುತ್ತೀರಿ. ಮತ್ತೊಂದೆಡೆ, ಇನ್ನೂ ಉದ್ಭವಿಸದ ಆದರೆ ಸನ್ನಿಹಿತವಾಗಿರುವ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯ ಸಮಸ್ಯೆಗೆ ಮೇಲ್ವಿಚಾರಣೆ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ.
ನಾಲ್ಕು ಚಿನ್ನದ ಸಂಕೇತಗಳು
ನಾಲ್ಕು ಗೋಲ್ಡನ್ ಮಾನಿಟರಿಂಗ್ ಸಿಗ್ನಲ್‌ಗಳೆಂದರೆ ಲೇಟೆನ್ಸಿ, ಟ್ರಾಫಿಕ್, ದೋಷಗಳು ಮತ್ತು ಸ್ಯಾಚುರೇಶನ್. ನೀವು ನಾಲ್ಕು ಬಳಕೆದಾರರ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮಾತ್ರ ಅಳೆಯಲು ಸಾಧ್ಯವಾದರೆ, ಆ ನಾಲ್ಕರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿ.
ವಿಳಂಬ
ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಬೇಕಾದ ಸಮಯ. ಯಶಸ್ವಿ ಮತ್ತು ವಿಫಲವಾದ ವಿನಂತಿಗಳ ಸುಪ್ತತೆಯ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್ ಅಥವಾ ಇತರ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸಂಪರ್ಕದ ನಷ್ಟದಿಂದ ಉಂಟಾದ HTTP 500 ದೋಷವನ್ನು ತ್ವರಿತವಾಗಿ ನಿರ್ಣಯಿಸಬಹುದು, ಆದಾಗ್ಯೂ, HTTP 500 ದೋಷವು ವಿಫಲವಾದ ವಿನಂತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಒಟ್ಟಾರೆ ಸುಪ್ತತೆಯ ಮೇಲೆ 500 ದೋಷದ ಪರಿಣಾಮವನ್ನು ನಿರ್ಧರಿಸುವುದು ತಪ್ಪಾದ ತೀರ್ಮಾನಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಮತ್ತೊಂದೆಡೆ, ನಿಧಾನ ದೋಷವು ತ್ವರಿತ ದೋಷವೂ ಆಗಿದೆ! ಆದ್ದರಿಂದ, ದೋಷಗಳನ್ನು ಸರಳವಾಗಿ ಫಿಲ್ಟರ್ ಮಾಡುವ ಬದಲು ದೋಷದ ಸುಪ್ತತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಸಂಚಾರ
ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಉನ್ನತ ಮಟ್ಟದ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ. ವೆಬ್ ಸೇವೆಗಾಗಿ, ಈ ಮಾಪನವು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ HTTP ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ, ವಿನಂತಿಗಳ ಸ್ವರೂಪದಿಂದ ಭಾಗಿಸಿ (ಉದಾಹರಣೆಗೆ, ಸ್ಥಿರ ಅಥವಾ ಕ್ರಿಯಾತ್ಮಕ ವಿಷಯ). ಆಡಿಯೊ ಸ್ಟ್ರೀಮಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಾಗಿ, ಈ ಮಾಪನವು ನೆಟ್‌ವರ್ಕ್ I/O ವೇಗ ಅಥವಾ ಏಕಕಾಲಿಕ ಅವಧಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕೇಂದ್ರೀಕರಿಸಬಹುದು. ಪ್ರಮುಖ ಮೌಲ್ಯದ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಾಗಿ, ಈ ಮಾಪನವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ವಹಿವಾಟುಗಳು ಅಥವಾ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳಾಗಿರಬಹುದು.
ದೋಷಗಳು
ಇದು ಸ್ಪಷ್ಟವಾದ (ಉದಾ HTTP 500), ಸೂಚ್ಯವಾದ (ಉದಾ HTTP 200 ಆದರೆ ಅಮಾನ್ಯವಾದ ವಿಷಯದೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ) ಅಥವಾ ನೀತಿ (ಉದಾ "ನೀವು ಒಂದು ಸೆಕೆಂಡಿನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸೆರೆಹಿಡಿದಿದ್ದರೆ, ಯಾವುದೇ ಒಂದು ಸೆಕೆಂಡ್ ದೋಷವಾಗಿದೆ") ವಿಫಲವಾದ ವಿನಂತಿಗಳ ದರವಾಗಿದೆ. ಎಲ್ಲಾ ವೈಫಲ್ಯದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು HTTP ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್‌ಗಳು ಸಾಕಾಗದೇ ಇದ್ದರೆ, ಭಾಗಶಃ ವೈಫಲ್ಯವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ದ್ವಿತೀಯ (ಆಂತರಿಕ) ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಅಗತ್ಯವಾಗಬಹುದು. ಅಂತಹ ಎಲ್ಲಾ ವಿಫಲ ವಿನಂತಿಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮಾಹಿತಿಯುಕ್ತವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ತಪ್ಪಾದ ವಿಷಯವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿರುವಿರಿ ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಎಂಡ್-ಟು-ಎಂಡ್ ಸಿಸ್ಟಮ್ ಪರೀಕ್ಷೆಗಳು ಸಹಾಯ ಮಾಡುತ್ತವೆ.
ಶುದ್ಧತ್ವ
ನಿಮ್ಮ ಸೇವೆಯನ್ನು ಎಷ್ಟು ತೀವ್ರವಾಗಿ ಬಳಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಮೆಟ್ರಿಕ್ ತೋರಿಸುತ್ತದೆ. ಇದು ಸಿಸ್ಟಮ್ ಮಾನಿಟರಿಂಗ್ ಅಳತೆಯಾಗಿದ್ದು ಅದು ಹೆಚ್ಚು ನಿರ್ಬಂಧಿತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಮೆಮೊರಿ-ನಿರ್ಬಂಧಿತ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ, ಮೆಮೊರಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, I/O- ನಿರ್ಬಂಧಿತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, I/Os ಸಂಖ್ಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ). ಅನೇಕ ವ್ಯವಸ್ಥೆಗಳು 100% ಬಳಕೆಯನ್ನು ತಲುಪುವ ಮೊದಲು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಆದ್ದರಿಂದ ಬಳಕೆಯ ಗುರಿಯನ್ನು ಹೊಂದಿರುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಉನ್ನತ ಮಟ್ಟದ ಲೋಡ್ ಮಾಪನಗಳಿಂದ ಶುದ್ಧತ್ವವನ್ನು ಪೂರಕಗೊಳಿಸಬಹುದು: ನಿಮ್ಮ ಸೇವೆಯು ಡಬಲ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸರಿಯಾಗಿ ನಿಭಾಯಿಸಬಹುದೇ, ಕೇವಲ 10% ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸಬಹುದೇ ಅಥವಾ ಪ್ರಸ್ತುತಕ್ಕಿಂತ ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿಭಾಯಿಸಬಹುದೇ? ವಿನಂತಿಯ ಸಂಕೀರ್ಣತೆಯನ್ನು ಬದಲಾಯಿಸುವ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಹೊಂದಿರದ ಸರಳ ಸೇವೆಗಳಿಗೆ (ಉದಾಹರಣೆಗೆ, "ನನಗೆ ಏನನ್ನೂ ಕೊಡು" ಅಥವಾ "ನನಗೆ ಅನನ್ಯ ಏಕ ಏಕತಾನದ ಪೂರ್ಣಾಂಕ ಬೇಕು"), ಅಪರೂಪವಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸುವ, ಸ್ಥಿರ ಲೋಡ್ ಪರೀಕ್ಷಾ ಮೌಲ್ಯವು ಸಾಕಾಗಬಹುದು. ಆದಾಗ್ಯೂ, ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ ಚರ್ಚಿಸಿದಂತೆ, ಹೆಚ್ಚಿನ ಸೇವೆಗಳು ಸಿಪಿಯು ಬಳಕೆ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಂತಹ ಪರೋಕ್ಷ ಸಂಕೇತಗಳನ್ನು ಬಳಸಬೇಕು, ಇದು ತಿಳಿದಿರುವ ಮೇಲಿನ ಬೌಂಡ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸುಪ್ತತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಶುದ್ಧತ್ವದ ಪ್ರಮುಖ ಸೂಚಕವಾಗಿದೆ. ಸಣ್ಣ ವಿಂಡೋದಲ್ಲಿ 99 ನೇ ಶೇಕಡಾವಾರು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಅಳೆಯುವುದು (ಉದಾ., ಒಂದು ನಿಮಿಷ) ಶುದ್ಧತ್ವದ ಆರಂಭಿಕ ಸಂಕೇತವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಅಂತಿಮವಾಗಿ, ಸ್ಯಾಚುರೇಶನ್ ಸನ್ನಿಹಿತವಾದ ಸ್ಯಾಚುರೇಶನ್ ಬಗ್ಗೆ ಮುನ್ನೋಟಗಳೊಂದಿಗೆ ಸಹ ಸಂಬಂಧಿಸಿದೆ, ಉದಾಹರಣೆಗೆ: "ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ 4 ಗಂಟೆಗಳಲ್ಲಿ ನಿಮ್ಮ ಹಾರ್ಡ್ ಡ್ರೈವ್ ಅನ್ನು ತುಂಬುತ್ತದೆ ಎಂದು ತೋರುತ್ತಿದೆ."
ನೀವು ಎಲ್ಲಾ ನಾಲ್ಕು ಗೋಲ್ಡನ್ ಸಿಗ್ನಲ್‌ಗಳನ್ನು ಅಳೆಯುತ್ತಿದ್ದರೆ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಸಮಸ್ಯೆ ಇದ್ದಾಗ (ಅಥವಾ, ಸ್ಯಾಚುರೇಶನ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಸಮೀಪದ ಸಮಸ್ಯೆ), ನೀವು ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ಎಚ್ಚರಿಸಿದರೆ, ನಿಮ್ಮ ಸೇವೆಯು ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಆವರಿಸಲ್ಪಡುತ್ತದೆ.
"ಬಾಲ" (ಅಥವಾ ಉಪಕರಣ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ) ಬಗ್ಗೆ ಚಿಂತೆ
ಮೊದಲಿನಿಂದಲೂ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವಾಗ, ಸರಾಸರಿ ಮೌಲ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಒಂದು ಪ್ರಲೋಭನೆ ಇರುತ್ತದೆ: ಸರಾಸರಿ ಸುಪ್ತತೆ, ನೋಡ್‌ಗಳ ಸರಾಸರಿ CPU ಬಳಕೆ ಅಥವಾ ಸರಾಸರಿ ಡೇಟಾಬೇಸ್ ಪೂರ್ಣತೆ. ಕೊನೆಯ ಎರಡು ಉದಾಹರಣೆಗಳ ಅಪಾಯವು ಸ್ಪಷ್ಟವಾಗಿದೆ: ಪ್ರೊಸೆಸರ್‌ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ವಿಲೇವಾರಿ ಮಾಡಲಾಗುತ್ತದೆ. ಅದೇ ವಿಳಂಬಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ವಿನಂತಿಗಳೊಂದಿಗೆ ಸರಾಸರಿ 1000ms ನಷ್ಟು ಸುಪ್ತತೆಯೊಂದಿಗೆ ವೆಬ್ ಸೇವೆಯನ್ನು ಚಲಾಯಿಸಿದರೆ, 1% ವಿನಂತಿಗಳು 5 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಬಳಕೆದಾರರು ಅಂತಹ ಅನೇಕ ವೆಬ್ ಸೇವೆಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಒಂದು ಬ್ಯಾಕೆಂಡ್‌ನ 99 ನೇ ಶೇಕಡಾವಾರು ಸುಲಭವಾಗಿ ಮುಂಭಾಗದ ಮಧ್ಯದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವಾಗಬಹುದು.
ನಿಧಾನ ಸರಾಸರಿ ಮತ್ತು ನಿಧಾನಗತಿಯ ವಿನಂತಿಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸಲು ಸರಳವಾದ ಮಾರ್ಗವೆಂದರೆ ಅಂಕಿಅಂಶಗಳಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಿದ ವಿನಂತಿಗಳ ಅಳತೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು (ಪ್ರದರ್ಶಿಸಲು ಉತ್ತಮ ಸಾಧನ ಹಿಸ್ಟೋಗ್ರಾಮ್‌ಗಳು) ನಿಜವಾದ ಲೇಟೆನ್ಸಿಗಳಿಗಿಂತ: ಸೇವೆ ಸಲ್ಲಿಸಿದ ಎಷ್ಟು ವಿನಂತಿಗಳು 0 ms ನಡುವೆ ತೆಗೆದುಕೊಂಡಿವೆ ಮತ್ತು 10 ms, 10 ms ಮತ್ತು 30 ms ನಡುವೆ, 30 ms ಮತ್ತು 100 ms ನಡುವೆ, 100 ms ಮತ್ತು 300 ms ನಡುವೆ ಇತ್ಯಾದಿ ವಿನಂತಿಗಳ.
ಅಳತೆಗಳಿಗಾಗಿ ಸೂಕ್ತ ಮಟ್ಟದ ವಿವರವನ್ನು ಆಯ್ಕೆಮಾಡುವುದು
ವ್ಯವಸ್ಥೆಯ ವಿವಿಧ ಅಂಶಗಳನ್ನು ವಿವರಗಳ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ಅಳೆಯಬೇಕು. ಉದಾಹರಣೆಗೆ:
- ಸಮಯದ ಅವಧಿಯಲ್ಲಿ CPU ಬಳಕೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದರಿಂದ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿಗಳಿಗೆ ಕಾರಣವಾಗುವ ದೀರ್ಘಾವಧಿಯ ಸ್ಪೈಕ್‌ಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ.
- ಮತ್ತೊಂದೆಡೆ, ಪ್ರತಿ ವರ್ಷಕ್ಕೆ 9 ಗಂಟೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಅಲಭ್ಯತೆಯನ್ನು ಗುರಿಯಾಗಿಸುವ ವೆಬ್ ಸೇವೆಗಾಗಿ (99,9% ವಾರ್ಷಿಕ ಅಪ್‌ಟೈಮ್), HTTP 200 ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿಮಿಷಕ್ಕೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಅಥವಾ ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸುವುದು ಅನಗತ್ಯವಾಗಿ ಆಗಾಗ್ಗೆ ಆಗುವ ಸಾಧ್ಯತೆಯಿದೆ.
- ಅಂತೆಯೇ, ಪ್ರತಿ 99,9-1 ನಿಮಿಷಗಳಿಗೊಮ್ಮೆ 2% ಲಭ್ಯತೆಗಾಗಿ ಹಾರ್ಡ್ ಡ್ರೈವ್ ಜಾಗವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಬಹುಶಃ ಅಗತ್ಯವಿಲ್ಲ.
ನಿಮ್ಮ ಅಳತೆಗಳ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿಯನ್ನು ನೀವು ಹೇಗೆ ರಚಿಸುತ್ತೀರಿ ಎಂಬುದರ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸಿ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ CPU ಲೋಡ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಆಸಕ್ತಿದಾಯಕ ಡೇಟಾವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ಅಂತಹ ಆಗಾಗ್ಗೆ ಅಳತೆಗಳು ಸಂಗ್ರಹಿಸಲು, ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಲು ತುಂಬಾ ದುಬಾರಿಯಾಗಬಹುದು. ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣಾ ಗುರಿಗೆ ಹೆಚ್ಚಿನ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿ ಅಗತ್ಯವಿದ್ದರೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರತಿಕ್ರಿಯೆಯ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಸರ್ವರ್‌ನಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಮತ್ತು ಆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸಲು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ನೀವು ಈ ವೆಚ್ಚಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು. ನೀವು:
- ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ CPU ಲೋಡ್ ಅನ್ನು ಅಳೆಯಿರಿ.
- ವಿವರವನ್ನು 5% ಗೆ ಕಡಿಮೆ ಮಾಡಿ.
- ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ.
ಹೆಚ್ಚಿನ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಶೇಖರಣಾ ಓವರ್‌ಹೆಡ್‌ಗೆ ಒಳಗಾಗದೆ ಹೆಚ್ಚಿನ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಈ ತಂತ್ರವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳ, ಆದರೆ ಸರಳವಲ್ಲ
ಒಂದರ ಮೇಲೊಂದು ವಿಭಿನ್ನ ಅವಶ್ಯಕತೆಗಳ ಮೇಲ್ಪದರವು ಬಹಳ ಸಂಕೀರ್ಣವಾದ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಕಾರಣವಾಗಬಹುದು. ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಸಿಸ್ಟಂ ಈ ಕೆಳಗಿನ ಸಂಕೀರ್ಣ ಅಂಶಗಳನ್ನು ಹೊಂದಿರಬಹುದು:
- ಎಲ್ಲಾ ರೀತಿಯ ವಿಭಿನ್ನ ಸೂಚಕಗಳಿಗಾಗಿ ವಿವಿಧ ಶೇಕಡಾವಾರುಗಳಲ್ಲಿ, ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಲೇಟೆನ್ಸಿಗಾಗಿ ವಿಭಿನ್ನ ಮಿತಿಗಳ ಪ್ರಕಾರ ಎಚ್ಚರಿಕೆಗಳು.
- ಸಂಭವನೀಯ ಕಾರಣಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಗುರುತಿಸಲು ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಬರೆಯುವುದು.
- ಸಮಸ್ಯೆಗಳ ಪ್ರತಿಯೊಂದು ಸಂಭವನೀಯ ಕಾರಣಗಳಿಗಾಗಿ ಸಂಬಂಧಿತ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ರಚಿಸಿ.
ಸಂಭಾವ್ಯ ತೊಡಕುಗಳ ಮೂಲಗಳು ಎಂದಿಗೂ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ. ಎಲ್ಲಾ ಸಾಫ್ಟ್‌ವೇರ್ ವ್ಯವಸ್ಥೆಗಳಂತೆ, ಮೇಲ್ವಿಚಾರಣೆಯು ತುಂಬಾ ಸಂಕೀರ್ಣವಾಗಬಹುದು ಮತ್ತು ಅದು ದುರ್ಬಲವಾಗಿರುತ್ತದೆ ಮತ್ತು ಬದಲಾಯಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ.
ಆದ್ದರಿಂದ, ನಿಮ್ಮ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳಗೊಳಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಿ. ಯಾವುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕೆಂದು ಆಯ್ಕೆಮಾಡುವಾಗ, ಈ ಕೆಳಗಿನವುಗಳನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ:
- ನೈಜ ಘಟನೆಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಹಿಡಿಯುವ ನಿಯಮಗಳು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳ, ಊಹಿಸಬಹುದಾದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಬೇಕು.
- ಡೇಟಾ ಸಂಗ್ರಹಣೆ, ಕ್ರೋಢೀಕರಣ ಮತ್ತು ಅಲರ್ಟಿಂಗ್‌ಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತೆಗೆದುಹಾಕಬೇಕು (ಉದಾಹರಣೆಗೆ, ಕೆಲವು SRE ತಂಡಗಳಿಗೆ ತ್ರೈಮಾಸಿಕಕ್ಕಿಂತ ಕಡಿಮೆ).
- ಸಂಗ್ರಹಿಸಿದ ಆದರೆ ಯಾವುದೇ ಪೂರ್ವವೀಕ್ಷಣೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ ತೋರಿಸದ ಅಥವಾ ಯಾವುದೇ ಎಚ್ಚರಿಕೆಯ ಮೂಲಕ ಬಳಸಲಾದ ಮೆಟ್ರಿಕ್‌ಗಳು ಅಳಿಸುವಿಕೆಗೆ ಅಭ್ಯರ್ಥಿಗಳಾಗಿವೆ.
Google ನಲ್ಲಿ, ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳೊಂದಿಗೆ ಮೂಲ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯು ತುಲನಾತ್ಮಕವಾಗಿ ಅದ್ವಿತೀಯ ವ್ಯವಸ್ಥೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (Google ನ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ವಾಸ್ತವವಾಗಿ ಹಲವಾರು ಉಪವ್ಯವಸ್ಥೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಆದರೆ ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಈ ಉಪವ್ಯವಸ್ಥೆಗಳ ಎಲ್ಲಾ ಅಂಶಗಳ ಬಗ್ಗೆ ತಿಳಿದಿರುತ್ತಾರೆ). ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಇತರ ತಂತ್ರಗಳೊಂದಿಗೆ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಸಂಯೋಜಿಸಲು ಇದು ಪ್ರಚೋದಿಸಬಹುದು: ವಿವರವಾದ ಸಿಸ್ಟಮ್ ಪ್ರೊಫೈಲಿಂಗ್, ಪ್ರಕ್ರಿಯೆ ಡೀಬಗ್ ಮಾಡುವುದು, ವಿನಾಯಿತಿಗಳು ಅಥವಾ ವೈಫಲ್ಯಗಳ ಬಗ್ಗೆ ವಿವರಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು, ಲೋಡ್ ಪರೀಕ್ಷೆ, ಲಾಗ್ ಸಂಗ್ರಹಣೆ ಮತ್ತು ವಿಶ್ಲೇಷಣೆ, ಅಥವಾ ಸಂಚಾರ ತಪಾಸಣೆ. ಇವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಮೂಲಭೂತ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ ಸಾಮಾನ್ಯತೆಯನ್ನು ಹೊಂದಿದ್ದರೂ, ಅವುಗಳನ್ನು ಮಿಶ್ರಣ ಮಾಡುವುದರಿಂದ ಹಲವಾರು ಫಲಿತಾಂಶಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಮತ್ತು ಸಂಕೀರ್ಣ ಮತ್ತು ದುರ್ಬಲವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುತ್ತದೆ. ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಇತರ ಹಲವು ಅಂಶಗಳಂತೆ, ಸ್ಪಷ್ಟವಾದ, ಸರಳವಾದ, ಸಡಿಲವಾಗಿ ಜೋಡಿಸಲಾದ ಇಂಟಿಗ್ರೇಷನ್ ಪಾಯಿಂಟ್‌ಗಳೊಂದಿಗೆ ವಿಭಿನ್ನ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವುದು ಉತ್ತಮ ತಂತ್ರವಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, ವೆಬ್ API ಅನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು ಸ್ವರೂಪದಲ್ಲಿ ಸಮಗ್ರ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಲು ಅದು ದೀರ್ಘಕಾಲದವರೆಗೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. )
ತತ್ವಗಳನ್ನು ಒಟ್ಟಿಗೆ ಕಟ್ಟುವುದು
ಈ ಅಧ್ಯಾಯದಲ್ಲಿ ಚರ್ಚಿಸಲಾದ ತತ್ವಗಳನ್ನು Google SRE ತಂಡಗಳು ಅನುಮೋದಿಸುವ ಮತ್ತು ಅನುಸರಿಸುವ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಎಚ್ಚರಿಕೆಯ ತತ್ವಶಾಸ್ತ್ರದಲ್ಲಿ ಸಂಯೋಜಿಸಬಹುದು. ಈ ಮೇಲ್ವಿಚಾರಣಾ ತತ್ವಕ್ಕೆ ಬದ್ಧವಾಗಿರುವುದು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ, ನಿಮ್ಮ ಎಚ್ಚರಿಕೆಯ ವಿಧಾನವನ್ನು ರಚಿಸಲು ಅಥವಾ ಪರಿಷ್ಕರಿಸಲು ಉತ್ತಮ ಆರಂಭದ ಹಂತವಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಗಾತ್ರ ಅಥವಾ ಸೇವೆ ಅಥವಾ ಸಿಸ್ಟಮ್‌ನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ನಿಮ್ಮ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯದ ಸರಿಯಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡಬಹುದು.
ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಎಚ್ಚರಿಕೆಯ ನಿಯಮಗಳನ್ನು ರಚಿಸುವಾಗ, ಈ ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವುದು ತಪ್ಪು ಧನಾತ್ಮಕ ಮತ್ತು ಅನಗತ್ಯ ಎಚ್ಚರಿಕೆಗಳನ್ನು ತಪ್ಪಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ:
- ಈ ನಿಯಮವು ತುರ್ತು, ಕ್ರಮಕ್ಕೆ ಕರೆಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ಮೇಲೆ ಅನಿವಾರ್ಯವಾಗಿ ಪರಿಣಾಮ ಬೀರುವ ವ್ಯವಸ್ಥೆಯ ಅನ್ಯಥಾ ಪತ್ತೆಹಚ್ಚಲಾಗದ ಸ್ಥಿತಿಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆಯೇ?
- ಇದು ಹಾನಿಕರವಲ್ಲ ಎಂದು ತಿಳಿದು ನಾನು ಈ ಎಚ್ಚರಿಕೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದೇ? ಈ ಎಚ್ಚರಿಕೆಯನ್ನು ನಾನು ಯಾವಾಗ ಮತ್ತು ಏಕೆ ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಮತ್ತು ಈ ಸನ್ನಿವೇಶವನ್ನು ನಾನು ಹೇಗೆ ತಪ್ಪಿಸಬಹುದು?
- ಈ ಎಚ್ಚರಿಕೆಯು ಬಳಕೆದಾರರ ಮೇಲೆ ನಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತಿದೆ ಎಂದು ಅರ್ಥವೇ? ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರಿಂಗ್ ಮೂಲಕ ಅಥವಾ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಬೇಕಾದ ಪರೀಕ್ಷಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬಳಸುವಾಗ ಬಳಕೆದಾರರು ಋಣಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರದ ಸಂದರ್ಭಗಳಿವೆಯೇ?
- ಈ ಎಚ್ಚರಿಕೆಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ನಾನು ಕ್ರಮ ಕೈಗೊಳ್ಳಬಹುದೇ? ಈ ಕ್ರಮಗಳು ತುರ್ತು ಅಥವಾ ಅವರು ಬೆಳಿಗ್ಗೆ ತನಕ ಕಾಯಬಹುದೇ? ಕ್ರಿಯೆಯನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದೇ? ಈ ಕ್ರಿಯೆಯು ದೀರ್ಘಾವಧಿಯ ಪರಿಹಾರವಾಗಿದೆಯೇ ಅಥವಾ ಅಲ್ಪಾವಧಿಯ ಪರಿಹಾರವಾಗಿದೆಯೇ?
- ಕೆಲವು ಜನರು ಈ ಸಮಸ್ಯೆಗಾಗಿ ಬಹು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಪಡೆಯುತ್ತಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮಾರ್ಗವಿದೆಯೇ?
ಈ ಪ್ರಶ್ನೆಗಳು ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ಎಚ್ಚರಿಕೆ ವ್ಯವಸ್ಥೆಗಳ ಮೂಲಭೂತ ತತ್ತ್ವಶಾಸ್ತ್ರವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ:
- ಪ್ರತಿ ಬಾರಿ ಎಚ್ಚರಿಕೆ ಬಂದಾಗ, ನಾನು ತಕ್ಷಣ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ನಾನು ಆಯಾಸಗೊಳ್ಳುವ ಮೊದಲು ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ ತುರ್ತಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು.
- ಪ್ರತಿಯೊಂದು ಎಚ್ಚರಿಕೆಯು ಪ್ರಸ್ತುತವಾಗಿರಬೇಕು.
- ಎಚ್ಚರಿಕೆಯ ಪ್ರತಿ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಮಾನವ ಹಸ್ತಕ್ಷೇಪದ ಅಗತ್ಯವಿದೆ. ಅಧಿಸೂಚನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದರೆ, ಅದು ಬರಬಾರದು.
- ಎಚ್ಚರಿಕೆಗಳು ಮೊದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಹೊಸ ಸಮಸ್ಯೆ ಅಥವಾ ಘಟನೆಯ ಬಗ್ಗೆ ಇರಬೇಕು.
ಈ ವಿಧಾನವು ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಮಸುಕುಗೊಳಿಸುತ್ತದೆ: ಎಚ್ಚರಿಕೆಯು ಹಿಂದಿನ ನಾಲ್ಕು ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸಿದರೆ, ಎಚ್ಚರಿಕೆಯನ್ನು ವೈಟ್-ಬಾಕ್ಸ್ ಅಥವಾ ಬ್ಲಾಕ್-ಬಾಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಕಳುಹಿಸಲಾಗಿದೆಯೇ ಎಂಬುದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. ಈ ವಿಧಾನವು ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಸಹ ಬಲಪಡಿಸುತ್ತದೆ: ಕಾರಣಗಳಿಗಿಂತ ರೋಗಲಕ್ಷಣಗಳನ್ನು ಗುರುತಿಸಲು ಹೆಚ್ಚು ಶ್ರಮವನ್ನು ವ್ಯಯಿಸುವುದು ಉತ್ತಮ; ಇದು ಕಾರಣಗಳಿಗೆ ಬಂದಾಗ, ನೀವು ಅನಿವಾರ್ಯ ಕಾರಣಗಳ ಬಗ್ಗೆ ಮಾತ್ರ ಚಿಂತಿಸಬೇಕಾಗಿದೆ.
ದೀರ್ಘಾವಧಿಯ ಮೇಲ್ವಿಚಾರಣೆ
ಇಂದಿನ ಉತ್ಪಾದಕತೆಯ ಪರಿಸರದಲ್ಲಿ, ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು ಬದಲಾಗುತ್ತಿರುವ ಸಾಫ್ಟ್‌ವೇರ್ ಆರ್ಕಿಟೆಕ್ಚರ್, ಕೆಲಸದ ಹೊರೆ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಗುರಿಗಳೊಂದಿಗೆ ನಿರಂತರವಾಗಿ ವಿಕಸನಗೊಳ್ಳುತ್ತಿರುವ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ಪ್ರಸ್ತುತ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಕಷ್ಟಕರವಾಗಿರುವ ಎಚ್ಚರಿಕೆಗಳು ಸಾಮಾನ್ಯವಾಗಬಹುದು, ಬಹುಶಃ ಪರಿಹರಿಸಲು ಯೋಗ್ಯವಾಗಿದೆ. ಈ ಹಂತದಲ್ಲಿ, ಯಾರಾದರೂ ಸಮಸ್ಯೆಯ ಮೂಲ ಕಾರಣಗಳನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಮತ್ತು ತೆಗೆದುಹಾಕಬೇಕು; ಅಂತಹ ನಿರ್ಣಯವು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಎಚ್ಚರಿಕೆಯ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಸಂಪೂರ್ಣ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅಗತ್ಯವಿರುತ್ತದೆ.
ದೀರ್ಘಾವಧಿಯ ಗುರಿಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು ಮೇಲ್ವಿಚಾರಣೆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಎಂಬುದು ಮುಖ್ಯ. ಇಂದು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಎಚ್ಚರಿಕೆಯು ನಾಳೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಧಾರಿಸುವುದರಿಂದ ವ್ಯಕ್ತಿಯನ್ನು ವಿಚಲಿತಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಧಾರಿಸಲು ಅಗತ್ಯವಿರುವ ಸಮಯಕ್ಕೆ ಉತ್ಪಾದಕ ವ್ಯವಸ್ಥೆಯ ಲಭ್ಯತೆ ಅಥವಾ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಇಳಿಕೆ ಕಂಡುಬರುತ್ತದೆ. ಈ ವಿದ್ಯಮಾನವನ್ನು ವಿವರಿಸಲು ಎರಡು ಉದಾಹರಣೆಗಳನ್ನು ನೋಡೋಣ.
ಬಿಗ್ಟೇಬಲ್ SRE: ಎ ಟೇಲ್ ಆಫ್ ಓವರ್-ಅಲರ್ಟ್
Google ನ ಆಂತರಿಕ ಮೂಲಸೌಕರ್ಯವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಒದಗಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸೇವೆಯ ಮಟ್ಟಕ್ಕೆ (SLO) ಅಳೆಯಲಾಗುತ್ತದೆ. ಹಲವು ವರ್ಷಗಳ ಹಿಂದೆ, ಬಿಗ್‌ಟೇಬಲ್‌ನ ಸೇವೆ SLO ಲೈವ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅನುಕರಿಸುವ ಸಿಂಥೆಟಿಕ್ ವಹಿವಾಟಿನ ಸರಾಸರಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಆಧರಿಸಿದೆ. ಬಿಗ್ಟೇಬಲ್ ಮತ್ತು ಸ್ಟೋರೇಜ್ ಸ್ಟಾಕ್‌ನ ಕೆಳ ಹಂತಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ, ಸರಾಸರಿ ಕಾರ್ಯಕ್ಷಮತೆಯು "ದೊಡ್ಡ" ಬಾಲದಿಂದ ನಡೆಸಲ್ಪಡುತ್ತದೆ: ಕೆಟ್ಟ 5% ಪ್ರಶ್ನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಉಳಿದವುಗಳಿಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ನಿಧಾನವಾಗಿರುತ್ತವೆ.
SLO ಮಿತಿಯನ್ನು ಸಮೀಪಿಸುತ್ತಿದ್ದಂತೆ ಇಮೇಲ್ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು SLO ಮೀರಿದಾಗ ಸಂದೇಶವಾಹಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ. ಎರಡೂ ವಿಧದ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸಾಕಷ್ಟು ಬಾರಿ ಕಳುಹಿಸಲಾಗಿದೆ, ಇದು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲದ ಎಂಜಿನಿಯರಿಂಗ್ ಸಮಯವನ್ನು ಸೇವಿಸುತ್ತದೆ: ತಂಡವು ವಾಸ್ತವವಾಗಿ ಸಂಬಂಧಿತವಾದ ಕೆಲವನ್ನು ಕಂಡುಹಿಡಿಯಲು ಎಚ್ಚರಿಕೆಗಳ ಮೂಲಕ ವಿಂಗಡಿಸಲು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ವ್ಯಯಿಸಿತು. ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಿಸಿಕೊಂಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ಕೆಲವು ಎಚ್ಚರಿಕೆಗಳು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಾಗಿ ಮಾತ್ರ. ಮೂಲಸೌಕರ್ಯದಲ್ಲಿನ ಅರ್ಥವಾಗುವ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಅನೇಕ ಎಚ್ಚರಿಕೆಗಳು ತುರ್ತು ಆಗಿರಲಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಮಾಣಿತ ರೀತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿಲ್ಲ.
ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಲು, ತಂಡವು ಮೂರು-ಮುಖದ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಂಡಿತು: ಬಿಗ್‌ಟೇಬಲ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಶ್ರಮಿಸುತ್ತಿರುವಾಗ, ನಾವು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಮ್ಮ SLO ಗುರಿಯನ್ನು ಪ್ರಶ್ನೆ ಪ್ರತಿಕ್ರಿಯೆಯ ಸುಪ್ತತೆಗೆ 75 ನೇ ಶೇಕಡಾವಾರು ಎಂದು ಹೊಂದಿಸಿದ್ದೇವೆ. ನಾವು ಇಮೇಲ್ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸಹ ಆಫ್ ಮಾಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಹಲವು ಇರುವುದರಿಂದ ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಮಯ ಕಳೆಯಲು ಅಸಾಧ್ಯವಾಗಿದೆ.
ಈ ತಂತ್ರವು ನಿರಂತರವಾಗಿ ಯುದ್ಧತಂತ್ರದ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು ಬಿಗ್ಟೇಬಲ್ ಮತ್ತು ಸ್ಟೋರೇಜ್ ಸ್ಟಾಕ್‌ನ ಕೆಳಗಿನ ಹಂತಗಳಲ್ಲಿ ದೀರ್ಘಾವಧಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಾರಂಭಿಸಲು ಉಸಿರಾಟದ ಕೋಣೆಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು. ಇಂಜಿನಿಯರ್‌ಗಳು ಸಾರ್ವಕಾಲಿಕ ಎಚ್ಚರಿಕೆಗಳೊಂದಿಗೆ ಬಾಂಬ್ ಸ್ಫೋಟಿಸದೆಯೇ ಕೆಲಸ ಮಾಡಬಹುದು. ಅಂತಿಮವಾಗಿ, ಎಚ್ಚರಿಕೆಯ ಸಂಸ್ಕರಣೆಯನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಮುಂದೂಡುವುದರಿಂದ ನಮ್ಮ ಸೇವೆಯ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
Gmail: ಊಹಿಸಬಹುದಾದ, ಅಲ್ಗಾರಿದಮಿಕ್ ಮಾನವ ಪ್ರತಿಕ್ರಿಯೆಗಳು
ಅದರ ಪ್ರಾರಂಭದಲ್ಲಿ, Gmail ಅನ್ನು ಮಾರ್ಪಡಿಸಿದ ವರ್ಕ್‌ಕ್ಯೂ ಪ್ರಕ್ರಿಯೆ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಇದನ್ನು ಹುಡುಕಾಟ ಸೂಚ್ಯಂಕದ ಪ್ರಕ್ರಿಯೆಯ ಭಾಗಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ವರ್ಕ್‌ಕ್ಯೂ ಅನ್ನು ದೀರ್ಘಾವಧಿಯ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಅಳವಡಿಸಲಾಯಿತು ಮತ್ತು ತರುವಾಯ Gmail ಗೆ ಅನ್ವಯಿಸಲಾಯಿತು, ಆದರೆ ಅಪಾರದರ್ಶಕ ಶೆಡ್ಯೂಲರ್ ಕೋಡ್‌ನಲ್ಲಿನ ಕೆಲವು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ.
ಆ ಸಮಯದಲ್ಲಿ, ವರ್ಕ್‌ಕ್ಯೂ ಬಳಸಿ ವೈಯಕ್ತಿಕ ಕಾರ್ಯಗಳನ್ನು ರದ್ದುಗೊಳಿಸಿದಾಗ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಪ್ರಚೋದಿಸಲು Gmail ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ರಚಿಸಲಾಗಿತ್ತು. ಈ ವಿಧಾನವು ಸೂಕ್ತವಲ್ಲ, ಏಕೆಂದರೆ ಆ ಸಮಯದಲ್ಲಿಯೂ ಸಹ, Gmail ಸಾವಿರಾರು ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಿತು, ಪ್ರತಿಯೊಂದೂ ನಮ್ಮ ಬಳಕೆದಾರರ ಶೇಕಡಾವಾರು ಭಾಗಕ್ಕೆ ಒದಗಿಸಲಾಗಿದೆ. Gmail ಬಳಕೆದಾರರಿಗೆ ಉತ್ತಮ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಒದಗಿಸುವ ಬಗ್ಗೆ ನಾವು ತುಂಬಾ ಕಾಳಜಿ ವಹಿಸಿದ್ದೇವೆ, ಆದರೆ ಹಲವಾರು ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ತಲುಪಲಿಲ್ಲ.
ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, Gmail SRE ಬಳಕೆದಾರರ ಮೇಲೆ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾಗಿ ಡೀಬಗ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುವ ಸಾಧನವನ್ನು ರಚಿಸಿದೆ. ದೀರ್ಘಾವಧಿಯ ಪರಿಹಾರವನ್ನು ಕಂಡುಕೊಳ್ಳುವವರೆಗೆ ಪರಿಹಾರದ ಮೂಲಕ ಸಮಸ್ಯೆಯ ಆವಿಷ್ಕಾರದಿಂದ ಸಂಪೂರ್ಣ ಚಕ್ರವನ್ನು ಸರಳವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕೆ ಎಂಬುದರ ಕುರಿತು ತಂಡವು ಕೆಲವು ಚರ್ಚೆಗಳನ್ನು ನಡೆಸಿತು, ಆದರೆ ಅಂತಹ ಪರಿಹಾರವು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ವಿಳಂಬವಾಗುತ್ತದೆ ಎಂದು ಕೆಲವರು ಕಳವಳ ವ್ಯಕ್ತಪಡಿಸಿದರು.
ಈ ಉದ್ವಿಗ್ನತೆಯು ತಂಡದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿತ್ತು ಮತ್ತು ಆಗಾಗ್ಗೆ ಸ್ವಯಂ-ಶಿಸ್ತಿನ ನಂಬಿಕೆಯ ಕೊರತೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ: ಕೆಲವು ತಂಡದ ಸದಸ್ಯರು ಸರಿಯಾದ ಪರಿಹಾರಕ್ಕಾಗಿ ಸಮಯವನ್ನು ಅನುಮತಿಸಲು ಬಯಸುತ್ತಾರೆ, ಇತರರು ಅಂತಿಮ ಪರಿಹಾರವನ್ನು ಮರೆತುಬಿಡುತ್ತಾರೆ ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವು ಶಾಶ್ವತವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಚಿಂತಿಸುತ್ತಾರೆ. ಈ ಸಮಸ್ಯೆಯು ಗಮನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ ಏಕೆಂದರೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ಶಾಶ್ವತವಾಗಿ ಮಾಡುವ ಬದಲು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಆರಂಭಿಕ "ನೋವು" ಕಡಿಮೆಯಾದ ನಂತರವೂ ದೀರ್ಘಾವಧಿಯ ಪರಿಹಾರಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಲ್ಲಿ ವ್ಯವಸ್ಥಾಪಕರು ಮತ್ತು ತಾಂತ್ರಿಕ ಸಿಬ್ಬಂದಿ ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತಾರೆ, ಸಮರ್ಥವಾಗಿ ದೀರ್ಘಕಾಲೀನ ಪರಿಹಾರಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತಾರೆ ಮತ್ತು ಆದ್ಯತೆ ನೀಡುತ್ತಾರೆ.
ನಿಯಮಿತ, ಪುನರಾವರ್ತಿತ ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ಅಲ್ಗಾರಿದಮಿಕ್ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಕೆಂಪು ಧ್ವಜವಾಗಿರಬೇಕು. ಈ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನಿಮ್ಮ ತಂಡದ ಇಷ್ಟವಿಲ್ಲದಿರುವಿಕೆ ಎಂದರೆ ತಂಡವು ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ನಂಬಬಹುದು ಎಂಬ ವಿಶ್ವಾಸವನ್ನು ಹೊಂದಿಲ್ಲ ಎಂದರ್ಥ. ಇದು ಗಂಭೀರ ಸಮಸ್ಯೆಯಾಗಿದ್ದು, ಅದನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ.
ದೀರ್ಘಕಾಲದ
ಸಾಮಾನ್ಯ ಥೀಮ್ ಬಿಗ್ಟೇಬಲ್ ಮತ್ತು ಜಿಮೇಲ್ ಉದಾಹರಣೆಗಳನ್ನು ಲಿಂಕ್ ಮಾಡುತ್ತದೆ: ಅಲ್ಪಾವಧಿಯ ಮತ್ತು ದೀರ್ಘಾವಧಿಯ ಲಭ್ಯತೆಯ ನಡುವಿನ ಸ್ಪರ್ಧೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಬಲವಾದ ಪ್ರಯತ್ನವು ದುರ್ಬಲವಾದ ವ್ಯವಸ್ಥೆಯು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಸಾಧಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಈ ಮಾರ್ಗವು ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಪಕಾಲಿಕವಾಗಿರುತ್ತದೆ, ತಂಡದ ಭಸ್ಮವಾಗಿಸುವಿಕೆಯಿಂದ ತುಂಬಿರುತ್ತದೆ ಮತ್ತು ಅದೇ ವೀರರ ತಂಡದ ಸಣ್ಣ ಸಂಖ್ಯೆಯ ಸದಸ್ಯರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ.
ನಿಯಂತ್ರಿತ, ಲಭ್ಯತೆಯಲ್ಲಿ ಅಲ್ಪಾವಧಿಯ ಕಡಿತವು ಸಾಮಾನ್ಯವಾಗಿ ನೋವಿನಿಂದ ಕೂಡಿದೆ, ಆದರೆ ವ್ಯವಸ್ಥೆಯ ದೀರ್ಘಾವಧಿಯ ಸ್ಥಿರತೆಗೆ ಕಾರ್ಯತಂತ್ರವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ. ಪ್ರತಿ ಎಚ್ಚರಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡದಿರುವುದು ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಎಚ್ಚರಿಕೆಯ ಪರಿಮಾಣದ ಒಟ್ಟಾರೆ ಮಟ್ಟವು ಕಾರ್ಯಸಾಧ್ಯವಾದ ತಂಡ ಮತ್ತು ಅನುಕೂಲಕರ ಮುನ್ನರಿವಿನೊಂದಿಗೆ ಆರೋಗ್ಯಕರ, ಸರಿಯಾಗಿ ಪ್ರವೇಶಿಸಬಹುದಾದ ವ್ಯವಸ್ಥೆಗೆ ಕಾರಣವಾಗುತ್ತದೆಯೇ ಎಂದು ಪರಿಗಣಿಸುವುದು ಮುಖ್ಯ. ನಾವು ಎಚ್ಚರಿಕೆಯ ಆವರ್ತನ ಅಂಕಿಅಂಶಗಳನ್ನು (ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಶಿಫ್ಟ್‌ಗೆ ಘಟನೆಗಳಂತೆ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಘಟನೆಯು ಬಹು ಸಂಬಂಧಿತ ಘಟನೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ) ನಿರ್ವಹಣೆಗೆ ತ್ರೈಮಾಸಿಕ ವರದಿಗಳಲ್ಲಿ, ನಿರ್ಧಾರ ತಯಾರಕರು ಎಚ್ಚರಿಕೆಯ ಸಿಸ್ಟಮ್ ಲೋಡ್ ಮತ್ತು ಒಟ್ಟಾರೆ ತಂಡದ ಆರೋಗ್ಯದ ನಿರಂತರ ನೋಟವನ್ನು ಹೊಂದಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ತೀರ್ಮಾನಕ್ಕೆ
ಆರೋಗ್ಯಕರ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಎಚ್ಚರಿಕೆಯ ಮಾರ್ಗವು ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇದು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಪ್ರಚೋದಿಸುವ ಸಮಸ್ಯೆಯ ಲಕ್ಷಣಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಕಾರಣವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಡೀಬಗ್ ಮಾಡುವ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನೀವು ನಿಯಂತ್ರಿಸುವ ಸ್ಟಾಕ್‌ನಲ್ಲಿ ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯಲ್ಲಿದ್ದರೆ ರೋಗಲಕ್ಷಣಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಸುಲಭವಾಗಿದೆ, ಆದಾಗ್ಯೂ ಡೇಟಾಬೇಸ್‌ನ ಮೇಲ್ವಿಚಾರಣೆ ಲೋಡ್ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಮಾಡಬೇಕು. ಇಮೇಲ್ ಅಧಿಸೂಚನೆಗಳು ಬಹಳ ಸೀಮಿತ ಉಪಯುಕ್ತತೆಯನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಸುಲಭವಾಗಿ ಶಬ್ದವಾಗುತ್ತವೆ; ಬದಲಿಗೆ, ಇಮೇಲ್ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಪ್ರಚೋದಿಸುವ ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ಸಮಸ್ಯೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ನೀವು ಬಳಸಬೇಕು. ಐತಿಹಾಸಿಕ ಪರಸ್ಪರ ಸಂಬಂಧಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ಈವೆಂಟ್ ಲಾಗ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಬಹುದು.
ದೀರ್ಘಾವಧಿಯಲ್ಲಿ, ರೋಗಲಕ್ಷಣಗಳು ಮತ್ತು ಸನ್ನಿಹಿತವಾದ ನೈಜ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆಗಳ ಯಶಸ್ವಿ ತಿರುಗುವಿಕೆಯನ್ನು ಸಾಧಿಸುವುದು ಅವಶ್ಯಕವಾಗಿದೆ, ಮೇಲ್ವಿಚಾರಣೆಯು ತ್ವರಿತ ರೋಗನಿರ್ಣಯವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಗುರಿಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು.
ಅನುವಾದವನ್ನು ಕೊನೆಯವರೆಗೂ ಓದಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು. ಮೇಲ್ವಿಚಾರಣೆಯ ಕುರಿತು ನನ್ನ ಟೆಲಿಗ್ರಾಮ್ ಚಾನಲ್‌ಗೆ ಚಂದಾದಾರರಾಗಿ и .
ಮೂಲ: www.habr.com