ಯೂರಿ ಬುಷ್ಮೆಲೆವ್ "ಲಾಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ವಿತರಿಸುವ ಕ್ಷೇತ್ರದಲ್ಲಿ ಕುಂಟೆಯ ನಕ್ಷೆ" - ವರದಿಯ ಪ್ರತಿಲೇಖನ

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

• ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯುವುದು ಹೇಗೆ;
• ದಾಖಲೆಗಳನ್ನು ಎಲ್ಲಿ ಬರೆಯಬೇಕು;
• ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಂಸ್ಕರಣೆಗಾಗಿ ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ತಲುಪಿಸುವುದು;
• ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದು ಮತ್ತು ಸಂಗ್ರಹಿಸುವುದು.

ಪ್ರಸ್ತುತ ಜನಪ್ರಿಯ ಕಂಟೈನರೈಸೇಶನ್ ತಂತ್ರಜ್ಞಾನಗಳ ಬಳಕೆಯು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಆಯ್ಕೆಗಳ ಕ್ಷೇತ್ರಕ್ಕೆ ಕುಂಟೆಯ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಮರಳನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಯೂರಿ ಬುಷ್ಮೆಲೆವ್ ಅವರ ವರದಿಯ ಪ್ರತಿಲೇಖನವು "ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ವಿತರಿಸುವ ಕ್ಷೇತ್ರದಲ್ಲಿ ರೇಕ್‌ಗಳ ನಕ್ಷೆ" ಬಗ್ಗೆ ನಿಖರವಾಗಿ ಹೇಳುತ್ತದೆ.

ಯಾರು ಕಾಳಜಿ ವಹಿಸುತ್ತಾರೆ, ದಯವಿಟ್ಟು ಬೆಕ್ಕಿನ ಕೆಳಗೆ.

ನನ್ನ ಹೆಸರು ಯೂರಿ ಬುಷ್ಮೆಲೆವ್. ನಾನು ಲಾಜಾಡಾದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ಇಂದು ನಾವು ನಮ್ಮ ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ತಯಾರಿಸಿದ್ದೇವೆ, ನಾವು ಅವುಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅಲ್ಲಿ ಏನು ಬರೆಯುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇನೆ.

ನಾವು ಎಲ್ಲಿಂದ ಬಂದಿದ್ದೇವೆ? ನಾವು ಯಾರು? ಲಜಾಡಾ ಆಗ್ನೇಯ ಏಷ್ಯಾದ ಆರು ದೇಶಗಳಲ್ಲಿ ನಂ. 1 ಆನ್‌ಲೈನ್ ಚಿಲ್ಲರೆ ವ್ಯಾಪಾರಿಯಾಗಿದೆ. ಈ ಎಲ್ಲಾ ದೇಶಗಳನ್ನು ನಮ್ಮ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ. ಪ್ರಸ್ತುತ ಒಟ್ಟು 4 ಡೇಟಾ ಕೇಂದ್ರಗಳಿವೆ. ಇದು ಏಕೆ ಮುಖ್ಯವಾಗಿದೆ? ಏಕೆಂದರೆ ಕೆಲವು ನಿರ್ಧಾರಗಳು ಕೇಂದ್ರಗಳ ನಡುವೆ ಬಹಳ ದುರ್ಬಲ ಸಂಪರ್ಕವಿದೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ. ನಮ್ಮಲ್ಲಿ ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಇದೆ. ನಾವು ಈಗಾಗಲೇ 80 ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಕಂಡು ನನಗೆ ಆಶ್ಚರ್ಯವಾಯಿತು. ನಾನು ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅವುಗಳಲ್ಲಿ ಕೇವಲ 20 ಇದ್ದವು. ಜೊತೆಗೆ PHP ಪರಂಪರೆಯ ಒಂದು ದೊಡ್ಡ ತುಣುಕು ಇದೆ, ಅದನ್ನು ನಾನು ಸಹ ಬದುಕಬೇಕು ಮತ್ತು ಸಹಿಸಿಕೊಳ್ಳಬೇಕು. ಇದೆಲ್ಲವೂ ಪ್ರಸ್ತುತ ಒಟ್ಟಾರೆಯಾಗಿ ಸಿಸ್ಟಮ್‌ಗೆ ನಿಮಿಷಕ್ಕೆ 6 ಮಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಸಂದೇಶಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಮುಂದೆ ನಾವು ಇದರೊಂದಿಗೆ ಹೇಗೆ ಬದುಕಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಇದು ಏಕೆ ಎಂದು ನಾನು ತೋರಿಸುತ್ತೇನೆ.

ಈ 6 ಮಿಲಿಯನ್ ಸಂದೇಶಗಳೊಂದಿಗೆ ನೀವು ಹೇಗಾದರೂ ಬದುಕಬೇಕು. ನಾವು ಅವರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು? ನಿಮಗೆ ಅಗತ್ಯವಿರುವ 6 ಮಿಲಿಯನ್ ಸಂದೇಶಗಳು:

• ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಕಳುಹಿಸಿ
• ವಿತರಣೆಗಾಗಿ ಸ್ವೀಕರಿಸಿ
• ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಶೇಖರಣೆಗಾಗಿ ವಿತರಿಸಿ.
• ವಿಶ್ಲೇಷಿಸಲು
• ಅದನ್ನು ಹೇಗಾದರೂ ಸಂಗ್ರಹಿಸಿ.

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

ಇದರೊಂದಿಗೆ ಬದುಕುವುದು ಹೇಗೆ? ಈಗ ನಾನು ಆಯ್ಕೆಗಳ ಕ್ಷೇತ್ರವನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ - ಈ ಸಮಸ್ಯೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು, ರವಾನಿಸುವುದು ಮತ್ತು ಸಂಗ್ರಹಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು.

ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಬರೆಯುವುದು ಹೇಗೆ? ವಿಭಿನ್ನ ಮಾರ್ಗಗಳಿವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಮ್ಮ ಫ್ಯಾಶನ್ ಒಡನಾಡಿಗಳು ನಮಗೆ ಹೇಳುವಂತೆ ಉತ್ತಮ ಅಭ್ಯಾಸವಿದೆ. ನಮ್ಮ ತಾತ ಹೇಳಿದಂತೆ ಎರಡು ರೀತಿಯ ಹಳೆಯ ಶಾಲೆಗಳಿವೆ. ಇತರ ಮಾರ್ಗಗಳಿವೆ.

ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದರೊಂದಿಗೆ ಪರಿಸ್ಥಿತಿಯು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಈ ನಿರ್ದಿಷ್ಟ ಭಾಗವನ್ನು ಪರಿಹರಿಸಲು ಹಲವು ಆಯ್ಕೆಗಳಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಈಗಾಗಲೇ ಹೆಚ್ಚಿನವುಗಳಿವೆ, ಆದರೆ ಇನ್ನೂ ಹಲವು ಇಲ್ಲ.

