Khi nào bỏ qua các lỗi phổ biến và chương trình phục hồi từ [đã đóng]

Tôi có một chương trình thực hiện hàng trăm yêu cầu CURL hàng ngày, yêu cầu SMTP và các yêu cầu khác. Ít hơn 1 phần trăm thời gian, yêu cầu CURL hoặc SMTP sẽ không thành công. Điều tốt nhất tôi có thể nói, nguyên nhân của vấn đề là do bên ngoài và không thể sửa được để đáng tin cậy 100%. Chương trình của tôi luôn có thể phục hồi từ nó và không cần sự tương tác của con người từ nó. Tôi có một hệ thống để gửi thông báo qua email khi có sự cố. Phần lớn những gì tôi nhận được là những thất bại vô hại của CURL và SMTP.

Tôi có nên gửi thông báo qua email về các lỗi phổ biến mà chương trình phục hồi không?

Phụ thuộc vào ứng dụng của bạn.

Email có thể hữu ích cho một thống kê nhưng nếu không, tôi sẽ tránh được thư rác này.
Những gì tôi làm trong các trường hợp tương tự: Gửi một bản tóm tắt mỗi ngày một lần để được thông báo chương trình của bạn hoạt động tốt như thế nào (và nó vẫn đang chạy).

Tôi sẽ chỉ gửi email, nếu tỷ lệ lỗi vượt quá giới hạn định sẵn cho thấy cần có sự can thiệp của con người.

Trong tình huống này tôi sẽ ngay lập tức ngừng gửi email.

Các email lỗi sẽ hoạt động như một tín hiệu cho thấy có gì đó không ổn và cần phải thực hiện hành động. Bởi vì bạn nhận được rất nhiều trong số chúng, chúng hoạt động như tiếng ồn tĩnh và bạn sẽ dễ dàng bỏ lỡ một email thực sự quan trọng xảy ra vì một lý do khác.

Tuy nhiên, nếu bạn nhận được 5 trong số các email này mỗi giờ và nhận được email như mỗi phút sẽ là điều gì đó bất thường, bạn cần xây dựng một cơ chế gửi một cái gì đó khi lỗi / giờ vượt qua một ngưỡng nhất định. Bởi vì một email có thể không còn ý nghĩa nữa, số lượng chúng trong một khoảng thời gian nhất định (phút / giờ / ngày) có thể có nghĩa là một cái gì đó lớn hơn.

Email không phải là một công cụ tốt để theo dõi lỗi. Xem xét các sản phẩm như Relic mới hoặc Thông tin chi tiết về ứng dụng để ghi lại tất cả các lỗi của bạn (và thông tin khác) để sau đó bạn có thể báo cáo về nó hoặc gửi thông báo qua email khi một số điều kiện được đáp ứng (ví dụ: khi nó thay đổi từ 1% không thành> 10% không thành công ).

Với các email riêng biệt cho từng lỗi, cuối cùng bạn sẽ bỏ qua các email và thậm chí có thể không nhận thấy bước nhảy từ 1% đến 10%. Tồi tệ hơn, nhà cung cấp email của bạn có thể thấy khối lượng lớn các email gần giống nhau từ một địa chỉ và đánh dấu tất cả chúng là thư rác.

Trong loại tình huống này, cố gắng tạo một thuật toán để tạo nhật ký các sự kiện lỗi và gửi một lần trong một ngày. Như pieter đã nói, cũng đưa ra một cảnh báo cho vượt quá số lỗi. Đó sẽ là một cách quản lý ứng dụng có hệ thống và xử lý sự cố.