ನನ್ನ ಹೆಸರು ಆಂಟನ್ ಬ್ಯಾಡೆರಿನ್. ನಾನು ಹೈ ಟೆಕ್ನಾಲಜಿ ಸೆಂಟರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಷನ್ ಮಾಡುತ್ತೇನೆ. ಒಂದು ತಿಂಗಳ ಹಿಂದೆ, ನಮ್ಮ ಕಾರ್ಪೊರೇಟ್ ಸಮ್ಮೇಳನವು ಕೊನೆಗೊಂಡಿತು, ಅಲ್ಲಿ ನಾವು ನಮ್ಮ ನಗರದ ಐಟಿ ಸಮುದಾಯದೊಂದಿಗೆ ನಮ್ಮ ಸಂಗ್ರಹವಾದ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದೇವೆ. ನಾನು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಕುರಿತು ಮಾತನಾಡಿದ್ದೇನೆ. ವಸ್ತುವನ್ನು ಕಿರಿಯ ಅಥವಾ ಮಧ್ಯಮ ಹಂತಕ್ಕೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ, ಅವರು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮೊದಲಿನಿಂದ ನಿರ್ಮಿಸಲಿಲ್ಲ.
ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯ ಆಧಾರವಾಗಿರುವ ಮೂಲಾಧಾರವು ವ್ಯಾಪಾರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಿದೆ. ಮೇಲ್ವಿಚಾರಣೆಯ ಸಲುವಾಗಿ ಮಾನಿಟರಿಂಗ್ ಯಾರಿಗೂ ಆಸಕ್ತಿಯಿಲ್ಲ. ವ್ಯಾಪಾರಕ್ಕೆ ಏನು ಬೇಕು? ಆದ್ದರಿಂದ ಎಲ್ಲವೂ ತ್ವರಿತವಾಗಿ ಮತ್ತು ದೋಷಗಳಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವ್ಯವಹಾರಗಳು ಪೂರ್ವಭಾವಿಯಾಗಿರಲು ಬಯಸುತ್ತವೆ, ಇದರಿಂದಾಗಿ ನಾವು ಸೇವೆಯಲ್ಲಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸುತ್ತೇವೆ ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ. ವಾಸ್ತವವಾಗಿ, ನಮ್ಮ ಗ್ರಾಹಕರೊಬ್ಬರಿಗಾಗಿ ಯೋಜನೆಯಲ್ಲಿ ಕಳೆದ ವರ್ಷ ನಾನು ಪರಿಹರಿಸಿದ ಸಮಸ್ಯೆಗಳು ಇವು.
ಯೋಜನೆಯ ಬಗ್ಗೆ
ಈ ಯೋಜನೆಯು ದೇಶದ ಅತಿದೊಡ್ಡ ಲಾಯಲ್ಟಿ ಕಾರ್ಯಕ್ರಮಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಬೋನಸ್ ಕಾರ್ಡ್‌ಗಳಂತಹ ವಿವಿಧ ಮಾರ್ಕೆಟಿಂಗ್ ಪರಿಕರಗಳ ಮೂಲಕ ಮಾರಾಟದ ಆವರ್ತನವನ್ನು ಹೆಚ್ಚಿಸಲು ನಾವು ಚಿಲ್ಲರೆ ಸರಪಳಿಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತೇವೆ. ಒಟ್ಟಾರೆಯಾಗಿ, ಯೋಜನೆಯು ಹತ್ತು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ 14 ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ಸಂದರ್ಶನದ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಿರ್ವಾಹಕರು ಯಾವಾಗಲೂ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾನು ಪದೇ ಪದೇ ಗಮನಿಸಿದ್ದೇನೆ: ಅನೇಕರು ಇನ್ನೂ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಸಾಂದರ್ಭಿಕವಾಗಿ ಸೇವೆಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಾರೆ.
ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, ಗ್ರಾಹಕರ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯು ಹಿಂದೆ ಐಸಿಂಗಾವನ್ನು ಆಧರಿಸಿದೆ. ಇದು ಮೇಲಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲಿಲ್ಲ. ಆಗಾಗ್ಗೆ ಕ್ಲೈಂಟ್ ಸ್ವತಃ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸಿದರು, ಮತ್ತು ಹೆಚ್ಚಾಗಿ, ಕಾರಣದ ಕೆಳಭಾಗಕ್ಕೆ ಹೋಗಲು ನಾವು ಸಾಕಷ್ಟು ಡೇಟಾವನ್ನು ಹೊಂದಿಲ್ಲ.
ಇದರ ಜೊತೆಗೆ, ಅದರ ಮುಂದಿನ ಅಭಿವೃದ್ಧಿಯ ನಿರರ್ಥಕತೆಯ ಬಗ್ಗೆ ಸ್ಪಷ್ಟವಾದ ತಿಳುವಳಿಕೆ ಇತ್ತು. ಐಸಿಂಗನ ಪರಿಚಯವಿರುವವರು ನನ್ನನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದ್ದರಿಂದ, ಯೋಜನೆಗಾಗಿ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರುವಿನ್ಯಾಸಗೊಳಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಪ್ರಮೀತಿಯಸ್
ನಾವು ಮೂರು ಪ್ರಮುಖ ಸೂಚಕಗಳ ಆಧಾರದ ಮೇಲೆ ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ:
- ಲಭ್ಯವಿರುವ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮೆಟ್ರಿಕ್‌ಗಳು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳಲ್ಲಿ 60 ಸಾವಿರ ಇವೆ. ಸಹಜವಾಗಿ, ಅವುಗಳಲ್ಲಿ ಬಹುಪಾಲು (ಬಹುಶಃ ಸುಮಾರು 95%) ನಾವು ಬಳಸುವುದಿಲ್ಲ ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ. ಮತ್ತೊಂದೆಡೆ, ಅವೆಲ್ಲವೂ ತುಲನಾತ್ಮಕವಾಗಿ ಅಗ್ಗವಾಗಿವೆ. ನಮಗೆ, ಈ ಹಿಂದೆ ಬಳಸಿದ ಐಸಿಂಗಾಗೆ ಹೋಲಿಸಿದರೆ ಇದು ಇತರ ವಿಪರೀತವಾಗಿದೆ. ಅದರಲ್ಲಿ, ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ನೋವು: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳು ದುಬಾರಿಯಾಗಿದೆ (ಯಾವುದೇ ಪ್ಲಗಿನ್‌ನ ಮೂಲ ಕೋಡ್ ಅನ್ನು ನೋಡಿ). ಯಾವುದೇ ಪ್ಲಗಿನ್ ಬ್ಯಾಷ್ ಅಥವಾ ಪೈಥಾನ್‌ನಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿದ್ದು, ಅದರ ಉಡಾವಣೆಯು ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ವಿಷಯದಲ್ಲಿ ದುಬಾರಿಯಾಗಿದೆ.
- ಈ ವ್ಯವಸ್ಥೆಯು ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ. ನಮ್ಮ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ 600 MB RAM, 15% ಒಂದು ಕೋರ್ ಮತ್ತು ಒಂದೆರಡು ಡಜನ್ IOPS ಸಾಕು. ಸಹಜವಾಗಿ, ನೀವು ಮೆಟ್ರಿಕ್ಸ್ ರಫ್ತುದಾರರನ್ನು ಚಲಾಯಿಸಬೇಕು, ಆದರೆ ಅವೆಲ್ಲವನ್ನೂ ಗೋದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚು ಶಕ್ತಿ ಹಸಿವಿನಿಂದ ಕೂಡಿರುವುದಿಲ್ಲ. ಆಧುನಿಕ ವಾಸ್ತವಗಳಲ್ಲಿ ಇದು ಸಮಸ್ಯೆ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ.
- ಕುಬರ್ನೆಟ್ಸ್ಗೆ ವಲಸೆ ಹೋಗುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಗ್ರಾಹಕರ ಯೋಜನೆಗಳನ್ನು ಪರಿಗಣಿಸಿ, ಆಯ್ಕೆಯು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ELK
ಹಿಂದೆ, ನಾವು ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಿಲ್ಲ ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಿಲ್ಲ. ನ್ಯೂನತೆಗಳು ಎಲ್ಲರಿಗೂ ಸ್ಪಷ್ಟವಾಗಿವೆ. ನಾವು ELK ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಾವು ಈಗಾಗಲೇ ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅನುಭವವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಅಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್‌ಗಳನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಮುಖ್ಯ ಆಯ್ಕೆಯ ಮಾನದಂಡವೆಂದರೆ ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟ ಮತ್ತು ಅದರ ವೇಗ.
ಲಿಕ್‌ಹೌಸ್
ಆರಂಭದಲ್ಲಿ, ಆಯ್ಕೆಯು InfluxDB ಮೇಲೆ ಬಿದ್ದಿತು. Nginx ಲಾಗ್ಗಳು, pg_stat_statements ನಿಂದ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು Prometheus ಐತಿಹಾಸಿಕ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವನ್ನು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ನಮಗೆ ಇನ್‌ಫ್ಲಕ್ಸ್ ಇಷ್ಟವಾಗಲಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ನಿಯತಕಾಲಿಕವಾಗಿ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಮೆಮೊರಿಯನ್ನು ಬಳಸಲಾರಂಭಿಸಿತು ಮತ್ತು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾನು remote_addr ಮೂಲಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಗುಂಪು ಮಾಡಲು ಬಯಸುತ್ತೇನೆ, ಆದರೆ ಈ DBMS ನಲ್ಲಿ ಗುಂಪು ಮಾಡುವುದು ಟ್ಯಾಗ್‌ಗಳ ಮೂಲಕ ಮಾತ್ರ. ಟ್ಯಾಗ್‌ಗಳು ದುಬಾರಿಯಾಗಿದೆ (ಮೆಮೊರಿ), ಅವುಗಳ ಸಂಖ್ಯೆ ಷರತ್ತುಬದ್ಧವಾಗಿ ಸೀಮಿತವಾಗಿದೆ.
ಮತ್ತೆ ನಮ್ಮ ಹುಡುಕಾಟ ಶುರು ಮಾಡಿದೆವು. ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯೊಂದಿಗೆ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಡೇಟಾಬೇಸ್ ಅಗತ್ಯವಿತ್ತು, ಮೇಲಾಗಿ ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಡೇಟಾ ಸಂಕೋಚನದೊಂದಿಗೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಈ ಎಲ್ಲಾ ಮಾನದಂಡಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಆಯ್ಕೆಗೆ ನಾವು ಎಂದಿಗೂ ವಿಷಾದಿಸಿಲ್ಲ. ನಾವು ಅದರಲ್ಲಿ ಯಾವುದೇ ಅಸಾಧಾರಣ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಬರೆಯುವುದಿಲ್ಲ (ಅಳವಡಿಕೆಗಳ ಸಂಖ್ಯೆ ನಿಮಿಷಕ್ಕೆ ಕೇವಲ ಐದು ಸಾವಿರ ಮಾತ್ರ).
ನ್ಯೂರೆಲಿಕ್
NewRelic ಐತಿಹಾಸಿಕವಾಗಿ ನಮ್ಮೊಂದಿಗೆ ಇದೆ ಏಕೆಂದರೆ ಅದು ಗ್ರಾಹಕರ ಆಯ್ಕೆಯಾಗಿದೆ. ನಾವು ಅದನ್ನು ಎಪಿಎಂ ಆಗಿ ಬಳಸುತ್ತೇವೆ.
ಜಬ್ಬಿಕ್ಸ್
ವಿವಿಧ API ಗಳ ಬ್ಲಾಕ್ ಬಾಕ್ಸ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ನಾವು Zabbix ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬಳಸುತ್ತೇವೆ.
ಮಾನಿಟರಿಂಗ್ ಅಪ್ರೋಚ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದು
ನಾವು ಕಾರ್ಯವನ್ನು ಕೊಳೆಯಲು ಬಯಸಿದ್ದೇವೆ ಮತ್ತು ಆ ಮೂಲಕ ಮೇಲ್ವಿಚಾರಣೆಯ ವಿಧಾನವನ್ನು ವ್ಯವಸ್ಥಿತಗೊಳಿಸುತ್ತೇವೆ.
ಇದನ್ನು ಮಾಡಲು, ನಾನು ನಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಈ ಕೆಳಗಿನ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಿದೆ:
- ಯಂತ್ರಾಂಶ ಮತ್ತು VMS;
- ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್;
- ಸಿಸ್ಟಮ್ ಸೇವೆಗಳು, ಸಾಫ್ಟ್ವೇರ್ ಸ್ಟಾಕ್;
- ಅಪ್ಲಿಕೇಶನ್;
- ವ್ಯಾಪಾರ ತರ್ಕ.
ಈ ವಿಧಾನವು ಏಕೆ ಅನುಕೂಲಕರವಾಗಿದೆ:
- ಪ್ರತಿ ಹಂತದ ಕೆಲಸಕ್ಕೆ ಯಾರು ಜವಾಬ್ದಾರರು ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ ಮತ್ತು ಇದರ ಆಧಾರದ ಮೇಲೆ ನಾವು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಳುಹಿಸಬಹುದು;
- ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿಗ್ರಹಿಸುವಾಗ ನಾವು ರಚನೆಯನ್ನು ಬಳಸಬಹುದು - ಒಟ್ಟಾರೆಯಾಗಿ ವರ್ಚುವಲ್ ಯಂತ್ರವು ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಡೇಟಾಬೇಸ್ ಅಲಭ್ಯತೆಯ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆಯನ್ನು ಕಳುಹಿಸುವುದು ವಿಚಿತ್ರವಾಗಿದೆ.
ಸಿಸ್ಟಂನ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಉಲ್ಲಂಘನೆಗಳನ್ನು ಗುರುತಿಸುವುದು ನಮ್ಮ ಕಾರ್ಯವಾಗಿರುವುದರಿಂದ, ಎಚ್ಚರಿಕೆಯ ನಿಯಮಗಳನ್ನು ಬರೆಯುವಾಗ ಗಮನ ಕೊಡಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಾವು ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಹೈಲೈಟ್ ಮಾಡಬೇಕು. ಮುಂದೆ, "VMS", "ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್" ಮತ್ತು "ಸಿಸ್ಟಮ್ ಸೇವೆಗಳು, ಸಾಫ್ಟ್ವೇರ್ ಸ್ಟಾಕ್" ಹಂತಗಳ ಮೂಲಕ ಹೋಗೋಣ.
ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು
ಹೋಸ್ಟಿಂಗ್ ನಮಗೆ ಪ್ರೊಸೆಸರ್, ಡಿಸ್ಕ್, ಮೆಮೊರಿ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಮೊದಲ ಎರಡರಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ಮೆಟ್ರಿಕ್ಸ್:
CPU ಕದ್ದ ಸಮಯ - ನೀವು ಅಮೆಜಾನ್‌ನಲ್ಲಿ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಖರೀದಿಸಿದಾಗ (t2.micro, ಉದಾಹರಣೆಗೆ), ನಿಮಗೆ ಸಂಪೂರ್ಣ ಪ್ರೊಸೆಸರ್ ಕೋರ್ ಅನ್ನು ನಿಯೋಜಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಅದರ ಸಮಯದ ಕೋಟಾ ಮಾತ್ರ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಮತ್ತು ನೀವು ಅದನ್ನು ಖಾಲಿ ಮಾಡಿದಾಗ, ಪ್ರೊಸೆಸರ್ ಅನ್ನು ನಿಮ್ಮಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.
ಅಂತಹ ಕ್ಷಣಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಮತ್ತು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಈ ಮೆಟ್ರಿಕ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ದಪ್ಪವಾದ ಸುಂಕವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಅಥವಾ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳು ಮತ್ತು API ವಿನಂತಿಗಳ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವಿಧ ಸರ್ವರ್‌ಗಳಿಗೆ ವಿತರಿಸುವುದು ಅಗತ್ಯವೇ?
IOPS + CPU iowait ಸಮಯ - ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, ಸಾಕಷ್ಟು IOPS ಅನ್ನು ಒದಗಿಸದಿರುವ ಮೂಲಕ ಅನೇಕ ಕ್ಲೌಡ್ ಹೋಸ್ಟಿಂಗ್‌ಗಳು ಪಾಪ ಮಾಡುತ್ತವೆ. ಇದಲ್ಲದೆ, ಕಡಿಮೆ IOPS ಹೊಂದಿರುವ ವೇಳಾಪಟ್ಟಿ ಅವರಿಗೆ ಒಂದು ವಾದವಲ್ಲ. ಆದ್ದರಿಂದ, CPU iowait ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಈ ಜೋಡಿ ಗ್ರಾಫ್‌ಗಳೊಂದಿಗೆ - ಕಡಿಮೆ IOPS ಮತ್ತು ಹೆಚ್ಚಿನ I/O ಕಾಯುವಿಕೆಯೊಂದಿಗೆ - ನೀವು ಈಗಾಗಲೇ ಹೋಸ್ಟಿಂಗ್‌ನೊಂದಿಗೆ ಮಾತನಾಡಬಹುದು ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದು.
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್ಸ್:
- % ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಮೆಮೊರಿಯ ಪ್ರಮಾಣ;
- ಸ್ವಾಪ್ ಬಳಕೆಯ ಚಟುವಟಿಕೆ: vmstat ಸ್ವಾಪಿನ್, ಸ್ವಾಪ್ಔಟ್;
- ಲಭ್ಯವಿರುವ ಐನೋಡ್‌ಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ % ನಲ್ಲಿ ಮುಕ್ತ ಸ್ಥಳ
- ಸರಾಸರಿ ಲೋಡ್;
- ಎರಡು ಸ್ಥಿತಿಯಲ್ಲಿ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ;
- ಕಾಂಟ್ರಾಕ್ ಟೇಬಲ್ ಪೂರ್ಣತೆ;
- ನೆಟ್ವರ್ಕ್ನ ಗುಣಮಟ್ಟವನ್ನು ss ಯುಟಿಲಿಟಿ, iproute2 ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು - ಅದರ ಔಟ್ಪುಟ್ನಿಂದ RTT ಸಂಪರ್ಕಗಳ ಸೂಚಕವನ್ನು ಪಡೆಯಿರಿ ಮತ್ತು ಅದನ್ನು ಡೆಸ್ಟ್ ಪೋರ್ಟ್ ಮೂಲಕ ಗುಂಪು ಮಾಡಿ.
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ನಾವು ಪ್ರಕ್ರಿಯೆಗಳಂತಹ ಘಟಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅದರ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳ ಗುಂಪನ್ನು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಗುರುತಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ಹಲವಾರು pgpools ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ.
ಮೆಟ್ರಿಕ್‌ಗಳ ಸೆಟ್ ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:
- ಸಿಪಿಯು;
- ಮೆಮೊರಿ ಪ್ರಾಥಮಿಕವಾಗಿ ನಿವಾಸಿ;
- IO - ಮೇಲಾಗಿ IOPS ನಲ್ಲಿ;
- FileFd - ತೆರೆದ ಮತ್ತು ಮಿತಿ;
- ಗಮನಾರ್ಹ ಪುಟ ವೈಫಲ್ಯಗಳು - ಈ ರೀತಿಯಾಗಿ ನೀವು ಯಾವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.
ನಾವು ಡಾಕರ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ ಮತ್ತು ಮೆಟ್ರಿಕ್ಸ್ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ಸಲಹೆಗಾರರನ್ನು ಬಳಸುತ್ತೇವೆ. ಇತರ ಯಂತ್ರಗಳಲ್ಲಿ ನಾವು ಪ್ರಕ್ರಿಯೆ-ರಫ್ತುದಾರರನ್ನು ಬಳಸುತ್ತೇವೆ.
ಸಿಸ್ಟಮ್ ಸೇವೆಗಳು, ಸಾಫ್ಟ್ವೇರ್ ಸ್ಟಾಕ್
ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಆದ ನಿಶ್ಚಿತಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಕಷ್ಟ.
ಸಾರ್ವತ್ರಿಕ ಸೆಟ್ ಹೀಗಿದೆ:
- ವಿನಂತಿ ದರ;
- ತಪ್ಪುಗಳ ಸಂಖ್ಯೆ;
- ಸುಪ್ತತೆ;
- ಶುದ್ಧತ್ವ.
ಈ ಮಟ್ಟದಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆಯ ನಮ್ಮ ಅತ್ಯಂತ ಗಮನಾರ್ಹ ಉದಾಹರಣೆಗಳೆಂದರೆ Nginx ಮತ್ತು PostgreSQL.
ನಮ್ಮ ಸಿಸ್ಟಂನಲ್ಲಿ ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಸೇವೆ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಹಿಂದೆ, ಡೇಟಾಬೇಸ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಮಗೆ ಆಗಾಗ್ಗೆ ತೊಂದರೆಯಾಗುತ್ತಿತ್ತು.
ನಾವು ಡಿಸ್ಕ್ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಲೋಡ್ ಅನ್ನು ನೋಡಿದ್ದೇವೆ, ಆದರೆ ನಿಧಾನ ಲಾಗ್ಗಳು ನಿಜವಾಗಿಯೂ ಏನನ್ನೂ ತೋರಿಸಲಿಲ್ಲ. ನಾವು pg_stat_statements ಅನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ, ಇದು ಪ್ರಶ್ನೆ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ನಿರ್ವಾಹಕರಿಗೆ ಬೇಕಾಗಿರುವುದು ಇಷ್ಟೇ.
ನಾವು ಓದುವ ಮತ್ತು ಬರೆಯುವ ವಿನಂತಿಗಳ ಚಟುವಟಿಕೆಯ ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ:
ಎಲ್ಲವೂ ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಪ್ರತಿ ವಿನಂತಿಯು ತನ್ನದೇ ಆದ ಬಣ್ಣವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಸಮಾನವಾದ ಗಮನಾರ್ಹ ಉದಾಹರಣೆಯೆಂದರೆ Nginx ಲಾಗ್ಗಳು. ಕೆಲವು ಜನರು ಅವುಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುವುದು ಅಥವಾ ಹೊಂದಿರಬೇಕಾದ ಪಟ್ಟಿಯಲ್ಲಿ ನಮೂದಿಸುವುದು ಆಶ್ಚರ್ಯವೇನಿಲ್ಲ. ಪ್ರಮಾಣಿತ ಸ್ವರೂಪವು ಹೆಚ್ಚು ತಿಳಿವಳಿಕೆ ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ವಿಸ್ತರಿಸಬೇಕಾಗಿದೆ.
ವೈಯಕ್ತಿಕವಾಗಿ, ನಾನು request_time, upstream_response_time, body_bytes_sent, request_length, request_id ಅನ್ನು ಸೇರಿಸಿದ್ದೇನೆ. ನಾವು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಮತ್ತು ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಯೋಜಿಸುತ್ತೇವೆ:
ನಾವು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಮತ್ತು ದೋಷಗಳ ಸಂಖ್ಯೆಯ ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ. ನೆನಪಿದೆಯೇ? ನಾನು ವ್ಯಾಪಾರ ಕಾರ್ಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿದ್ದೇನೆಯೇ? ತ್ವರಿತವಾಗಿ ಮತ್ತು ದೋಷಗಳಿಲ್ಲದೆ? ನಾವು ಈಗಾಗಲೇ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಎರಡು ಚಾರ್ಟ್‌ಗಳೊಂದಿಗೆ ಆವರಿಸಿದ್ದೇವೆ. ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕರ್ತವ್ಯದಲ್ಲಿರುವ ನಿರ್ವಾಹಕರನ್ನು ನೀವು ಈಗಾಗಲೇ ಕರೆಯಬಹುದು.
ಆದರೆ ಇನ್ನೂ ಒಂದು ಸಮಸ್ಯೆ ಉಳಿದಿದೆ - ಘಟನೆಯ ಕಾರಣಗಳ ತ್ವರಿತ ನಿರ್ಮೂಲನೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು.
ಘಟನೆ ಪರಿಹಾರ
ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸುವುದರಿಂದ ಹಿಡಿದು ಪರಿಹರಿಸುವವರೆಗಿನ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹಲವಾರು ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:
- ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸುವುದು;
- ಕರ್ತವ್ಯ ನಿರ್ವಾಹಕರಿಗೆ ಸೂಚನೆ;
- ಘಟನೆಗೆ ಪ್ರತಿಕ್ರಿಯೆ;
- ಕಾರಣಗಳ ನಿರ್ಮೂಲನೆ.
ನಾವು ಇದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಮಾಡಬೇಕು ಎಂಬುದು ಮುಖ್ಯ. ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸುವ ಮತ್ತು ಅಧಿಸೂಚನೆಯನ್ನು ಕಳುಹಿಸುವ ಹಂತಗಳಲ್ಲಿ ನಾವು ಹೆಚ್ಚು ಸಮಯವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ - ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಅವರಿಗೆ ಎರಡು ನಿಮಿಷಗಳನ್ನು ಕಳೆಯಲಾಗುತ್ತದೆ, ನಂತರದವುಗಳು ಸುಧಾರಣೆಗಳಿಗಾಗಿ ಸರಳವಾಗಿ ಉಳುಮೆ ಮಾಡಿದ ಕ್ಷೇತ್ರವಾಗಿದೆ.
ಡ್ಯೂಟಿ ಆಫೀಸರ್ ಫೋನ್ ರಿಂಗಾಯಿತು ಎಂದು ಊಹಿಸೋಣ. ಅವನು ಏನು ಮಾಡುತ್ತಾನೆ? ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಗಳನ್ನು ನೋಡಿ - ಏನು ಮುರಿದುಹೋಯಿತು, ಎಲ್ಲಿ ಮುರಿದುಹೋಯಿತು, ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು? ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ನಾವು ಹೇಗೆ ಉತ್ತರಿಸುತ್ತೇವೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:
ಅಧಿಸೂಚನೆಯ ಪಠ್ಯದಲ್ಲಿ ನಾವು ಈ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ಸರಳವಾಗಿ ಸೇರಿಸುತ್ತೇವೆ, ಈ ಸಮಸ್ಯೆಗೆ ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು, ಅದನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಉಲ್ಬಣಗೊಳಿಸಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ವಿಕಿ ಪುಟಕ್ಕೆ ಲಿಂಕ್ ಅನ್ನು ನೀಡಿ.
ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ ಮತ್ತು ವ್ಯವಹಾರ ತರ್ಕದ ಬಗ್ಗೆ ನಾನು ಇನ್ನೂ ಏನನ್ನೂ ಹೇಳಿಲ್ಲ. ದುರದೃಷ್ಟವಶಾತ್, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇನ್ನೂ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಗ್ರಹಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿಲ್ಲ. ಈ ಹಂತಗಳಿಂದ ಯಾವುದೇ ಮಾಹಿತಿಯ ಏಕೈಕ ಮೂಲವೆಂದರೆ ಲಾಗ್ಗಳು.
ಒಂದೆರಡು ಅಂಕಗಳು.
ಮೊದಲಿಗೆ, ರಚನಾತ್ಮಕ ದಾಖಲೆಗಳನ್ನು ಬರೆಯಿರಿ. ಸಂದೇಶದ ಪಠ್ಯದಲ್ಲಿ ಸಂದರ್ಭವನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ಅವರನ್ನು ಗುಂಪು ಮಾಡಲು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಇದೆಲ್ಲವನ್ನೂ ಸಾಮಾನ್ಯಗೊಳಿಸಲು ಲಾಗ್‌ಸ್ಟಾಶ್ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಎರಡನೆಯದಾಗಿ, ತೀವ್ರತೆಯ ಮಟ್ಟವನ್ನು ಸರಿಯಾಗಿ ಬಳಸಿ. ಪ್ರತಿಯೊಂದು ಭಾಷೆಗೂ ತನ್ನದೇ ಆದ ಮಾನದಂಡವಿದೆ. ವೈಯಕ್ತಿಕವಾಗಿ, ನಾನು ನಾಲ್ಕು ಹಂತಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇನೆ:
- ದೋಷವಿಲ್ಲ;
- ಕ್ಲೈಂಟ್ ಸೈಡ್ ದೋಷ;
- ತಪ್ಪು ನಮ್ಮ ಕಡೆ ಇದೆ, ನಾವು ಹಣವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ನಾವು ಅಪಾಯಗಳನ್ನು ಹೊಂದುವುದಿಲ್ಲ;
- ತಪ್ಪು ನಮ್ಮ ಕಡೆ ಇದೆ, ನಾವು ಹಣವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ.
ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುತ್ತೇನೆ. ವ್ಯಾಪಾರ ತರ್ಕದ ಆಧಾರದ ಮೇಲೆ ನೀವು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಕು. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸ್ವತಃ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಮಾರಾಟದ ಸಂಖ್ಯೆ, ಹೊಸ ಬಳಕೆದಾರರ ನೋಂದಣಿಗಳ ಸಂಖ್ಯೆ, ಪ್ರಸ್ತುತ ಸಕ್ರಿಯ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆ ಮತ್ತು ಮುಂತಾದ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಯತ್ನಿಸಿ.
ನಿಮ್ಮ ಸಂಪೂರ್ಣ ವ್ಯಾಪಾರವು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಒಂದು ಬಟನ್ ಆಗಿದ್ದರೆ, ಅದು ಕ್ಲಿಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಉಳಿದೆಲ್ಲವೂ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ.
ನೀವು ಇದನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಮಾಡಿದಂತೆ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್ಗಳು, Nginx ಲಾಗ್ಗಳು ಮತ್ತು ಮುಂತಾದವುಗಳಲ್ಲಿ ನೀವು ಅದನ್ನು ಹಿಡಿಯಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರದಲ್ಲಿರಬೇಕು.
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳು ಸಹಜವಾಗಿ ಮುಖ್ಯವಾಗಿವೆ, ಆದರೆ ವ್ಯಾಪಾರವು ಅವುಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿಲ್ಲ, ನಾವು ಅವರಿಗೆ ಪಾವತಿಸುವುದಿಲ್ಲ.
ಮೂಲ: www.habr.com