Cách sử dụng các cấp độ log4J

Question

Cách thực hành tốt nhất khi sử dụng các mức log4j khi mã hóa. Tôi có nghĩa là khi nào chúng ta sử dụng ghi nhật ký INFO, khi nào chúng ta sử dụng ghi nhật ký DEBUG/ERROR, vv ..

Answer 1

Cách tốt nhất để học là ví dụ. Đọc nguồn của một số thứ nguồn mở, như, oh, Tomcat hoặc bất kỳ thứ gì trong khu vực ứng dụng của bạn và xem những gì bạn thấy.

Answer 2

ERROR ghi nhật ký phải luôn bật.

INFO + DEBUG phải bật khi theo dõi sự cố/lỗi.

Answer 3

Nói chung, tôi làm theo các hướng dẫn sau:

• DEBUG: thứ cấp thấp. bộ nhớ cache hit, bộ nhớ cache miss, mở kết nối db
• INFO: Sự kiện có ý nghĩa kinh doanh - tạo khách hàng, sạc cc ...
• WARN: có thể là một vấn đề nhưng không chỉ dừng lại ứng dụng của bạn. không tìm thấy địa chỉ email/không hợp lệ
• ERROR: sự cố không mong muốn. không thể mở kết nối db. vv ...

Answer 4

ban đầu của tôi luôn luôn là INFO mức tương đương với System.out, và LỖI tương đương với System.err.

DEBUG - Tại đây bạn đặt tất cả thông tin truy tìm và thông tin cụ thể mà bạn không muốn thấy khi "mức độ thoải mái" của bạn là system.out.

INFO - sử dụng thông báo này cho các tin nhắn chung, thông báo tiến độ, cho các tin nhắn liên quan đến ứng dụng chứ không phải để truy tìm.

WARN - cung cấp cảnh báo rằng cái gì là sai, có lẽ bất ngờ, hoặc là một workaround được sử dụng, nhưng ứng dụng vẫn có thể tiếp tục (timeout ổ cắm/lần thử lại, không hợp lệ người dùng nhập vào, vv).

ERROR - cảnh báo về các vấn đề ngăn ứng dụng của bạn tiếp tục bình thường, ví dụ: cơ sở dữ liệu bị hỏng, thiếu cấu hình bootstrap.

Lỗi thường gặp khi viết thư viện là sử dụng mức ERROR để biểu thị các sự cố với ứng dụng gọi điện (mã sử dụng thư viện) thay vì chỉ ra các lỗi thực trong thư viện. Xem ví dụ lỗi hibernate này ->http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731

Điều này thực sự gây phiền toái vì thư từ cấp ERROR thực sự khó ngăn chặn, vì vậy chỉ sử dụng chúng để cho biết các vấn đề với mã của riêng bạn.

Tất cả - Tôi không thực sự sử dụng cái này, nó thực tế giống như DEBUG hoặc TRACE.

Answer 5

Đối với những gì người khác đã đề cập, tôi sẽ thêm mức TRACE và FATAL, trước đây là tốt cho việc ghi nhật ký chi tiết, sau đó là chỉ ra tổng số nút hiển thị. Có những hướng dẫn chung về cách bạn sử dụng các cấp, như đã đề cập ở trên. Tuy nhiên, hầu hết quan trọng nhất là cách BẠN sẽ sử dụng nó và cách USERS của bạn sẽ diễn giải chúng. Bạn cần các cấp để tập trung vào các vấn đề, vì vậy hãy quyết định vấn đề gì trong trường hợp của bạn. Người dùng của bạn sẽ hầu như không bao giờ cần theo dõi hoặc các câu lệnh gỡ lỗi, nhưng họ chắc chắn sẽ muốn giải quyết vấn đề và báo cáo cho bạn.

Answer 6

Mặc dù câu hỏi này khá cũ, đây thực sự là một điểm quan trọng mà mọi nhà phát triển nên biết, tôi khuyên bạn nên kiểm tra trang chính thức của Apache log4j.

Ngoài ra tôi đã tìm thấy và hữu ích hình ảnh mô tả này một cách hoàn hảo, log4jImage lấy từ supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html

Answer 7

TRACE: Mức nhật ký tối thiểu. Cung cấp mức thông tin chi tiết nhất.

DEBUG: Tuyên bố đăng nhập ở đây nhằm giúp các nhà phát triển. Trạng thái chi tiết của ứng dụng của bạn.

INFO: Thông tin doanh nghiệp chung. Tiến độ và trạng thái đơn đăng ký của bạn

WARN: Cảnh báo về các sự kiện không mong muốn. Đây không phải là đủ nghiêm trọng để hủy bỏ đơn của bạn.

ERROR: Các sự cố nghiêm trọng trong đơn đăng ký của bạn.

Cũng có mức độ ghi nhật ký phù hợp được bật trong các môi trường khác nhau cũng quan trọng không kém.

Answer 8

Dưới đây là một số hướng dẫn tôi sử dụng:

• TRACE: verbose đăng nhập để gỡ lỗi mức rất thấp, điều tôi thường không cần phải nhìn thấy trong một bản ghi, trừ khi có một số vấn đề rất khó hiểu hay bất thường.

• DEBUG: chỉ ghi nhật ký dành cho nhà phát triển - nội dung của các biến, kết quả so sánh và các thông tin khác giúp gỡ rối logic nghiệp vụ.

• INFO: thông tin cấp cao như tác vụ X đã hoàn thành hoặc một số quy tắc được hài lòng và đây là những gì tôi sẽ làm tiếp theo vì quy tắc đó.

• WARN: có thể có vấn đề nhưng không đủ nghiêm trọng để thực hiện bất kỳ tác hại thực sự nào đối với luồng logic của doanh nghiệp. Ví dụ có thể một số biến đôi khi sẽ là null nhưng chúng ta không nhất thiết cần nó hoặc chúng ta có thể làm việc xung quanh nó bằng cách nào đó. Đồng thời chúng tôi vẫn muốn biết về nó chỉ trong trường hợp chúng tôi được nói sau đó chúng ta cần phải tìm các ví dụ về nó hoặc điều tra kỹ hơn lý do tại sao nó xảy ra.

• ERROR: Vấn đề nghiêm trọng cần phải được điều tra thêm, nhưng không đủ nghiêm trọng để ngăn ứng dụng hoàn thành nhiệm vụ trong tầm tay.

• FATAL: Một vấn đề bất ngờ rất nghiêm trọng mà chúng tôi không thể làm việc xung quanh hoặc khôi phục và thậm chí có thể ngăn ứng dụng làm điều gì đó hữu ích.