🥇 ಮಾನಿಟರಿಂಗ್ ಸತ್ತಿದೆಯೇ? — ಲಾಂಗ್ ಲೈವ್ ಮಾನಿಟರಿಂಗ್

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

ಸರಿಯಾದ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಯೋಜಿಸುವಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ. ಯಾವುದೇ ತೊಂದರೆ ಇಲ್ಲದಿದ್ದರೆ, ನನ್ನ ಭಾಷಣವು ಒಂದು ಪ್ರಬಂಧವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ: "ದಯವಿಟ್ಟು ಪ್ರಮೀತಿಯಸ್ + ಗ್ರಾಫನಾ ಮತ್ತು ಪ್ಲಗಿನ್‌ಗಳು 1, 2, 3 ಅನ್ನು ಸ್ಥಾಪಿಸಿ." ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಇನ್ನು ಮುಂದೆ ಆ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತು ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ, ಸಾಫ್ಟ್‌ವೇರ್ ಘಟಕಗಳ ವಿಷಯದಲ್ಲಿ 2008 ರಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದ ಯಾವುದನ್ನಾದರೂ ಎಲ್ಲರೂ ನಂಬುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ.

ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯ ಸಂಘಟನೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಾನು ಹೇಳಲು ಸಾಹಸ ಮಾಡುತ್ತೇನೆ ... ಸಮರ್ಥ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ ಯೋಜನೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಮತ್ತು ಪರಿಸ್ಥಿತಿ ತುಂಬಾ ಕೆಟ್ಟದಾಗಿದೆ, ಏನಾದರೂ ಬಿದ್ದರೆ, ಅದು ಗಮನಿಸದೆ ಹೋಗುವ ಅಪಾಯವಿದೆ - ಎಲ್ಲಾ ನಂತರ, "ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ" ಎಂದು ಎಲ್ಲರಿಗೂ ಖಚಿತವಾಗಿದೆ.
ಬಹುಶಃ ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತಿದೆ. ಮತ್ತೆ ಹೇಗೆ?

ನಾವೆಲ್ಲರೂ ಈ ಕೆಳಗಿನ ರೀತಿಯ ಕಥೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ: ನಿರ್ದಿಷ್ಟ ಡೆವೊಪ್ಸ್, ನಿರ್ದಿಷ್ಟ ನಿರ್ವಾಹಕರು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ, ಅಭಿವೃದ್ಧಿ ತಂಡವು ಅವರ ಬಳಿಗೆ ಬಂದು ಹೇಳುತ್ತದೆ - "ನಾವು ಬಿಡುಗಡೆಯಾಗಿದ್ದೇವೆ, ಈಗ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ." ಏನು ಮಾನಿಟರ್? ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

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

ಹಾಗಾದರೆ ಏನು ಬದಲಾಗಿದೆ? - ಎಲ್ಲವೂ ಬದಲಾಗಿದೆ!

2008 ಎಲ್ಲವು ಚೆನ್ನಾಗಿದೆ

ಒಂದೆರಡು ಡೆವಲಪರ್‌ಗಳು, ಒಂದು ಸರ್ವರ್, ಒಂದು ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಇವೆ. ಇದೆಲ್ಲವೂ ಇಲ್ಲಿಂದ ಹೋಗುತ್ತದೆ. ನಾವು ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು zabbix, Nagios, cacti ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ತದನಂತರ ನಾವು CPU ನಲ್ಲಿ, ಡಿಸ್ಕ್ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಮತ್ತು ಡಿಸ್ಕ್ ಜಾಗದಲ್ಲಿ ಸ್ಪಷ್ಟ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ. ಸೈಟ್ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ಆರ್ಡರ್‌ಗಳು ಬರುತ್ತಿವೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಒಂದೆರಡು ಹಸ್ತಚಾಲಿತ ಪರಿಶೀಲನೆಗಳನ್ನು ಸಹ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ - ನಾವು ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದ್ದೇವೆ.

ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಒದಗಿಸಲು ನಿರ್ವಾಹಕರು ಮಾಡಿದ ಕೆಲಸದ ಪ್ರಮಾಣವನ್ನು ನಾವು ಹೋಲಿಕೆ ಮಾಡಿದರೆ, ಅದರಲ್ಲಿ 98% ಸ್ವಯಂಚಾಲಿತವಾಗಿದೆ: ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ವ್ಯಕ್ತಿಯು Zabbix ಅನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಬೇಕು, ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಮತ್ತು 2% - ಬಾಹ್ಯ ತಪಾಸಣೆಗಾಗಿ: ಸೈಟ್ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ, ಹೊಸ ಆದೇಶಗಳು ಬಂದಿವೆ.

2010 ಲೋಡ್ ಬೆಳೆಯುತ್ತಿದೆ

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

ಇದಲ್ಲದೆ, ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಘಟಕವು ಇನ್ನೂ ವ್ಯವಸ್ಥಾಪಕರ ತಲೆಯಲ್ಲಿ ದೊಡ್ಡದಾಗಿದೆ. ನನ್ನ ತಲೆಯಲ್ಲಿ ಇನ್ನೂ ಒಂದು ಕಲ್ಪನೆ ಇದೆ, ಮಾನಿಟರಿಂಗ್ ಮಾಡುವ ವ್ಯಕ್ತಿಯು zabbix ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮತ್ತು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

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

ಗಮನಿಸಿ: ನಾನು "ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಸೆಟ್" ಅನ್ನು 3 ಬಾರಿ ಬರೆದಿದ್ದೇನೆ. ಅಂದರೆ, ಮೇಲ್ವಿಚಾರಣೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ವ್ಯಕ್ತಿಯು ಜಬ್ಬಿಕ್ಸ್ ಅನ್ನು ಸರಳವಾಗಿ ಸ್ಥಾಪಿಸುವವರಲ್ಲ. ಇದು ಕೋಡಿಂಗ್ ಪ್ರಾರಂಭಿಸುವ ವ್ಯಕ್ತಿ. ಆದರೆ ತಂಡದ ಮನಸ್ಸಿನಲ್ಲಿ ಇನ್ನೂ ಏನೂ ಬದಲಾಗಿಲ್ಲ.

