Apache2 thường xuyên bị lỗi khi sử dụng HestiaCP? Hướng dẫn giám sát và khắc phục sự cố tự động Monit (bao gồm cấu hình đầy đủ)

Thường xuyên gặp sự cố Apache2 bị treo hoặc Monit tự động khởi động lại không thành công trong môi trường HestiaCP ? Bài viết này cung cấp hướng dẫn thực tế để tránh những lỗi thường gặp khi giám sát Apache2 bằng Monit, phân tích sâu các vấn đề phổ biến như sai lệch đường dẫn PID và chặn quyền, đồng thời cung cấp các tệp cấu hình tự động hóa Monit cấp độ sản xuất. Nắm vững các kỹ thuật bảo trì máy chủ có tính khả dụng cao ngay bây giờ và đạt được khả năng tự động phục hồi cấp độ hai sau sự cố!

Những khó khăn tôi gặp phải khi sử dụng Monit để giám sát Apache2.

Thứ Sáu tuần trước, máy chủ đã gửi cho tôi một cảnh báo Monit vào giữa đêm.

Tôi liếc nhìn bảng điều khiển trong trạng thái mơ màng, và ở cột trạng thái apache2, có một dòng chữ Timeout màu đỏ.

Tôi đã suy nghĩ một chút. Tôi vừa mới cài đặt hệ thống giám sát Monit cho máy chủ trong ngày hôm nay, và tôi đã sao chép và dán cấu hình từ một hướng dẫn trực tuyến. Chắc sẽ không có vấn đề gì, phải không?

Sáng hôm sau, nó lại tự động tắt. Sau lần thứ ba, Monitor đơn giản là bỏ cuộc và màn hình hiển thị "Không được giám sát".

TÔI...

Tôi phải thừa nhận, lúc đầu tôi không coi trọng chuyện này. Giám sát Apache2 ư? Bạn có thể tìm thấy hàng tấn cấu hình mẫu trực tuyến, chỉ cần sao chép và dán. Nhưng quá trình dán đó thực sự khiến tôi phát điên.

Nguyên nhân gốc rễ của xung đột giữa kiến ​​trúc mặc định của HestiaCP và các cổng Monit.

Trước tiên, hãy để tôi cho bạn xem cấu hình đã gây ra cho tôi rất nhiều rắc rối, để bạn có thể so sánh xem nó có hoàn toàn giống với phiên bản mà bạn đã thấy hay không.

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

Nghe có vẻ ổn, phải không? Nó kiểm tra cổng 80, và nếu bị lỗi, nó sẽ khởi động lại. Nếu sau 5 lần khởi động lại mà vẫn bị lỗi, nó sẽ hết thời gian chờ.

Vấn đề là, Apache2 của bạn thậm chí không chạy trên cổng 80.

Đây là một điểm yếu của HestiaCP, và là nguyên nhân gốc rễ khiến nhiều người mắc phải. Kiến trúc mặc định của HestiaCP là một máy chủ proxy ngược gồm Nginx và Apache2, trong đó Nginx chiếm giữ các cổng 80 và 443 ở phía trước, và Apache2 chạy trên cổng cục bộ 8081 ở phía sau.

Nếu bạn yêu cầu Monit kiểm tra trạng thái hoạt động của Apache2 trên cổng 80, điều đó giống như việc bạn đến McDonald's để tìm KFC vậy. Máy chủ nhìn bạn với vẻ mặt ngơ ngác, và cả hai cùng nhìn chằm chằm vào nhau. Cuối cùng, Monit xác định rằng máy chủ của bạn đã ngừng hoạt động và bắt đầu khởi động lại một cách điên cuồng.

Sau khi khởi động lại, cổng vẫn là 8081. Monit sau đó thử dò tìm cổng 80, nhưng cũng thất bại, vì vậy nó lại khởi động lại. Chu kỳ này lặp đi lặp lại cho đến khi Monit quyết định rằng nó không thể sửa chữa được nữa và hết thời gian chờ.

Lần đầu tiên gặp phải vấn đề này, tôi thực sự rất ngạc nhiên. Chín trong mười hướng dẫn tôi tìm thấy trực tuyến đều sử dụng cổng 80. Nếu bạn làm theo chúng, vấn đề không phải ở bạn, mà là ở chính nguồn thông tin đó.

