Edumall Monitoring Stack Part 1 — Check_MK

Lê Cao Hoàng
Edumall Engineering
6 min readNov 11, 2019

#line_sys-devops

Đối với các hệ thống lớn, việc theo dõi và cảnh báo hệ thống/ứng dụng trở nên cấp thiết do cần truy vết lại thông tin khi xảy ra sự cố. Quá trình này sẽ tách ra làm 2 nhánh:

  • Monitoring chủ động (Proactive monitoring)
  • Monitoring bị động (Passive Monitoring)

Edumall hiện tại xây dựng hệ thống theo dõi và cảnh báo hệ thống/ứng dụng theo cả 2 nhánh trên. Monitoring stack của Edumall bao gồm:

  • Check_MK
  • AWS CloudWatch +AWS SNS
  • Grafana
  • Graylog + ElasticSearch
  • Slack, Mattermost and Telegram
  • Sentry

Trong phần mở đầu, chúng ta sẽ tìm hiểu về hệ thống theo dõi và cảnh báo hệ thống với Check_MK.

1. Khái quát về Check_MK

Check_MK được phát triển từ năm 2008 như là một plugin của OMD-Nagios Core.

OMD — Open Monitoring Distribution là một project được phát triển từ năm 2010 bới Mathias Kettner. OMD sử dụng nhân là Nagios Core, kết hợp với các phần mềm mã nguồn mở khác để đóng gói thành một sản phẩm phục vụ cho nhu cầu giám sát, cảnh báo và hiển thị

Check_MK được xây dựng từ những đóng góp của cộng đồng về những khó khăn hay khuyết điểm mà Nagios gặp phải, từ đó đưa ra quyết định cần tích hợp thêm những sản phẩm gì để cải thiện.

Việc cài đặt trở nên vô cùng đơng giản. Check_MK được đóng gói hoàn chỉnh trong một package, việc cài đặt và cấu hình chỉ mất khoảng 10 phút với chỉ một câu lệnh

2. Cách thức hoạt động

Có 2 mô đun mà Check_MK sử dụng để cải thiện đáng kể hiệu năng là Livestatus và Livecheck

2.1 Livestatus

Trước khi có Livestatus

  • Kết quả giám sát được sẽ lưu trong file status.dat gây nên hiện tượng nút thắt cổ chai cho CPU và Disk I/O
  • Trạng thái của file status không phải là real-time mà update ít nhất là mỗi 10s
  • NDOUtils sử dụng database để theo dõi kết quả (MySQL hoặc PostgreSQL), nhưng vẫn còn một số thiếu sót quan trọng.
  • Việc cài đặt NDOUtils khá phức tạp
  • NDOUtils cần một database cho việc lưu trữ dữ liệu. Hơn nữa, việc dữ liệu lưu trong database này tăng lên một cách nhanh chóng khiến cho bạn phải tiêu tốn nhiều CPU chỉ để cập nhập database.
  • Một số dự án tương tự vẫn sử dụng NDOUtils: Centreon và Opsview
  • Việc dọn dẹp database có thể khiến Nagios bị treo trong một khoảng thời gian nhất định

Sau khi có Livestatus

  • Livestatus cũng sử dụng Nagios Event Broker API như NDO, nhưng nó sẽ không chủ động ghi dữ liệu ra. Thay vào đó, nó sẽ mở ra một socket để dữ liệu có thể được lấy ra theo yêu cầu
  • Livestatus tiêu tốn ít CPU
  • Livestatus không làm cho Disk I/O thay đổi khi truy vấn trạng thái dữ liệu
  • Không cần cấu hình. Không cần cơ sở dữ liệu. Không cần quản lý
  • Livestatus có quy mô lớn với hơn 50.000 dịch vụ

2.2 Livecheck

Trước Nagios 4.0, ngay cả một hệ thống hoàn hảo hiếm khi quản lý để thực hiện hơn một vài nghìn lần kiểm tra mỗi phút.

Trong khi hệ thống càng lớn, tỷ lệ check tối đa sẽ trở nên rất tệ. Càng nhiều máy chủ và dịch vụ thì đồng nghĩa với việc khoảng thời gian check cần phải tăng lên.

Các vấn đề tồn tại trong Nagios (trước Nagios 4.0)

  • Mỗi lần check tạo ra một bản fork. Quá trình fork rất tốn kém ngay cả khi kernel được tối ưu hóa
  • Quá trình fork trong Nagios Core (trước phiên bản Nagios 4.0) không phân tán ra nhiều CPU mà thực hiện trên chỉ một CPU đơn. Điều này dẫn tới việc giới hạn số lần check mỗi giây, trong khi phần lớn các CPU khác rảnh rỗi.

Làm thế nào để Livecheck giải quyết được vấn đề nút thắt cổ chai

  • Livecheck sử dụng các helper process, các core giao tiếp với helper thông qua Unix socket (điều này không xảy ra trên file system)
  • Chỉ có một một helper program được fork thay vì toàn bộ Nagios Core.
  • Các tiến trình fork được phân tán trên tất cả các CPU thay vì chỉ một như trước
  • Process VM size tổng chỉ khoảng 100KB
  • Việc thực hiện check_icmp sẽ cho một con số cải tiến cụ thể. Giả sử nếu sử dụng CPU dual core 2800 MHz CPU:
  • Trước đây sẽ là 300 ICMP check/second
  • Sau khi cải tiến là 2600 ICMP check/second

3. Giao diện quản lý

Check_MK sử dụng giao diện multi-site để quản lý đa kênh.

Multisite là một phần của dự án Check_MK như là một giao diện web cho người dùng tốt hơn để thay thế cho Nagios

Một GUI mới và sáng tạo để xem thông tin trạng thái Nagios và kiểm soát hệ thống giám sát. Nó dựa trên MK Livestatus và nhằm mục đích thay thế cho GUI web Nagios. Multisite hỗ trợ giám sát phân tán bằng một cách hiệu quả nhất

  • WATO : no more config file :)

Với Nagios, mỗi khi cấu hình một host mới, hay cấu hình một cảnh báo…bạn phải mất ít nhất 15p cho việc tạo, sửa đổi file cấu hình, dùng câu lệnh để restart service…chưa kể thời gian tìm lỗi nếu cấu hình sai. Với WATO, tất cả các thao tác đó có thể thực hiện trong vòng 3p trên giao diện WEB.

  • Agent giám sát có sẵn cho Linux và Windows
  • Đáp ứng được giao diện người dùng trên điện thoại
  • Khả năng tìm kiếm mạnh mẽ
  • Thông số đo lường trực quan với Perf-O-Meter

3.1 Dashboard quản lý

Dashboard tổng hợp chứa status của tất cả các service được phân theo group. Ở dashboard này sẽ show ra thông tin về tên service đang đc monitor, trạng thái chi tiết, thời gian check, đến hiệu năng của service (thời gian trả về khi gọi đến service).

Cột “Views” bên cạnh là các dashboard khác nhau, nhưng các bạn chỉ cần quan tâm tới dashboard trên tương ứng với “Service by group” trong mục “Service Groups”.

Các config trên Check_mk chủ yếu trong sheet này.

3.2 Check Uptime/Downtime of Service

  • Vào mục Service Group ở trên để xem tất cả các service.
  • Vào bất kì 1 service để xem trạng thái chi tiết của service đấy → vào mục “Availability”
  • Tham số bên cạnh là chỉ số uptime của service tính theo % vầ tổng số giây. Chọn mục “Export as CSV” để xuất báo cáo về time uptime của service.
  • Chọn mục “Timeline” để xem chi tiết tổng số time uptime/downtime của service.

--

--