HestiaCP ಯೊಂದಿಗೆ Apache2 ಪದೇ ಪದೇ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತಿದೆಯೇ? ಸ್ವಯಂಚಾಲಿತ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ದೋಷನಿವಾರಣೆ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ (ಸಂಪೂರ್ಣ ಸಂರಚನೆಯೊಂದಿಗೆ)

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

ಅಪಾಚೆ2 ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಮಾನಿಟ್ ಬಳಸುವಾಗ ನಾನು ಎದುರಿಸಿದ ಅಪಾಯಗಳು

ಕಳೆದ ಶುಕ್ರವಾರ, ಸರ್ವರ್ ನನಗೆ ಮಧ್ಯರಾತ್ರಿ ಮಾನಿಟ್ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡಿತು.

ನಾನು ದಿಗ್ಭ್ರಮೆಗೊಂಡು ಫಲಕದತ್ತ ಕಣ್ಣು ಹಾಯಿಸಿದೆ, ಮತ್ತು apache2 ಸ್ಥಿತಿ ಕಾಲಂನಲ್ಲಿ, ಕೆಂಪು ಬಣ್ಣದ ಟೈಮ್‌ಔಟ್ ಇತ್ತು.

ನಾನು ಅದರ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಯೋಚಿಸಿದೆ. ನಾನು ಹಗಲಿನಲ್ಲಿ ಸರ್ವರ್‌ಗೆ ಮಾನಿಟ್ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿದೆ, ಮತ್ತು ನಾನು ಆನ್‌ಲೈನ್ ಟ್ಯುಟೋರಿಯಲ್‌ನಿಂದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಕಲಿಸಿ ಅಂಟಿಸಿದೆ. ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿರಬಾರದು, ಸರಿ?

ಮರುದಿನ ಬೆಳಿಗ್ಗೆ, ಅದು ಮತ್ತೆ ಸಮಯ ಮೀರಿತು. ಮೂರನೇ ಬಾರಿಯ ನಂತರ, ಮಾನಿಟರ್ ಸುಮ್ಮನೆ ಕೈಬಿಟ್ಟಿತು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ "ಮಾನಿಟರ್ ಆಗಿಲ್ಲ" ಎಂದು ಪ್ರದರ್ಶಿಸಿತು.

ನಾನು...

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

ಹೆಸ್ಟಿಯಾಸಿಪಿಯ ಡೀಫಾಲ್ಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಮಾನಿಟ್ ಪೋರ್ಟ್‌ಗಳ ನಡುವಿನ ಸಂಘರ್ಷದ ಮೂಲ ಕಾರಣ

ನನಗೆ ತುಂಬಾ ತೊಂದರೆ ಉಂಟುಮಾಡಿದ ಸಂರಚನೆಯನ್ನು ಮೊದಲು ನಿಮಗೆ ತೋರಿಸುತ್ತೇನೆ, ಆಗ ಅದು ನೀವು ನೋಡಿದ ಆವೃತ್ತಿಯಂತೆಯೇ ಇದೆಯೇ ಎಂದು ನೀವು ನೋಡಬಹುದು.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

ಚೆನ್ನಾಗಿ ಕಾಣುತ್ತಿದೆ ಅಲ್ವಾ? ಅದು ಪೋರ್ಟ್ 80 ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಕ್ರ್ಯಾಶ್ ಆದಲ್ಲಿ, ಅದು ಮರುಪ್ರಾರಂಭಗೊಳ್ಳುತ್ತದೆ. 5 ಬಾರಿ ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರವೂ ಕ್ರ್ಯಾಶ್ ಆದಲ್ಲಿ, ಅದರ ಸಮಯ ಮುಗಿಯುತ್ತದೆ.

ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ನಿಮ್ಮ Apache2 ಪೋರ್ಟ್ 80 ರಲ್ಲಿಯೂ ಚಾಲನೆಯಲ್ಲಿಲ್ಲ.

ಇದು ಹೆಸ್ಟಿಯಾಸಿಪಿಯ ಒಂದು ಅಪಾಯ, ಮತ್ತು ಅನೇಕ ಜನರು ಇದರಲ್ಲಿ ಬೀಳಲು ಮೂಲ ಕಾರಣ. ಹೆಸ್ಟಿಯಾಸಿಪಿಯ ಡೀಫಾಲ್ಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ Nginx + Apache2 ನ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯಾಗಿದ್ದು, Nginx ಮುಂದೆ ಪೋರ್ಟ್‌ಗಳು 80 ಮತ್ತು 443 ಅನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿದೆ ಮತ್ತು Apache2 ಹಿಂಭಾಗದಲ್ಲಿ ಸ್ಥಳೀಯ ಪೋರ್ಟ್ 8081 ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ.

