27 Feb 2011

Sự cần thiết của một hệ thống cảnh báo

Trước giờ mình luôn nghĩ hệ thống Monitoring (default + bản thân tự customize) đã đủ đáp ứng được nhu cầu:
-Phát hiện ra sự cố
-Cảnh báo kịp thời
-Có khả năng phục hồi hệ thống một cách nhanh nhất

Nhưng mình phát hiện ý nghĩ đó là sai khi tiếp cận với hệ thống cảnh báo của những người làm chuyên nghiệp (dù chỉ tiếp cận qua những gì họ giới thiệu) và sự cố network vừa qua tại công ty mà mình đang làm việc.
Sự cố network xảy ra làm ngưng trệ hầu như tất cả các sản phẩm đang hoạt động. Không biết bạn có cảm giác thế nào khi hệ thống cảnh báo tất cả server (hàng trăm) đều trong trạng thái “DOWN”, mình thì gần như buông tay.
Thứ nhất tuy hệ thống network không thuộc phạm vi quản lí của team mình, nhưng hệ thống monitor phải detect được sự cố network đó ngay khi nó vừa xảy ra, nhưng đã không làm được việc.
Thứ 2, khi sự cố network được giải quyết, dù mạng đã thông nhưng service vẫn gặp sự cố dù hệ thống cảnh báo cho biết tình trạng tất cả service đều bình thường.

 
Vấn đề thứ 2 là điểm rất đáng quan tâm. Hầu hết các hệ thống cảnh báo và mind-set của người thiết lập hệ thống cảnh báo đều cho rằng hệ thống gặp vấn đề khi bản thân dịch vụ (nằm trên hệ thống đó) gặp vấn đề. Nhưng trong một hệ thống lớn, mà hầu như tất cả các dịch vụ cần kết nối với nhau thì chỉ kiểm tra đơn giản như vậy không hiệu quả. Điểm cốt lõi là làm sao ta có thể biết được dịch vụ A kết nối với dịch vụ B không thành công, trong một khoảng thời gian nào đó thì đưa ra cảnh báo dù services hay processes đang trong tình trạng bình thường, lắng nghe chờ kết nối.
Các công cụ cảnh báo cũng phát triển một tính năng là phát hiện open port, một tính năng khác là giả lập client kết nối và thu thập kết quả nhận được. Thường gặp nhất là các tool kiểm tra database server. Hệ thống cảnh báo gởi tới db server một câu query giá trị nào đó, tính xem khoảng thời gian nhận được trả lời, kiểm tra response có bình thường hay không...nếu không, đưa ra cảnh báo.
Nhưng khi các application phát triển + số servers cần được monitor tăng cao, người ta thường dùng agent. Ưu điểm của agent là triển khai nhanh, kiểm tra nhanh ...và chỉ có thế thôi. Agent làm việc trên chính local server và nghiễm nhiên những câu truy vấn (như mysql chẳng hạn) thường cho ra kết quả tốt mặc dù server liên quan không kết nối được. Do đó, nếu chỉ phụ thuộc hoàn toàn vào agent là một sai lầm lớn mà cho đến khi sự cố thật sự xảy ra, mình mới biết được.

Hãy nghĩ xem một hệ thống cảnh báo có thể làm được những việc: biết được server đang chạy dịch vụ gì, với những processes nào, số lượng processes là bao nhiêu trong trạng thái bình thường và phát hiện được việc tăng hay giảm số processes trong tình trạng bất thường, lắng nghe trên port nào, với protocol gì, tình trạng kết nối với server bên ngoài ra sao (trong trường hợp có kết nối), với vai trò nào (server hay client), có khả năng cảnh báo nhanh và restart services khi cần thiết, tự động báo kết quả phục hồi, đưa ra error_log (nếu có). Và tất nhiên, phải cho ta biết được tổng quan hệ thống trong tình trạng hiện tại ra sao, nhờ vào các công cụ thống kê có sẵn, hoặc cacti hay tương tự...và tất nhiên phải làm việc một cách trơn tru sẽ tuyệt vời đến mức nào.