ಆದರೆ ಜಗತ್ತು ಬದಲಾಗುತ್ತಿದೆ, ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿದೆ. ವರ್ಚುವಲೈಸೇಶನ್ ಲೇಯರ್ ಮತ್ತು ಹಲವಾರು ಹೊಸ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ. ಅವರು ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. "ಮೈಕ್ರೊ ಸರ್ವಿಸ್‌ನಂತೆ ವಾಸನೆ ಬರುತ್ತದೆ" ಎಂದು ಯಾರು ಹೇಳಿದರು? ಆದರೆ ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಇನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ ವೆಬ್‌ಸೈಟ್‌ನಂತೆ ಕಾಣುತ್ತದೆ. ನಾವು ಅದರ ಕಡೆಗೆ ತಿರುಗಬಹುದು ಮತ್ತು ಅದು ಅಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ತನ್ನದೇ ಆದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು. ಮತ್ತು ನೀವು 5-7-10 ವರ್ಷಗಳಿಂದ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿರುವ ಯೋಜನೆಯಲ್ಲಿ ನಿರಂತರವಾಗಿ ತೊಡಗಿಸಿಕೊಂಡಿರುವ ನಿರ್ವಾಹಕರಾಗಿದ್ದರೆ, ಈ ಜ್ಞಾನವು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತದೆ: ಹೊಸ ಮಟ್ಟವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ - ನೀವು ಅದನ್ನು ಅರಿತುಕೊಂಡಿದ್ದೀರಿ, ಇನ್ನೊಂದು ಹಂತವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ - ನೀವು ಅದನ್ನು ಅರಿತುಕೊಂಡಿದ್ದೀರಿ ...

ಆದರೆ ಅಪರೂಪವಾಗಿ ಯಾರಾದರೂ 10 ವರ್ಷಗಳವರೆಗೆ ಯೋಜನೆಯೊಂದಿಗೆ ಹೋಗುತ್ತಾರೆ.

ಮಾನಿಟರಿಂಗ್‌ಮ್ಯಾನ್‌ನ ಪುನರಾರಂಭ

ನೀವು ಹೊಸ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗೆ ಬಂದಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸೋಣ, ಅದು ತಕ್ಷಣವೇ 20 ಡೆವಲಪರ್‌ಗಳನ್ನು ನೇಮಿಸಿಕೊಂಡಿದೆ, 15 ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳನ್ನು ಬರೆದಿದೆ ಮತ್ತು ನೀವು ನಿರ್ವಾಹಕರಾಗಿದ್ದೀರಿ: “CI/CD ಅನ್ನು ನಿರ್ಮಿಸಿ. ದಯವಿಟ್ಟು." ನೀವು CI/CD ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೀರಿ ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ಕೇಳುತ್ತೀರಿ: ""ಕ್ಯೂಬ್" ನಲ್ಲಿ ಉತ್ಪಾದನೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ನಮಗೆ ಕಷ್ಟ, ಅದರಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದೆ. ಅದೇ "ಕ್ಯೂಬ್" ನಲ್ಲಿ ನಮಗೆ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಮಾಡಿ.
ಈ ಘನದಲ್ಲಿ ನೀವು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ತಯಾರಿಸುತ್ತೀರಿ. ಅವರು ತಕ್ಷಣವೇ ನಿಮಗೆ ಹೇಳುತ್ತಾರೆ: "ಉತ್ಪಾದನೆಯಿಂದ ಪ್ರತಿದಿನ ನವೀಕರಿಸಲಾಗುವ ಹಂತದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಾವು ಬಯಸುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಅದು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಉತ್ಪಾದನಾ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹಾಳು ಮಾಡುವುದಿಲ್ಲ."

ನೀವು ಈ ಎಲ್ಲದರಲ್ಲೂ ವಾಸಿಸುತ್ತೀರಿ. ಬಿಡುಗಡೆಗೆ 2 ವಾರಗಳು ಉಳಿದಿವೆ, ಅವರು ನಿಮಗೆ ಹೇಳುತ್ತಾರೆ: "ಈಗ ನಾವು ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡೋಣ ..." ಅಂದರೆ. ಕ್ಲಸ್ಟರ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ, ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ, ಬಾಹ್ಯ ಸೇವೆಗಳೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ...

ಮತ್ತು ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳು ಸಾಮಾನ್ಯ ಯೋಜನೆಯನ್ನು ತಮ್ಮ ತಲೆಯಿಂದ ತೆಗೆದುಕೊಂಡು ಹೇಳುತ್ತಾರೆ: “ಸರಿ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ! ಇದೆಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಸ್ಥಾಪಿಸಿ. ಹೌದು, ಹೌದು: Prometheus + Grafana + ಪ್ಲಗಿನ್‌ಗಳು.
ಮತ್ತು ಅವರು ಸೇರಿಸುತ್ತಾರೆ: "ನಿಮಗೆ ಎರಡು ವಾರಗಳಿವೆ, ಎಲ್ಲವೂ ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ."

ನಾವು ನೋಡುವ ಬಹಳಷ್ಟು ಯೋಜನೆಗಳಲ್ಲಿ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ. ನಾವು 2 ವಾರಗಳವರೆಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಒಬ್ಬ ವ್ಯಕ್ತಿಯನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ ಎಂದು ಊಹಿಸಿ, ಮತ್ತು ನಾವು ಅವರಿಗೆ ಪುನರಾರಂಭವನ್ನು ಬರೆಯುತ್ತೇವೆ. ನಾವು ಇಲ್ಲಿಯವರೆಗೆ ಹೇಳಿರುವ ಎಲ್ಲವನ್ನೂ ಗಮನಿಸಿದರೆ ಈ ವ್ಯಕ್ತಿಯು ಯಾವ ಕೌಶಲ್ಯಗಳನ್ನು ಹೊಂದಿರಬೇಕು?