ನೀವು ಪೋರ್ಟ್ 80 ರಲ್ಲಿ ಅಪಾಚೆ2 ನ ಜೀವಂತಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಮಾನಿಟ್‌ಗೆ ಕೇಳಿದರೆ, ಅದು ಕೆಎಫ್‌ಸಿಯನ್ನು ಹುಡುಕಲು ಮೆಕ್‌ಡೊನಾಲ್ಡ್ಸ್‌ಗೆ ಹೋದಂತೆ. ಸರ್ವರ್ ನಿಮ್ಮನ್ನು ಖಾಲಿಯಾಗಿ ನೋಡುತ್ತದೆ, ಮತ್ತು ನೀವಿಬ್ಬರೂ ಒಬ್ಬರನ್ನೊಬ್ಬರು ದಿಟ್ಟಿಸಿ ನೋಡುತ್ತೀರಿ. ಕೊನೆಯಲ್ಲಿ, ನೀವು ಕೆಳಗೆ ಬಿದ್ದಿದ್ದೀರಿ ಎಂದು ಮಾನಿಟ್‌ಗೆ ಮನವರಿಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಉದ್ರಿಕ್ತವಾಗಿ ಮರುಪ್ರಾರಂಭಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ಪೋರ್ಟ್ ಇನ್ನೂ 8081 ಆಗಿದೆ. ನಂತರ ಮಾನಿಟ್ ಪೋರ್ಟ್ 80 ಅನ್ನು ತನಿಖೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಅದು ಸಹ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಮತ್ತೆ ಪುನರಾರಂಭಗೊಳ್ಳುತ್ತದೆ. ಮಾನಿಟ್ ಅದನ್ನು ದುರಸ್ತಿ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಿರ್ಧರಿಸುವವರೆಗೆ ಮತ್ತು ಸಮಯ ಮೀರುವವರೆಗೆ ಈ ಚಕ್ರವು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ.

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

ದೋಷಪೂರಿತ Apache2 PID ಫೈಲ್‌ನಿಂದಾಗಿ ಮಾನಿಟ್ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ ಎಂದು ತಪ್ಪಾಗಿ ಗುರುತಿಸಿತು.

ಪೋರ್ಟ್ ಅನ್ನು 80 ರಿಂದ 8081 ಗೆ ಬದಲಾಯಿಸಿದ ನಂತರ, ಮಾನಿಟ್ ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಸರಿಯೇ?

ಆದಾಗ್ಯೂ, ವಾಸ್ತವದಲ್ಲಿ, ಅದು ಇನ್ನೂ ಸಾಂದರ್ಭಿಕವಾಗಿ "ಕಾರ್ಯನಿರ್ವಹಣೆ ವಿಫಲವಾಗಿದೆ " ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.

ಬಹಳ ಹೊತ್ತು ಹೆಣಗಾಡಿದ ನಂತರ, ಕೊನೆಗೂ ಕಾರಣ ಸರಳವೆಂದು ನಾನು ಕಂಡುಕೊಂಡೆ: PID ಫೈಲ್ ದೋಷಪೂರಿತವಾಗಿದೆ.

ಯೋಚಿಸಿ ನೋಡಿ, ಮಾನಿಟ್ ಅಪಾಚೆ2 ಅನ್ನು ತೀವ್ರವಾಗಿ ಮರುಪ್ರಾರಂಭಿಸುತ್ತಿತ್ತು, ಪ್ರತಿ ಬಾರಿಯೂ ಬಲವಂತವಾಗಿ ಅದನ್ನು ಕೊಂದು ಮರುಪ್ರಾರಂಭಿಸುತ್ತಿತ್ತು, ಹಲವಾರು ಬಾರಿ ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಹೋಗುತ್ತಿತ್ತು. ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, /var/run/apache2/apache2.pid ಫೈಲ್ 0 ಬೈಟ್‌ಗಳಾಗಬಹುದು.

ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಫೈಲ್ ಇನ್ನೂ ಇದೆ, ಆದರೆ ಅದು ಖಾಲಿಯಾಗಿದೆ.

ಮಾನಿಟ್ ಈ ಫೈಲ್ ಅನ್ನು ಓದಿದಾಗ, ಅದು ಏನನ್ನೂ ಕಾಣುವುದಿಲ್ಲ. ನಿಮ್ಮ ಅಪಾಚೆ2 ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ ಸಹ, ಅದು ನಿಮ್ಮ ಅಪಾಚೆ2 ಅನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ; ಈ ಪ್ರಕ್ರಿಯೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಮಾನಿಟ್ ಭಾವಿಸುವುದಿಲ್ಲ.