ಆದರೆ ವಿತರಣೆ ಮತ್ತು ನಂತರದ ವಿಶ್ಲೇಷಣೆಯೊಂದಿಗೆ, ವ್ಯತ್ಯಾಸಗಳ ಸಂಖ್ಯೆಯು ಸ್ಫೋಟಗೊಳ್ಳಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ನಾನು ಈಗ ಪ್ರತಿಯೊಂದು ಆಯ್ಕೆಯನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ. ವಿಷಯದ ಬಗ್ಗೆ ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಎಲ್ಲರಿಗೂ ಮುಖ್ಯ ಆಯ್ಕೆಗಳು ಚೆನ್ನಾಗಿ ತಿಳಿದಿವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಲಜಾಡಾದಲ್ಲಿ ನಾವು ಅದನ್ನು ಹೇಗೆ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅದು ಹೇಗೆ ಪ್ರಾರಂಭವಾಯಿತು ಎಂಬುದನ್ನು ನಾನು ನಿಮಗೆ ತೋರಿಸುತ್ತೇನೆ.

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

ಸದ್ಯಕ್ಕೆ ಸ್ವಲ್ಪ ಮುಂದೆ ನೋಡೋಣ. ನಾವು ಈ ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ತಲುಪಿಸಿದ್ದೇವೆ? ಯಾರೋ ಒಬ್ಬರು ಟಿಡಿ-ಏಜೆಂಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದಾರೆ, ಅದು ನಿಜವಾಗಿ ನಿರರ್ಗಳವಾಗಿದೆ, ಆದರೆ ಸಾಕಷ್ಟು ನಿರರ್ಗಳವಾಗಿಲ್ಲ. ಈ ಎರಡು ಯೋಜನೆಗಳ ನಡುವಿನ ಸಂಬಂಧ ನನಗೆ ಇನ್ನೂ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ, ಆದರೆ ಅವುಗಳು ಒಂದೇ ವಿಷಯದ ಬಗ್ಗೆ ತೋರುತ್ತದೆ. ಮತ್ತು ಈ ನಿರರ್ಗಳವಾಗಿ, ರೂಬಿಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಲಾಗ್ ಫೈಲ್‌ಗಳನ್ನು ಓದುತ್ತದೆ, ಕೆಲವು ರೀತಿಯ ಕ್ರಮಬದ್ಧತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು JSON ಗೆ ಪಾರ್ಸ್ ಮಾಡಿದೆ. ನಂತರ ನಾನು ಅವರನ್ನು ಕಾಫ್ಕಾಗೆ ಕಳುಹಿಸಿದೆ. ಇದಲ್ಲದೆ, ಕಾಫ್ಕಾದಲ್ಲಿ ನಾವು ಪ್ರತಿ API ಗಾಗಿ 4 ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಏಕೆ 4? ಲೈವ್ ಇರುವುದರಿಂದ, ಅಲ್ಲಿ ಸ್ಟೇಜಿಂಗ್ ಇದೆ, ಮತ್ತು stdout ಮತ್ತು stderr ಇರುವುದರಿಂದ. ಡೆವಲಪರ್‌ಗಳು ಅವುಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಅಭಿವರ್ಧಕರು ಅವುಗಳನ್ನು ಕಾಫ್ಕಾದಲ್ಲಿ ರಚಿಸಬೇಕು. ಇದಲ್ಲದೆ, ಕಾಫ್ಕಾವನ್ನು ಮತ್ತೊಂದು ಇಲಾಖೆಯು ನಿಯಂತ್ರಿಸಿತು. ಆದ್ದರಿಂದ, ಟಿಕೆಟ್ ಅನ್ನು ರಚಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು ಇದರಿಂದ ಅವರು ಪ್ರತಿ API ಗೆ 4 ವಿಷಯಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ. ಎಲ್ಲರೂ ಅದನ್ನು ಮರೆತುಬಿಟ್ಟರು. ಸಾಮಾನ್ಯವಾಗಿ, ಕಸ ಮತ್ತು ಗಡಿಬಿಡಿ ಇತ್ತು.

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

ಮೇಲಿಂದ ಮೇಲೆ ನೋಡಿದರೆ ಹೀಗೆ ಕಾಣುತ್ತದೆ. ಹಾಗೆ ಮಾಡಬೇಡ! ಇಲ್ಲಿ ಸಮಸ್ಯೆಯ ಪ್ರದೇಶಗಳನ್ನು ತಕ್ಷಣವೇ ಸಂಖ್ಯೆಗಳೊಂದಿಗೆ ಗುರುತಿಸಲಾಗುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳಿವೆ, ಆದರೆ 6 ನಿಜವಾಗಿಯೂ ಸಮಸ್ಯಾತ್ಮಕವಾದವುಗಳಾಗಿದ್ದು, ಅದರ ಬಗ್ಗೆ ಏನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ. ಈಗ ನಾನು ಅವರ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಹೇಳುತ್ತೇನೆ.

ಇಲ್ಲಿ (1,2,3) ನಾವು ಫೈಲ್ಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಇಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಮೂರು ರೇಕ್ಗಳಿವೆ.

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

