Phạm vi kiểm tra sức khỏe đối với hệ thống triển khai ứng dụng web là gì?

Hôm nay tôi có nhiệm vụ "viết kiểm tra sức khỏe" cho một dịch vụ chạy dài là hệ thống điều phối để triển khai một ứng dụng web.

Tôi đang cố gắng xác định phạm vi kiểm tra sức khỏe như vậy là gì và đã đưa ra những câu hỏi liên quan đến phạm vi kiểm tra sức khỏe:

1. Có đủ tốt để xem xét dịch vụ lành mạnh nếu hệ thống điều phối báo cáo rằng nhiệm vụ đang chạy?
2. Hoặc chúng ta nên ping thủ công từng dịch vụ?
3. Hoặc nó nên đi xa hơn và cố gắng đảm bảo rằng ứng dụng web thực hiện những gì nó phải làm, như hiển thị một trang web?
4. Có phải Healthcheck cũng phải kiểm tra xem một số dịch vụ phụ thuộc cũng đang chạy không? Giống như một cơ sở dữ liệu hoặc hệ thống điều phối chính nó. Hay đó là trách nhiệm của một cuộc kiểm tra sức khỏe khác?
5. Và cuối cùng, nếu một trong các dịch vụ phụ thuộc đã chết và ứng dụng web sau đó không thành công, thì ứng dụng web có báo cáo tình trạng xấu không, hay nó có tốt cho sức khỏe không, vì đó không phải là lỗi của ứng dụng web?

Tôi biết đây là 5 câu hỏi riêng biệt, nhưng tất cả chúng đều liên quan đến phạm vi kiểm tra sức khỏe đối với một dịch vụ chạy dài triển khai một ứng dụng web, vì vậy tôi nghĩ sẽ hợp lý hơn khi giữ chúng trong một câu hỏi duy nhất.

Điều này rất khó thực hiện đối với tôi bởi vì tôi không chắc định nghĩa về những gì lành mạnh, hoặc kiểm tra sức khỏe tiêu chuẩn cho những thứ như thế này sẽ như thế nào.

Kiểm tra sức khỏe cho dịch vụ cụ thể này nên chứa gì?

Điều này khó thực hiện vì định nghĩa thế nào là lành mạnh

Bạn đã trả lời câu hỏi của riêng bạn ở đây. Định nghĩa của kiểm tra sức khỏe sẽ thay đổi, bởi vì những gì lành mạnh khác nhau. Nó cũng phụ thuộc vào những gì đang ban hành kiểm tra sức khỏe.

Một câu hỏi hay để tự hỏi mình là "từ quan điểm của người hỏi, dịch vụ được kiểm tra có hoạt động như mong đợi không?" Nếu đây là bạn, bạn có thể xác định nó. Nếu đó là một nhóm / dịch vụ khác, bạn cần xác định tiêu chuẩn / thông số kỹ thuật cho kiểm tra sức khỏe là gì.

Có khả năng trong một tổ chức lớn, bạn sẽ có một số loại tiêu chuẩn cho những gì một kiểm tra sức khỏe nên làm. Hình dung điều đó.

Cụ thể ở đây, ví dụ về ứng dụng web của bạn có nghĩa là nó sẽ không trở lại khỏe mạnh vì ứng dụng web không lành mạnh. Nhưng có lẽ định nghĩa của bạn về "khỏe mạnh" sẽ bao gồm điều này là "ok." Đây là một phần của các cuộc thảo luận về yêu cầu ở trên (một lần nữa, ngay cả khi đó chỉ là mã của riêng bạn).

Khuyến nghị của tôi cho rằng nó không được chỉ định ở nơi khác sẽ có một số loại mã trạng thái liên quan đến các lỗi khác nhau. Khi bạn truy vấn ứng dụng web, nó có thể trả về lỗi "dịch vụ phụ thuộc đã chết" và do đó, khách hàng của bạn (hoặc bất cứ điều gì đang thực hiện kiểm tra sức khỏe) có thể biết lý do khách hàng đã chết.

Đối với các câu hỏi được chỉnh sửa:

Có đủ tốt để xem xét dịch vụ lành mạnh nếu hệ thống điều phối báo cáo rằng nhiệm vụ đang chạy?

Không, chỉ vì một quy trình đang chạy không có nghĩa là nó không bị treo, hoàn toàn không có chức năng hoặc nhiều khả năng khác.

Hoặc chúng ta nên ping thủ công từng dịch vụ?

Điều này có thể hoạt động, tùy thuộc vào phạm vi chức năng ứng dụng của bạn. Nếu xác minh dịch vụ đáp ứng với "bạn còn sống không?" ping sau đó có thể là tất cả những gì được yêu cầu. Nhưng nếu dịch vụ có thể dễ dàng "sống và đáp ứng nhưng không thực sự hoạt động" thì có lẽ bạn cũng cần kiểm tra những thứ khác.

Hoặc nó nên đi xa hơn và cố gắng đảm bảo rằng ứng dụng web thực hiện những gì nó phải làm, như hiển thị một trang web?

Kiểm tra sức khỏe của bạn cần phải đảm bảo rằng các chức năng cần thiết được mong đợi hoạt động như mong đợi.

Nếu lợi nhuận ứng dụng của bạn "khỏe mạnh" và không thể làm những gì nó cần phải làm, bạn cũng có thể thoát khỏi toàn bộ healthcheck vì nó sẽ cung cấp cho dương tính giả (chưa kể đến nhầm lẫn các quái ra khỏi người cố gắng để gỡ rối vấn đề - 'hey máy chủ web của chúng tôi hiển thị tốt, tại sao chúng tôi không thể xem trang? ').

