Thực hành tốt nhất để ghi nhật ký và theo dõi trong .NET

Tôi đã đọc rất nhiều về truy tìm và ghi nhật ký, cố gắng tìm một số quy tắc vàng cho các thực tiễn tốt nhất trong vấn đề này, nhưng không có gì cả. Mọi người nói rằng các lập trình viên giỏi tạo ra dấu vết tốt, nhưng đặt nó theo cách đó và nó phải đến từ kinh nghiệm.

Tôi cũng đã đọc những câu hỏi tương tự ở đây và qua internet và chúng không thực sự giống với những gì tôi đang hỏi hoặc không có câu trả lời thỏa mãn, có thể vì các câu hỏi thiếu một số chi tiết.

Vì vậy, mọi người nói rằng việc theo dõi nên sắp xếp lại trải nghiệm gỡ lỗi ứng dụng trong trường hợp bạn không thể đính kèm trình gỡ lỗi. Nó sẽ cung cấp đủ ngữ cảnh để bạn có thể thấy đường dẫn nào được thực hiện tại mỗi điểm kiểm soát trong ứng dụng.

Đi sâu hơn, bạn thậm chí có thể phân biệt giữa theo dõi và ghi nhật ký sự kiện, trong đó "ghi nhật ký sự kiện khác với theo dõi ở chỗ nó nắm bắt các trạng thái chính thay vì luồng kiểm soát chi tiết".

Bây giờ, giả sử tôi muốn thực hiện theo dõi và ghi nhật ký chỉ sử dụng các lớp .NET tiêu chuẩn, những lớp trong System.Diagnosticskhông gian tên. Tôi hình dung rằng lớp TraceSource phù hợp với công việc hơn lớp Trace tĩnh, vì tôi muốn phân biệt giữa các cấp theo dõi và sử dụng lớp TraceSource tôi có thể truyền vào một tham số thông báo loại sự kiện, trong khi sử dụng lớp Trace tôi phải sử dụng Trace.WriteLineIfvà sau đó xác minh những thứ như SourceSwitch.TraceInformationvà SourceSwitch.TraceErrors, và thậm chí nó không có thuộc tính như TraceVerbosehoặc TraceStart.

Với tất cả những gì trong tâm trí, bạn sẽ xem xét một thực hành tốt để làm như sau:

• Theo dõi một sự kiện "Bắt đầu" khi bắt đầu một phương thức, nó sẽ đại diện cho một hoạt động logic đơn lẻ hoặc một đường ống, cùng với một chuỗi đại diện của các giá trị tham số được truyền vào phương thức.
• Theo dõi một sự kiện "Thông tin" khi chèn một mục vào cơ sở dữ liệu.
• Theo dõi một sự kiện "Thông tin" khi đi theo con đường này hay con đường khác trong một câu lệnh if / other quan trọng.
• Theo dõi "Lỗi nghiêm trọng" hoặc "Lỗi" trong khối bắt tùy thuộc vào việc đó có phải là lỗi có thể phục hồi hay không.
• Theo dõi sự kiện "Dừng" khi kết thúc thực hiện phương thức.

Ngoài ra, vui lòng làm rõ khi nào tốt nhất để theo dõi các loại sự kiện Verbose và Cảnh báo. Nếu bạn có ví dụ về mã với theo dõi / ghi nhật ký đẹp và sẵn sàng chia sẻ, điều đó sẽ rất xuất sắc.

Lưu ý: Tôi đã tìm thấy một số thông tin tốt ở đây, nhưng vẫn không phải là những gì tôi đang tìm kiếm: http://msdn.microsoft.com/en-us/magazine/ff714589.aspx

Tầm quan trọng của các loại dấu vết phải được chọn không phải vì vị trí của dấu vết trong mã, mà bởi vì thông điệp theo dõi ít ​​nhiều quan trọng. Thí dụ:

Theo dõi một sự kiện "Bắt đầu" khi bắt đầu một phương thức, sẽ đại diện cho một hoạt động logic đơn lẻ hoặc một đường ống, cùng với biểu diễn chuỗi của các giá trị tham số được truyền vào phương thức.

Sử dụng loại bắt đầu khi bạn bắt đầu một hoạt động hợp lý. Điều này không có nghĩa là dấu vết bắt đầu phải ở đầu một phương thức, cũng không có nghĩa là một phương thức phải có dấu vết bắt đầu.

