Cách tốt nhất để quản lý ghi nhật ký lỗi cho các trường hợp ngoại lệ là gì?

Giới thiệu

Nếu xảy ra lỗi trên một trang web hoặc hệ thống, tất nhiên sẽ hữu ích khi ghi nhật ký và hiển thị cho người dùng một thông báo lịch sự với mã tham chiếu cho lỗi.

Và nếu bạn có nhiều hệ thống, bạn không muốn thông tin này xuất hiện xung quanh - thật tốt khi có một nơi tập trung duy nhất cho nó.

Ở cấp độ đơn giản nhất, tất cả những gì cần thiết là một id tăng dần và kết xuất hàng loạt các chi tiết lỗi. (Và có thể "nơi tập trung" là một hộp thư đến email.)

Ở đầu kia của phổ có lẽ là một cơ sở dữ liệu được chuẩn hóa hoàn toàn, cũng cho phép bạn nhấn nút và xem biểu đồ lỗi mỗi ngày hoặc xác định loại lỗi phổ biến nhất trên hệ thống X là gì, liệu máy chủ A có nhiều cơ sở dữ liệu hơn không lỗi kết nối hơn máy chủ B, v.v.

Điều tôi đang đề cập ở đây là ghi nhật ký lỗi / ngoại lệ ở cấp mã bằng một hệ thống từ xa - không phải theo dõi vấn đề "dựa trên con người", chẳng hạn như được thực hiện với Jira, Trac, v.v.

Câu hỏi

Tôi đang tìm kiếm suy nghĩ từ các nhà phát triển đã sử dụng loại hệ thống này, đặc biệt liên quan đến:

• Các tính năng thiết yếu bạn không thể làm mà không có là gì?
• Điều gì là tốt để có các tính năng thực sự giúp bạn tiết kiệm thời gian?
• Những tính năng nào có vẻ là một ý tưởng tốt, nhưng thực sự không hữu ích?

Ví dụ: tôi muốn nói rằng chức năng "hiển thị trùng lặp" xác định nhiều lần xảy ra lỗi (mà không phải lo lắng về các chi tiết 'không quan trọng' có thể khác nhau) là rất cần thiết.
Nút "tạo sự cố trong [Jira / etc] cho lỗi này" nghe có vẻ tiết kiệm thời gian.

Chỉ cần lặp lại, những gì tôi theo sau là những trải nghiệm thực tế từ những người đã sử dụng các hệ thống như vậy, tốt nhất là sao lưu với lý do tại sao một tính năng tuyệt vời / khủng khiếp.
(Nếu bạn định đưa ra giả thuyết nào thì ít nhất hãy đánh dấu câu trả lời của bạn như vậy.)

Tôi đã ở trong một dự án có lỗi máy khách đăng nhập bằng thư viện Microsoft Enterprise . Tất cả ngoại lệ nơi gửi đến hộp thư của chúng tôi. Trong chủ đề thư, chúng tôi đã thêm mã băm của lỗi nối tiếp để tránh các thư trùng lặp. Tất nhiên người ta có thể lưu trữ các tin nhắn nối tiếp trong cơ sở dữ liệu và như vậy.

Tôi khuyên bạn nên kiểm tra thư viện Microsoft Enterprise và Log4Net .

Một số tính năng của Log4Net

• Hỗ trợ cho nhiều khung
• Xuất ra nhiều mục tiêu đăng nhập
• Kiến trúc đăng nhập phân cấp
• Cấu hình XML
• Cấu hình động
• Ghi nhật ký bối cảnh
• Kiến trúc đã được chứng minh
• Thiết kế mô đun và mở rộng • Hiệu suất cao với tính linh hoạt

Trong trường hợp ứng dụng cơ sở dữ liệu, một số loại ID (như <TABLE>:<PrimaryKeyID>) cho phép bạn theo dõi các bản ghi trong cơ sở dữ liệu liên quan đến phạm vi bắt ngoại lệ.

Tôi đã thực hiện nó với Oracle và PL / SQL, ghi lại ID trong bảng cơ sở dữ liệu trong ứng dụng, từ trình xử lý ngoại lệ.

Phần lớn những gì bạn mô tả (ví dụ: các phần cụ thể ghi nhật ký) được triển khai trong thư viện doanh nghiệp như Amir Rezaei đã lưu ý. Mọi thứ khác dường như là phần phân tích nhiều hơn (nghĩa là phải làm gì với nhật ký sau đó).

Trong trường hợp của tôi, tôi đã tạo ra một số ứng dụng nhỏ và tập lệnh sql giúp cho một số thứ dễ dàng hơn. Đây là một số điều mà tôi thực sự thích:

• Nhóm các lỗi giống nhau lại với nhau (ví dụ: 100 người dùng đều gặp cùng một lỗi trong cùng một thời điểm là 1 báo cáo lỗi với ghi chú có bao nhiêu sự cố đã xảy ra)
• Tự động nộp một vé trong trình theo dõi trường hợp (không bao giờ quản lý để thực hiện điều này 'chỉ với một nút bấm' nhưng luôn muốn)
• Tên người dùng của người dùng phần mềm (không chỉ máy, có sẵn với hầu hết các logger). Trong một số trường hợp, tài khoản người dùng tự động gây ra sự cố trong khi ở những người khác, người dùng cụ thể là nguyên nhân gây ra sự cố. "Tôi cần xem Mike làm một số công việc, anh ta cứ gây ra một lỗi cụ thể."
• "Hành động của người dùng" - Tôi đã có một ngăn xếp toàn cầu sẽ theo dõi mọi lần nhấn / bấm nút có thể thao tác như người dùng đã thực hiện và đã xử lý các bản ghi lỗi. Tái tạo lỗi thường là trường hợp đi qua dấu vết đó và thực hiện các bước tương tự như người dùng (Tôi đã hy vọng xây dựng trình tạo thử nghiệm CodedUI để phân tích dấu vết và thực hiện các bước tự động, nhưng không bao giờ thực hiện)

Đôi khi, thông tin nhật ký quá lớn để được lưu trữ trên đĩa. Một cách tiếp cận tôi đã thấy là viết các mục đăng nhập của bạn vào một firehose (nói, perl) một cái gì đó như thế này:

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

sau đó một nhà phân tích có thể tìm ra những gì họ muốn xem xét.

Dưới đây là một số điều tôi đã học được từ việc theo dõi lỗi trong các ứng dụng của mình:

• Có thể theo dõi một tệp nhật ký cuộn (tôi thường sử dụng log4net / log4j để đăng nhập các ứng dụng và BareTail để theo dõi nhật ký) thực sự hữu ích để có thể kiểm tra tình trạng hiện tại của hệ thống
• Để xem khi nào sự cố được đưa ra và tốc độ xảy ra sự cố, thật tốt khi đưa chúng vào cơ sở dữ liệu có dấu thời gian để bạn có thể chạy báo cáo.
• Khả năng gửi email / sms / thông báo bằng giọng nói là rất hữu ích trong việc đảm bảo các hệ thống luôn hoạt động, nhưng bạn phải có khả năng dễ dàng tùy chỉnh loại lỗi nào cảnh báo bạn. Nếu bạn nhận được 800 email lỗi mỗi ngày, bạn chắc chắn sẽ bỏ lỡ "Ồ không có trung tâm dữ liệu đang cháy".

Tôi đã có kết quả tuyệt vời cho log4net vì nó thực sự dễ dàng đăng nhập vào nhiều nơi và thay đổi cấu hình ghi nhật ký cũng dễ dàng.

elmah là một hệ thống ghi nhật ký lỗi nguồn mở cho các ứng dụng ASP.NET và có thể được thêm vào một hệ thống hiện có (sử dụng NuGet http://nuget.codeplex.com/ ) một cách nhanh chóng và dễ dàng. Nó hỗ trợ các phụ trợ khác nhau và chức năng thông báo.

Tôi không biết bất kỳ ai đã thêm nó vào một ứng dụng máy tính để bàn vì nó chạy như một trang web nhưng không có gì ngăn cản bạn chạy nó như một dịch vụ và đăng các ngoại lệ của bạn lên nó thông qua web.

http://code.google.com.vn/p/elmah/

ELMAH (Mô-đun ghi nhật ký lỗi và Trình xử lý) là một phương tiện ghi nhật ký lỗi toàn ứng dụng hoàn toàn có thể cắm được. Nó có thể được tự động thêm vào một ứng dụng web ASP.NET đang chạy hoặc thậm chí tất cả các ứng dụng web ASP.NET trên máy mà không cần phải biên dịch lại hoặc triển khai lại.

Khi ELMAH đã được đưa vào một ứng dụng web đang chạy và được định cấu hình phù hợp, bạn có được các phương tiện sau mà không thay đổi một dòng mã nào:

• Ghi nhật ký của gần như tất cả các ngoại lệ chưa được xử lý.
• Một trang web để xem từ xa toàn bộ nhật ký của các ngoại lệ được mã hóa lại.
• Một trang web để xem từ xa các chi tiết đầy đủ của bất kỳ một ngoại lệ nào được ghi lại, bao gồm cả dấu vết ngăn xếp màu.
• Trong nhiều trường hợp, bạn có thể xem lại màn hình vàng chết chóc ban đầu mà ASP.NET tạo ra cho một ngoại lệ nhất định, ngay cả khi customErrorsđã tắt chế độ.
• Một thông báo e-mail của từng lỗi tại thời điểm nó xảy ra.
• Một nguồn cấp dữ liệu RSS của 15 lỗi cuối cùng từ nhật ký ...