ಎರಡನೆಯ ಅಂಶವೆಂದರೆ (2,3) ನಾವು API ಗೆ ಸಾಕಷ್ಟು ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. API ಫೈಲ್‌ಗೆ ಬಹಳಷ್ಟು ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತದೆ. ಕಡತಗಳು ಬೆಳೆಯುತ್ತಿವೆ. ನಾವು ಅವುಗಳನ್ನು ತಿರುಗಿಸಬೇಕಾಗಿದೆ. ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಅಲ್ಲಿ ಯಾವುದೇ ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಅವುಗಳನ್ನು ತಿರುಗಿಸುವುದು ಕೆಟ್ಟದಾಗಿದೆ ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಶೆಲ್ ಮೂಲಕ ಡೈರೆಕ್ಟರಿಗೆ ಮರುನಿರ್ದೇಶಿಸುವ ಮೂಲಕ ತಯಾರಿಸಲಾಗುತ್ತದೆ. ನಾವು ಅದನ್ನು ಪರಿಷ್ಕರಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಹ್ಯಾಂಡಲ್‌ಗಳನ್ನು ಪುನಃ ತೆರೆಯಲು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೇಳಲು ನಿಮಗೆ ಸಾಧ್ಯವಿಲ್ಲ. ಏಕೆಂದರೆ ಡೆವಲಪರ್‌ಗಳು ನಿಮ್ಮನ್ನು ಮೂರ್ಖರಂತೆ ನೋಡುತ್ತಾರೆ: “ಯಾವ ವಿವರಣೆಗಳು? ನಾವು ಸಾಮಾನ್ಯವಾಗಿ stdout ಗೆ ಬರೆಯುತ್ತೇವೆ. ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಡೆವಲಪರ್‌ಗಳು ಲಾಗ್ರೊಟೇಟ್ ಮಾಡಲು ಕಾಪಿಟ್ರಂಕೇಟ್ ಮಾಡಿದ್ದಾರೆ, ಇದು ಫೈಲ್‌ನ ನಕಲನ್ನು ಸರಳವಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮೂಲವನ್ನು ಲಿಪ್ಯಂತರ ಮಾಡುತ್ತದೆ. ಅಂತೆಯೇ, ಈ ನಕಲು ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಡಿಸ್ಕ್ ಜಾಗವು ಸಾಮಾನ್ಯವಾಗಿ ಖಾಲಿಯಾಗುತ್ತದೆ.

(4) ನಾವು ವಿಭಿನ್ನ API ಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಸ್ವರೂಪಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅವು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿದ್ದವು, ಆದರೆ regexp ಅನ್ನು ವಿಭಿನ್ನವಾಗಿ ಬರೆಯಬೇಕಾಗಿತ್ತು. ಇದೆಲ್ಲವನ್ನೂ ಪಪಿಟ್ ನಿಯಂತ್ರಿಸಿದ್ದರಿಂದ, ತಮ್ಮದೇ ಆದ ಜಿರಳೆಗಳನ್ನು ಹೊಂದಿರುವ ವರ್ಗಗಳ ದೊಡ್ಡ ಗುಂಪೇ ಇತ್ತು. ಜೊತೆಗೆ, ಹೆಚ್ಚಿನ ಸಮಯ td-ಏಜೆಂಟ್ ಮೆಮೊರಿಯನ್ನು ತಿನ್ನಬಹುದು, ಮೂರ್ಖರಾಗಬಹುದು, ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಟಿಸಬಹುದು. ಹೊರಗಿನಿಂದ ಅವನು ಏನನ್ನೂ ಮಾಡುತ್ತಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯವಾಗಿತ್ತು. ಅತ್ಯುತ್ತಮವಾಗಿ, ಅವನು ಬೀಳುತ್ತಾನೆ ಮತ್ತು ಯಾರಾದರೂ ಅವನನ್ನು ನಂತರ ಎತ್ತಿಕೊಂಡು ಹೋಗುತ್ತಾರೆ. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಎಚ್ಚರಿಕೆಯು ಬರುತ್ತದೆ, ಮತ್ತು ಯಾರಾದರೂ ಹೋಗಿ ಅದನ್ನು ತಮ್ಮ ಕೈಗಳಿಂದ ಎತ್ತುತ್ತಾರೆ.

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

ನಾವು ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ತಪ್ಪಿತಸ್ಥರನ್ನು ಹುಡುಕದಿರಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

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

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

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

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

ನಿರರ್ಗಳವಾಗಿ ಮೊದಲನೆಯದಾಗಿ, ನಾನು ಅವನನ್ನು ಹಿಂದಿನ ಕೆಲಸದಲ್ಲಿ ಎದುರಿಸಿದೆ, ಮತ್ತು ಅವನು ನಿಯತಕಾಲಿಕವಾಗಿ ಅಲ್ಲಿ ಬಿದ್ದನು. ಎರಡನೆಯದಾಗಿ, ಇದು ಒಂದೇ ವಿಷಯ, ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಮಾತ್ರ.

ಫೈಲ್ಬೀಟ್. ಅದು ನಮಗೆ ಹೇಗೆ ಅನುಕೂಲಕರವಾಗಿತ್ತು? ಏಕೆಂದರೆ ಅದು ಗೋದಲ್ಲಿದೆ ಮತ್ತು ನಾವು ಗೋದಲ್ಲಿ ಸಾಕಷ್ಟು ಪರಿಣತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅದರಂತೆ, ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ, ನಾವು ಹೇಗಾದರೂ ಅದನ್ನು ನಮಗಾಗಿ ಸೇರಿಸಬಹುದು. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ. ಆದ್ದರಿಂದ ನಿಮಗಾಗಿ ಅದನ್ನು ಪುನಃ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸುವ ಯಾವುದೇ ಪ್ರಲೋಭನೆಯೂ ಇಲ್ಲ.

ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್‌ಗೆ ಸ್ಪಷ್ಟವಾದ ಪರಿಹಾರವೆಂದರೆ ಈ ಪ್ರಮಾಣದಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ ಸಿಸ್‌ಲಾಗ್‌ಗಳು (syslog-ng/rsyslog/nxlog).

ಅಥವಾ ನಿಮ್ಮದೇ ಆದದನ್ನು ಬರೆಯಿರಿ, ಆದರೆ ನಾವು ಇದನ್ನು ತಿರಸ್ಕರಿಸಿದ್ದೇವೆ, ಹಾಗೆಯೇ ಫೈಲ್‌ಬೀಟ್. ನೀವು ಏನನ್ನಾದರೂ ಬರೆಯುತ್ತಿದ್ದರೆ, ವ್ಯವಹಾರಕ್ಕೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಬರೆಯುವುದು ಉತ್ತಮ. ದಾಖಲೆಗಳನ್ನು ತಲುಪಿಸಲು, ರೆಡಿಮೇಡ್ ಏನನ್ನಾದರೂ ತೆಗೆದುಕೊಳ್ಳುವುದು ಉತ್ತಮ.