Tệp PID của Apache2 bị lỗi đã khiến Monit nhận diện nhầm tiến trình này là không tồn tại.

Sau khi thay đổi cổng từ 80 sang 8081, về mặt lý thuyết Monit sẽ có thể phát hiện ra nó, đúng không?

Tuy nhiên, trên thực tế, đôi khi nó vẫn báo lỗi "Quá trình thực thi thất bại ".

Sau một thời gian dài vật lộn, cuối cùng tôi cũng phát hiện ra nguyên nhân rất đơn giản: tệp PID đã bị hỏng.

Hãy nghĩ mà xem, Monit liên tục khởi động lại Apache2, mỗi lần đều buộc phải tắt và khởi động lại nó, lặp đi lặp lại nhiều lần. Trong quá trình này, tệp /var/run/apache2/apache2.pid có thể bị giảm xuống còn 0 byte.

Nói cách khác, tập tin vẫn còn đó, nhưng nó trống rỗng.

Khi Monit đọc tập tin này, nó không tìm thấy gì. Nó không nhận ra Apache2 của bạn, ngay cả khi Apache2 đang chạy hoàn hảo trong nền; Monit cho rằng tiến trình đó không tồn tại.

Khi nhìn thấy cảnh này, tôi đã chết lặng trong giây lát.

Đây là tình trạng bế tắc. Monit không phát hiện được phiên bản Apache 2, khởi động lại Apache2, làm hỏng tệp PID trong quá trình khởi động lại, thất bại trong lần phát hiện tiếp theo và lại khởi động lại. Chu kỳ này tiếp diễn cho đến khi hết thời gian chờ.

Các bước khắc phục sự cố và sửa chữa cho việc giám sát Apache2 trong môi trường HestiaCP

Thành thật mà nói, quy trình điều tra không phức tạp, nhưng bạn cần biết nên điều tra theo hướng nào.

Bước đầu tiên là xác định Apache2 đang lắng nghe trên cổng nào. Chỉ cần gõ một lệnh vào terminal.

netstat -tulpn | grep apache2

Ngoài ra, bạn cũng có thể sử dụng lệnh `ss`; hiệu quả tương tự.

ss -tulpn | grep apache2

Bạn sẽ thấy kết quả tương tự như thế này.

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

Đã xác nhận là 8081, chứ không phải 80. Đó chính là nguồn gốc của vấn đề.

Bước thứ hai là sửa chữa tệp PID bị hỏng. Việc này đơn giản hơn.

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

Đầu tiên, tạm dừng giám sát Monit để tránh nó can thiệp trong khi bạn đang khắc phục sự cố. Sau đó, khởi động lại Apache2 để cho phép nó ghi lại PID sạch. Cuối cùng, sử dụng lệnh `cat` để kiểm tra nội dung tệp; nó phải chứa một chuỗi số, chứ không phải một chuỗi rỗng.

Khi bước này hoàn tất, về cơ bản vấn đề đã được giải quyết.

Phân tích so sánh giữa cấu hình bảo vệ thích ứng truyền thống và cấu hình bảo vệ chủ động của Monit.

Các hướng dẫn trực tuyến về cấu hình Apache2 với Monit thường thuộc hai loại.

Một loại là "kiểu thích ứng truyền thống", sử dụng lệnh `service` để quản lý các dịch vụ và kiểm tra các cổng cục bộ mà không thêm quá nhiều hạn chế phức tạp. Cấu hình này có thể được sử dụng trên HestiaCP bằng cách chỉ cần thay đổi cổng, và nó tương đối ổn định.

Một cách tiếp cận khác là phương pháp "bảo vệ mạnh mẽ", sử dụng systemctl để quản lý các dịch vụ, thêm các hạn chế đối với tiến trình con và áp dụng logic phát hiện nghiêm ngặt hơn. Phương pháp này trông rất hiệu quả, nhưng lại có một lỗi nghiêm trọng: lệnh dừng được sử dụng là `killall -9`.