ಇದನ್ನು ನೋಡಿದಾಗ, ನಾನು ಒಂದು ಕ್ಷಣ ಮೂಕನಾದೆ.

ಇದು ಒಂದು ಡೆಡ್‌ಲಾಕ್ ಆಗಿದೆ. ಮಾನಿಟ್ ಅಪಾಚೆ 2 ನಿದರ್ಶನವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ, ಅಪಾಚೆ 2 ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮರುಪ್ರಾರಂಭಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ PID ಫೈಲ್ ಅನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸುತ್ತದೆ, ಮುಂದಿನ ಪತ್ತೆ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಮತ್ತೆ ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಸಮಯ ಮೀರುವವರೆಗೆ ಈ ಚಕ್ರವು ಮುಂದುವರಿಯುತ್ತದೆ.

ಹೆಸ್ಟಿಯಾಸಿಪಿ ಪರಿಸರದಲ್ಲಿ ಅಪಾಚೆ2 ಮಾನಿಟರಿಂಗ್‌ಗಾಗಿ ದೋಷನಿವಾರಣೆ ಮತ್ತು ದುರಸ್ತಿ ಹಂತಗಳು

ನಿಜ ಹೇಳಬೇಕೆಂದರೆ, ತನಿಖಾ ಪ್ರಕ್ರಿಯೆಯು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ, ಆದರೆ ಯಾವ ದಿಕ್ಕಿನಲ್ಲಿ ತನಿಖೆ ನಡೆಸಬೇಕೆಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು.

ಮೊದಲ ಹಂತವೆಂದರೆ ನಿಮ್ಮ Apache2 ಯಾವ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಕೇಳುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು. ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಆಜ್ಞೆಯನ್ನು ಟೈಪ್ ಮಾಡಿ.

netstat -tulpn | grep apache2

ಪರ್ಯಾಯವಾಗಿ, ನೀವು `ss` ಆಜ್ಞೆಯನ್ನು ಬಳಸಬಹುದು; ಪರಿಣಾಮವು ಒಂದೇ ಆಗಿರುತ್ತದೆ.

ss -tulpn | grep apache2

ನೀವು ಇದೇ ರೀತಿಯ ಔಟ್ಪುಟ್ ಅನ್ನು ನೋಡುತ್ತೀರಿ.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

ಅದು 80 ಅಲ್ಲ, 8081 ಎಂದು ದೃಢಪಟ್ಟಿದೆ. ಅದು ಸಮಸ್ಯೆಯ ಮೂಲ.

ಎರಡನೇ ಹಂತವೆಂದರೆ ದೋಷಪೂರಿತ PID ಫೈಲ್ ಅನ್ನು ದುರಸ್ತಿ ಮಾಡುವುದು. ಇದು ಸರಳವಾಗಿದೆ.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

ಮೊದಲು, ನೀವು ಕೆಲಸಗಳನ್ನು ಸರಿಪಡಿಸುವಾಗ ಮಾನಿಟ್ ಮಾನಿಟರಿಂಗ್ ಮಧ್ಯಪ್ರವೇಶಿಸದಂತೆ ತಡೆಯಲು ಅದನ್ನು ವಿರಾಮಗೊಳಿಸಿ. ನಂತರ, ಅಪಾಚೆ 2 ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಅದು ಕ್ಲೀನ್ ಪಿಐಡಿಯನ್ನು ಪುನಃ ಬರೆಯಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ಫೈಲ್ ವಿಷಯವನ್ನು ಪರಿಶೀಲಿಸಲು `ಕ್ಯಾಟ್` ಅನ್ನು ಬಳಸಿ; ಅದು ಖಾಲಿ ಸ್ಟ್ರಿಂಗ್ ಅಲ್ಲ, ಸಂಖ್ಯೆಗಳ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು.

ಈ ಹಂತ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಸಮಸ್ಯೆ ಮೂಲತಃ ಪರಿಹಾರವಾಗುತ್ತದೆ.

ಮಾನಿಟ್ ಸಾಂಪ್ರದಾಯಿಕ ಅಡಾಪ್ಟಿವ್ ಮತ್ತು ಆಕ್ರಮಣಕಾರಿ ರಕ್ಷಣಾತ್ಮಕ ಸಂರಚನೆಗಳ ತುಲನಾತ್ಮಕ ವಿಶ್ಲೇಷಣೆ

ಮಾನಿಟ್‌ನೊಂದಿಗೆ ಅಪಾಚೆ2 ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಆನ್‌ಲೈನ್ ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ವರ್ಗಗಳಾಗಿ ಬರುತ್ತವೆ.