ಆದ್ದರಿಂದ, ಆಯ್ಕೆಯು ವಾಸ್ತವವಾಗಿ syslog-ng ಮತ್ತು rsyslog ನಡುವಿನ ಆಯ್ಕೆಗೆ ಬಂದಿತು. ನಾವು ಈಗಾಗಲೇ ಪಪಿಟ್‌ನಲ್ಲಿ rsyslog ಗಾಗಿ ತರಗತಿಗಳನ್ನು ಹೊಂದಿದ್ದರಿಂದ ನಾನು rsyslog ಕಡೆಗೆ ವಾಲಿದ್ದೇನೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಸ್ಪಷ್ಟವಾದ ವ್ಯತ್ಯಾಸವನ್ನು ನಾನು ಕಾಣಲಿಲ್ಲ. ಸಿಸ್ಲಾಗ್ ಎಂದರೇನು, ಸಿಸ್ಲಾಗ್ ಎಂದರೇನು. ಹೌದು, ಕೆಲವು ಕೆಟ್ಟ ದಾಖಲಾತಿಗಳನ್ನು ಹೊಂದಿವೆ, ಕೆಲವು ಉತ್ತಮವಾಗಿವೆ. ಇದನ್ನು ಈ ರೀತಿ ಮಾಡಬಹುದು, ಮತ್ತು ಇನ್ನೊಂದು ವಿಭಿನ್ನವಾಗಿ ಮಾಡಬಹುದು.

ಮತ್ತು rsyslog ಬಗ್ಗೆ ಸ್ವಲ್ಪ. ಮೊದಲನೆಯದಾಗಿ, ಇದು ಬಹಳಷ್ಟು ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ ಇದು ತಂಪಾಗಿದೆ. ಇದು ಮಾನವ-ಓದಬಲ್ಲ ರೈನರ್‌ಸ್ಕ್ರಿಪ್ಟ್ (ಆಧುನಿಕ ಸಂರಚನಾ ಭಾಷೆ) ಹೊಂದಿದೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟೂಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಟಿಡಿ-ಏಜೆಂಟ್‌ನ ನಡವಳಿಕೆಯನ್ನು ನಾವು ಅನುಕರಿಸಲು ಇದು ಅದ್ಭುತವಾದ ಬೋನಸ್ ಆಗಿದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಏನೂ ಬದಲಾಗಿಲ್ಲ. ಅಂದರೆ, ನಾವು td-agent ಅನ್ನು rsyslog ಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಸದ್ಯಕ್ಕೆ ಎಲ್ಲವನ್ನೂ ಬಿಟ್ಟುಬಿಡುತ್ತೇವೆ. ಮತ್ತು ನಾವು ತಕ್ಷಣ ಕೆಲಸದ ವಿತರಣೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ಮುಂದೆ, rsyslog ನಲ್ಲಿ mmnormalize ಒಂದು ಅದ್ಭುತ ವಿಷಯವಾಗಿದೆ. ಇದು ನಿಮಗೆ ಲಾಗ್‌ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ Grok ಮತ್ತು regexp ನೊಂದಿಗೆ ಅಲ್ಲ. ಇದು ಅಮೂರ್ತ ಸಿಂಟ್ಯಾಕ್ಸ್ ಮರವನ್ನು ಮಾಡುತ್ತದೆ. ಕಂಪೈಲರ್ ಮೂಲಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುವ ರೀತಿಯಲ್ಲಿಯೇ ಇದು ಲಾಗ್‌ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ. ಇದು ನಿಮಗೆ ಬೇಗನೆ ಕೆಲಸ ಮಾಡಲು, ಕಡಿಮೆ CPU ಅನ್ನು ಸೇವಿಸಲು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ನಿಜವಾಗಿಯೂ ತಂಪಾದ ವಿಷಯವಾಗಿದೆ. ಇತರ ಬೋನಸ್‌ಗಳ ಗುಂಪೇ ಇವೆ. ನಾನು ಅವರ ಮೇಲೆ ನೆಲೆಸುವುದಿಲ್ಲ.

rsyslog ಹಲವಾರು ಇತರ ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ಅವು ಬೋನಸ್‌ಗಳಂತೆಯೇ ಇರುತ್ತವೆ. ಮುಖ್ಯ ಸಮಸ್ಯೆಗಳೆಂದರೆ ನೀವು ಅದನ್ನು ಹೇಗೆ ಬೇಯಿಸುವುದು ಎಂದು ತಿಳಿಯಬೇಕು ಮತ್ತು ನೀವು ಆವೃತ್ತಿಯನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ.

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

ಏಕೆ ಕಡತ ಇಲ್ಲ? ಏಕೆಂದರೆ ಎಲ್ಲರೂ ಓದುತ್ತಾರೆ Badushechka ಬಗ್ಗೆ ಲೇಖನ, ಇದು ಡಾಕರ್‌ಗೆ ಫೈಲ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದೆ ಮತ್ತು rsyslog ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಬದಲಾಗಿದೆ ಮತ್ತು ಡಾಕರ್ ಈ ಫೈಲ್ ಅನ್ನು ಕಳೆದುಕೊಂಡಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ಇದು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ತೆರೆದಿರುತ್ತದೆ, ಆದರೆ ಅವರು ಬರೆಯುವ ಸಾಕೆಟ್ ಅಲ್ಲ. ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ತಡೆಯುವ ಸಮಸ್ಯೆಯ ಸುತ್ತಲೂ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ.

Rsyslog ಸ್ಲೈಡ್‌ನಲ್ಲಿ ಸೂಚಿಸಲಾದ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ರಿಲೇ ಅಥವಾ ಕಾಫ್ಕಾಗೆ ಲಾಗ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಕಾಫ್ಕಾ ಹಳೆಯ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ. ರಿಲೇ - ಲಾಗ್‌ಗಳನ್ನು ತಲುಪಿಸಲು ನಾನು ಶುದ್ಧ rsyslog ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದೆ. ಸಂದೇಶ ಕ್ಯೂ ಇಲ್ಲದೆ, ಪ್ರಮಾಣಿತ rsyslog ಉಪಕರಣಗಳನ್ನು ಬಳಸಿ. ಮೂಲತಃ, ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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

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

ಸಮಸ್ಯೆಗಳೇನು? ನಮ್ಮ ಲೈವ್ API ಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 50k ಸಂದೇಶಗಳನ್ನು ಬರೆಯುತ್ತಿವೆ ಎಂದು ನಾವು ಪತ್ತೆ ಮಾಡಿದಾಗ (ಇದ್ದಕ್ಕಿದ್ದಂತೆ!) ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದವು. ಇದು ಸ್ಟೇಜಿಂಗ್ ಇಲ್ಲದ ಲೈವ್ API ಮಾತ್ರ. ಮತ್ತು ಗ್ರೇಲಾಗ್ ನಮಗೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಕೇವಲ 12 ಸಾವಿರ ಸಂದೇಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಮತ್ತು ಸಮಂಜಸವಾದ ಪ್ರಶ್ನೆ ಹುಟ್ಟಿಕೊಂಡಿತು: ಅವಶೇಷಗಳು ಎಲ್ಲಿವೆ? ಇದರಿಂದ ನಾವು ಗ್ರೇಲಾಗ್ ಸರಳವಾಗಿ ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ತೀರ್ಮಾನಿಸಿದೆವು. ನಾವು ನೋಡಿದ್ದೇವೆ, ಮತ್ತು, ಗ್ರೇಲಾಗ್ ಮತ್ತು ಎಲಾಸ್ಟಿಕ್ ಸರ್ಚ್ ಈ ಹರಿವನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

