Hi ae, Trải qua một loạt blog đau đầu vl toàn những thứ ở đẩu ở đâu ý. Buổi nay sẽ chỉ là vài chia sẻ nhỏ tí về việc monitor web - service (dịch vụ web) cái mà dù ở đâu và làm chi (làm sys hay devops) kiểu gì cũng có ngày ae cũng va phải. Có thể nhiều cái chắc ae đã biết rồi nhưng không sao tôi nguyện làm thư ký cho ae tổng hợp lại cho hệ thống vậy. Hy vọng có gì đó hay ho giúp ích cho các ae mới vào nghề và cả những ae lâu năm cần thư ký :d. Okey.

Intro Monitor

Monitor sử dụng check TCP port?

Cách làm này cứ nghĩ là ngây ngô và đơn giản nhưng tính ra cũng khá hiệu quả. Với thời gian check đủ nhỏ (tôi dùng là 10s) dễ dàng phát hiện ra hiện tượng chập chờn của dịch vụ. Lỗi thường gặp vd như web service keep connection quá lâu (do sysadmin không tunning timeout) làm web server đạt ngưỡng connection dẫn tới reject các client tiếp theo :)

Monitor sử dụng check http service?

HTTP Monitor

Cách làm này là liên tục request tới web service có thể truyền hoặc không truyền đối số để kiểm tra mã trả về có là 200 không hoặc giá trị trả về có đúng đắn về mặt logic xử lý tương ứng với giá trị truyền vào hay không. Từ đó đánh giá web service sống hay chết. Đây là cách làm đơn giản và hiệu quả vừa giúp kiểm tra kết nối vừa giúp kiểm tra tính đúng đắn trong luồng hoạt động logic của web service. Hầu hết các tool monitor đều hỗ trợ full tính năng này.

Còn cách nào được nữa?

else Monitor

Một T/H đặc biệt xảy ra, tool của bạn check TCP port vẫn ngon lành, check HTTP service vẫn ngon lành. Nhưng phía cskh phản hồi rằng một số người dùng kêu không thể truy cập sử dụng được dịch vụ, khi họ vào xài dịch vụ thì web lại bị 5XX. Sếp giao cho bạn tìm nguyên nhân thật nhanh vì nếu còn tiếp diễn hiện tượng như vậy trải nghiệm khách hàng xuống dốc, khách hàng sẽ bực bội và bỏ đi. Thật khó hiểu, tôi phải làm ntn bây giờ?

OK, Việc cần bây giờ không phải là monitor một hoặc 1 số case nhất định như 2 t/h trên mà cần phải monitor toàn bộ các request tới web server của mình. Tôi nghĩ đây là lúc bạn cần có 1 hệ thống logging tập trung để log lại toàn bộ request khách hàng gửi tới service của mình.

Như điều hiển nhiên thành phần hệ thống logging tập trung gồm : Hệ thống Logging server tập trung và Client lấy log gửi về hệ thống tập trung. Opensource có bộ ELK làm hệ thống logging server tập trung khá tốt dựng chưa tới 15p. (Ae có thể tham khảo blog của anh cùng cty tôi Dựng ELK trong 15p). Client lấy log sẽ được cài trên web server đẩy log access, error và các loại log khác về log tập trung. Client cũng có nhiều loại dùng filebeat hoặc syslog/rsyslog/syslog-ng - tất cả đều miễn phí. Sau khi log được đẩy về viết các bộ parser để tách riêng các trường ra. Ở đây tôi chỉ nêu đại ý, ae search gg chi tiết nha. Nói chung guide rất nhiều nên làm cái này cũng rất nhanh, chắc khoảng buổi sáng là xong toàn bộ.

Sau khi có hệ thống logging tập trung thì quá dễ để mining log rùi. Giờ tôi ưu tiên lọc và tìm nguyên nhân và xử triệt để các request có mã trả về theo thứ tự 5XX (die backend Service) -> 4XX (Get lộn) -> 3XX (Perhap loop). Vì chắc chắn 90% T/H cskh phản ánh sẽ nằm trong group này rùi :). Xử lý ntn thì nhìn request và hỏi dev là biết thôi chứ còn ls :)

Cuối cùng là tìm xử triệt để các slow request với time response quá lớn trong access log (dĩ nhiên lọc và sắp xếp dựa vào hệ thống logging). Đây là các request tiềm ẩn khả năng gây lỗi 504 :) gateway timeout hoặc làm người dùng “Uống hết mịa cốc cafe app/web mới load xong”. Để xử các loại này cần có sự phối hợp với dev tìm nguyên nhân. Thông thường có 1 cơ chế gọi là profiling trong lập trình để debug xác định điểm nghẽn/dắt dựa trên loging execute time (có thể cần sửa code). Ae mà thích mày mò cũng có thể blackbox làm việc không cần dev này nhưng khá khó và mất t/g nên tốt nhất nhờ dev họ sửa cho nhanh, tg để làm cái khác hay ho hơn.

Tôi nghĩ tới đây đã xử được kha khá vấn đề rồi.

Phương án dài hơi hơn :)

Tôi đề xuất phương án cải tổ thật nhanh (very fast) lại mô hình dịch vụ như sau:

Model

(Nếu bạn đã chạy theo mô hình này rồi thì không cần làm nữa)

Loadblancer có nhiều sản phẩm opensource rất tốt. Hai ứng cử viên sáng giá là Nginx và Haproxy (Free). Ở đây khuyến cáo xài layer 7 dể phục vụ login và tracking request. Với mỗi sản phẩm này đều có tính năng count số http request group theo từng mã trả về. Có thông số này sẽ không khó khăn để ta xác định số lượng/tỉ lệ mỗi loại mã trả về của web serivice trong một khoảng thời gian nhất định. Với tôi, tôi hay đẩy các thông số này về mấy tool monitor để lưu trữ, tính toán (hầu hết các tool monitor đều hỗ trợ tính năng này. Tôi thì tôi dùng Tick - Grafana, bạn thích cũng thử xài coi). Như vậy hàng ngày tôi chỉ cần vào đây ngó qua qua là biết tổng quan web service của tôi hoạt động ntn rồi (bao nhiêu 200, bn 404, bn 500, …). Bạn thích cũng có thể set khi có số lượng tỉ lệ request != 2XX quá lớn thì alert qua email/sms/telegram nếu muốn :) thế là khỏi lo bị thông mà không biết.

OK nhưng dù ntn cũng đừng quên xây dựng cho mình một hệ thống log tập trung thật tốt và đẩy toàn bộ log của loadblancer, web server, os, db, … về vì bạn có thể cần dùng tới bất cứ khi nào.

Hey, bài viết tưởng ngắn mà cũng dài và mất t/g ra phết. Mấy cái này thật ra định viết lâu rồi :). Ờ thỉnh thoảng có nhiều cái muốn làm mà chả sx được mà làm.

Ok, hy vọng vẫn giữ được nhịp điệu viết đều đều vì đôi khi viết ra cũng hay ho lắm chứ :)

Note: Ae tham khảo hệ thống monitor của wikipedia để mở rộng tầm mắt nha Wikipedia Web service monitoring

Hong

Nửa đêm hàng xóm mới nấu cái gì thơm thế