Mức ghi nhật ký - Logback - quy tắc ngón tay cái để gán mức ghi nhật ký

Tôi đang sử dụng logback trong dự án hiện tại của tôi.

Nó cung cấp sáu cấp ghi nhật ký: TRACE DEBUG INFO WARN ERROR OFF

Tôi đang tìm một quy tắc để xác định mức độ nhật ký cho các hoạt động chung. Chẳng hạn, nếu một luồng bị khóa, thông điệp tường trình sẽ được đặt thành mức gỡ lỗi hoặc mức thông tin. Hoặc nếu một socket đang được sử dụng, id cụ thể của nó sẽ được ghi lại ở mức gỡ lỗi hoặc mức theo dõi.

Tôi sẽ đánh giá cao câu trả lời với nhiều ví dụ cho mỗi cấp độ đăng nhập.

Tôi chủ yếu xây dựng các hệ thống quy mô lớn, tính sẵn sàng cao, vì vậy câu trả lời của tôi thiên về việc xem xét nó từ quan điểm hỗ trợ sản xuất; Điều đó nói rằng, chúng tôi chỉ định đại khái như sau:

• lỗi : hệ thống gặp sự cố, khách hàng có thể bị ảnh hưởng (hoặc sẽ sớm bị) và việc khắc phục có thể cần sự can thiệp của con người. "Quy tắc 2AM" áp dụng tại đây - nếu bạn đang gọi, bạn có muốn thức dậy lúc 2 giờ sáng nếu tình trạng này xảy ra không? Nếu có, sau đó đăng nhập nó là "lỗi".

• cảnh báo : một sự kiện kỹ thuật hoặc kinh doanh bất ngờ đã xảy ra, khách hàng có thể bị ảnh hưởng, nhưng có lẽ không cần sự can thiệp của con người ngay lập tức. Khi có cuộc gọi, mọi người sẽ không được gọi ngay lập tức, nhưng nhân viên hỗ trợ sẽ muốn xem xét các vấn đề này càng sớm càng tốt để hiểu tác động là gì. Về cơ bản bất kỳ vấn đề nào cần được theo dõi nhưng có thể không cần can thiệp ngay.

• Thông tin : những điều chúng ta muốn thấy với khối lượng lớn trong trường hợp chúng ta cần phân tích pháp y một vấn đề. Các sự kiện vòng đời hệ thống (bắt đầu hệ thống, dừng) tại đây. Các sự kiện vòng đời "Phiên" (đăng nhập, đăng xuất, v.v.) tại đây. Các sự kiện ranh giới quan trọng cũng nên được xem xét (ví dụ: các cuộc gọi cơ sở dữ liệu, các cuộc gọi API từ xa). Các ngoại lệ kinh doanh điển hình có thể xuất hiện ở đây (ví dụ: đăng nhập thất bại do thông tin xấu). Bất kỳ sự kiện nào khác mà bạn nghĩ rằng bạn sẽ cần phải xem trong sản xuất với khối lượng lớn tại đây.

• gỡ lỗi : chỉ về tất cả mọi thứ không làm cho "thông tin" bị cắt ... bất kỳ thông điệp nào hữu ích trong việc theo dõi dòng chảy qua hệ thống và cách ly các vấn đề, đặc biệt là trong giai đoạn phát triển và QA. Chúng tôi sử dụng nhật ký mức "gỡ lỗi" cho mục nhập / thoát của hầu hết các phương thức không tầm thường và đánh dấu các sự kiện và điểm quyết định thú vị bên trong các phương thức.

• theo dõi : chúng tôi không sử dụng điều này thường xuyên, nhưng điều này sẽ dành cho nhật ký khối lượng cực kỳ chi tiết và có khả năng cao mà bạn thường không muốn bật ngay cả trong quá trình phát triển bình thường. Các ví dụ bao gồm việc hủy một hệ thống phân cấp đối tượng đầy đủ, ghi lại một số trạng thái trong mỗi lần lặp của một vòng lặp lớn, v.v.