Điều này đang được nói, trong hầu hết các trường hợp, một hoạt động logic sẽ thực sự bắt đầu khi bắt đầu phương thức. Nếu không, bạn nên tự hỏi nếu mã được tái cấu trúc chính xác.

Thông số truy tìm cũng có thể là một ý tưởng tồi . Bạn phải suy nghĩ những gì để theo dõi, từng trường hợp. Ví dụ, nó thực sự xấu khi theo dõi các tham số của một phương thức void Authenticate(string userName, string plainPassword).

Theo dõi một sự kiện "Thông tin" khi chèn một mục vào cơ sở dữ liệu.

Nó phụ thuộc. Một số mặt hàng phải được truy tìm, nhưng không phải mọi mặt hàng.

• Ví dụ, hãy tưởng tượng bạn đang thực sự chèn một mục nhật ký vào cơ sở dữ liệu của bạn. Bạn sẽ theo dõi nhật ký? Rồi đăng nhập dấu vết? Và sau đó theo dõi đăng nhập của dấu vết?
• Một ví dụ khác: bạn đang chèn một dữ liệu nhạy cảm. Điều này đòi hỏi phải kiểm toán. Vì bạn đã kiểm tra việc chèn, tại sao phải truy tìm nó?

Theo dõi một sự kiện "Thông tin" khi đi theo con đường này hay con đường khác trong một câu lệnh if / other quan trọng.

Một lần nữa, nó phụ thuộc.

Theo dõi "Lỗi nghiêm trọng" hoặc "Lỗi" trong khối bắt tùy thuộc vào thời tiết, đây là lỗi có thể phục hồi.

Hành động được thực hiện sau một lỗi không thể phục hồi có thể nhiều hơn dấu vết. Ví dụ: phía máy chủ, bạn muốn lưu trữ ngoại lệ trong cơ sở dữ liệu để phân tích thêm. Ngoài ra, một số trường hợp ngoại lệ ít quan trọng hơn những trường hợp khác và không yêu cầu truy tìm.

Theo dõi sự kiện "Dừng" khi kết thúc thực hiện phương thức.

Xem điểm đầu tiên.

vui lòng làm rõ khi nào tốt nhất để theo dõi các loại sự kiện Verbose và Cảnh báo.

Verbose:

Verbose được sử dụng để theo dõi những gì bạn cần theo dõi khi có điều gì đó thực sự sai. Điều đó có nghĩa là trong hầu hết các trường hợp, bạn sẽ vô hiệu hóa dấu vết của các thông báo dài dòng, nhưng đôi khi, bạn phải gỡ lỗi một số phần của mã để hiểu lý do tại sao một cái gì đó không thành công trong trường hợp cạnh.

Bạn thường có rất nhiều thông điệp dài dòng cho phép bạn hiểu rất rõ luồng ứng dụng. Điều đó cũng có nghĩa là những tin nhắn đó phải bị vô hiệu hóa hầu hết thời gian vì:

• nếu không, nhật ký sẽ phát triển rất nhanh,
• bạn không cần chúng hầu hết thời gian,
• chúng có thể chứa dữ liệu nhạy cảm về luồng ứng dụng.

Hãy suy nghĩ về verbose như một công cụ bạn phải sử dụng khi bạn không có quyền truy cập vào trình gỡ lỗi.

Cảnh báo:

Theo dõi loại cảnh báo được sử dụng khi có lỗi và quan trọng xảy ra, nhưng không quá quan trọng để được coi là lỗi. Ví dụ, RAM thấp có thể phát ra cảnh báo, nhưng không có lý do để theo dõi lỗi, vì ứng dụng của bạn có thể tiếp tục, ngay cả khi nó sẽ chậm hơn bình thường.

Ví dụ:

• Ví dụ 1: ứng dụng không thể mở tệp mà người dùng yêu cầu mở. Tệp tồn tại và không được sử dụng, quyền được đặt chính xác, nhưng một cái gì đó chặn việc mở tệp. Trong trường hợp này, bạn sẽ theo dõi một lỗi , vì ứng dụng của bạn không thể quản lý trường hợp này và tiếp tục hoạt động như mong đợi của người dùng (tức là thực sự đọc tệp).

