VPN ಸರ್ವರ್‌ನ ಡಿಸ್ಕ್ ಬೆಳವಣಿಗೆ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಮಿತಿಗೊಳಿಸುವುದು

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

ಬೆಳೆದ ಸಂಗ್ರಹ ಮತ್ತು ಅದು ಬೆಳೆದ ದರವನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ

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

df -h /var
df -i /var

ನಂತರ ಬೆಳವಣಿಗೆಯನ್ನು ಮಾಲೀಕರಿಗೆ ಆರೋಪಿಸಿ. journal‌ನ ಸ್ವಂತ ಬಳಕೆಯ ಅಂಕಿ journal ಅನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದು ತನ್ನ ಸಂರಚನಾ ಫೈಲ್‌ನ ಪಥಕ್ಕೆ ಬರೆಯುವ ಡೀಮನ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ.

journalctl --disk-usage

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

ತೆರೆದ ಫೈಲ್‌ಗೆ ರೊಟೇಶನ್ ಏನು ಮಾಡುತ್ತದೆ

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

lsof +L1 | head

ನೀತಿ ಫೈಲ್ ಅನ್ನು ಬರೆಯುವ ಘಟಕಕ್ಕೆ ಸೇರಿದ್ದು. journal ತನ್ನ ಸಂಗ್ರಹಣಾ ಮಿತಿಗಳನ್ನು ತನ್ನ ಸಂರಚನಾ ಫೈಲ್‌ನಿಂದ ಜಾರಿಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಫೈಲ್ ಆಧಾರಿತ ಸೇವೆ ಸಾಮಾನ್ಯವಾಗಿ logrotate ಅನ್ನು ಅವಲಂಬಿಸುತ್ತದೆ: ರಚನೆ ನಿಯಮ ಮತ್ತು ಮರುತೆರೆಯುವ ಸಂಕೇತದೊಂದಿಗೆ, ಅಥವಾ ಬರಹಗಾರ ಮತ್ತೆ ತೆರೆಯಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಸ್ಥಳದಲ್ಲೇ ಕತ್ತರಿಸುವ ವಿಧಾನದೊಂದಿಗೆ. ಮೊದಲು ಏನನ್ನೂ ಬದಲಿಸದೆ ನಿರ್ಧಾರವನ್ನು ದೃಢೀಕರಿಸಿ:

logrotate -d /etc/logrotate.conf

ಮಿತಿ ಎಲ್ಲಿರಬೇಕು ಮತ್ತು ಎಷ್ಟು ದೊಡ್ಡದಾಗಿರಬೇಕು

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

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

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

ಮರುಪ್ರಾರಂಭದ ನಂತರ ಮಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಮುಂದಿನ ರೀಬೂಟ್‌ವರೆಗೆ ಇರುವ ಧಾರಣಾ ಬದಲಾವಣೆ ಬದಲಾವಣೆ ಅಲ್ಲ. ಬರಹಗಾರನನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ, ಹೊಸ ಮಿತಿ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ನಂತರವೂ ರೊಟೇಶನ್ ಚಲಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. journal‌ಗೆ, ಒಂದು ಮರುಪ್ರಾರಂಭ ಮತ್ತು ಒಂದು ಬಳಕೆಯ ಓದಿಕೆ ಎರಡೂ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ:

systemctl restart systemd-journald
journalctl --disk-usage

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

ಮುಂದಿನ ಓದಿಕೆಯನ್ನು ಇದರೊಂದಿಗೆ ಹೋಲಿಸಿ

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

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

ಏನನ್ನು, ಎಲ್ಲಿ, ಎಷ್ಟು ಕಾಲ ಇಡಲಾಗುತ್ತದೆ ಮತ್ತು ಯಾರು ಅದನ್ನು ತೆಗೆಯುತ್ತಾರೆ ಎಂದು ಬರೆಯಿರಿ. ಆ ವಾಕ್ಯವೇ ಫಲಿತಾಂಶ, ಮತ್ತು ಇದು ಮುಂದಿನ ಮರುಪ್ರಾರಂಭದವರೆಗೂ ಉಳಿಯುವ ಈ ಕೆಲಸದ ಏಕೈಕ ಭಾಗ.