Vì hoặc quan trọng hơn việc chọn các mức nhật ký phù hợp là đảm bảo rằng các nhật ký có ý nghĩa và có bối cảnh cần thiết. Ví dụ: hầu như bạn sẽ luôn muốn bao gồm ID luồng trong nhật ký để bạn có thể theo dõi một chuỗi nếu cần. Bạn cũng có thể muốn sử dụng một cơ chế để liên kết thông tin doanh nghiệp (ví dụ: ID người dùng) với chuỗi để nó cũng được ghi lại. Trong thông điệp tường trình của bạn, bạn sẽ muốn bao gồm đủ thông tin để đảm bảo tin nhắn có thể được thực thi. Một nhật ký như "ngoại lệ FileNotFound bị bắt" không hữu ích lắm. Một thông báo tốt hơn là "ngoại lệ FileNotFound bị bắt trong khi cố gắng mở tệp cấu hình: /usr/local/app/somefile.txt. UserId = 12344."

Ngoài ra còn có một số hướng dẫn ghi nhật ký tốt ngoài đó ... ví dụ: đây là đoạn trích được chỉnh sửa từ JCL (Nhật ký Jakarta Commons) :

• lỗi - Lỗi thời gian chạy khác hoặc điều kiện không mong muốn. Hy vọng những thứ này sẽ được hiển thị ngay lập tức trên bảng điều khiển trạng thái.
• cảnh báo - Sử dụng API không dùng nữa, sử dụng API kém, lỗi 'gần như', các tình huống thời gian chạy khác không mong muốn hoặc không mong muốn, nhưng không nhất thiết là "sai". Hy vọng những thứ này sẽ được hiển thị ngay lập tức trên bảng điều khiển trạng thái.
• thông tin - Các sự kiện thời gian chạy thú vị (khởi động / tắt máy). Hy vọng những thứ này sẽ được hiển thị ngay lập tức trên bảng điều khiển, vì vậy hãy thận trọng và giữ ở mức tối thiểu.
• gỡ lỗi - thông tin chi tiết về dòng chảy qua hệ thống. Hy vọng những điều này sẽ được ghi vào nhật ký.
• theo dõi - thông tin chi tiết hơn. Hy vọng những điều này sẽ được ghi vào nhật ký.

Cách tiếp cận của tôi, tôi nghĩ đến từ một sự phát triển hơn là quan điểm hoạt động, là:

• Lỗi có nghĩa là việc thực hiện một số nhiệm vụ không thể hoàn thành; một email không thể được gửi, một trang không thể được hiển thị, một số dữ liệu không thể được lưu trữ vào cơ sở dữ liệu, đại loại như thế. Một cái gì đó chắc chắn đã đi sai.
• Cảnh báo có nghĩa là một cái gì đó bất ngờ đã xảy ra, nhưng việc thực thi đó có thể tiếp tục, có lẽ ở chế độ xuống cấp; một tệp cấu hình bị thiếu nhưng mặc định đã được sử dụng, giá được tính là âm, do đó, nó được giữ ở mức 0, v.v ... Có gì đó không đúng, nhưng nó vẫn chưa chính xác - cảnh báo thường là một dấu hiệu cho thấy sẽ có một lỗi rất sớm.
• Thông tin có nghĩa là một cái gì đó bình thường nhưng có ý nghĩa đã xảy ra; hệ thống bắt đầu, hệ thống dừng lại, công việc cập nhật hàng tồn kho hàng ngày đã chạy, v.v. Không nên có một torrent liên tục trong số này, nếu không thì có quá nhiều thứ để đọc.
• Gỡ lỗi có nghĩa là một cái gì đó bình thường và không đáng kể đã xảy ra; một người dùng mới đã đến trang web, một trang được hiển thị, một đơn đặt hàng đã được thực hiện, một mức giá đã được cập nhật. Đây là thứ được loại trừ khỏi thông tin vì sẽ có quá nhiều.
• Dấu vết là thứ tôi chưa bao giờ thực sự sử dụng.

Điều này cũng có thể giúp ích một cách hữu hình, để hiểu nếu một yêu cầu ghi nhật ký (từ mã) ở một mức nhất định sẽ dẫn đến việc nó thực sự được ghi lại với mức ghi nhật ký hiệu quả mà việc triển khai được cấu hình. Quyết định mức độ hiệu quả mà bạn muốn định cấu hình bạn triển khai với các Câu trả lời khác ở đây và sau đó tham khảo điều này để xem nếu một yêu cầu ghi nhật ký cụ thể từ mã của bạn có thực sự được ghi lại không ...

Ví dụ :

• "Liệu một dòng mã đăng nhập ghi nhật ký tại WARN có thực sự được ghi lại khi triển khai của tôi được cấu hình với ERROR không?" Bảng nói, KHÔNG.
• "Liệu một dòng mã đăng nhập mà đăng nhập tại WARN có thực sự được ghi lại khi triển khai của tôi được cấu hình với DEBUG không?" Bảng nói, CÓ.