ಕಬ್ಬಿಣದ ಮೂಲಸೌಕರ್ಯದ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ನಿಶ್ಚಿತಗಳನ್ನು ಅವನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.
ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ನಿಶ್ಚಿತಗಳನ್ನು ಅವನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು (ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ “ಕ್ಯೂಬ್” ಗೆ ಹೋಗಲು ಬಯಸುತ್ತಾರೆ, ಏಕೆಂದರೆ ನೀವು ಎಲ್ಲದರಿಂದ ಅಮೂರ್ತವಾಗಬಹುದು, ಮರೆಮಾಡಬಹುದು, ಏಕೆಂದರೆ ನಿರ್ವಾಹಕರು ಉಳಿದವುಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಾರೆ) - ಸ್ವತಃ, ಅದರ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಒಳಗೆ.
ಸೇವೆಗಳು ಪರಸ್ಪರ ವಿಶೇಷ ರೀತಿಯಲ್ಲಿ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಮತ್ತು ಸೇವೆಗಳು ಪರಸ್ಪರ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಎಂಬುದರ ನಿಶ್ಚಿತಗಳನ್ನು ತಿಳಿದಿರಬೇಕು. ಕೆಲವು ಸೇವೆಗಳು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಸಂವಹನ ನಡೆಸುವ ಯೋಜನೆಯನ್ನು ನೋಡಲು ಸಾಕಷ್ಟು ಸಾಧ್ಯವಿದೆ, ಏಕೆಂದರೆ ಬೇರೆ ಮಾರ್ಗವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಕೆಂಡ್ REST ಮೂಲಕ, gRPC ಮೂಲಕ ಕ್ಯಾಟಲಾಗ್ ಸೇವೆಗೆ ಹೋಗುತ್ತದೆ, ಉತ್ಪನ್ನಗಳ ಪಟ್ಟಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ನೀವು ಇಲ್ಲಿ ಕಾಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಇತರ ಸೇವೆಗಳೊಂದಿಗೆ ಇದು ಅಸಮಕಾಲಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದೇಶವನ್ನು ವಿತರಣಾ ಸೇವೆಗೆ ವರ್ಗಾಯಿಸಿ, ಪತ್ರವನ್ನು ಕಳುಹಿಸಿ, ಇತ್ಯಾದಿ.
ನೀವು ಬಹುಶಃ ಈ ಎಲ್ಲದರಿಂದ ಈಗಾಗಲೇ ಈಜಿದ್ದೀರಾ? ಮತ್ತು ಇದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾದ ನಿರ್ವಾಹಕರು ಇನ್ನಷ್ಟು ಗೊಂದಲಕ್ಕೊಳಗಾದರು.
ಅವನು ಸರಿಯಾಗಿ ಯೋಜಿಸಲು ಮತ್ತು ಯೋಜಿಸಲು ಶಕ್ತರಾಗಿರಬೇಕು - ಕೆಲಸವು ಹೆಚ್ಚು ಹೆಚ್ಚು ಆಗುತ್ತದೆ.
ಆದ್ದರಿಂದ ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅವರು ರಚಿಸಿದ ಸೇವೆಯಿಂದ ತಂತ್ರವನ್ನು ರಚಿಸಬೇಕು. ಅವನಿಗೆ ಯೋಜನೆಯ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಅದರ ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ ತಿಳುವಳಿಕೆ ಬೇಕು + ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಬಳಸುವ ತಂತ್ರಜ್ಞಾನಗಳ ತಿಳುವಳಿಕೆ.

ಸಂಪೂರ್ಣವಾಗಿ ಸಾಮಾನ್ಯವಾದ ಪ್ರಕರಣವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳೋಣ: ಕೆಲವು ಸೇವೆಗಳು PHP ನಲ್ಲಿವೆ, ಕೆಲವು ಸೇವೆಗಳು Go ನಲ್ಲಿವೆ, ಕೆಲವು ಸೇವೆಗಳು JS ನಲ್ಲಿವೆ. ಅವರು ಹೇಗಾದರೂ ಪರಸ್ಪರ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. "ಮೈಕ್ರೋ ಸರ್ವಿಸ್" ಎಂಬ ಪದವು ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ: ಡೆವಲಪರ್‌ಗಳು ಯೋಜನೆಯನ್ನು ಒಟ್ಟಾರೆಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದ ಹಲವು ವೈಯಕ್ತಿಕ ವ್ಯವಸ್ಥೆಗಳಿವೆ. ತಂಡದ ಒಂದು ಭಾಗವು JS ನಲ್ಲಿ ಸೇವೆಗಳನ್ನು ಬರೆಯುತ್ತದೆ ಅದು ತಮ್ಮದೇ ಆದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಉಳಿದ ಸಿಸ್ಟಮ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ತಿಳಿದಿಲ್ಲ. ಇತರ ಭಾಗವು ಪೈಥಾನ್‌ನಲ್ಲಿ ಸೇವೆಗಳನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ಇತರ ಸೇವೆಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರಲ್ಲಿ ಮಧ್ಯಪ್ರವೇಶಿಸುವುದಿಲ್ಲ; ಅವರು ತಮ್ಮದೇ ಆದ ಪ್ರದೇಶದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತಾರೆ. ಮೂರನೆಯದು PHP ಅಥವಾ ಬೇರೆ ಯಾವುದೋ ಸೇವೆಗಳನ್ನು ಬರೆಯುವುದು.
ಈ ಎಲ್ಲಾ 20 ಜನರನ್ನು 15 ಸೇವೆಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ ಮತ್ತು ಒಬ್ಬ ನಿರ್ವಾಹಕರು ಮಾತ್ರ ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ನಿಲ್ಲಿಸು! 15 ಜನರಿಗೆ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ ನಾವು ಸಿಸ್ಟಮ್ ಅನ್ನು 20 ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿದ್ದೇವೆ.