• Ví dụ 2: sau khi kiểm tra lỗi trong ví dụ đầu tiên, bạn thấy rằng lỗi xảy ra do thực tế là đường dẫn tệp dài hơn 259 ký tự. Vì vậy, bạn cấu trúc lại mã của bạn để bắt PathTooLongException. Khi, lần sau, người dùng cố gắng mở cùng một tệp, phiên bản mới của ứng dụng hiển thị một thông báo giải thích rằng tệp quá dài và phải được chuyển sang thư mục khác để rút ngắn đường dẫn đầy đủ để mở tệp này trong ứng dụng này. Bạn cũng theo dõi một tin nhắn .

• Ví dụ 3: ứng dụng của bạn mất hai mươi giây để mở và phân tích một tệp nhỏ trong khi hầu hết các tệp mất từ ​​mười đến một trăm mili giây để mở và phân tích cú pháp. Bạn theo dõi một cảnh báo với thông tin liên quan: loại đĩa thực sự là tệp, hệ thống tệp, kích thước của tệp, thời gian chính xác, thời gian bật máy tính, v.v. Khi người dùng phàn nàn rằng phải mất hai mươi vài giây để mở tập tin, bạn lấy dấu vết để tìm những gì xảy ra. Ví dụ, bạn thấy rằng phải mất quá nhiều thời gian để tải các tệp từ chia sẻ mạng khi máy tính vừa mới khởi động. Bạn giải thích cho người dùng rằng sự chậm trễ là do mạng và không liên quan đến ứng dụng của bạn.

• Ví dụ 4: tệp đã mở được hiển thị không chính xác. Bạn kích hoạt theo dõi dài dòng nơi bạn thực sự thấy cách dữ liệu được tải từ tệp và sau đó phân tích cú pháp.

 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics thật tuyệt vời vì bạn có thể định cấu hình nơi thông tin theo dõi sẽ đi đến đâu (tệp, eventlog, cơ sở dữ liệu, ....)

Thật không may, nếu bạn muốn sử dụng, System.Diagnosticsbạn phải biết trước ( vào lúc tuyệt vọng ), những dòng dấu vết nào có thể theo dõi. (Trong bài viết ví dụ này là Chuyển, Tiếp tục, Tạm dừng, ...). Đây có thể được cấu hình để bị vô hiệu hóa, Debuglevel hoặc Errorlevel.

Tôi thích có một hệ thống ghi nhật ký nơi tôi có thể quyết định trong thời gian chạy trên classlevel / namepacelevel , mức độ chi tiết của việc ghi nhật ký. Ví dụ, tất cả các Debug trở lên từ MyNamespace.Business.*nhưng không MyNamespace.Business.Calculations.

Nếu bạn đang sử dụng log4net (hoặc Common.logging), mỗi lớp sẽ có trình ghi nhật ký riêng để bạn có thể dễ dàng quyết định lớp nào được ghi ở mức nào.

Vì các hoạt động cơ sở dữ liệu nằm trong một lớp riêng biệt, không cần thêm quy tắc riêng

Trace an "Information" event when inserting an item into the database.

Thay vào đó tôi thích có những hướng dẫn sau:

• Tracelevel sẽ hiển thị quy trình làm việc cơ bản
• Debuglevel sẽ hiển thị dữ liệu chi tiết và xử lý trong quy trình công việc, bao gồm các quyết định trong quy trình chương trình với lý do (Tạo mục mới vì mục không tồn tại trong DB)
• Infolevel để bắt đầu / dừng dịch vụ và một mục nhập cho mỗi quy trình công việc / GUI bắt đầu

Bạn có thể thử khung Story , nó có một cách tiếp cận duy nhất để ghi nhật ký vì nó "làm cho" bạn viết tất cả các nhật ký (và thêm thông tin liên quan khác) vào ngữ cảnh để khi bạn cần đọc nó sau này bạn sẽ có mọi thứ bạn cần.

Nó sẽ tự động thêm các khái niệm "bắt đầu" và "dừng lại" như là bắt đầu và kết thúc của một câu chuyện.

Và với hệ thống dựa trên quy tắc, bạn có thể kiểm soát những việc cần làm với từng câu chuyện (bối cảnh) dựa trên thông tin mà nó có, ví dụ như in tất cả các câu chuyện có lỗi hoặc đến từ người dùng "quản trị viên".

Ngoài ra thêm thông tin về bài viết trên blog này