ಮುಂದೆ, ನಾವು ಹಾದಿಯಲ್ಲಿ ಮಾಡಿದ ಇತರ ಆವಿಷ್ಕಾರಗಳು.

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

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

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

ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುವುದು? ನೀವು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪಡೆಯಬೇಕಾದರೆ, ಎಲ್ಲಾ ಯಂತ್ರಗಳಿಗೆ ಓಡದಂತೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು, ಫೈಲ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸಿ. ಇದು ಕೆಲಸ ಮಾಡುವ ಭರವಸೆ ಇದೆ. ಇದನ್ನು ಯಾವುದೇ ಸರ್ವರ್‌ನಿಂದ ಮಾಡಬಹುದು. ನೀವು ಅಲ್ಲಿ ಡಿಸ್ಕ್ಗಳನ್ನು ಅಂಟಿಸಬೇಕು ಮತ್ತು ಸಿಸ್ಲಾಗ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕು. ಇದರ ನಂತರ, ಎಲ್ಲಾ ಲಾಗ್‌ಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಹೊಂದಲು ನಿಮಗೆ ಖಾತರಿ ನೀಡಲಾಗುತ್ತದೆ. ನಂತರ ನೀವು ನಿಧಾನವಾಗಿ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ, ಗ್ರೇಲಾಗ್ ಮತ್ತು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಆದರೆ ನೀವು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ ಮತ್ತು ಮೇಲಾಗಿ, ಸಾಕಷ್ಟು ಡಿಸ್ಕ್ ಅರೇಗಳಿರುವವರೆಗೆ ನೀವು ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.

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

ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್ ಮತ್ತು ಗ್ರೇಲಾಗ್‌ನೊಂದಿಗೆ ಈ ಭಾಗವು ನಿಜವಾಗಿಯೂ ಹೊರಹೊಮ್ಮುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಅದನ್ನು ತೊಡೆದುಹಾಕಬೇಕು. ನೀವು ಒಂದು ವಿಷಯವನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ.

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

ಹೊಸ ಗ್ರೇಲಾಗ್‌ನಲ್ಲಿ ನಿಖರವಾಗಿ ಏನು ಸೇರಿಸಲಾಗಿದೆ. ನಾವು ಎಲ್ಲವನ್ನೂ ಡಾಕರ್‌ಗೆ ಬರೆದಿದ್ದೇವೆ. ನಾವು ಸರ್ವರ್‌ಗಳ ಗುಂಪನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಮೂರು ಕಾಫ್ಕಾ ನಿದರ್ಶನಗಳನ್ನು ಹೊರತಂದಿದ್ದೇವೆ, 7 ಗ್ರೇಲಾಗ್ ಸರ್ವರ್‌ಗಳ ಆವೃತ್ತಿ 2.3 (ನಾವು ಎಲಾಸ್ಟಿಕ್‌ಸರ್ಚ್ ಆವೃತ್ತಿ 5 ಬಯಸಿದ್ದರಿಂದ). ಎಚ್‌ಡಿಡಿಯಿಂದ ದಾಳಿಯ ಸಮಯದಲ್ಲಿ ಇದೆಲ್ಲವನ್ನೂ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ಸಾವಿರ ಸಂದೇಶಗಳ ಸೂಚಿಕೆ ದರವನ್ನು ನೋಡಿದ್ದೇವೆ. ವಾರಕ್ಕೆ 140 ಟೆರಾಬೈಟ್ ಡೇಟಾ ಎಂಬ ಅಂಕಿ ಅಂಶವನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ.

ಮತ್ತು ಮತ್ತೆ ಕುಂಟೆ! ನಮಗೆ ಎರಡು ಮಾರಾಟಗಳು ಬರಲಿವೆ. ನಾವು 6 ಮಿಲಿಯನ್ ಸಂದೇಶಗಳನ್ನು ಮೀರಿ ಹೋಗಿದ್ದೇವೆ. ಗ್ರೇಲಾಗ್‌ಗೆ ಅಗಿಯಲು ಸಮಯವಿಲ್ಲ. ಹೇಗಾದರೂ ಮಾಡಿ ಮತ್ತೆ ಬದುಕಬೇಕು.

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

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

ಗ್ರೇಲಾಗ್‌ನಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ.

ದರ ಮಿತಿಯನ್ನು ಮಾಡಿ ಇದರಿಂದ ನಮ್ಮ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮತ್ತು ಉಳಿದೆಲ್ಲವನ್ನೂ ನಾಶಪಡಿಸದ ಒಂದು ಕ್ರೇಜಿ API ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.

ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಕೆಲವು ರೀತಿಯ SLA ಗೆ ಸಹಿ ಮಾಡಿ ಇದರಿಂದ ನಾವು ತುಂಬಾ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದು. ನೀವು ಹೆಚ್ಚು ಬರೆದರೆ, ಕ್ಷಮಿಸಿ.

ಮತ್ತು ದಸ್ತಾವೇಜನ್ನು ಬರೆಯಿರಿ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ನಾವು ಅನುಭವಿಸಿದ ಎಲ್ಲದರ ಫಲಿತಾಂಶಗಳು. ಮೊದಲನೆಯದಾಗಿ, ಮಾನದಂಡಗಳು. ಎರಡನೆಯದಾಗಿ, ಸಿಸ್ಲಾಗ್ ಕೇಕ್ ಆಗಿದೆ. ಮೂರನೆಯದಾಗಿ, rsyslog ಸ್ಲೈಡ್‌ನಲ್ಲಿ ಬರೆದಂತೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಪ್ರಶ್ನೆಗಳಿಗೆ ಹೋಗೋಣ.

ಪ್ರಶ್ನೆಗಳು.

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ನೀವು ತೆಗೆದುಕೊಳ್ಳದಿರಲು ಏಕೆ ನಿರ್ಧರಿಸಿದ್ದೀರಿ... (ಫೈಲ್‌ಬೀಟ್?)

