Làm thế nào để bạn giám sát các dịch vụ Node Micro chạy bên trong Docker Container?

Bài viết này về " Ứng dụng Dockerized của bạn khỏe mạnh như thế nào?" giải thích sự cố với giám sát, nhưng nó không cung cấp bất kỳ ví dụ hay nào về cách thực sự giám sát một dịch vụ siêu nhỏ bên trong thùng chứa docker.

Chúng tôi hiện đang sử dụng PM2 monit để giám sát các dịch vụ siêu nhỏ của mình, nhưng khi chúng tôi đặt chúng vào các thùng chứa docker, chúng tôi sẽ mất khả năng truy cập dữ liệu này trong một màn hình cho tất cả các dịch vụ siêu nhỏ khác nhau mà mỗi dịch vụ đều chạy trong bộ chứa docker của riêng chúng.

Giám sát Dockerswarm sẽ cho chúng ta biết trạng thái của các container, nhưng không phải là microservice chạy bên trong chúng.

Cách chứng minh vững chắc để giải quyết vấn đề này là gì?

Đây là một khu vực nơi Kubernetes có mô hình chính xác, cần có một bộ cân bằng tải giữa tất cả các hệ thống cần kiểm tra sức khỏe chức năng.

Khi bạn bắt đầu thêm Nagios, Zabbix hoặc các loại giám sát khác vào hệ thống, bạn bắt đầu xây dựng một máy trạng thái lớn. Điều này sẽ phá vỡ mô hình khớp nối lỏng lẻo và đưa ra các phụ thuộc lẫn nhau ngăn cản việc tái cấu trúc dễ dàng. Mặc dù không được đặt ra, sự khác biệt chính giữa microservice và các biến thể khác của SOA là khớp nối lỏng lẻo này.

Nếu các dịch vụ được xử lý tốt và thực hiện một chức năng duy nhất, hãy thực hiện kiểm tra sức khỏe tại bộ cân bằng tải ngược dòng, sau đó giám sát các thành viên nhóm hoạt động.

Như một ví dụ trong HAproxy

backend myapp
[...]
option tcp-check
tcp-check send GET\ /health HTTP/1.0\r\n
tcp-check send Host:\ foo\r\n
tcp-check send \r\n
tcp-check expect rstring ^HTTP/1.1\ 200\ Ok
tcp-check expect string container\ Good
server srv1 10.0.0.1:8080 check
server srv2 10.0.0.2:8080 check

Về lý thuyết, bạn không quan tâm đến hiệu suất của một container thực tế, chỉ là hiệu suất tổng thể của bạn là tốt.

Phương pháp này giúp dễ dàng tự sửa chữa hệ thống và mở rộng quy mô với mức độ phức tạp tối thiểu.

Về cơ bản, bạn chỉ phải kiểm tra xem số lượng hệ thống bạn mong đợi còn sống hay không, và nếu không, bạn sẽ quay thêm một số hệ thống nữa. Nếu bạn cần thêm dung lượng, bạn chỉ cần thay đổi số lượng nút dự kiến.

Điều này cũng đơn giản hóa việc tái cấu trúc vì bạn chỉ cần sao chép hoặc sửa đổi thử nghiệm này mà không cần phụ thuộc bên ngoài hoặc máy trạng thái.

Nó cũng sẽ giảm thời gian và nửa đêm cảnh báo Pagerduty khi hệ thống tự sửa chữa.

Đối với các số liệu hệ thống tổng thể, cần thiết để theo dõi các vấn đề như độ trễ, tôi sẽ muốn chúng ở một vị trí trung tâm bằng cách sử dụng một công cụ như elaticsearch. Nếu bạn sử dụng syslog, logstash hoặc log4 ??? để thu thập các số liệu sẽ hữu ích hơn nhiều về lâu dài. Khi các hệ thống là giám sát dựa trên bỏ phiếu truyền thống nhỏ và đơn giản có thể cung cấp đủ số liệu nhưng tốt nhất là có chúng ở định dạng có thể tìm kiếm và quan trọng hơn là liên quan đến các hệ thống khác.

Các giải pháp như monit vẫn có chỗ đứng của chúng, nhưng đó là theo dõi các thành phần tồn tại lâu như VM hoặc kim loại trần lưu trữ bầy đàn của bạn, nhưng chính các container nên được tách ra khỏi hệ thống đó để có được lợi ích cao nhất từ ​​mô hình dịch vụ vi mô.

Một giải pháp thường được sử dụng (không dành riêng cho container) là xây dựng API kiểm tra sức khỏe trong dịch vụ của bạn để kiểm tra tất cả các chức năng bạn muốn theo dõi (giả sử có sẵn DB và các phụ thuộc khác) và trả về một số đầu ra dự kiến ​​(giả sử < dịch vụ>: <trạng thái>). Sau đó, bạn có thể kích hoạt cảnh báo từ một dịch vụ giám sát như Nagios nếu API này không trả lại ok cho tất cả các dịch vụ. Điều này cũng sẽ thất bại nếu bản thân microservice không lành mạnh.

Cách tiếp cận này cũng có lợi ích khi chạy thử nghiệm chức năng cho dịch vụ của bạn (bằng cách nhấn điểm cuối API).

Cách tiếp cận này không bao gồm một số trường hợp cạnh mặc dù - ví dụ. microservice chạy (nhưng các API cụ thể không thành công).