Phát triển một hệ thống như vậy không phải dễ, cho dù ta luôn nghĩ nó phải làm được như thế. Có những hệ thống cảnh báo, mà cho dù khi service gặp sự cố, mình không thể phát hiện ra sự cố là gì mặc dù nhận được cảnh báo, ích lợi mang lại của công cụ này không cao ngoài việc notify cho người quản trị biết mà kiểm tra.

Thử đưa ra một ví dụ về cách monitor thông thường, trước kia mình hay sử dụng Monit. Monit cung cấp khả năng monitor các dịch vụ thông dụng, ví dụ như Apache HTTP, nginx, Mysql... Khi thiết lập để Monit kiểm tra, mình sẽ làm các bước:
- chỉ định monit monitor process httpd
- kiểm tra xem process này còn tồn tại trên hệ thống hay không?
- Nếu process không tồn tại, quay lại bước 2.
- Cứ thế nếu vượt quá n lần, monit restart httpd theo command định trước.


Việc này đơn giản tới mức, bạn có thể viết script kiểm tra trong vòng...1 phút và dùng cron job để chạy. Nhưng nếu kiểm tra kĩ lại, rõ ràng các bước trên là sai. So sánh:
- Xác định server đang chạy Apache httpd. (1)
- Xác định command start dịch vụ này là gì.(2)
- Số lượng process vượt ngưỡng: trên/ dưới.(3)
- Tự động request đến localhost port 80 để xem tình trạng phục vụ thế nào, thời gian
response bao lâu, status code trả về là gì? (4)
- Dùng monitoring server send request đến server cần kiểm tra lặp lại bước 4. (5).
- Kiểm tra xem process này còn tồn tại trên hệ thống hay không? (6)
- Nếu 1 trong các bước 3, 4, 5, 6 đều vượt quá giới hạn cảnh báo trong n lần, thực hiện bước 7, send alert, sau x phút restart dịch vụ. (7)

Đó mới là điều mà hệ thống cảnh báo nên làm.
Và rõ ràng, không có application nào mặc định có thể làm được việc này, người thiết lập cần phải đưa ra phương pháp riêng của mình, sau đó mới tích hợp vào công cụ cảnh báo.

Cái mình muốn nói đến là, khi một hệ thống đã phát triển to lớn đến mức nào đó, thì các công cụ cũng như quan niệm quản trị cũ cũng cần phải được phát triển để bắt kịp hệ thống hiện tại. Những gì không dùng được, không có tác dụng hoặc tác dụng kém thì nên bỏ đi và tìm một giải pháp khác. Điểm mấu chốt trong việc quản trị hệ thống là con người, nếu không đủ nhân lực để thực hiện việc kiểm tra 24/7 thì nên tự phát triển công cụ cảnh báo tốt nhất, chặt chẽ nhất một cách có thể, hoặc thuê một dịch vụ nào đó đảm bảo được yêu cầu trên.

Bản thân mình nhận thấy, hệ thống cảnh báo của hầu hết các công ty ở VN hiện nay đã lỗi thời, nếu không nhờ vào một đội ngũ nào đó kiểm tra (bằng mắt) thì khả năng phát hiện sự cố ngay khi xảy ra là rất hiếm hoi. Chưa nói đến việc phục hồi sự cố sau khi nó xảy ra, vì không có một hệ thống cảnh báo + phục hồi đúng chuẩn của nó.


3 comments:

anhhk said...

god bless us, https://github.com/pjhyett/god

hungnv said...

tổng quan có vẻ hay, ngoại trừ được viết bằng ruby. em có một công thức (em cho là khá hay), bữa nào nói cho nghe, ha ha

Nhan said...

Tuyệt quá anh ơi :)

Disqus