từ tài liệu đăng nhập lại :

Theo một cách đồ họa hơn, đây là cách quy tắc lựa chọn hoạt động. Trong bảng sau, tiêu đề dọc hiển thị mức độ của yêu cầu ghi nhật ký, được chỉ định bởi p, trong khi tiêu đề ngang hiển thị mức hiệu quả của trình ghi nhật ký, được chỉ định bởi q. Giao điểm của các hàng (yêu cầu mức) và cột (mức hiệu quả) là kết quả boolean từ quy tắc lựa chọn cơ bản.

Vì vậy, một dòng mã yêu cầu ghi nhật ký sẽ chỉ thực sự được ghi lại nếu mức ghi nhật ký hiệu quả của việc triển khai của nó nhỏ hơn hoặc bằng mức độ nghiêm trọng được yêu cầu của dòng mã đó .

Tôi trả lời điều này đến từ một kiến ​​trúc dựa trên thành phần, trong đó một tổ chức có thể đang chạy nhiều thành phần có thể dựa vào nhau. Trong một thất bại lan truyền, mức ghi nhật ký sẽ giúp xác định cả hai thành phần nào bị ảnh hưởng và nguyên nhân gốc.

• LRI - Thành phần này đã bị lỗi và nguyên nhân được cho là nội bộ (bất kỳ ngoại lệ nào, ngoại lệ chưa xử lý, không phụ thuộc được đóng gói ... ví dụ: cơ sở dữ liệu, ví dụ REST sẽ nhận được lỗi 4xx từ phụ thuộc). Đưa tôi (người bảo trì thành phần này) ra khỏi giường.

• WARN - Thành phần này có lỗi được cho là do thành phần phụ thuộc (ví dụ REST sẽ là trạng thái 5xx từ phụ thuộc). Lấy những người bảo trì thành phần THAT ra khỏi giường.

• THÔNG TIN - Bất cứ điều gì khác mà chúng tôi muốn nhận được cho một nhà điều hành. Nếu bạn quyết định đăng nhập đường dẫn hạnh phúc thì tôi khuyên bạn nên giới hạn 1 thông điệp tường trình cho mỗi hoạt động quan trọng (ví dụ: mỗi yêu cầu http đến).

Đối với tất cả các thông điệp tường trình, hãy đảm bảo ghi nhật ký ngữ cảnh hữu ích (và ưu tiên làm cho thông điệp có thể đọc được / hữu ích hơn là có các "mã lỗi")

• DEBUG (và bên dưới) - Không nên sử dụng tất cả (và chắc chắn không có trong sản xuất). Trong quá trình phát triển, tôi sẽ khuyên bạn nên sử dụng kết hợp TDD và Gỡ lỗi (khi cần thiết) thay vì mã gây ô nhiễm với các báo cáo nhật ký. Trong sản xuất, ghi nhật ký INFO ở trên, kết hợp với các số liệu khác là đủ.

Một cách hay để hình dung các mức ghi nhật ký ở trên là tưởng tượng một bộ màn hình giám sát cho từng thành phần. Khi tất cả chạy tốt, chúng có màu xanh lá cây, nếu một thành phần ghi lại CẢNH BÁO thì nó sẽ chuyển sang màu cam (màu hổ phách) nếu bất cứ thứ gì ghi lại LRI thì nó sẽ chuyển sang màu đỏ.

Trong trường hợp xảy ra sự cố, bạn nên để một thành phần (nguyên nhân gốc) chuyển sang màu đỏ và tất cả các thành phần bị ảnh hưởng sẽ chuyển sang màu cam / hổ phách.

Không khác nhau cho các câu trả lời khác, khung của tôi có các cấp độ gần như giống nhau:

1. Lỗi: lỗi logic nghiêm trọng trên ứng dụng, như thời gian chờ kết nối cơ sở dữ liệu. Những điều cần sửa lỗi trong tương lai gần
2. Cảnh báo: các vấn đề không phá vỡ, nhưng công cụ cần chú ý. Giống như một trang được yêu cầu không tìm thấy
3. Thông tin: được sử dụng trong dòng đầu tiên của hàm / phương thức, để hiển thị một quy trình đã được gọi hoặc một bước đã ổn, giống như một truy vấn chèn được thực hiện
4. log: thông tin logic, giống như kết quả của câu lệnh if
5. gỡ lỗi: nội dung biến có liên quan để được xem vĩnh viễn