Commons Logging ưu tiên thực hành tốt nhất

Question

Đây có thể là một câu hỏi hoàn toàn chủ quan (nếu không có tổ chức nào cố gắng chuẩn hóa điều này), nhưng nhóm của tôi phải vật lộn với điều này nhiều hơn bạn nghĩ.

Chúng tôi sử dụng Apache Commons Logging làm giao diện ghi nhật ký của chúng tôi và thường sử dụng mức độ ưu tiên không nhất quán trong nhóm phát triển của chúng tôi. Ví dụ, một số nhà phát triển đăng nhập bất kỳ trường hợp ngoại lệ nào bị lỗi (log.fatal (message)) mặc dù luồng có thể xử lý lỗi trong khi những người khác chỉ đăng nhập để gây tử vong khi một cái gì đó khiến chương trình nhất thiết ngừng thực hiện vì bất kỳ lý do gì.

Tôi muốn biết các nhóm khác xác định từng mức độ ưu tiên như thế nào. Có ai làm việc tại một công ty cố gắng xác định rõ ràng các phương pháp hay nhất cho việc này không? Jakarta có cân nhắc điều này không?

Mục tiêu của tôi là gửi một đề xuất đơn giản cho mỗi ưu tiên cho toàn bộ nhóm của tôi để chúng tôi có thể xử lý đăng nhập ứng dụng khó xử một cách hiệu quả theo cách nhất quán.

Answer 1

Đây là những gì chúng tôi sử dụng (và tôi muốn nói rằng nhiều người khác cũng):

• Fatal: lỗi gây nguy hiểm cho tính thống nhất của hệ thống và có thể yêu cầu một shutdown ngay lập tức/khởi động lại - rất hiếm khi bằng tay sử dụng
• LRI: các trường hợp ngoại lệ không được ném và đại diện cho lỗi trong hệ thống (thường là tất cả các ngoại lệ không bị bắt đến một điểm nhất định)
• CẢNH BÁO: ngoại lệ có thể xảy ra nhưng được tính hoặc các tình huống có thể ngụ ý lỗi sử dụng/logic - chúng tôi quyết định có theo dõi những người đó hay không
• THÔNG TIN: bất cứ điều gì bạn cần có trong nhật ký, ví dụ: những gì người dùng hiện đang làm (trong trường hợp ứng dụng web của chúng tôi: trang nào người dùng đang điều hướng đến v.v.)
• GB L :I: chỉ gỡ lỗi các thông báo như thời gian vv, thường bị tắt trong nhật ký
• TRACE: chúng tôi không sử dụng rằng, bạn có thể sử dụng nó để có thông tin gỡ lỗi cụ thể hơn nữa

Trong một số trường hợp, chúng tôi bắt đầu ghi nhật ký là L ERI, để nhận thông báo khi có điều gì đó mà chúng tôi không muốn xảy ra. Sau đó, nếu chúng tôi quyết định rằng không thể xóa nguồn cho lỗi đó, chúng tôi xử lý nó và thay đổi cấp nhật ký thành WARN.

Lưu ý rằng hệ thống thử nghiệm và sản xuất của chúng tôi được thiết lập để gửi email cho FATAL và ERROR. Vì vậy, chúng tôi không phải kiểm tra các tệp nhật ký cho những người đó theo cách thủ công nhưng chỉ phải kiểm tra một hộp thư email đến.

Hy vọng điều đó sẽ hữu ích.

Chỉnh sửa: bạn đã xem qua số Apache Commons Logging best pratices chưa?

Answer 2

Tôi đã luôn sử dụng điều này làm phương châm; Tôi sử dụng Log4j nhiều hơn Commons Logging nhưng điều này vẫn có thể hữu ích:

DEBUG - để biết thông tin thực sự gỡ lỗi; sẽ không được nhìn thấy trong sản phẩm sản xuất hoặc vận chuyển, vì INFO sẽ là mức tối thiểu; tốt để ghi lại thời gian, số lần xuất hiện sự kiện, v.v.

INFO - mức tối thiểu để sử dụng sản xuất/vận chuyển; ghi lại dữ liệu có thể hữu ích trong điều tra pháp y và để xác nhận kết quả thành công ("lưu trữ 999 mục trong DB OK"); tất cả thông tin ở đây phải như vậy mà bạn sẽ được OK với người dùng cuối/khách hàng nhìn thấy nó và gửi cho bạn nó, nếu cần (không có bí mật, không thô tục!)

WARN - không phải là một mức độ lỗi như vậy, nhưng hữu ích khi biết hệ thống có thể xâm nhập vào lãnh thổ tinh ranh, vd công cụ logic kinh doanh như "số lượng sản phẩm đã đặt hàng < 0" cho thấy lỗi ở đâu đó, nhưng không phải là ngoại lệ của hệ thống; Tôi có xu hướng không sử dụng nó nhiều để thành thật, việc tìm kiếm những thứ có xu hướng tự nhiên phù hợp hơn với INFO hoặc ERROR

ERROR - sử dụng điều này cho trường hợp ngoại lệ (trừ khi có lý do chính đáng để giảm WARN hoặc INFO); ghi lại stacktraces đầy đủ cùng với các giá trị biến quan trọng mà không có chẩn đoán là không thể; chỉ sử dụng cho các lỗi ứng dụng/hệ thống, chứ không phải xấu hoàn cảnh logic kinh doanh

Fatal - chỉ sử dụng cho một lỗi của mức độ nghiêm trọng cao như vậy mà nó theo nghĩa đen ngăn chặn các ứng dụng từ bắt đầu/tiếp tục