ಆದರೆ ಅದನ್ನು ಹೇಗಾದರೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗಿದೆ ...

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

ನಾನು ಏನು ಹೇಳಲಿ... ಹೂಸ್ಟನ್, ನಮಗೆ ಸಮಸ್ಯೆಗಳಿವೆ.

ಆಧುನಿಕ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಸ್ವತಃ ಸಾಫ್ಟ್‌ವೇರ್ ಯೋಜನೆಯಾಗಿದೆ

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

ಉದಾಹರಣೆಗೆ, ಕಾಫ್ಕಾ ಮೂಲಕ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುವ ಹಲವಾರು ಸೇವೆಗಳಿವೆ. ಆರ್ಡರ್ ಬಂದಿತು, ನಾವು ಕಾಫ್ಕಾಗೆ ಆದೇಶದ ಬಗ್ಗೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಿದ್ದೇವೆ. ಆದೇಶದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಕೇಳುವ ಮತ್ತು ಸರಕುಗಳನ್ನು ಸಾಗಿಸುವ ಸೇವೆ ಇದೆ. ಆದೇಶದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಕೇಳುವ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಪತ್ರವನ್ನು ಕಳುಹಿಸುವ ಸೇವೆ ಇದೆ. ತದನಂತರ ಹೆಚ್ಚಿನ ಸೇವೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ನಾವು ಗೊಂದಲಕ್ಕೊಳಗಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.

ಮತ್ತು ಬಿಡುಗಡೆಯ ಮೊದಲು ಸ್ವಲ್ಪ ಸಮಯ ಉಳಿದಿರುವಾಗ ನೀವು ಇದನ್ನು ನಿರ್ವಾಹಕರು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗೆ ನೀಡಿದರೆ, ವ್ಯಕ್ತಿಯು ಈ ಸಂಪೂರ್ಣ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಆ. ಈ ಪ್ರಮಾಣದ ಯೋಜನೆಯು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಇದು ಸಿಸ್ಟಮ್ ಅಭಿವೃದ್ಧಿಗೆ ಅಂಶವಾಗಿರಬೇಕು.
ಆದರೆ ಆಗಾಗ್ಗೆ, ವಿಶೇಷವಾಗಿ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಲ್ಲಿ, ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ನಂತರದವರೆಗೆ ಹೇಗೆ ಮುಂದೂಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. “ಈಗ ನಾವು ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆಯನ್ನು ಮಾಡುತ್ತೇವೆ, ನಾವು ಅದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ, ಅದು ಬೀಳಲಿ - ನಾವು ತ್ಯಾಗಕ್ಕೆ ಸಿದ್ಧರಿದ್ದೇವೆ. ತದನಂತರ ನಾವು ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ. ” ಯೋಜನೆಯು ಹಣವನ್ನು ಗಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ (ಅಥವಾ ವೇಳೆ), ವ್ಯವಹಾರವು ಇನ್ನೂ ಹೆಚ್ಚಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತದೆ - ಏಕೆಂದರೆ ಅದು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮತ್ತಷ್ಟು ಹೊರತರಬೇಕಾಗಿದೆ! ಮತ್ತು ನೀವು ಮೊದಲು ಹಿಂದಿನ ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾದ ಹಂತದಲ್ಲಿ ನೀವು ಇದ್ದೀರಿ, ಇದು 1% ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಹೆಚ್ಚು. ಮತ್ತು ಮೂಲಕ, ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಡೆವಲಪರ್‌ಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಅವರಿಗೆ ಅವಕಾಶ ನೀಡುವುದು ಸುಲಭ. ಪರಿಣಾಮವಾಗಿ, ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ, ಎಲ್ಲವನ್ನೂ ತಿರುಗಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಅಂತ್ಯವಿಲ್ಲದ ಡೆಡ್‌ಲಾಕ್‌ನಲ್ಲಿರುವಿರಿ.

ಆದ್ದರಿಂದ ಪ್ರಾರಂಭದಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಯೋಜನೆಯನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು, ಮತ್ತು ನೀವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾದ ಯೋಜನೆಯನ್ನು ಪಡೆದರೆ ಏನು ಮಾಡಬೇಕು, ಆದರೆ ಎಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲವೇ?

ಮೊದಲಿಗೆ, ನೀವು ಯೋಜಿಸಬೇಕಾಗಿದೆ.

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

ಮೊದಲಿಗೆ, ನೀವು ಏನು ಮತ್ತು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ, ತದನಂತರ ಉಪಕರಣವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಏಕೆಂದರೆ ಇತರ ಜನರು ನಿಮಗಾಗಿ ಯೋಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಅವರು ಮಾಡಬೇಕು? ಇತರ ಜನರು ಸಾರ್ವತ್ರಿಕ ವ್ಯವಸ್ಥೆಯ ಬಗ್ಗೆ ತಮ್ಮಷ್ಟಕ್ಕೇ ಯೋಚಿಸಿದರು - ಅಥವಾ ಈ ಪ್ಲಗಿನ್ ಅನ್ನು ಬರೆಯುವಾಗ ಯೋಚಿಸಲಿಲ್ಲ. ಮತ್ತು ಈ ಪ್ಲಗಿನ್ 5 ಸಾವಿರ ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿರುವುದರಿಂದ ಅದು ಯಾವುದೇ ಪ್ರಯೋಜನಕಾರಿ ಎಂದು ಅರ್ಥವಲ್ಲ. ಬಹುಶಃ ನೀವು 5001 ನೇ ಆಗುತ್ತೀರಿ ಏಕೆಂದರೆ ಮೊದಲು ಅಲ್ಲಿ 5000 ಜನರು ಇದ್ದರು.