ಒಂದು ವಿಧವೆಂದರೆ "ಸಾಂಪ್ರದಾಯಿಕ ಅಳವಡಿಕೆ ಪ್ರಕಾರ", ಇದು ಸೇವೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ನಿರ್ಬಂಧಗಳನ್ನು ಸೇರಿಸದೆ ಸ್ಥಳೀಯ ಪೋರ್ಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಲು `service` ಆಜ್ಞೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಈ ಸಂರಚನೆಯನ್ನು HestiaCP ನಲ್ಲಿ ಪೋರ್ಟ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ಬಳಸಬಹುದು ಮತ್ತು ಇದು ತುಲನಾತ್ಮಕವಾಗಿ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.

ಮತ್ತೊಂದು ವಿಧಾನವೆಂದರೆ "ಆಕ್ರಮಣಕಾರಿ ರಕ್ಷಣೆ" ವಿಧಾನ, ಇದು ಸೇವೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು systemctl ಅನ್ನು ಬಳಸುತ್ತದೆ, ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆ ನಿರ್ಬಂಧಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಕಠಿಣ ಪತ್ತೆ ತರ್ಕವನ್ನು ಬಳಸುತ್ತದೆ. ಇದು ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಇದು ಮಾರಕ ದೋಷವನ್ನು ಹೊಂದಿದೆ: ಬಳಸಲಾದ ಸ್ಟಾಪ್ ಆಜ್ಞೆಯು `killall -9` ಆಗಿದೆ.

`killall -9` ಎಂದರೆ ಏನು? ಸಾಧನವು ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ಬಲವಂತವಾಗಿ ಅದನ್ನು ಕೊಲ್ಲುವುದು ಎಂದರ್ಥ. ಈ ಕ್ರೂರ ಕಾರ್ಯಾಚರಣೆಯು ಭ್ರಷ್ಟ PID ಫೈಲ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ಬಿಟ್ಟು ಹೋಗಬಹುದು, ಅದು ನಾನು ಈಗ ಉಲ್ಲೇಖಿಸಿದ ಸಮಸ್ಯೆಯಾಗಿದೆ.

ಆಕ್ರಮಣಕಾರಿ ಸಂರಚನೆಯಲ್ಲಿ ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ನಿಜಕ್ಕೂ ಉಪಯುಕ್ತ ಎಂಬುದು ನನ್ನ ವೈಯಕ್ತಿಕ ಅನುಭವ. ನಿಮ್ಮ Apache2 CC ದಾಳಿಯಿಂದ ತುಂಬಿಹೋದಾಗ, ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದರಿಂದ ಸರ್ವರ್ ಮೆಮೊರಿ ಖಾಲಿಯಾಗುವುದನ್ನು ತಡೆಯಬಹುದು. ಆದಾಗ್ಯೂ, `killall -9` ವಿಧಾನವು ನಿಜವಾಗಿಯೂ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ.

ಹಾಗಾಗಿ ಕೊನೆಯಲ್ಲಿ ನಾನು ರಾಜಿ ಮಾಡಿಕೊಂಡು ಎರಡೂ ಸಂರಚನೆಗಳ ಅನುಕೂಲಗಳನ್ನು ಸಂಯೋಜಿಸಿದೆ.

ಹೆಸ್ಟಿಯಾಸಿಪಿ ಅಪಾಚೆ2 ಮಾನಿಟ್ ಬೆಸ್ಟ್ ಪ್ರಾಕ್ಟೀಸ್ ಕಾನ್ಫಿಗರೇಶನ್

/etc/monit/conf.d/apache2 ಫೈಲ್ ಅನ್ನು ಈ ಕೆಳಗಿನ ವಿಷಯದೊಂದಿಗೆ ಮಾರ್ಪಡಿಸಿ.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

ಈ ಕೆಲವು ಸಾಲುಗಳ ಸಂರಚನೆಯ ಹಿಂದಿನ ತರ್ಕವನ್ನು ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ.

ಹೆಸ್ಟಿಯಾಸಿಪಿಯ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ನಿಖರವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವಂತೆ ಪೋರ್ಟ್ 8081 ಅನ್ನು ಬರೆಯಿರಿ; ಮೂರ್ಖತನದಿಂದ ಪೋರ್ಟ್ 80 ಅನ್ನು ಬರೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ.

PID ಫೈಲ್ ಅನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸದಂತೆ ಅದನ್ನು ನಿಲ್ಲಿಸಲು `killall -9` ಬದಲಿಗೆ `systemctl stop` ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ.

