Trình ghi nhật ký ngoại lệ: Thực tiễn tốt nhất

Question

Tôi vừa bắt đầu sử dụng trình ghi nhật ký ngoại lệ (EurekaLog) trong ứng dụng (Delphi) của tôi. Bây giờ ứng dụng của tôi gửi cho tôi rất nhiều thông báo lỗi qua e-mail mỗi ngày. Đây là những gì tôi phát hiện ra cho đến nay

• rất nhiều lỗi trùng lặp
• nhiều mail so với cùng PC

Trong khi điều này là đầu vào có giá trị cao để cải thiện ứng dụng của tôi, tôi hơi bị choáng ngợp bởi tuyệt lượng thông tin tôi nhận được.

Thực tiễn tốt nhất của bạn để xử lý thư từ ứng dụng của bạn là gì?

Answer 1

Tôi nghĩ bạn nên bỏ tất cả các bản sao. Chỉ để lại số lượng báo cáo. I E. nếu bạn nhận được, hãy nói 100 báo cáo, nhưng chỉ có 4 vấn đề duy nhất - chỉ để lại 4 báo cáo, ném ra 96 ​​báo cáo khác, nhưng sử dụng số lượng của chúng để sắp xếp báo cáo theo mức độ nghiêm trọng. Ví dụ, 6 báo cáo cho vấn đề thứ tư, 10 báo cáo cho thứ ba, 20 cho thứ hai và 60 cho đầu tiên. Vì vậy, bạn nên khắc phục vấn đề đầu tiên với 60 báo cáo và chỉ sau đó chuyển sang thứ hai.

Tôi tin rằng EurekaLog có BugID trong báo cáo của mình. Cùng một vấn đề có cùng một BugID. Điều này sẽ cho phép bạn sắp xếp các báo cáo với các bản sao. Trình xem EurekaLog cũng có thể sắp xếp các bản sao.

Answer 2

Nếu bạn nhận được nhiều thông tin vì hiện tại trường hợp bạn không nhận được bất kỳ thông tin nào.

Vì vậy, tôi sẽ nói phân loại các lỗi của bạn thành các nhóm, như CẢNH BÁO, L FATI BẤT HỢP, v.v. Sau đó, giới hạn email của bạn thành các thư quan trọng nhất (FATAL). Ngoài việc xem xét nhật ký của bạn một cách thường xuyên (ngày, tuần ...).

Answer 3

Nó sẽ phụ thuộc rất nhiều vào những lỗi được gửi lại. Một trong những rõ ràng là nếu có lỗi trong ứng dụng của bạn, họ cần sửa chữa và các bản vá lỗi/cập nhật gửi đến khách hàng của bạn.

Nếu chúng là ngoại lệ mà bạn biết có thể xảy ra và không yêu cầu bạn được thông báo, bạn có thể thêm "Bộ lọc ngoại lệ" trong tùy chọn Nhật ký Eureaka để chỉ định cách xử lý (hoặc bỏ qua!).

Một tùy chọn khác là sử dụng biến EurekaLog (nơi bạn có thể thêm mô tả ngoại lệ v.v.) vào dòng tiêu đề thư và sau đó sử dụng ứng dụng email khách của bạn để lọc dựa trên điều này.

Answer 4

Những gì tôi đã thực hiện với ghi nhật ký ngoại lệ, sử dụng madExcept làm lõi, nhưng cơ chế truyền tải của riêng tôi, có tất cả chúng đi vào cơ sở dữ liệu. Thông tin cốt lõi được trích xuất từ ​​mỗi báo cáo và đưa vào các trường và toàn bộ báo cáo cũng được lưu trữ. Theo dõi ngăn xếp được tự động phân tích để loại bỏ các chức năng không thú vị, để lại một danh sách chỉ các chức năng của tôi đã thất bại. Với điều này xảy ra tự động, bây giờ tôi có thể "bỏ qua" từng thông điệp cá nhân đến, nhưng xem hình ảnh lớn hơn trong một lưới cho thấy tôi chỉ đơn giản là chức năng nào đang gặp nhiều sự cố nhất. Sau đó tôi có thể tập trung vào chúng, tìm kiếm nguyên nhân và sửa chúng.

Ứng dụng hiển thị của tôi cũng có thể lọc báo cáo trong các bản dựng trước một số nhất định nếu tôi chọn, để tôi có thể yêu cầu không bao gồm "MyWidget.BadProc" trước khi tạo 75 khi tôi đã sửa nó.

Điều này đã giúp tôi cải thiện ứng dụng của mình và đạt được các vấn đề mà mọi người thấy có vấn đề nhất mà không phải đoán.

Answer 5

Tôi đã thực hiện việc này bằng madExcept. Nó thực sự hữu ích cho việc theo dõi các vấn đề chúng tôi không thể tái sản xuất.

Điều gì khiến tôi hỏi tại sao bạn lại nhận được quá nhiều? Các ngoại lệ chưa được loại bỏ nên ít và xa. Đặc biệt nếu người dùng thấy hộp thoại báo lỗi. Tôi chịu trách nhiệm cho một số ứng dụng, mỗi ứng dụng có hàng trăm lượt cài đặt và tôi hiếm khi nhận được thông báo qua email.

Nếu chúng chủ yếu là từ một số lượng rất nhỏ máy tính, tôi sẽ làm việc với một số người dùng đó để tìm hiểu xem họ đang làm gì khác hoặc cách thiết lập của họ có thể tạo ngoại lệ.

Nếu chúng đến từ khắp nơi, đó có thể là lỗi đã trải qua quá trình kiểm tra của bạn.

Dù bằng cách nào, hãy sử dụng các chi tiết để sửa mã của bạn hoặc ít nhất, dự đoán các trường hợp ngoại lệ đã biết và bẫy chúng đúng cách (không trống thử..except).

Khắc phục sự cố điểm nóng sẽ giảm bớt số lượng email bạn nhận được, làm cho thông báo định kỳ dễ quản lý hơn nhiều.