ಉತ್ತರಿಸಿ: ನಾವು ಫೈಲ್‌ಗೆ ಬರೆಯಬೇಕಾಗಿದೆ. ನಾನು ನಿಜವಾಗಿಯೂ ಬಯಸಲಿಲ್ಲ. ನಿಮ್ಮ API ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರಾರು ಸಂದೇಶಗಳನ್ನು ಬರೆಯುವಾಗ, ನೀವು ಅದನ್ನು ಗಂಟೆಗೆ ಒಮ್ಮೆ ತಿರುಗಿಸಿದರೂ ಸಹ, ಇದು ಇನ್ನೂ ಆಯ್ಕೆಯಾಗಿಲ್ಲ. ನೀವು ಪೈಪ್ನಲ್ಲಿ ಬರೆಯಬಹುದು. ಅದಕ್ಕೆ ಡೆವಲಪರ್‌ಗಳು ನನ್ನನ್ನು ಕೇಳಿದರು: "ನಾವು ಬರೆಯುತ್ತಿರುವ ಪ್ರಕ್ರಿಯೆಯು ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಏನಾಗುತ್ತದೆ?" ಅವರಿಗೆ ಏನು ಉತ್ತರಿಸಬೇಕೆಂದು ನಾನು ಕಂಡುಕೊಳ್ಳಲಿಲ್ಲ ಮತ್ತು ಹೇಳಿದೆ: "ಸರಿ, ಸರಿ, ನಾವು ಅದನ್ನು ಮಾಡಬೇಡಿ."

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ನೀವು HDFS ಗೆ ಲಾಗ್‌ಗಳನ್ನು ಏಕೆ ಬರೆಯಬಾರದು?

ಉತ್ತರಿಸಿ: ಇದು ಮುಂದಿನ ಹಂತವಾಗಿದೆ. ನಾವು ಪ್ರಾರಂಭದಲ್ಲಿಯೇ ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಿದ್ದೇವೆ, ಆದರೆ ಈ ಸಮಯದಲ್ಲಿ ಇದನ್ನು ಮಾಡಲು ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳಿಲ್ಲದ ಕಾರಣ, ಅದು ನಮ್ಮ ದೀರ್ಘಕಾಲೀನ ಪರಿಹಾರದಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ಕಾಲಮ್ ಸ್ವರೂಪವು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.

ಉತ್ತರಿಸಿ: ನನಗೆ ಅರ್ಥವಾಗಿದೆ. ಅದಕ್ಕಾಗಿ ನಾವು ಎರಡೂ ಕೈಗಳಿಂದ ಇದ್ದೇವೆ.

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ನೀವು rsyslog ಗೆ ಬರೆಯುತ್ತಿದ್ದೀರಿ. ಅಲ್ಲಿ ನೀವು TCP ಮತ್ತು UDP ಎರಡನ್ನೂ ಬಳಸಬಹುದು. ಆದರೆ UDP ಆಗಿದ್ದರೆ, ನೀವು ವಿತರಣೆಯನ್ನು ಹೇಗೆ ಖಾತರಿಪಡಿಸುತ್ತೀರಿ?

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

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: API ಲಾಗ್‌ನಲ್ಲಿ ಕೆಲವು ಸಂದೇಶಗಳನ್ನು ರಚಿಸಿದಾಗ ಮತ್ತು ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಿಗೆ ನಿಯಂತ್ರಣವನ್ನು ವರ್ಗಾಯಿಸಿದಾಗ, ವಿಭಿನ್ನ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಿಂದ ಸಂದೇಶಗಳು ತಪ್ಪಾದ ಕ್ರಮದಲ್ಲಿ ಬರುವ ಸಮಸ್ಯೆಯನ್ನು ನೀವು ಎದುರಿಸಿದ್ದೀರಾ? ಇದರಿಂದ ಗೊಂದಲ ಉಂಟಾಗುತ್ತದೆ.

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

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಿಂದ ಬದಲಾಗಬಹುದು.

ಉತ್ತರಿಸಿ: ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು API ಮೂಲಕ ರಚಿಸಲಾಗಿದೆ. ಇದು ವಾಸ್ತವವಾಗಿ, ಸಂಪೂರ್ಣ ಅಂಶವಾಗಿದೆ. ನಮ್ಮಲ್ಲಿ NTP ಇದೆ. API ಸಂದೇಶದಲ್ಲಿಯೇ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. rsyslog ಅದನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ.

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

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

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ಅಸಹಜ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನೀವು ಅಲ್ಲಿಂದ ಲಾಗ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಾ?

ಉತ್ತರಿಸಿ: ನೀವು ಅಲ್ಲಿಗೆ (ಫೈಲ್ ಸಂಗ್ರಹಣೆಗೆ) ಹೋಗಿ ನೋಡಬಹುದು.

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ನೀವು ಲಾಗ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಿಲ್ಲ ಎಂದು ನೀವು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೀರಿ?

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

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದಲ್ಲಿ ನೀವು ಪುನರಾವರ್ತನೆಯೊಂದಿಗೆ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೀರಿ. ನಿಮ್ಮ ಬಳಿ ಎಷ್ಟು ಪ್ರತಿಕೃತಿಗಳಿವೆ?

ಉತ್ತರಿಸಿ: ಒಂದು ಸಾಲು.

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ಇದು ಕೇವಲ ಒಂದು ಸಾಲೇ?

ಉತ್ತರಿಸಿ: ಇದು ಮಾಸ್ಟರ್ ಮತ್ತು ಪ್ರತಿಕೃತಿ. ಡೇಟಾವನ್ನು ಎರಡು ಪ್ರತಿಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.

ನಿಮ್ಮ ಪ್ರಶ್ನೆ: ನೀವು ಹೇಗಾದರೂ rsyslog ಬಫರ್ ಗಾತ್ರವನ್ನು ಸರಿಹೊಂದಿಸಿದ್ದೀರಾ?

ಉತ್ತರಿಸಿ: ನಾವು ಕಸ್ಟಮ್ ಯುನಿಕ್ಸ್ ಸಾಕೆಟ್‌ಗೆ ಡೇಟಾಗ್ರಾಮ್‌ಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ. ಇದು ತಕ್ಷಣವೇ ನಮ್ಮ ಮೇಲೆ 128 ಕಿಲೋಬೈಟ್‌ಗಳ ಮಿತಿಯನ್ನು ವಿಧಿಸುತ್ತದೆ. ನಾವು ಅದಕ್ಕೆ ಹೆಚ್ಚು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಾವು ಇದನ್ನು ಮಾನದಂಡಕ್ಕೆ ಬರೆದಿದ್ದೇವೆ. ಶೇಖರಣೆಗೆ ಬರಲು ಬಯಸುವವರು 128 ಕಿಲೋಬೈಟ್ಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ. ಗ್ರಂಥಾಲಯಗಳು, ಮೇಲಾಗಿ, ಕತ್ತರಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಸಂದೇಶವನ್ನು ಕತ್ತರಿಸಲಾಗಿದೆ ಎಂದು ಧ್ವಜವನ್ನು ಇರಿಸಲಾಗುತ್ತದೆ. ಸಂದೇಶಕ್ಕಾಗಿ ನಮ್ಮ ಮಾನದಂಡವು ವಿಶೇಷ ಕ್ಷೇತ್ರವನ್ನು ಹೊಂದಿದೆ, ಅದು ರೆಕಾರ್ಡಿಂಗ್ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಕಡಿತಗೊಳಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಈ ಕ್ಷಣವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಮಗೆ ಅವಕಾಶವಿದೆ.