Ngoài ra - xem xét khai thác gỗ của bạn thông thường, cả hai mức DEBUG và INFO đều hoạt động, bạn muốn có thể theo dõi một câu chuyện hay thông qua các sự kiện nổi bật dễ tìm, và để đảm bảo rằng bạn không làm bất cứ điều gì quá chi tiết, làm giảm khả năng đọc.

Đồng thời đảm bảo bạn sử dụng mẫu để dẫn đến các cột gọn gàng cho những thứ như dấu thời gian, nguồn cấp và mức độ nghiêm trọng - một lần nữa, nó giúp khả năng đọc ồ ạt.

Answer 3

tôi mất

• Fatal: Chương trình này là trong một nhà nước mà không thể được xử lý và phải được chấm dứt (tự động hoặc bởi người sử dụng).
• Lỗi: Hoạt động của chương trình không thành công theo cách mà người dùng có thể phát hiện (không thể lưu thay đổi/tệp không đọc), nhưng chương trình vẫn có thể hoạt động (thử tải tệp khác).
• Cảnh báo: Đã xảy ra sự cố nhưng người dùng không nhận thấy thông báo (máy chủ không trả lời được ping; có thể khi máy chủ đó cần thiết sẽ gây ra lỗi/gây tử vong)
• Thông tin: Hành động của người dùng/chính hành động chương trình (tệp được tải, sao lưu tự động được lưu trữ).
• Gỡ lỗi: Truy tìm thông tin. Phần nào của chương trình đang chạy, mà là những giá trị của các thông số

Answer 4

Đây là những gì công ty của tôi đề nghị:

TRACE - Tin nhắn có lẽ chỉ hữu ích trong chu kỳ phát triển, và có thể tạo ra quá thường xuyên để sử dụng phù hợp trong sản xuất. Ví dụ: nếu tôi đang ghi nhật ký giá trị trung gian trong vòng lặp bên trong, tôi sẽ sử dụng TRACE.

DEBUG - Thư được sử dụng để ghi lại các bước khác nhau trong hoạt động bình thường của máy chủ. Thông thường những điều này sẽ được nhắm vào các nhà phát triển chứ không phải là nhân viên hoạt động.

INFO - Thư có tính chất tích cực hoặc trung tính mà chúng tôi dự kiến ​​sẽ đăng nhập vào môi trường sản xuất. Nên có ý nghĩa cho nhân viên điều hành.

WARN - Thông báo cho biết điều kiện có thể gây nguy hiểm cho khả năng của máy chủ phản hồi yêu cầu một cách chính xác và kịp thời.

ERROR - Thông báo cho biết hành vi hoặc điều kiện bất ngờ.

FATAL - Thông báo cho biết hành vi hoặc điều kiện không mong muốn khiến cho quá trình đăng ký tiếp tục không thể hoặc nguy hiểm.

Chúng tôi hy vọng các bản ghi trong quá trình sản xuất sẽ được đặt ở INFO và chúng tôi hy vọng chúng sẽ được đọc bởi những người không phải là nhà phát triển. Nét đặc trưng của thông điệp log là cả một cuộc trò chuyện khác ...

Answer 5

Tôi đang sử dụng một cách tiếp cận đơn giản hơn:

• DEBUG: tắt trong sản xuất, do đó chủ yếu được sử dụng bởi các nhà phát triển để đăng nhập truy vấn nhất định , timings, giá trị tham số, vv

• INFO: Đăng nhập tất cả mọi thứ để bạn biết khi nhìn lại tất cả mọi thứ để giải thích như thế nào kết quả của bạn đã được tính toán và do đó bạn có thể sửa lỗi

• LỖI: Tất cả những gì cần ai đó (nhà phát triển/hoạt động) chú ý

tôi không sử dụng WARN, bởi vì không ai bao giờ lọc tất cả các file log cho WARN tin nhắn. Nếu nó là quan trọng, sau đó nó là L ERI (và ai đó phải quan tâm đến nó), nếu không, nó là INFO (và không ai quan tâm đến nó cho đến khi có một vấn đề). Tương tự cho FATAL.

Tôi cũng không sử dụng TRACE. Mọi thứ tôi cần biết trong quá trình phát triển đều là DEBUG.

Answer 6

Nếu bạn đang tìm kiếm một đề xuất đơn giản được hỗ trợ bởi ngành, tại sao không chỉ xem xét triển khai/tài liệu đơn giản trong ngành?

Chúng tôi sử dụng một API logback/log4j như một logging level guide => mà làm cho nó đơn giản/tài liệu/hỗ trợ bởi ngành công nghiệp:

• Cấp ALL có cấp bậc thấp nhất có thể và được thiết kế để bật tất cả đăng nhập.

• Cấp DEBUG chỉ định các sự kiện thông tin chi tiết hữu ích nhất để gỡ lỗi ứng dụng.

• Cấp ERROR chỉ định các sự kiện lỗi có thể vẫn cho phép ứng dụng tiếp tục chạy.

• Cấp FATAL chỉ định các sự kiện lỗi rất nghiêm trọng có thể dẫn đến ứng dụng bị hủy.

• Cấp INFO chỉ định thông báo mang tính thông tin làm nổi bật tiến độ của ứng dụng ở cấp độ chi tiết.

• Cấp TẮT có xếp hạng cao nhất có thể và được thiết kế để tắt ghi nhật ký.

• Cấp TRACE chỉ định các sự kiện thông tin các tinh chỉnh so với DEBUG

• Cấp WARN chỉ định các tình huống nguy hiểm tiềm tàng.