Có phải Healthcheck cũng phải kiểm tra xem một số dịch vụ phụ thuộc cũng đang chạy không? Giống như một cơ sở dữ liệu hoặc hệ thống điều phối chính nó. Hay đó là trách nhiệm của một cuộc kiểm tra sức khỏe khác?

Điều này phụ thuộc phần nào. Nếu dịch vụ của bạn phụ thuộc vào dịch vụ khác, bản chất của sự tương tác đó sẽ được phản ánh trong các cuộc gọi API / mạng được gửi đến nó trong ứng dụng của bạn và được tích hợp vào kiểm tra sức khỏe.

Ví dụ: máy chủ web đọc từ cơ sở dữ liệu cần có thông tin trạng thái về cơ sở dữ liệu được tích hợp trong đó - hoặc ứng dụng web sẽ bị sập nếu cuộc gọi API thất bại. Bạn có thể sửa đổi một cách tầm thường những cuộc gọi này để được đưa vào kiểm tra sức khỏe của bạn.

Tuy nhiên, nếu dịch vụ của bạn đang gửi các sự kiện tới người tiêu dùng lắng nghe mà không có bất kỳ xác nhận nào, thì điều đó ít quan trọng hơn đối với chức năng của ứng dụng mà người tiêu dùng còn sống. "Khỏe mạnh" cho ứng dụng của bạn đang gửi tin nhắn, không thực sự nhận được chúng.

Về cơ bản, nếu dịch vụ của bạn cần nói chuyện với các dịch vụ khác và xác minh sức khỏe của họ bằng mọi cách thì ít nhất có một mức kiểm tra cơ bản trong kiểm tra sức khỏe của dịch vụ của bạn. Điều này sẽ có ý nghĩa về mặt khái niệm khi tôi vừa nói vì ứng dụng của bạn sẽ xử lý việc này (hoặc bị sập ngẫu nhiên, tôi đoán vậy).

Và cuối cùng, nếu một trong các dịch vụ phụ thuộc đã chết và ứng dụng web sau đó không thành công, thì ứng dụng web có báo cáo tình trạng xấu không, hay nó có tốt cho sức khỏe không, vì đó không phải là lỗi của ứng dụng web?

Điều này về cơ bản đã được trả lời ở trên. Đề nghị của tôi sẽ là để kiểm tra sức khỏe của bạn trả lại mã / tin nhắn / bất cứ điều gì cung cấp thông tin này. Cả hai thông tin đều quan trọng: dịch vụ phụ thuộc mà dịch vụ của bạn cần đã chết và kết quả là dịch vụ của bạn sẽ không hoạt động như mong đợi.

Nói chung, kiểm tra sức khỏe chỉ có nghĩa là "nó còn sống và nó đang phản ứng". Kiểm tra thêm hơn đó là rất chuyên môn và phụ thuộc hoàn toàn vào việc sử dụng hệ thống. Việc bạn có đi xa hơn để kiểm tra xem hệ thống đang xử lý các yêu cầu chính xác hay không là tùy thuộc vào bạn, nhưng bạn nên thực hiện các thao tác cơ bản trước - kiểm tra xem có ở đó không, kiểm tra xem nó có thể nhận yêu cầu không và sẽ trả lời phản hồi.

Cách dễ nhất để thực hiện kiểm tra sức khỏe là chỉ cần viết một lệnh mà dịch vụ xử lý bằng cách sử dụng cùng một cơ chế mà các lệnh khác sử dụng, không có gì ngoài trả về một xác nhận. Điều đó sẽ hiển thị trực tiếp và hệ thống đang nhận và xử lý các phản hồi.

Kiểm tra các hệ thống phụ thuộc không phải là một phần của kiểm tra sức khỏe, bạn cần giữ cho nó đơn giản và khép kín. Thêm lần lượt kiểm tra sức khỏe cho từng dịch vụ phụ thuộc. Bằng cách đó, bạn có thể nhận được một danh sách các hệ thống đang hoạt động, khỏe mạnh và dễ dàng biết khi nào một thiết bị xấu, đó là cái nào!

Theo kinh nghiệm của tôi, các dịch vụ quan trọng có xu hướng có các tính năng sau:

Nhịp tim

Nếu dịch vụ chạy một cách thường xuyên, điều này chỉ ghi một dòng vào tệp nhật ký hoặc tương tự cùng với dấu thời gian để chỉ ra rằng cơ thể dịch vụ đã khởi động tại một thời điểm nhất định.

Bánh mì vụn

Tương tự như trên, mẩu bánh mì thường chỉ là một bãi chứa tên phương thức (và đôi khi là tham số) để cho thấy rằng dịch vụ đang xử lý phần thân dịch vụ như mong đợi và nơi ở trong luồng. Vì chúng có thể tạo ra nhiều đầu ra hơn, chúng thường được kiểm soát bởi các tệp cấu hình hoặc tương tự để chúng có thể bị tắt sau khi dịch vụ đã được liệt kê.

Nó có thể hấp dẫn để thêm rất nhiều thứ khác như trạng thái của các máy chủ, dịch vụ và cơ sở dữ liệu khác nhau và tương tự. Trong khi điều này chắc chắn có giá trị, tôi khuyên bạn không nên viết bất cứ điều gì quá rộng rãi. Chúng có thể hữu ích cho sự an tâm của bạn nhưng các biện pháp bảo vệ như vậy có xu hướng bị lạm dụng một khi các bên chịu trách nhiệm về các điểm tiếp xúc khác nhau biết rằng họ đang ở đó. Trước khi bạn biết điều đó, bạn có thể viết một ứng dụng chẩn đoán cho toàn bộ công ty.