ನೀವು ಮೂಲಸೌಕರ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬ್ಯಾಕೆಂಡ್ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ, ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ. ದೋಷ ಕಾಣಿಸುತ್ತದೆ. ಅವರು ನಿಮ್ಮ ಬಳಿಗೆ ಬಂದು "ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ, ನೀವು ಇಲ್ಲಿ ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ?" - "ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿದ್ದೇವೆ." - "ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂದು ನೀವು ನೋಡದಿದ್ದರೆ ನೀವು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೀರಿ?!"

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

ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಗೆ ಸಮಾನಾಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ನಡೆಸಬೇಕು ಎಂಬುದು ನನ್ನ ಮುಖ್ಯ ಆಲೋಚನೆ. ನೀವು ಇತರ ಕಾರ್ಯಗಳಿಗಾಗಿ ಮಾನಿಟರಿಂಗ್ ತಂಡವನ್ನು ವಿಚಲಿತಗೊಳಿಸಿದರೆ (CI/CD, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸಿಂಗ್, ಮೂಲಸೌಕರ್ಯ ಮರುಸಂಘಟನೆಯನ್ನು ರಚಿಸುವುದು), ಮಾನಿಟರಿಂಗ್ ವಿಳಂಬವಾಗಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಎಂದಿಗೂ ಹಿಡಿಯುವುದಿಲ್ಲ (ಅಥವಾ ಬೇಗ ಅಥವಾ ನಂತರ ನೀವು ಅದನ್ನು ನಿಲ್ಲಿಸಬೇಕಾಗುತ್ತದೆ).

ಮಟ್ಟದಿಂದ ಎಲ್ಲವೂ

ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯ ಸಂಘಟನೆಯನ್ನು ನಾನು ಈ ರೀತಿ ನೋಡುತ್ತೇನೆ.

1) ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟ:

ಅಪ್ಲಿಕೇಶನ್ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು;
ಸೇವೆಗಳ ಆರೋಗ್ಯ ಮಾಪನಗಳ ಮೇಲ್ವಿಚಾರಣೆ;
ಏಕೀಕರಣ ಮೇಲ್ವಿಚಾರಣೆ.

2) ಮೂಲಸೌಕರ್ಯ ಮಟ್ಟ:

ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಮಟ್ಟದ ಮೇಲ್ವಿಚಾರಣೆ;
ಸಿಸ್ಟಮ್ ಸಾಫ್ಟ್ವೇರ್ ಮಾನಿಟರಿಂಗ್;
ಕಬ್ಬಿಣದ ಮಟ್ಟದ ಮೇಲ್ವಿಚಾರಣೆ.

3) ಮತ್ತೆ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟ - ಆದರೆ ಎಂಜಿನಿಯರಿಂಗ್ ಉತ್ಪನ್ನವಾಗಿ:

ಅಪ್ಲಿಕೇಶನ್ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು;
ಎಪಿಎಂ;
ಪತ್ತೆ ಹಚ್ಚುವುದು.

4) ಎಚ್ಚರಿಕೆ:

ಎಚ್ಚರಿಕೆ ವ್ಯವಸ್ಥೆಯ ಸಂಘಟನೆ;
ಕರ್ತವ್ಯ ವ್ಯವಸ್ಥೆಯ ಸಂಘಟನೆ;
"ಜ್ಞಾನ ಬೇಸ್" ನ ಸಂಘಟನೆ ಮತ್ತು ಘಟನೆಯ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಕೆಲಸದ ಹರಿವು.

ಪ್ರಮುಖ: ನಾವು ಎಚ್ಚರಿಕೆಯನ್ನು ಪಡೆಯುವುದು ನಂತರ ಅಲ್ಲ, ಆದರೆ ತಕ್ಷಣವೇ! ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು "ಹೇಗಾದರೂ ನಂತರ" ಯಾರು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ. ಎಲ್ಲಾ ನಂತರ, ಮೇಲ್ವಿಚಾರಣೆಯ ಕಾರ್ಯವೇನು: ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಎಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಸರಿಯಾದ ಜನರಿಗೆ ತಿಳಿಸಲು. ನೀವು ಇದನ್ನು ಕೊನೆಯವರೆಗೂ ಬಿಟ್ಟರೆ, "ನಮಗೆ ಏನೂ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ" ಎಂದು ಕರೆಯುವ ಮೂಲಕ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಎಂದು ಸರಿಯಾದ ಜನರಿಗೆ ತಿಳಿಯುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ - ವ್ಯಾಪಾರ ಲಾಜಿಕ್ ಮಾನಿಟರಿಂಗ್

ಅಪ್ಲಿಕೇಶನ್ ಬಳಕೆದಾರರಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ಅಂಶವನ್ನು ಪರಿಶೀಲಿಸುವ ಬಗ್ಗೆ ಇಲ್ಲಿ ನಾವು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ.

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

ಸೈಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಮುಖಪುಟವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಆಗಾಗ್ಗೆ ಕೇಳಿದಾಗ, ಪ್ರೋಗ್ರಾಮರ್ಗಳು API ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರತಿ ಬಾರಿ ಎಳೆಯಬಹುದಾದ ಹ್ಯಾಂಡಲ್ ಅನ್ನು ನೀಡುತ್ತಾರೆ. ಮತ್ತು ಈ ಕ್ಷಣದಲ್ಲಿ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಇನ್ನೂ /api/test/helloworld ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಬರೆಯುತ್ತಾರೆ
ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಏಕೈಕ ಮಾರ್ಗವೇ? - ಇಲ್ಲ!