ಮಕ್ಕಳ ಪ್ರಕ್ರಿಯೆಯ ಮಿತಿಯನ್ನು ಸೇರಿಸಲಾಗಿದೆ: ಮಕ್ಕಳ ಸಂಖ್ಯೆ 120 ಮೀರಿದರೆ, CC ದಾಳಿಗಳನ್ನು ತಡೆಗಟ್ಟಲು ಎರಡು ಸತತ ಚಕ್ರಗಳ ನಂತರ ಪ್ರಕ್ರಿಯೆಯು ಪುನರಾರಂಭಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಇದು ತುಂಬಾ ಆಕ್ರಮಣಕಾರಿಯಲ್ಲ.

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

ಅಂತಿಮ ಸಮಯ ಮೀರುವ ಮಿತಿಯನ್ನು 10 ಚಕ್ರಗಳ ಒಳಗೆ 5 ಪುನರಾರಂಭಗಳಿಗೆ ಸಡಿಲಗೊಳಿಸಲಾಗುತ್ತದೆ, ಇದು ಸಾಕಷ್ಟು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ನೀಡುತ್ತದೆ.

ಹೆಸ್ಟಿಯಾಸಿಪಿ ಮಾನಿಟ್ ಮಾನಿಟರಿಂಗ್ಕಾನ್ಫಿಗರೇಶನ್ ದೋಷನಿವಾರಣೆ ಸಾರಾಂಶ ಮತ್ತು ಅನುಭವ ಹಂಚಿಕೆ

ಸಂರಚನಾ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದ ನಂತರ, ನಾನು apache2 ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದೆ, ಮತ್ತು ಫಲಕವು ಅಂತಿಮವಾಗಿ ಹಸಿರು "ಸರಿ" ಸೂಚಕವನ್ನು ತೋರಿಸಿದೆ.

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

ಮಾನಿಟ್ ಸ್ವತಃ ಒಳ್ಳೆಯದು, ಮತ್ತು ಡೀಮನ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಪ್ರತಿ ಸರ್ವರ್ ಮಾಡಬೇಕಾದ ಕೆಲಸ. ಆದರೆ ಸಮಸ್ಯೆಯೆಂದರೆ ಅನೇಕ ಆನ್‌ಲೈನ್ ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು "ಅಪಾಚೆ 2 ಪ್ರತ್ಯೇಕವಾಗಿ ಪೋರ್ಟ್ 80 ಅನ್ನು ಬಳಸುತ್ತದೆ" ಎಂಬ ಊಹೆಯನ್ನು ಆಧರಿಸಿವೆ, ಆದರೆ ಹೆಸ್ಟಿಯಾಸಿಪಿ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುತ್ತದೆ, ಅಂದರೆ ಈ ಊಹೆ ನಿಜವಾಗುವುದಿಲ್ಲ.

ನೀವು ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿದರೆ, ಸಮಸ್ಯೆ ನಿಮ್ಮದಲ್ಲ; ಟ್ಯುಟೋರಿಯಲ್ ನಿಮ್ಮದಕ್ಕಿಂತ ಭಿನ್ನವಾದ ಸನ್ನಿವೇಶಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತದೆ.

ಹಾಗಾಗಿ ನೀವು HestiaCP ಬಳಸುತ್ತಿದ್ದರೆ ಮತ್ತು Apache2 ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು Monit ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಎರಡು ವಿಷಯಗಳನ್ನು ನೆನಪಿಡಿ: ಪೋರ್ಟ್ ಅನ್ನು 8081 ಗೆ ಬದಲಾಯಿಸಿ, ಮತ್ತು ಅದನ್ನು ನಿಲ್ಲಿಸಲು `killall -9` ಅಲ್ಲ, `systemctl` ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ. ನೀವು ಈ ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡಿದರೆ, ನೀವು ಯಾವುದೇ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ನೀವು ಇಲ್ಲಿಯವರೆಗೆ ಓದಿರುವುದರಿಂದ, ಇದು ನಿಮಗೆ ಉಪಯುಕ್ತವೆನಿಸಿದರೆ, ದಯವಿಟ್ಟು ಲೈಕ್ ಮಾಡಿ ಮತ್ತು ಹಂಚಿಕೊಳ್ಳಿ. ನೀವು ಮೊದಲು ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸಿದರೆ, ನೀವು ನನ್ನನ್ನು ಸಹ ಅನುಸರಿಸಬಹುದು!

ನನ್ನ ಲೇಖನ ಓದಿದ್ದಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ಮುಂದಿನ ಬಾರಿ ಭೇಟಿಯಾಗೋಣ.