Lệnh `killall -9` nghĩa là gì? Nó có nghĩa là buộc phải tắt thiết bị bất kể nó đang làm gì. Thao tác cưỡng chế này dễ để lại các tệp PID bị hỏng, đó chính là vấn đề tôi vừa đề cập.

Theo kinh nghiệm cá nhân của tôi, việc giới hạn số lượng tiến trình con trong cấu hình tấn công mạnh mẽ thực sự hữu ích. Khi Apache2 bị quá tải bởi một cuộc tấn công CC, việc giới hạn số lượng tiến trình con có thể ngăn máy chủ hết bộ nhớ. Tuy nhiên, phương pháp `killall -9` thực sự không thể sử dụng được.

Cuối cùng, tôi đã thỏa hiệp và kết hợp những ưu điểm của cả hai cấu hình.

Cấu hình thực tiễn tốt nhất của HestiaCP Apache2 Monit

Hãy chỉnh sửa nội dung sau trong tệp /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

Tôi xin được giải thích ngắn gọn về logic đằng sau vài dòng cấu hình này.

Hãy ghi cổng 8081 sao cho khớp chính xác với kiến ​​trúc proxy ngược của HestiaCP; đừng ghi nhầm cổng 80 nữa.

Hãy sử dụng lệnh `systemctl stop` thay vì `killall -9` để dừng tệp PID, nhằm tránh làm hỏng tệp này.

Đã thêm giới hạn cho tiến trình con: nếu số lượng tiến trình con vượt quá 120, tiến trình sẽ khởi động lại sau hai chu kỳ liên tiếp để ngăn chặn các cuộc tấn công CC, nhưng mức độ can thiệp không quá mạnh.

Logic phát hiện lỗi đã được sửa đổi để sử dụng phương pháp "trong 2 chu kỳ", nghĩa là quá trình khởi động lại chỉ được kích hoạt sau hai lỗi liên tiếp, giúp giảm thiểu lỗi báo động sai. Cấu hình trước đây, khởi động lại chỉ sau một lần phát hiện, thực sự hơi quá nhạy.

Ngưỡng thời gian chờ cuối cùng được nới lỏng xuống còn 5 lần khởi động lại trong vòng 10 chu kỳ, vẫn đảm bảo khả năng chịu lỗi cần thiết.

HestiaCP Giám sát đơn vịTóm tắt khắc phục sự cố cấu hình và chia sẻ kinh nghiệm

Sau khi thực hiện các thay đổi cấu hình, tôi đã theo dõi apache2, và bảng điều khiển cuối cùng đã hiển thị chỉ báo "OK" màu xanh lá cây.

Tôi phải diễn tả cảm xúc của mình lúc đó như thế nào nhỉ? Cảm giác giống như mất hai ngày vật lộn với một lỗi phần mềm, cuối cùng phát hiện ra nguyên nhân chỉ là một dòng cấu hình sai. Vừa bực bội vừa buồn cười.

Monit tự nó đã là một công cụ tốt, và việc giám sát các tiến trình nền là điều mà mọi máy chủ nên làm. Nhưng vấn đề là nhiều hướng dẫn trực tuyến dựa trên giả định rằng "Apache2 chỉ sử dụng cổng 80", trong khi HestiaCP sử dụng proxy ngược, điều đó có nghĩa là giả định này không đúng.

Nếu bạn làm theo hướng dẫn, vấn đề không phải ở bạn; mà là hướng dẫn đó áp dụng cho trường hợp khác với trường hợp của bạn.

Vì vậy, nếu bạn cũng đang sử dụng HestiaCP và mày mò với Monit để giám sát Apache2, hãy nhớ hai điều: Thay đổi cổng thành 8081 và sử dụng lệnh `systemctl` để dừng nó, chứ không phải `killall -9`. Nếu bạn làm hai việc này, bạn sẽ tránh được mọi sự cố khác.

Vì bạn đã đọc đến đây, nếu thấy hữu ích, hãy nhấn thích và chia sẻ nhé. Nếu muốn nhận thông tin cập nhật sớm nhất, bạn cũng có thể theo dõi tôi!

Cảm ơn bạn đã đọc bài viết của tôi. Hẹn gặp lại lần sau.