ಅಂತಹ ಚೆಕ್ಗಳನ್ನು ರಚಿಸುವುದು ಮೂಲಭೂತವಾಗಿ ಡೆವಲಪರ್ಗಳ ಕಾರ್ಯವಾಗಿದೆ. ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಕೋಡ್ ಬರೆಯುವ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಬರೆಯಬೇಕು. ಏಕೆಂದರೆ ನೀವು ಅದನ್ನು ನಿರ್ವಾಹಕರಿಗೆ ಸೋರಿಕೆ ಮಾಡಿದರೆ, "ಡ್ಯೂಡ್, ಎಲ್ಲಾ 25 ಕಾರ್ಯಗಳಿಗಾಗಿ API ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಪಟ್ಟಿ ಇಲ್ಲಿದೆ, ದಯವಿಟ್ಟು ಎಲ್ಲವನ್ನೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ!" - ಏನೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.
ನೀವು "ಹಲೋ ವರ್ಲ್ಡ್" ಅನ್ನು ಮುದ್ರಿಸಿದರೆ, API ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಯಾರಿಗೂ ತಿಳಿದಿರುವುದಿಲ್ಲ. ಪ್ರತಿ API ಬದಲಾವಣೆಯು ಚೆಕ್‌ಗಳಲ್ಲಿ ಬದಲಾವಣೆಗೆ ಕಾರಣವಾಗಬೇಕು.
ನೀವು ಈಗಾಗಲೇ ಅಂತಹ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಈ ಚೆಕ್‌ಗಳನ್ನು ಬರೆಯುವ ಡೆವಲಪರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ, ಅಥವಾ ನಷ್ಟವನ್ನು ಸ್ವೀಕರಿಸಿ, ಏನನ್ನೂ ಪರಿಶೀಲಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಿ.

ತಾಂತ್ರಿಕ ಸಲಹೆಗಳು:

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

ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ - ಆರೋಗ್ಯ ಮೆಟ್ರಿಕ್ಸ್ ಮಾನಿಟರಿಂಗ್

ಈಗ ನಾವು ಸೇವೆಗಳ ಬಾಹ್ಯ ಆರೋಗ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ.

ಬಾಹ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್‌ನ ಎಲ್ಲಾ "ಹ್ಯಾಂಡಲ್‌ಗಳನ್ನು" ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಬಾಹ್ಯ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯಿಂದ ಕರೆಯುತ್ತೇವೆ. ಆದರೆ ಬಳಕೆದಾರರು "ನೋಡುವ" "ಹಿಡಿಕೆಗಳು" ಇವುಗಳಾಗಿವೆ. ನಮ್ಮ ಸೇವೆಗಳು ಸ್ವತಃ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ. ಇಲ್ಲಿ ಉತ್ತಮವಾದ ಕಥೆಯಿದೆ: K8s ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಕನಿಷ್ಠ "ಕ್ಯೂಬ್" ಸ್ವತಃ ಸೇವೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಮನವರಿಕೆ ಮಾಡಬಹುದು. ಆದರೆ ನಾನು ನೋಡಿದ ಚೆಕ್‌ಗಳಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಒಂದೇ ಮುದ್ರಣ “ಹಲೋ ವರ್ಲ್ಡ್”. ಆ. ಆದ್ದರಿಂದ ಅವರು ನಿಯೋಜನೆಯ ನಂತರ ಒಮ್ಮೆ ಎಳೆಯುತ್ತಾರೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಅವರು ಉತ್ತರಿಸಿದರು - ಅಷ್ಟೆ. ಮತ್ತು ಸೇವೆಯು ತನ್ನದೇ ಆದ API ಅನ್ನು ಒದಗಿಸಿದರೆ, ಅದೇ API ಗಾಗಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿದೆ, ಅದನ್ನು ಸಹ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ತಿಳಿದುಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಅದನ್ನು ಈಗಾಗಲೇ ಒಳಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿದ್ದೇವೆ.

ಇದನ್ನು ತಾಂತ್ರಿಕವಾಗಿ ಸರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಹೇಗೆ: ಪ್ರತಿ ಸೇವೆಯು ಅದರ ಪ್ರಸ್ತುತ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಅಂತಿಮ ಬಿಂದುವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ ಮತ್ತು ಗ್ರಾಫನಾ (ಅಥವಾ ಯಾವುದೇ ಇತರ ಅಪ್ಲಿಕೇಶನ್) ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ಸೇವೆಗಳ ಸ್ಥಿತಿಯನ್ನು ನೋಡುತ್ತೇವೆ.

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

ಅಪ್ಲಿಕೇಶನ್ ಲೇಯರ್ - ಇಂಟಿಗ್ರೇಷನ್ ಮಾನಿಟರಿಂಗ್

ಏಕೀಕರಣ ಮಾನಿಟರಿಂಗ್ ವ್ಯಾಪಾರ-ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಗಳ ನಡುವಿನ ಸಂವಹನಗಳ ಮೇಲ್ವಿಚಾರಣೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.

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

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

ನಾನು ಏನು ಮಾಡಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ:

