ಇದು 2019, ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಲಾಗ್ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಗೆ ನಾವು ಇನ್ನೂ ಪ್ರಮಾಣಿತ ಪರಿಹಾರವನ್ನು ಹೊಂದಿಲ್ಲ. ಈ ಲೇಖನದಲ್ಲಿ, ನೈಜ ಅಭ್ಯಾಸದಿಂದ ಉದಾಹರಣೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ನಮ್ಮ ಹುಡುಕಾಟಗಳು, ಎದುರಿಸಿದ ಸಮಸ್ಯೆಗಳು ಮತ್ತು ಅವುಗಳ ಪರಿಹಾರಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ.
ಆದಾಗ್ಯೂ, ಮೊದಲಿಗೆ, ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ ವಿಭಿನ್ನ ಗ್ರಾಹಕರು ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾನು ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ:
- ಯಾರಾದರೂ ಭದ್ರತೆ ಮತ್ತು ಆಡಿಟ್ ಲಾಗ್ಗಳನ್ನು ನೋಡಲು ಬಯಸುತ್ತಾರೆ;
- ಯಾರಾದರೂ - ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯದ ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್;
- ಮತ್ತು ಕೆಲವರಿಗೆ, ಕೇವಲ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಕು, ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ.
ನಾವು ವಿವಿಧ "ವಿಶ್ ಲಿಸ್ಟ್‌ಗಳನ್ನು" ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಯಾವ ತೊಂದರೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಕೆಳಗಿನ ಕಟ್ ಅನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.
ಸಿದ್ಧಾಂತ: ಲಾಗಿಂಗ್ ಉಪಕರಣಗಳ ಬಗ್ಗೆ
ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್ನ ಘಟಕಗಳ ಹಿನ್ನೆಲೆ
ಲಾಗಿಂಗ್ ಬಹಳ ದೂರ ಸಾಗಿದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ವಿಶ್ಲೇಷಿಸುವ ವಿಧಾನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಅದನ್ನು ನಾವು ಇಂದು ಬಳಸುತ್ತೇವೆ. 1950 ರ ದಶಕದಲ್ಲಿ, ಫೋರ್ಟ್ರಾನ್ ಪ್ರಮಾಣಿತ ಇನ್‌ಪುಟ್/ಔಟ್ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ಗಳ ಅನಲಾಗ್ ಅನ್ನು ಪರಿಚಯಿಸಿತು, ಇದು ಪ್ರೋಗ್ರಾಮರ್‌ಗೆ ತನ್ನ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡಿತು. ಆ ಕಾಲದ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಗೆ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸಿದ ಮೊದಲ ಕಂಪ್ಯೂಟರ್ ಲಾಗ್‌ಗಳು ಇವು. ಇಂದು ನಾವು ಅವುಗಳಲ್ಲಿ ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್ನ ಮೊದಲ ಘಟಕವನ್ನು ನೋಡುತ್ತೇವೆ - ಲಾಗ್‌ಗಳ ಮೂಲ ಅಥವಾ "ನಿರ್ಮಾಪಕ".
ಕಂಪ್ಯೂಟರ್ ವಿಜ್ಞಾನವು ಇನ್ನೂ ನಿಲ್ಲಲಿಲ್ಲ: ಕಂಪ್ಯೂಟರ್ ನೆಟ್ವರ್ಕ್ಗಳು ಕಾಣಿಸಿಕೊಂಡವು, ಮೊದಲ ಕ್ಲಸ್ಟರ್ಗಳು ... ಹಲವಾರು ಕಂಪ್ಯೂಟರ್ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದವು. ಈಗ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಹಲವಾರು ಯಂತ್ರಗಳಿಂದ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಲವಂತಪಡಿಸಿದರು, ಮತ್ತು ವಿಶೇಷ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅವರು ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯವನ್ನು ತನಿಖೆ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಸಂದರ್ಭದಲ್ಲಿ OS ಕರ್ನಲ್ ಸಂದೇಶಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಕೇಂದ್ರೀಕೃತ ಲಾಗ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ವಿವರಿಸಲು, 2000 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ ಇದನ್ನು ಪ್ರಕಟಿಸಲಾಯಿತು , ಇದು ರಿಮೋಟ್_ಸಿಸ್ಲಾಗ್ ಅನ್ನು ಪ್ರಮಾಣೀಕರಿಸಿದೆ. ಮತ್ತೊಂದು ಪ್ರಮುಖ ಅಂಶವು ಹೇಗೆ ಕಾಣಿಸಿಕೊಂಡಿತು: ಲಾಗ್ ಸಂಗ್ರಾಹಕ ಮತ್ತು ಅವುಗಳ ಸಂಗ್ರಹಣೆ.
ಲಾಗ್‌ಗಳ ಪರಿಮಾಣದಲ್ಲಿನ ಹೆಚ್ಚಳ ಮತ್ತು ವೆಬ್ ತಂತ್ರಜ್ಞಾನಗಳ ವ್ಯಾಪಕ ಪರಿಚಯದೊಂದಿಗೆ, ಬಳಕೆದಾರರಿಗೆ ಯಾವ ಲಾಗ್ಗಳನ್ನು ಅನುಕೂಲಕರವಾಗಿ ತೋರಿಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸಿದೆ. ಸರಳ ಕನ್ಸೋಲ್ ಪರಿಕರಗಳನ್ನು (awk/sed/grep) ಹೆಚ್ಚು ಸುಧಾರಿತ ಸಾಧನಗಳಿಂದ ಬದಲಾಯಿಸಲಾಗಿದೆ ಲಾಗ್ ವೀಕ್ಷಕರು - ಮೂರನೇ ಘಟಕ.
ಲಾಗ್‌ಗಳ ಪರಿಮಾಣದಲ್ಲಿನ ಹೆಚ್ಚಳದಿಂದಾಗಿ, ಬೇರೆ ಯಾವುದೋ ಸ್ಪಷ್ಟವಾಯಿತು: ಲಾಗ್‌ಗಳು ಅಗತ್ಯವಿದೆ, ಆದರೆ ಅವೆಲ್ಲವೂ ಅಲ್ಲ. ಮತ್ತು ವಿಭಿನ್ನ ಲಾಗ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ಮಟ್ಟದ ಸಂರಕ್ಷಣೆ ಅಗತ್ಯವಿರುತ್ತದೆ: ಕೆಲವು ದಿನದಲ್ಲಿ ಕಳೆದುಹೋಗಬಹುದು, ಆದರೆ ಇತರವುಗಳನ್ನು 5 ವರ್ಷಗಳವರೆಗೆ ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಡೇಟಾ ಹರಿವುಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಮತ್ತು ರೂಟಿಂಗ್ ಮಾಡಲು ಒಂದು ಘಟಕವನ್ನು ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ಸೇರಿಸಲಾಗಿದೆ - ಅದನ್ನು ಕರೆಯೋಣ ಫಿಲ್ಟರ್.
ಸಂಗ್ರಹಣೆಯು ಒಂದು ಪ್ರಮುಖ ಅಧಿಕವನ್ನು ಮಾಡಿದೆ: ಸಾಮಾನ್ಯ ಫೈಲ್‌ಗಳಿಂದ ಸಂಬಂಧಿತ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಮತ್ತು ನಂತರ ಡಾಕ್ಯುಮೆಂಟ್-ಆಧಾರಿತ ಸಂಗ್ರಹಣೆಗೆ (ಉದಾಹರಣೆಗೆ, ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ). ಆದ್ದರಿಂದ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಂಗ್ರಾಹಕರಿಂದ ಬೇರ್ಪಡಿಸಲಾಯಿತು.
ಅಂತಿಮವಾಗಿ, ಲಾಗ್ನ ಪರಿಕಲ್ಪನೆಯು ಇತಿಹಾಸಕ್ಕಾಗಿ ನಾವು ಸಂರಕ್ಷಿಸಲು ಬಯಸುವ ಘಟನೆಗಳ ಒಂದು ರೀತಿಯ ಅಮೂರ್ತ ಸ್ಟ್ರೀಮ್‌ಗೆ ವಿಸ್ತರಿಸಿದೆ. ಅಥವಾ ಬದಲಿಗೆ, ನೀವು ತನಿಖೆ ನಡೆಸಬೇಕಾದರೆ ಅಥವಾ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ವರದಿಯನ್ನು ರಚಿಸಬೇಕಾದರೆ ...
ಪರಿಣಾಮವಾಗಿ, ತುಲನಾತ್ಮಕವಾಗಿ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ, ಲಾಗ್ ಸಂಗ್ರಹವು ಒಂದು ಪ್ರಮುಖ ಉಪವ್ಯವಸ್ಥೆಯಾಗಿ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ, ಇದನ್ನು ಬಿಗ್ ಡೇಟಾದಲ್ಲಿನ ಉಪವಿಭಾಗಗಳಲ್ಲಿ ಒಂದೆಂದು ಸರಿಯಾಗಿ ಕರೆಯಬಹುದು.
ಒಂದು ಕಾಲದಲ್ಲಿ ಸಾಮಾನ್ಯ ಮುದ್ರಣಗಳು "ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್" ಗೆ ಸಾಕಷ್ಟು ಆಗಿದ್ದರೆ, ಈಗ ಪರಿಸ್ಥಿತಿಯು ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ದಾಖಲೆಗಳು
ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಬಂದಾಗ, ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಮಸ್ಯೆಯು ಅದನ್ನು ಬೈಪಾಸ್ ಮಾಡಲಿಲ್ಲ. ಕೆಲವು ವಿಧಗಳಲ್ಲಿ, ಇದು ಇನ್ನಷ್ಟು ನೋವಿನಿಂದ ಕೂಡಿದೆ: ಮೂಲಸೌಕರ್ಯ ವೇದಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ಸರಳೀಕೃತವಾಗಿಲ್ಲ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಸಂಕೀರ್ಣವಾಗಿದೆ. ಅನೇಕ ಹಳೆಯ ಸೇವೆಗಳು ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳಿಗೆ ವಲಸೆ ಹೋಗಲಾರಂಭಿಸಿವೆ. ಲಾಗ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಲಾಗ್ ಮೂಲಗಳ ಹೆಚ್ಚುತ್ತಿರುವ ಸಂಖ್ಯೆಯಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ, ಅವುಗಳ ವಿಶೇಷ ಜೀವನ ಚಕ್ರ, ಮತ್ತು ಲಾಗ್‌ಗಳ ಮೂಲಕ ಎಲ್ಲಾ ಸಿಸ್ಟಮ್ ಘಟಕಗಳ ಸಂಬಂಧಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಅಗತ್ಯತೆ...
ಮುಂದೆ ನೋಡುವಾಗ, ದುರದೃಷ್ಟವಶಾತ್, ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಯಾವುದೇ ಪ್ರಮಾಣಿತ ಲಾಗಿಂಗ್ ಆಯ್ಕೆ ಇಲ್ಲ, ಅದು ಎಲ್ಲರೊಂದಿಗೆ ಅನುಕೂಲಕರವಾಗಿ ಹೋಲಿಸುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ. ಸಮುದಾಯದಲ್ಲಿ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಯೋಜನೆಗಳು ಈ ಕೆಳಗಿನಂತಿವೆ:
- ಯಾರಾದರೂ ಸ್ಟಾಕ್ ಅನ್ನು ಬಿಚ್ಚುತ್ತಾರೆ EFK (Elasticsearch, Fluentd, Kibana);
- ಯಾರೋ ಇತ್ತೀಚೆಗೆ ಬಿಡುಗಡೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ ಅಥವಾ ಬಳಸುತ್ತದೆ ;
- нас (ಮತ್ತು ಬಹುಶಃ ನಾವು ಮಾತ್ರವಲ್ಲ? ..) ನನ್ನ ಸ್ವಂತ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ನಾನು ಹೆಚ್ಚಾಗಿ ತೃಪ್ತನಾಗಿದ್ದೇನೆ - ...
ನಿಯಮದಂತೆ, ನಾವು K8s ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಈ ಕೆಳಗಿನ ಬಂಡಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ (ಸ್ವಯಂ ಹೋಸ್ಟ್ ಮಾಡಿದ ಪರಿಹಾರಗಳಿಗಾಗಿ):
- ;
- .
ಆದಾಗ್ಯೂ, ಅವುಗಳ ಸ್ಥಾಪನೆ ಮತ್ತು ಸಂರಚನೆಯ ಸೂಚನೆಗಳ ಮೇಲೆ ನಾನು ವಾಸಿಸುವುದಿಲ್ಲ. ಬದಲಿಗೆ, ನಾನು ಅವರ ನ್ಯೂನತೆಗಳು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಪರಿಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಹೆಚ್ಚು ಜಾಗತಿಕ ತೀರ್ಮಾನಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇನೆ.
K8 ಗಳಲ್ಲಿ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಅಭ್ಯಾಸ ಮಾಡಿ
"ದೈನಂದಿನ ದಾಖಲೆಗಳು", ನಿಮ್ಮಲ್ಲಿ ಎಷ್ಟು ಮಂದಿ ಇದ್ದಾರೆ?..
ಸಾಕಷ್ಟು ದೊಡ್ಡ ಮೂಲಸೌಕರ್ಯದಿಂದ ಲಾಗ್‌ಗಳ ಕೇಂದ್ರೀಕೃತ ಸಂಗ್ರಹಣೆಗೆ ಗಣನೀಯ ಸಂಪನ್ಮೂಲಗಳು ಬೇಕಾಗುತ್ತವೆ, ಇದನ್ನು ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು, ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಖರ್ಚು ಮಾಡಲಾಗುತ್ತದೆ. ವಿವಿಧ ಯೋಜನೆಗಳ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ವಿವಿಧ ಅವಶ್ಯಕತೆಗಳನ್ನು ಮತ್ತು ಅವುಗಳಿಂದ ಉಂಟಾಗುವ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸೋಣ
ಲಾಗ್ಗಳನ್ನು ಸಾಕಷ್ಟು ಸಕ್ರಿಯವಾಗಿ ಉತ್ಪಾದಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಕೇಂದ್ರೀಕೃತ ಸಂಗ್ರಹಣೆಯನ್ನು ನೋಡೋಣ: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 5000 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಾಲುಗಳು. ಅವರ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸೋಣ, ಅವುಗಳನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಸೇರಿಸಿ.
ಗರಿಷ್ಠ ನೈಜ ಸಮಯದ ಅಗತ್ಯವಿರುವ ತಕ್ಷಣ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ 4-ಕೋರ್ ಸರ್ವರ್ ಈಗಾಗಲೇ ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಓವರ್‌ಲೋಡ್ ಆಗುತ್ತದೆ:
ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ ಈ ರೀತಿಯ ಲೋಡ್ ಆಗಿದೆ. ಮತ್ತು ಡೇಟಾಬೇಸ್ ಹೆಚ್ಚಿದ ಡಿಸ್ಕ್ ಲೋಡ್‌ನೊಂದಿಗೆ ಇದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ, ಇದು ಈ ಕೆಳಗಿನ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
ಪಾಯಿಂಟ್ ಎಂಬುದು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ (ಅವು ಲಾಗ್ ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ) ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಮಯದಲ್ಲಿ ತಮ್ಮದೇ ಆದ ತೊಂದರೆಗಳನ್ನು ಹೊಂದಿವೆ. ಅವುಗಳಲ್ಲಿ ಸೇರಿಸಲಾದ ಡೇಟಾವು ತಾತ್ಕಾಲಿಕ ವಿಭಾಗವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಮುಖ್ಯ ಕೋಷ್ಟಕದೊಂದಿಗೆ ವಿಲೀನಗೊಳಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ರೆಕಾರ್ಡಿಂಗ್ ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಬಹಳ ಬೇಡಿಕೆಯಿದೆ, ಮತ್ತು ಇದು ಮೇಲಿನ ಸೂಚನೆಯನ್ನು ನಾವು ಸ್ವೀಕರಿಸಿದ ಮಿತಿಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ: 1 ಕ್ಕಿಂತ ಹೆಚ್ಚು ಉಪವಿಭಾಗಗಳನ್ನು 300 ಸೆಕೆಂಡಿನಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ (ವಾಸ್ತವವಾಗಿ, ಇದು 300 ಒಳಸೇರಿಸುವಿಕೆಗಳು ಪ್ರತಿ ಸೆಕೆಂಡ್).
ಈ ನಡವಳಿಕೆಯನ್ನು ತಪ್ಪಿಸಲು, ಸಾಧ್ಯವಾದಷ್ಟು ದೊಡ್ಡ ತುಂಡುಗಳಲ್ಲಿ ಮತ್ತು ಪ್ರತಿ 1 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 2 ಬಾರಿ ಹೆಚ್ಚು. ಆದಾಗ್ಯೂ, ದೊಡ್ಡ ಸ್ಫೋಟಗಳಲ್ಲಿ ಬರೆಯುವುದು ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಬಾರಿ ಬರೆಯಬೇಕೆಂದು ಸೂಚಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿಯಾಗಿ, ಬಫರ್ ಓವರ್‌ಫ್ಲೋ ಮತ್ತು ಲಾಗ್‌ಗಳ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. Fluentd ಬಫರ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು ಪರಿಹಾರವಾಗಿದೆ, ಆದರೆ ನಂತರ ಮೆಮೊರಿ ಬಳಕೆ ಕೂಡ ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಹೇಳಿಕೆಯನ್ನು: ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗಿನ ನಮ್ಮ ಪರಿಹಾರದ ಮತ್ತೊಂದು ಸಮಸ್ಯಾತ್ಮಕ ಅಂಶವು ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ (ಲಾಗ್‌ಹೌಸ್) ವಿಭಜನೆಯನ್ನು ಬಾಹ್ಯ ಕೋಷ್ಟಕಗಳ ಮೂಲಕ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. . ದೊಡ್ಡ ಸಮಯದ ಮಧ್ಯಂತರಗಳನ್ನು ಸ್ಯಾಂಪಲ್ ಮಾಡುವಾಗ, ಹೆಚ್ಚಿನ RAM ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಇದು ಕಾರಣವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಮೆಟಾಟೇಬಲ್ ಎಲ್ಲಾ ವಿಭಾಗಗಳ ಮೂಲಕ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ - ನಿಸ್ಸಂಶಯವಾಗಿ ಅಗತ್ಯ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಈಗ ಈ ವಿಧಾನವನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗಳಿಗೆ ಬಳಕೆಯಲ್ಲಿಲ್ಲ ಎಂದು ಸುರಕ್ಷಿತವಾಗಿ ಘೋಷಿಸಬಹುದು (ಸಿ ).
ಪರಿಣಾಮವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ನೈಜ ಸಮಯದಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರತಿ ಯೋಜನೆಯು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ (ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಅವುಗಳ ವಿತರಣೆಯು ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ). ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೀವು ಬಳಸಬೇಕಾಗುತ್ತದೆ ಶೇಖರಣೆ, ಅದಕ್ಕೆ ನಾವು ನಂತರ ಹಿಂತಿರುಗುತ್ತೇವೆ. ಮೇಲೆ ವಿವರಿಸಿದ ಪ್ರಕರಣವು ನಿಜವಾಗಿದೆ. ಮತ್ತು ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಗ್ರಾಹಕರಿಗೆ ಸರಿಹೊಂದುವಂತಹ ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಥಿರವಾದ ಪರಿಹಾರವನ್ನು ನೀಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಕನಿಷ್ಠ ವಿಳಂಬದೊಂದಿಗೆ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ...
ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದ ಬಗ್ಗೆ ಏನು?
ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟವು ಭಾರೀ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ. ಅದೇ ಯೋಜನೆಯಲ್ಲಿ ಪ್ರಯತ್ನಿಸೋಣ. ಈಗ ಲೋಡ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
Elasticsearch ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಜೀರ್ಣಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಯಿತು, ಆದಾಗ್ಯೂ, ಅಂತಹ ಸಂಪುಟಗಳನ್ನು ಬರೆಯುವುದು CPU ಅನ್ನು ಹೆಚ್ಚು ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ. ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಆಯೋಜಿಸುವ ಮೂಲಕ ಇದನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ. ತಾಂತ್ರಿಕವಾಗಿ, ಇದು ಸಮಸ್ಯೆಯಲ್ಲ, ಆದರೆ ಲಾಗ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ಈಗಾಗಲೇ ಸುಮಾರು 8 ಕೋರ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಘಟಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ಬಾಟಮ್ ಲೈನ್: ಈ ಆಯ್ಕೆಯನ್ನು ಸಮರ್ಥಿಸಬಹುದು, ಆದರೆ ಯೋಜನೆಯು ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮತ್ತು ಅದರ ನಿರ್ವಹಣೆಯು ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಗಮನಾರ್ಹ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖರ್ಚು ಮಾಡಲು ಸಿದ್ಧವಾಗಿದ್ದರೆ ಮಾತ್ರ.
ನಂತರ ನೈಸರ್ಗಿಕ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ:
ಯಾವ ದಾಖಲೆಗಳು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆ?
ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ: ಲಾಗ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಮಾಹಿತಿಯುಕ್ತವಾಗಿರಬೇಕು ಮತ್ತು ಮುಚ್ಚಬಾರದು ಪ್ರತಿಯೊಂದೂ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಘಟನೆ.
ನಾವು ಯಶಸ್ವಿ ಆನ್ಲೈನ್ ಸ್ಟೋರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ. ಯಾವ ಲಾಗ್‌ಗಳು ಮುಖ್ಯ? ಸಾಧ್ಯವಾದಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ಉದಾಹರಣೆಗೆ, ಪಾವತಿ ಗೇಟ್‌ವೇನಿಂದ, ಉತ್ತಮ ಉಪಾಯವಾಗಿದೆ. ಆದರೆ ಉತ್ಪನ್ನ ಕ್ಯಾಟಲಾಗ್‌ನಲ್ಲಿನ ಇಮೇಜ್ ಸ್ಲೈಸಿಂಗ್ ಸೇವೆಯಿಂದ ಎಲ್ಲಾ ಲಾಗ್‌ಗಳು ನಮಗೆ ನಿರ್ಣಾಯಕವಲ್ಲ: ದೋಷಗಳು ಮತ್ತು ಸುಧಾರಿತ ಮೇಲ್ವಿಚಾರಣೆ ಮಾತ್ರ ಸಾಕು (ಉದಾಹರಣೆಗೆ, ಈ ಘಟಕವು ಉತ್ಪಾದಿಸುವ 500 ದೋಷಗಳ ಶೇಕಡಾವಾರು).
ಹಾಗಾಗಿ ನಾವು ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇವೆ ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್ ಅನ್ನು ಯಾವಾಗಲೂ ಸಮರ್ಥಿಸಲಾಗುವುದಿಲ್ಲ. ಆಗಾಗ್ಗೆ ಕ್ಲೈಂಟ್ ಎಲ್ಲಾ ಲಾಗ್ಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಬಯಸುತ್ತಾರೆ, ಆದಾಗ್ಯೂ, ಸಂಪೂರ್ಣ ಲಾಗ್‌ನಿಂದ, ವ್ಯವಹಾರಕ್ಕೆ ನಿರ್ಣಾಯಕವಾಗಿರುವ ಷರತ್ತುಬದ್ಧ 5% ಸಂದೇಶಗಳು ಮಾತ್ರ ಅಗತ್ಯವಿದೆ:
- ಕೆಲವೊಮ್ಮೆ ಕಂಟೈನರ್ ಲಾಗ್ನ ಗಾತ್ರ ಮತ್ತು ದೋಷ ಸಂಗ್ರಾಹಕ (ಉದಾಹರಣೆಗೆ, ಸೆಂಟ್ರಿ) ಅನ್ನು ಮಾತ್ರ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಕು.
- ಘಟನೆಗಳನ್ನು ತನಿಖೆ ಮಾಡಲು ದೋಷ ಅಧಿಸೂಚನೆ ಮತ್ತು ದೊಡ್ಡ ಸ್ಥಳೀಯ ಲಾಗ್ ಸಾಕಷ್ಟು ಆಗಿರಬಹುದು.
- ನಾವು ಪ್ರತ್ಯೇಕವಾಗಿ ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳು ಮತ್ತು ದೋಷ ಸಂಗ್ರಹ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಮಾಡುವ ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಡೆವಲಪರ್‌ಗೆ ಲಾಗ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲ - ಅವರು ದೋಷದ ಕುರುಹುಗಳಿಂದ ಎಲ್ಲವನ್ನೂ ನೋಡಿದರು.
ಜೀವನದಿಂದ ವಿವರಣೆ
ಇನ್ನೊಂದು ಕಥೆಯು ಉತ್ತಮ ಉದಾಹರಣೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಚಯಿಸುವ ಮೊದಲು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ವಾಣಿಜ್ಯ ಪರಿಹಾರವನ್ನು ಈಗಾಗಲೇ ಬಳಸುತ್ತಿರುವ ನಮ್ಮ ಗ್ರಾಹಕರೊಬ್ಬರ ಭದ್ರತಾ ತಂಡದಿಂದ ನಾವು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ.
ಕಾರ್ಪೊರೇಟ್ ಸಮಸ್ಯೆ ಪತ್ತೆ ಸಂವೇದಕ - ಕ್ಯೂರಾಡಾರ್‌ನೊಂದಿಗೆ ಕೇಂದ್ರೀಕೃತ ಲಾಗ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಯ "ಸ್ನೇಹಿತರನ್ನು ಮಾಡಿಕೊಳ್ಳುವುದು" ಅಗತ್ಯವಾಗಿತ್ತು. ಈ ವ್ಯವಸ್ಥೆಯು ಸಿಸ್ಲಾಗ್ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಲಾಗ್ಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು FTP ಯಿಂದ ಹಿಂಪಡೆಯಬಹುದು. ಆದಾಗ್ಯೂ, fluentd ಗಾಗಿ remote_syslog ಪ್ಲಗಿನ್‌ನೊಂದಿಗೆ ಅದನ್ನು ಸಂಯೋಜಿಸಲು ತಕ್ಷಣವೇ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ (ಅದು ಬದಲಾದಂತೆ, ). QRadar ಅನ್ನು ಹೊಂದಿಸುವಲ್ಲಿನ ತೊಂದರೆಗಳು ಕ್ಲೈಂಟ್‌ನ ಭದ್ರತಾ ತಂಡದ ಬದಿಯಲ್ಲಿವೆ.
ಇದರ ಪರಿಣಾಮವಾಗಿ, ವ್ಯಾಪಾರ-ನಿರ್ಣಾಯಕ ಲಾಗ್‌ಗಳ ಭಾಗವನ್ನು FTP QRadar ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಯಿತು ಮತ್ತು ಇನ್ನೊಂದು ಭಾಗವನ್ನು ನೇರವಾಗಿ ನೋಡ್‌ಗಳಿಂದ ದೂರಸ್ಥ ಸಿಸ್ಲಾಗ್ ಮೂಲಕ ಮರುನಿರ್ದೇಶಿಸಲಾಯಿತು. ಇದಕ್ಕಾಗಿ ನಾವು ಸಹ ಬರೆದಿದ್ದೇವೆ - ಬಹುಶಃ ಇದು ಯಾರಿಗಾದರೂ ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ... ಪರಿಣಾಮವಾಗಿ ಯೋಜನೆಗೆ ಧನ್ಯವಾದಗಳು, ಕ್ಲೈಂಟ್ ಸ್ವತಃ ನಿರ್ಣಾಯಕ ದಾಖಲೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಿದರು (ಅವರ ನೆಚ್ಚಿನ ಸಾಧನಗಳನ್ನು ಬಳಸಿ), ಮತ್ತು ನಾವು ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್ನ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು, ಕೇವಲ ಉಳಿಸಿದೆ ಕಳೆದ ತಿಂಗಳು.
ಇನ್ನೊಂದು ಉದಾಹರಣೆಯು ಏನು ಮಾಡಬಾರದು ಎಂಬುದಕ್ಕೆ ಸಾಕಷ್ಟು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರಕ್ರಿಯೆಗಾಗಿ ನಮ್ಮ ಗ್ರಾಹಕರಲ್ಲಿ ಒಬ್ಬರು ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಬಳಕೆದಾರರಿಂದ ಬರುವ ಈವೆಂಟ್‌ಗಳು, ಮಲ್ಟಿಲೈನ್ ಮಾಡಲಾಗಿದೆ ರಚನೆಯಿಲ್ಲದ ಔಟ್ಪುಟ್ ಲಾಗ್‌ನಲ್ಲಿ ಮಾಹಿತಿ. ನೀವು ಊಹಿಸಿದಂತೆ, ಅಂತಹ ದಾಖಲೆಗಳು ಓದಲು ಮತ್ತು ಸಂಗ್ರಹಿಸಲು ಬಹಳ ಅನನುಕೂಲವಾಗಿದೆ.
ದಾಖಲೆಗಳಿಗಾಗಿ ಮಾನದಂಡಗಳು
ಅಂತಹ ಉದಾಹರಣೆಗಳು ಲಾಗ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಯ್ಕೆಮಾಡುವುದರ ಜೊತೆಗೆ, ನೀವು ಮಾಡಬೇಕಾದ ತೀರ್ಮಾನಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ ಲಾಗ್ಗಳನ್ನು ಸ್ವತಃ ವಿನ್ಯಾಸಗೊಳಿಸಿ! ಇಲ್ಲಿ ಅವಶ್ಯಕತೆಗಳೇನು?
- ಲಾಗ್‌ಗಳು ಯಂತ್ರ-ಓದಬಲ್ಲ ಸ್ವರೂಪದಲ್ಲಿರಬೇಕು (ಉದಾಹರಣೆಗೆ, JSON).
- ದಾಖಲೆಗಳು ಕಾಂಪ್ಯಾಕ್ಟ್ ಆಗಿರಬೇಕು ಮತ್ತು ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಲಾಗಿಂಗ್ ಮಟ್ಟವನ್ನು ಬದಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ನೀವು ಲಾಗಿಂಗ್ ಮಟ್ಟದಂತಹ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಚಲಾಯಿಸಬೇಕು ಎಚ್ಚರಿಕೆ ಅಥವಾ ದೋಷ.
- ಲಾಗ್ಗಳನ್ನು ಸಾಮಾನ್ಯಗೊಳಿಸಬೇಕು, ಅಂದರೆ, ಲಾಗ್ ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿ, ಎಲ್ಲಾ ಸಾಲುಗಳು ಒಂದೇ ರೀತಿಯ ಕ್ಷೇತ್ರವನ್ನು ಹೊಂದಿರಬೇಕು.
ರಚನೆಯಿಲ್ಲದ ಲಾಗ್‌ಗಳು ಲಾಗ್ಗಳನ್ನು ಶೇಖರಣೆಗೆ ಲೋಡ್ ಮಾಡುವಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಅವುಗಳ ಸಂಸ್ಕರಣೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸಬಹುದು. ವಿವರಣೆಯಂತೆ, ದೋಷ 400 ರೊಂದಿಗಿನ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ, ಇದು ನಿರರ್ಗಳ ಲಾಗ್‌ಗಳಲ್ಲಿ ಅನೇಕರು ಖಂಡಿತವಾಗಿಯೂ ಎದುರಿಸಿದ್ದಾರೆ:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
ದೋಷ ಎಂದರೆ ನೀವು ರೆಡಿಮೇಡ್ ಮ್ಯಾಪಿಂಗ್‌ನೊಂದಿಗೆ ಸೂಚ್ಯಂಕಕ್ಕೆ ಅಸ್ಥಿರವಾಗಿರುವ ಕ್ಷೇತ್ರವನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ವೇರಿಯಬಲ್‌ನೊಂದಿಗೆ nginx ಲಾಗ್‌ನಲ್ಲಿನ ಕ್ಷೇತ್ರವು ಸರಳವಾದ ಉದಾಹರಣೆಯಾಗಿದೆ $upstream_status. ಇದು ಸಂಖ್ಯೆ ಅಥವಾ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. ಉದಾಹರಣೆಗೆ:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
ಸರ್ವರ್ 10.100.0.10 404 ದೋಷದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಮತ್ತೊಂದು ವಿಷಯ ಸಂಗ್ರಹಣೆಗೆ ಕಳುಹಿಸಲಾಗಿದೆ ಎಂದು ಲಾಗ್‌ಗಳು ತೋರಿಸುತ್ತವೆ. ಪರಿಣಾಮವಾಗಿ, ಲಾಗ್‌ಗಳಲ್ಲಿನ ಮೌಲ್ಯವು ಈ ರೀತಿ ಆಯಿತು:
"upstream_response_time": "0.001, 0.007"
ಈ ಪರಿಸ್ಥಿತಿಯು ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಅದು ಪ್ರತ್ಯೇಕತೆಗೆ ಅರ್ಹವಾಗಿದೆ .
ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಬಗ್ಗೆ ಏನು?
ವಿನಾಯಿತಿ ಇಲ್ಲದೆ ಎಲ್ಲಾ ಲಾಗ್‌ಗಳು ಪ್ರಮುಖವಾದ ಸಂದರ್ಭಗಳಿವೆ. ಮತ್ತು ಇದರೊಂದಿಗೆ, ಮೇಲೆ ಪ್ರಸ್ತಾಪಿಸಲಾದ/ಚರ್ಚಿತ K8s ಗಾಗಿ ವಿಶಿಷ್ಟ ಲಾಗ್ ಸಂಗ್ರಹಣೆ ಯೋಜನೆಗಳು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿವೆ.
ಉದಾಹರಣೆಗೆ, fluentd ಅಲ್ಪಾವಧಿಯ ಕಂಟೈನರ್‌ಗಳಿಂದ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಮ್ಮ ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ವಲಸೆ ಧಾರಕವು 4 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ ಮತ್ತು ನಂತರ ಅಳಿಸಲಾಗಿದೆ - ಅನುಗುಣವಾದ ಟಿಪ್ಪಣಿಯ ಪ್ರಕಾರ:
"helm.sh/hook-delete-policy": hook-succeeded
ಈ ಕಾರಣದಿಂದಾಗಿ, ಶೇಖರಣೆಯಲ್ಲಿ ವಲಸೆ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಲಾಗ್ ಅನ್ನು ಸೇರಿಸಲಾಗಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ರಾಜಕೀಯ ಸಹಾಯ ಮಾಡಬಹುದು. before-hook-creation.
ಮತ್ತೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ ಡಾಕರ್ ಲಾಗ್ ತಿರುಗುವಿಕೆ. ಲಾಗ್‌ಗಳಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಬರೆಯುವ ಅಪ್ಲಿಕೇಶನ್ ಇದೆ ಎಂದು ಹೇಳೋಣ. ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ನಾವು ಎಲ್ಲಾ ಲಾಗ್ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ನಿರ್ವಹಿಸುತ್ತೇವೆ, ಆದರೆ ಸಮಸ್ಯೆ ಕಾಣಿಸಿಕೊಂಡ ತಕ್ಷಣ - ಉದಾಹರಣೆಗೆ, ತಪ್ಪಾದ ಸ್ವರೂಪದೊಂದಿಗೆ ಮೇಲೆ ವಿವರಿಸಿದಂತೆ - ಪ್ರಕ್ರಿಯೆಯು ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಡಾಕರ್ ಫೈಲ್ ಅನ್ನು ತಿರುಗಿಸುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ವ್ಯಾಪಾರ-ನಿರ್ಣಾಯಕ ದಾಖಲೆಗಳು ಕಳೆದುಹೋಗಬಹುದು.
ಅದಕ್ಕಾಗಿಯೇ ಲಾಗ್ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಮುಖ್ಯ, ಅವುಗಳ ಸುರಕ್ಷತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅತ್ಯಂತ ಮೌಲ್ಯಯುತವಾದವುಗಳನ್ನು ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕಳುಹಿಸುವ ಎಂಬೆಡಿಂಗ್. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕೆಲವನ್ನು ರಚಿಸಲು ಇದು ಅತಿಯಾಗಿರುವುದಿಲ್ಲ ದಾಖಲೆಗಳ "ಸಂಚಯಕ", ಇದು ನಿರ್ಣಾಯಕ ಸಂದೇಶಗಳನ್ನು ಉಳಿಸುವಾಗ ಸಂಕ್ಷಿಪ್ತ ಸಂಗ್ರಹಣೆಯ ಅಲಭ್ಯತೆಯನ್ನು ಬದುಕಬಲ್ಲದು.
ಅಂತಿಮವಾಗಿ, ನಾವು ಅದನ್ನು ಮರೆಯಬಾರದು ಯಾವುದೇ ಉಪವ್ಯವಸ್ಥೆಯನ್ನು ಸರಿಯಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಮುಖ್ಯ. ಇಲ್ಲದಿದ್ದರೆ, ನಿರರ್ಗಳ ಸ್ಥಿತಿಯಲ್ಲಿರುವ ಪರಿಸ್ಥಿತಿಗೆ ಓಡುವುದು ಸುಲಭ CrashLoopBackOff ಮತ್ತು ಏನನ್ನೂ ಕಳುಹಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಇದು ಪ್ರಮುಖ ಮಾಹಿತಿಯ ನಷ್ಟವನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ.
ಸಂಶೋಧನೆಗಳು
ಈ ಲೇಖನದಲ್ಲಿ, ನಾವು Datadog ನಂತಹ SaaS ಪರಿಹಾರಗಳನ್ನು ನೋಡುತ್ತಿಲ್ಲ. ಇಲ್ಲಿ ವಿವರಿಸಿದ ಅನೇಕ ಸಮಸ್ಯೆಗಳನ್ನು ಈಗಾಗಲೇ ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರುವ ವಾಣಿಜ್ಯ ಕಂಪನಿಗಳು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲಾಗಿದೆ, ಆದರೆ ಪ್ರತಿಯೊಬ್ಬರೂ ವಿವಿಧ ಕಾರಣಗಳಿಗಾಗಿ SaaS ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ (ಮುಖ್ಯವಾದವುಗಳು ವೆಚ್ಚ ಮತ್ತು 152-FZ ಅನುಸರಣೆ).
ಕೇಂದ್ರೀಕೃತ ಲಾಗ್ ಸಂಗ್ರಹವು ಮೊದಲಿಗೆ ಸರಳವಾದ ಕಾರ್ಯದಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ಅಲ್ಲ. ಇದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ:
- ನಿರ್ಣಾಯಕ ಘಟಕಗಳನ್ನು ಮಾತ್ರ ವಿವರವಾಗಿ ಲಾಗ್ ಇನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ದೋಷ ಸಂಗ್ರಹಣೆಯನ್ನು ಇತರ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.
- ಅನಗತ್ಯ ಲೋಡ್ ಅನ್ನು ಸೇರಿಸದಂತೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಲಾಗ್ಗಳನ್ನು ಕನಿಷ್ಠವಾಗಿ ಇರಿಸಬೇಕು.
- ಲಾಗ್‌ಗಳು ಯಂತ್ರವನ್ನು ಓದಬಲ್ಲವು, ಸಾಮಾನ್ಯೀಕರಿಸುವುದು ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾದ ಸ್ವರೂಪವನ್ನು ಹೊಂದಿರಬೇಕು.
- ನಿಜವಾಗಿಯೂ ನಿರ್ಣಾಯಕ ಲಾಗ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕಳುಹಿಸಬೇಕು, ಅದನ್ನು ಮುಖ್ಯವಾದವುಗಳಿಂದ ಬೇರ್ಪಡಿಸಬೇಕು.
- ಲಾಗ್ ಸಂಚಯಕವನ್ನು ಪರಿಗಣಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಇದು ಹೆಚ್ಚಿನ ಹೊರೆಯ ಸ್ಫೋಟಗಳಿಂದ ನಿಮ್ಮನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಸಂಗ್ರಹಣೆಯ ಮೇಲೆ ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚು ಏಕರೂಪವಾಗಿ ಮಾಡುತ್ತದೆ.
ಈ ಸರಳ ನಿಯಮಗಳು, ಎಲ್ಲೆಡೆ ಅನ್ವಯಿಸಿದರೆ, ಮೇಲೆ ವಿವರಿಸಿದ ಸರ್ಕ್ಯೂಟ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ - ಅವುಗಳು ಪ್ರಮುಖ ಘಟಕಗಳನ್ನು (ಬ್ಯಾಟರಿ) ಕಳೆದುಕೊಂಡಿದ್ದರೂ ಸಹ. ನೀವು ಅಂತಹ ತತ್ವಗಳಿಗೆ ಬದ್ಧವಾಗಿಲ್ಲದಿದ್ದರೆ, ಕಾರ್ಯವು ನಿಮ್ಮನ್ನು ಮತ್ತು ಮೂಲಸೌಕರ್ಯವನ್ನು ಸಿಸ್ಟಮ್ನ ಮತ್ತೊಂದು ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ (ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಿಷ್ಪರಿಣಾಮಕಾರಿ) ಘಟಕಕ್ಕೆ ಸುಲಭವಾಗಿ ಕರೆದೊಯ್ಯುತ್ತದೆ.
ಪಿಎಸ್
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «».
ಮೂಲ: www.habr.com