ಪ್ರಶ್ನೆ: ನೀವು ಮುರಿದ JSON ಬರೆಯುತ್ತೀರಾ?

ಉತ್ತರಿಸಿ: ಬ್ರೋಕನ್ JSON ಅನ್ನು ರಿಲೇ ಸಮಯದಲ್ಲಿ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ. ಅಥವಾ ಗ್ರೇಲಾಗ್ ಅನ್ನು ತ್ಯಜಿಸಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಅದು JSON ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದರೆ ಸರಿಪಡಿಸಬೇಕಾದ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳು ಇವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಹೆಚ್ಚಾಗಿ rsyslog ಗೆ ಕಟ್ಟಲಾಗುತ್ತದೆ. ನಾನು ಈಗಾಗಲೇ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಭರ್ತಿ ಮಾಡಿದ್ದೇನೆ, ಅದು ಇನ್ನೂ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿದೆ.

ಪ್ರಶ್ನೆ: ಕಾಫ್ಕಾ ಏಕೆ? ನೀವು RabbitMQ ಅನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೀರಾ? ಅಂತಹ ಹೊರೆಗಳ ಅಡಿಯಲ್ಲಿ ಗ್ರೇಲಾಗ್ ವಿಫಲಗೊಳ್ಳುತ್ತದೆಯೇ?

ಉತ್ತರಿಸಿ: ಗ್ರೇಲಾಗ್‌ನೊಂದಿಗೆ ಇದು ನಮಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ. ಮತ್ತು ಗ್ರೇಲಾಗ್ ನಮಗೆ ಆಕಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ. ಅವನು ನಿಜವಾಗಿಯೂ ಸಮಸ್ಯಾತ್ಮಕ. ಅವನು ಒಂದು ವಿಶಿಷ್ಟ ವಿಷಯ. ಮತ್ತು, ವಾಸ್ತವವಾಗಿ, ಇದು ಅಗತ್ಯವಿಲ್ಲ. ನಾನು rsyslog ನಿಂದ ನೇರವಾಗಿ elasticsearch ಗೆ ಬರೆಯಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ನಂತರ Kibana ಅನ್ನು ನೋಡುತ್ತೇನೆ. ಆದರೆ ನಾವು ಭದ್ರತಾ ಸಿಬ್ಬಂದಿಯೊಂದಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ಬಗೆಹರಿಸಬೇಕಾಗಿದೆ. ನಾವು ಗ್ರೇಲಾಗ್ ಅನ್ನು ಹೊರಹಾಕಿದಾಗ ಮತ್ತು ಕಿಬಾನಾವನ್ನು ಬಳಸಿದಾಗ ಇದು ನಮ್ಮ ಅಭಿವೃದ್ಧಿಗೆ ಸಂಭವನೀಯ ಆಯ್ಕೆಯಾಗಿದೆ. ಲಾಗ್‌ಸ್ಟ್ಯಾಶ್ ಅನ್ನು ಬಳಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಏಕೆಂದರೆ ನಾನು rsyslog ನೊಂದಿಗೆ ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡಬಹುದು. ಮತ್ತು ಇದು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟಕ್ಕೆ ಬರೆಯಲು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಹೊಂದಿದೆ. ನಾವು ಗ್ರೇಲಾಗ್‌ನೊಂದಿಗೆ ಹೇಗಾದರೂ ಬದುಕಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ನಾವು ಅದನ್ನು ಸ್ವಲ್ಪ ಟ್ಯೂನ್ ಮಾಡಿದ್ದೇವೆ. ಆದರೆ ಇನ್ನೂ ಸುಧಾರಣೆಗೆ ಅವಕಾಶವಿದೆ.

ಕಾಫ್ಕಾ ಬಗ್ಗೆ. ಇದು ಐತಿಹಾಸಿಕವಾಗಿ ನಡೆದದ್ದು ಹೀಗೆ. ನಾನು ಬಂದಾಗ, ಅದು ಆಗಲೇ ಇತ್ತು ಮತ್ತು ಅದಕ್ಕೆ ದಾಖಲೆಗಳನ್ನು ಈಗಾಗಲೇ ಬರೆಯಲಾಗಿದೆ. ನಾವು ಸರಳವಾಗಿ ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದರೊಳಗೆ ಲಾಗ್ಗಳನ್ನು ಸರಿಸಿದ್ದೇವೆ. ನಾವು ಅವನ ನಿರ್ವಹಣೆ, ಅವನು ಹೇಗೆ ಭಾವಿಸುತ್ತಾನೆಂದು ನಮಗೆ ತಿಳಿದಿದೆ. RabbitMQ ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ... ಇದು RabbitMQ ನೊಂದಿಗೆ ನಮಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತು RabbitMQ ನಮಗೆ ಆಕಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ. ನಾವು ಅದನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಅದರಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ. ಈಗ, ಮಾರಾಟದ ಮೊದಲು, ಅವರು ಅವನನ್ನು ಮೋಡಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವನು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ. ಆದರೆ ಅದಕ್ಕೂ ಮೊದಲು ನಾನು ಅದನ್ನು ನಿರ್ಮಾಣಕ್ಕೆ ಬಿಡುಗಡೆ ಮಾಡಲು ಸಿದ್ಧರಿರಲಿಲ್ಲ. ಇನ್ನೂ ಒಂದು ಅಂಶವಿದೆ. ಗ್ರೇಲಾಗ್ ಆವೃತ್ತಿ AMQP 0.9 ಅನ್ನು ಓದಬಹುದು ಮತ್ತು rsyslog ಆವೃತ್ತಿ AMQP 1.0 ಅನ್ನು ಬರೆಯಬಹುದು. ಮತ್ತು ಎರಡೂ ಮಾಡಬಹುದಾದ ಮಧ್ಯದಲ್ಲಿ ಒಂದೇ ಪರಿಹಾರವಿಲ್ಲ. ಇದು ಒಂದು ಅಥವಾ ಇನ್ನೊಂದು. ಆದ್ದರಿಂದ, ಸದ್ಯಕ್ಕೆ ಕಾಫ್ಕಾ ಮಾತ್ರ. ಆದರೆ ಇದು ತನ್ನದೇ ಆದ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಹೊಂದಿದೆ. ಏಕೆಂದರೆ ನಾವು ಬಳಸುವ rsyslog ಆವೃತ್ತಿಯ omkafka rsyslog ನಿಂದ ಹೊರತೆಗೆದ ಸಂಪೂರ್ಣ ಸಂದೇಶ ಬಫರ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಸದ್ಯ ನಾವು ಅದನ್ನು ಸಹಿಸಿಕೊಂಡಿದ್ದೇವೆ.