ಸಿಂಕ್ರೊನಸ್ ಸಂವಹನಕ್ಕಾಗಿ: ಅಂತಿಮ ಬಿಂದುವು ಸಂಬಂಧಿತ ಸೇವೆಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಆ. ನಾವು ಈ ಅಂತಿಮ ಬಿಂದುವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಸೇವೆಯೊಳಗೆ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಎಳೆಯಿರಿ, ಅದು ಎಲ್ಲಾ ಬಿಂದುಗಳಿಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು "ನಾನು ಅಲ್ಲಿಗೆ ಎಳೆಯಬಹುದು ಮತ್ತು ಅಲ್ಲಿಗೆ ಎಳೆಯಬಹುದು, ನಾನು ಅಲ್ಲಿಗೆ ಎಳೆಯಬಹುದು..." ಎಂದು ಹೇಳುತ್ತದೆ.
ಅಸಮಕಾಲಿಕ ಸಂವಹನಕ್ಕಾಗಿ: ಒಳಬರುವ ಸಂದೇಶಗಳು - ಪರೀಕ್ಷಾ ಸಂದೇಶಗಳಿಗಾಗಿ ಅಂತಿಮ ಬಿಂದುವು ಬಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯ ಸ್ಥಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.
ಅಸಮಕಾಲಿಕ ಸಂವಹನಕ್ಕಾಗಿ: ಹೊರಹೋಗುವ ಸಂದೇಶಗಳು - ಅಂತಿಮ ಬಿಂದುವು ಪರೀಕ್ಷಾ ಸಂದೇಶಗಳನ್ನು ಬಸ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಸಂಭವಿಸಿದಂತೆ: ಬಸ್‌ಗೆ ಡೇಟಾವನ್ನು ಎಸೆಯುವ ಸೇವೆಯನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಈ ಸೇವೆಗೆ ಬರುತ್ತೇವೆ ಮತ್ತು ಅದರ ಏಕೀಕರಣ ಆರೋಗ್ಯದ ಬಗ್ಗೆ ನಮಗೆ ಹೇಳಲು ಕೇಳುತ್ತೇವೆ. ಮತ್ತು ಸೇವೆಯು ಎಲ್ಲೋ ಮುಂದೆ ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸಬೇಕಾದರೆ (WebApp), ಆಗ ಅದು ಈ ಪರೀಕ್ಷಾ ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಆರ್ಡರ್‌ಪ್ರೊಸೆಸಿಂಗ್ ಬದಿಯಲ್ಲಿ ಸೇವೆಯನ್ನು ನಡೆಸಿದರೆ, ಅದು ಮೊದಲು ಸ್ವತಂತ್ರವಾಗಿ ಪೋಸ್ಟ್ ಮಾಡಬಹುದಾದದನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಅವಲಂಬಿತ ವಿಷಯಗಳಿದ್ದರೆ, ಅದು ಬಸ್‌ನಿಂದ ಪರೀಕ್ಷಾ ಸಂದೇಶಗಳ ಗುಂಪನ್ನು ಓದುತ್ತದೆ, ಅದು ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು, ವರದಿ ಮಾಡಬಹುದು ಮತ್ತು , ಅಗತ್ಯವಿದ್ದರೆ, ಅವುಗಳನ್ನು ಮತ್ತಷ್ಟು ಪೋಸ್ಟ್ ಮಾಡಿ, ಮತ್ತು ಈ ಬಗ್ಗೆ ಅವರು ಹೇಳುತ್ತಾರೆ - ಎಲ್ಲವೂ ಸರಿ, ನಾನು ಜೀವಂತವಾಗಿದ್ದೇನೆ.

"ಯುದ್ಧ ಡೇಟಾದಲ್ಲಿ ನಾವು ಇದನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬಹುದು?" ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ನಾವು ಆಗಾಗ್ಗೆ ಕೇಳುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಅದೇ ಆದೇಶ ಸೇವೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಆದೇಶವು ಸರಕುಗಳನ್ನು ಬರೆಯುವ ಗೋದಾಮಿಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ: ನಾವು ಇದನ್ನು ಯುದ್ಧ ಡೇಟಾದಲ್ಲಿ ಪರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ "ನನ್ನ ಸರಕುಗಳನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ!" ಪರಿಹಾರ: ಈ ಸಂಪೂರ್ಣ ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭದಲ್ಲಿಯೇ ಯೋಜಿಸಿ. ನೀವು ಅಪಹಾಸ್ಯ ಮಾಡುವ ಘಟಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಸಹ ಹೊಂದಿದ್ದೀರಿ. ಆದ್ದರಿಂದ, ವ್ಯವಹಾರದ ಕಾರ್ಯಾಚರಣೆಗೆ ಹಾನಿಯಾಗದ ಸಂವಹನ ಚಾನಲ್ ಅನ್ನು ನೀವು ಹೊಂದಿರುವ ಆಳವಾದ ಮಟ್ಟದಲ್ಲಿ ಅದನ್ನು ಮಾಡಿ.

ಮೂಲಸೌಕರ್ಯ ಮಟ್ಟ

ಮೂಲಸೌಕರ್ಯ ಮಾನಿಟರಿಂಗ್ ಎನ್ನುವುದು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಸ್ವತಃ ಮೇಲ್ವಿಚಾರಣೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.

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

ವ್ಯವಹಾರ ಘಟಕವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟ

ಮುಖ್ಯ ಅಂಶಗಳು:

ELK. ಇದು ಉದ್ಯಮದ ಮಾನದಂಡವಾಗಿದೆ. ಕೆಲವು ಕಾರಣಗಳಿಂದ ನೀವು ಲಾಗ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸದಿದ್ದರೆ, ತಕ್ಷಣ ಅದನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ.
ಎಪಿಎಂ ಅಪ್ಲಿಕೇಶನ್ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ಮುಚ್ಚುವ ಮಾರ್ಗವಾಗಿ ಬಾಹ್ಯ APM ಗಳು (NewRelic, BlackFire, Datadog). ನಿಮ್ಮೊಂದಿಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನೀವು ಈ ವಿಷಯವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಸ್ಥಾಪಿಸಬಹುದು.
ಟ್ರೇಸಿಂಗ್. ಡಜನ್ಗಟ್ಟಲೆ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳಲ್ಲಿ, ನೀವು ಎಲ್ಲವನ್ನೂ ಪತ್ತೆಹಚ್ಚಬೇಕು, ಏಕೆಂದರೆ ವಿನಂತಿಯು ಇನ್ನು ಮುಂದೆ ತನ್ನದೇ ಆದ ಮೇಲೆ ಜೀವಿಸುವುದಿಲ್ಲ. ನಂತರ ಸೇರಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ, ಆದ್ದರಿಂದ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ತಕ್ಷಣವೇ ನಿಗದಿಪಡಿಸುವುದು ಉತ್ತಮ - ಇದು ಡೆವಲಪರ್‌ಗಳ ಕೆಲಸ ಮತ್ತು ಉಪಯುಕ್ತತೆಯಾಗಿದೆ. ನೀವು ಇನ್ನೂ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸದಿದ್ದರೆ, ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ! ಜೇಗರ್/ಜಿಪ್ಕಿನ್ ನೋಡಿ

ಎಚ್ಚರಿಸುತ್ತಿದೆ

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

ತಂತ್ರಜ್ಞಾನ ಸ್ಟಾಕ್

ನಮ್ಮ ಸ್ಟಾಕ್ ಈ ಕೆಳಗಿನಂತಿದೆ ಎಂದು ಊಹಿಸೋಣ:

ಡೇಟಾ ಸಂಗ್ರಹಣೆ - ಪ್ರಮೀತಿಯಸ್ + ಗ್ರಾಫನಾ;
ಲಾಗ್ ವಿಶ್ಲೇಷಣೆ - ELK;
APM ಅಥವಾ ಟ್ರೇಸಿಂಗ್ಗಾಗಿ - ಜೇಗರ್ (ಜಿಪ್ಕಿನ್).

ಆಯ್ಕೆಗಳ ಆಯ್ಕೆಯು ನಿರ್ಣಾಯಕವಲ್ಲ. ಏಕೆಂದರೆ ಆರಂಭದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮತ್ತು ಯೋಜನೆಯನ್ನು ಬರೆದುಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ನಿಮ್ಮ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಸರಿಹೊಂದುವ ಸಾಧನಗಳನ್ನು ನೀವು ಆಯ್ಕೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ನೀವು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡಿರುವುದು ಪ್ರಶ್ನೆ. ಏಕೆಂದರೆ ಬಹುಶಃ ನೀವು ಆರಂಭದಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಿದ ಸಾಧನವು ನಿಮ್ಮ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ.

ನಾನು ಇತ್ತೀಚೆಗೆ ಎಲ್ಲೆಡೆ ಕಾಣುವ ಕೆಲವು ತಾಂತ್ರಿಕ ಅಂಶಗಳು:

ಪ್ರಮೀತಿಯಸ್ನನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ ತಳ್ಳಲಾಗುತ್ತಿದೆ - ಇದನ್ನು ಯಾರು ತಂದರು?! ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ನೀವು ಏನು ಮಾಡುತ್ತೀರಿ? ನೀವು ಒಳಗೆ ಸಂಕೀರ್ಣ ಕ್ಲಸ್ಟರ್ ಹೊಂದಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್ ಒಳಗೆ ಕೆಲವು ರೀತಿಯ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆ ಇರಬೇಕು ಮತ್ತು ಕೆಲವು ಹೊರಗೆ ಕ್ಲಸ್ಟರ್ ಒಳಗಿನಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

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

ಸಂಶೋಧನೆಗಳು

ಅಭಿವೃದ್ಧಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಉಪಯುಕ್ತತೆಗಳ ಸ್ಥಾಪನೆಯಲ್ಲ, ಆದರೆ ಸಾಫ್ಟ್‌ವೇರ್ ಉತ್ಪನ್ನದ ಅಭಿವೃದ್ಧಿ. ಇಂದಿನ ಮಾನಿಟರಿಂಗ್‌ನ 98% ಕೋಡಿಂಗ್ ಆಗಿದೆ. ಸೇವೆಗಳಲ್ಲಿ ಕೋಡಿಂಗ್, ಬಾಹ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಕೋಡಿಂಗ್, ಬಾಹ್ಯ ಸೇವೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಮತ್ತು ಅಷ್ಟೆ.
ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ನಿಮ್ಮ ಡೆವಲಪರ್‌ಗಳ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡಬೇಡಿ: ಇದು ಅವರ ಕೆಲಸದ 30% ವರೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಇದು ಯೋಗ್ಯವಾಗಿದೆ.
ಡೆವೊಪ್ಸ್, ನೀವು ಏನನ್ನಾದರೂ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಚಿಂತಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಕೆಲವು ವಿಷಯಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಚಿಂತನೆಯ ಮಾರ್ಗವಾಗಿದೆ. ನೀವು ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿರಲಿಲ್ಲ, ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಕೆಲಸ ನಿಖರವಾಗಿ ಅವರ ಕೆಲಸವಾಗಿದೆ.
ಯೋಜನೆಯು ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡದಿದ್ದರೆ (ಮತ್ತು ನೀವು ನಿರ್ವಾಹಕರಾಗಿದ್ದರೆ), ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯೋಜಿಸಿ.
ಉತ್ಪನ್ನವು ಈಗಾಗಲೇ ಉತ್ಪಾದನೆಯಲ್ಲಿದ್ದರೆ ಮತ್ತು ನೀವು "ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿಸಲು" ಹೇಳಲಾದ ಡೆವೊಪ್ಸ್ ಆಗಿದ್ದರೆ - ನಾನು ಈ ಎಲ್ಲದರ ಬಗ್ಗೆ ಬರೆದದ್ದನ್ನು ನಿರ್ವಹಣೆಗೆ ವಿವರಿಸಲು ಪ್ರಯತ್ನಿಸಿ.

ಇದು ಸೇಂಟ್ ಹೈಲೋಡ್++ ಸಮ್ಮೇಳನದಲ್ಲಿ ವರದಿಯ ವಿಸ್ತೃತ ಆವೃತ್ತಿಯಾಗಿದೆ.

ನನ್ನ ಆಲೋಚನೆಗಳು ಮತ್ತು ಆಲೋಚನೆಗಳು ಮತ್ತು ಸಂಬಂಧಿತ ವಿಷಯಗಳಲ್ಲಿ ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ಇಲ್ಲಿ ನೀವು ಮಾಡಬಹುದು ಚಾನಲ್ ಓದಿ 🙂

ಮೂಲ: www.habr.com

ಮಾನಿಟರಿಂಗ್ ಸತ್ತಿದೆಯೇ? - ದೀರ್ಘಾವಧಿಯ ಮೇಲ್ವಿಚಾರಣೆ