ಪ್ರಶ್ನೆ: ನೀವು ಕಾಫ್ಕಾವನ್ನು ಬಳಸುತ್ತಿದ್ದೀರಾ ಏಕೆಂದರೆ ನೀವು ಅದನ್ನು ಈಗಾಗಲೇ ಹೊಂದಿದ್ದೀರಾ? ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಉದ್ದೇಶಕ್ಕಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲವೇ?

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

ಪ್ರಶ್ನೆ: ಸಾಕೆಟ್ಗಳೊಂದಿಗೆ ನಮಗೆ ಈ ಶಾಮನಿಸಂ ಏಕೆ ಬೇಕು? ಕಂಟೈನರ್‌ಗಳಿಗಾಗಿ ನೀವು ಸಿಸ್ಲಾಗ್ ಲಾಗ್ ಡ್ರೈವರ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೀರಾ?

ಉತ್ತರಿಸಿ: ನಾವು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದಾಗ, ಡಾಕರ್‌ನೊಂದಿಗಿನ ನಮ್ಮ ಸಂಬಂಧವು ಉದ್ವಿಗ್ನವಾಗಿತ್ತು. ಇದು ಡಾಕರ್ 1.0 ಅಥವಾ 0.9 ಆಗಿತ್ತು. ಡಾಕರ್ ಸ್ವತಃ ವಿಚಿತ್ರವಾಗಿತ್ತು. ಎರಡನೆಯದಾಗಿ, ನೀವು ಅದರೊಳಗೆ ಲಾಗ್‌ಗಳನ್ನು ಸಹ ತಳ್ಳಿದರೆ ... ಅದು ಎಲ್ಲಾ ಲಾಗ್‌ಗಳನ್ನು ಡಾಕರ್ ಡೀಮನ್ ಮೂಲಕ ತನ್ನ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ ಎಂದು ನನಗೆ ಪರಿಶೀಲಿಸದ ಅನುಮಾನವಿದೆ. ಒಂದು API ಹುಚ್ಚರಾಗಿದ್ದರೆ, ಉಳಿದ APIಗಳು stdout ಮತ್ತು stderr ಅನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬ ಅಂಶದಲ್ಲಿ ಸಿಲುಕಿಕೊಂಡಿವೆ. ಇದು ಎಲ್ಲಿಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ಈ ಸ್ಥಳದಲ್ಲಿ ಡಾಕರ್ ಸಿಸ್ಲಾಗ್ ಡ್ರೈವರ್ ಅನ್ನು ಬಳಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂಬ ಭಾವನೆಯ ಮಟ್ಟದಲ್ಲಿ ನನಗೆ ಅನುಮಾನವಿದೆ. ನಮ್ಮ ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷಾ ವಿಭಾಗವು ಲಾಗ್‌ಗಳೊಂದಿಗೆ ತನ್ನದೇ ಆದ ಗ್ರೇಲಾಗ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದೆ. ಅವರು ಡಾಕರ್ ಲಾಗ್ ಡ್ರೈವರ್‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಅಲ್ಲಿ ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಆದರೆ ಅವರು ತಕ್ಷಣವೇ GELF ಅನ್ನು ಗ್ರೇಲಾಗ್‌ಗೆ ಬರೆಯುತ್ತಾರೆ. ನಾವು ಇದೆಲ್ಲವನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಸಮಯದಲ್ಲಿ, ನಮಗೆ ಕೆಲಸ ಮಾಡಲು ಇದು ಬೇಕಾಗಿತ್ತು. ಬಹುಶಃ ನಂತರ, ಯಾರಾದರೂ ಬಂದು ನೂರು ವರ್ಷಗಳಿಂದ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಹೇಳಿದಾಗ, ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.

ಪ್ರಶ್ನೆ: ನೀವು rsyslog ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವೆ ವಿತರಣೆಯನ್ನು ಮಾಡುತ್ತೀರಿ. ಕಾಫ್ಕಾ ಏಕೆ ಅಲ್ಲ?

ಉತ್ತರಿಸಿ: ನಾವು ವಾಸ್ತವವಾಗಿ ಎರಡನ್ನೂ ಮಾಡುತ್ತೇವೆ. ಎರಡು ಕಾರಣಗಳಿಗಾಗಿ. ಚಾನಲ್ ಸಂಪೂರ್ಣವಾಗಿ ಸತ್ತಿದ್ದರೆ, ನಮ್ಮ ಎಲ್ಲಾ ಲಾಗ್‌ಗಳು, ಸಂಕುಚಿತ ರೂಪದಲ್ಲಿಯೂ ಸಹ ಅದರ ಮೂಲಕ ಕ್ರಾಲ್ ಆಗುವುದಿಲ್ಲ. ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಕಾಫ್ಕಾ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಲಾಗ್‌ಗಳು ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುವುದನ್ನು ನಾವು ಹೇಗೆ ತೊಡೆದುಹಾಕುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ನೇರವಾಗಿ ಕಾಫ್ಕಾವನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ. ನಾವು ಉತ್ತಮ ಚಾನಲ್ ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅದನ್ನು ಮುಕ್ತಗೊಳಿಸಲು ಬಯಸಿದರೆ, ನಾವು ಅವರ rsyslog ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಆದರೆ ವಾಸ್ತವವಾಗಿ, ನೀವು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಇದರಿಂದ ಅದು ಹೊಂದಿಕೆಯಾಗದದನ್ನು ಸ್ವತಃ ಬೀಳಿಸುತ್ತದೆ. ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ನೇರವಾಗಿ ಎಲ್ಲೋ rsyslog ವಿತರಣೆಯನ್ನು ಮತ್ತು ಕಾಫ್ಕಾವನ್ನು ಎಲ್ಲೋ ಬಳಸುತ್ತೇವೆ.

ಮೂಲ: www.habr.com