Tại sao mức TRACE tồn tại và khi nào tôi nên sử dụng nó chứ không phải DEBUG?

Trong Log4J, Slf4J và một vài khung ghi nhật ký khác trong Java, bạn có hai mức "nhà phát triển" để ghi nhật ký:

• GỬI
• TRACE

Tôi hiểu DEBUG làm gì, vì lời giải thích rất rõ ràng:

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

Nhưng mức TRACE không cụ thể lắm về trường hợp sử dụng của nó:

Cấp độ TRACE chỉ định các sự kiện thông tin chi tiết hơn DEBUG

(Nguồn: log4J JavaDoc )

Điều này không cho tôi biết làm thế nào hoặc khi nào sử dụng TRACE. Thật thú vị, đây không phải là mức độ nghiêm trọng được xác định trong tiêu chuẩn nhật ký hệ thống . Googling cho sự khác biệt giữa TRACE và DEBUG dường như chỉ quay trở lại "sử dụng DEBUG, ồ, và cũng có TRACE". Tôi không thể tìm thấy trường hợp sử dụng cụ thể cho cấp độ TRACE. Điều tốt nhất tôi có thể tìm thấy là trang wiki cũ này đang tranh luận về sự tồn tại của cấp độ.

Điều này, với tư cách là một kiến ​​trúc sư, đưa ra rất nhiều cờ và câu hỏi trong đầu tôi. Nếu một nhà phát triển trẻ yêu cầu tôi thêm TRACE vào kiến ​​trúc của mình, tôi sẽ bắn phá anh ta bằng các câu hỏi:

• Một số ví dụ về thông tin nên được ghi lại bằng TRACE chứ không phải với DEBUG là gì?
• Vấn đề cụ thể nào tôi giải quyết bằng cách đăng nhập thông tin đó?
• Trong các ví dụ đó, các thuộc tính của thông tin được ghi lại phân biệt rõ ràng giữa việc ghi nhật ký ở cấp TRACE thay vì cấp DEBUG là gì?
• Tại sao thông tin đó phải đi qua cơ sở hạ tầng đăng nhập?
  • Những lợi ích của việc lưu giữ thông tin trong nhật ký nhật ký thay vì chỉ sử dụng là System.out.printlngì?
  • Tại sao tốt hơn là sử dụng nhật ký cho việc này chứ không phải là trình gỡ lỗi?
• Điều gì sẽ là một ví dụ điển hình của việc đăng nhập ở cấp độ TRACE?
  • Những lợi ích cụ thể đã đạt được bằng cách đăng nhập ở cấp độ TRACE thay vì DEBUG trong ví dụ là gì?
  • Tại sao những lợi ích quan trọng?
  • Ngược lại: Tôi đã tránh được những vấn đề gì khi đăng nhập tại TRACE thay vì DEBUG?
  • Làm thế nào khác tôi có thể giải quyết những vấn đề? Tại sao đăng nhập ở cấp TRACE tốt hơn các giải pháp khác?
• Có nên để lại câu lệnh log mức TRACE trong mã sản xuất không? Tại sao?

Nhưng cho rằng nó có mặt trong hầu hết các khung chính, tôi đoán nó có ích cho việc gì không? Vậy ... TRACE để làm gì và phân biệt nó với DEBUG là gì?

Ví dụ về thông tin nên được ghi lại bằng TRACE chứ không phải với DEBUG là gì?

Nếu tôi có một thuật toán trải qua một loạt các bước, cấp độ theo dõi sẽ in thông tin về từng bước đó ở cấp độ tốt nhất. Những thứ như đầu vào và đầu ra theo nghĩa đen của mỗi bước.

Nói chung, theo dõi sẽ bao gồm tất cả các gỡ lỗi (giống như gỡ lỗi bao gồm tất cả các cảnh báo và lỗi).

Vấn đề cụ thể nào tôi giải quyết bằng cách đăng nhập thông tin đó?

Bạn cần phải gỡ lỗi cái gì mà kết quả đầu ra cách quá nhiều dữ liệu để đăng nhập bên ngoài của một xây dựng cụ thể khi bạn đang nhắm mục tiêu mà điều đặc biệt và không quan tâm về các lỗi hoặc thông tin đăng nhập khác (kể từ khi khối lượng thông tin dấu vết sẽ che khuất chúng). Trong một số loggers, bạn sẽ biến một mô-đun nhất định lên chỉ theo dõi cấp độ.

Trong các ví dụ đó, các thuộc tính của thông tin được ghi lại phân biệt rõ ràng giữa việc ghi nhật ký ở cấp TRACE thay vì cấp DEBUG là gì?

Nói chung, ghi nhật ký mức theo dõi không thể được bật trong thời gian duy trì vì nó làm giảm hiệu năng của ứng dụng rất nhiều và / hoặc tạo ra sự phong phú của dữ liệu nhật ký không bền vững do các ràng buộc về đĩa / băng thông.

Ghi nhật ký mức gỡ lỗi thường có thể được bật trong một thời gian dài hơn mà không làm cho ứng dụng không thể sử dụng được.

Tại sao thông tin đó phải đi qua cơ sở hạ tầng đăng nhập?

Nó không phải. Một số khung có một tracelogger riêng.

Thông thường, nó kết thúc trong các bản ghi vì traceloggers và logger bình thường có nhu cầu tương tự liên quan đến việc ghi vào đĩa / mạng, xử lý lỗi, xoay vòng bản ghi, v.v.

Tại sao tốt hơn là sử dụng nhật ký cho việc này chứ không phải là trình gỡ lỗi?

Bởi vì trình gỡ lỗi có thể không thể đính kèm vào máy gặp sự cố. Bạn có thể không biết đủ để biết nơi thậm chí đặt điểm dừng hoặc bước qua mã. Bạn có thể không thể tái tạo một cách đáng tin cậy lỗi trong trình gỡ lỗi, vì vậy hãy sử dụng nhật ký để bắt lỗi "nếu nó xảy ra".

Nhưng họ chỉ là tên. Giống như bất kỳ nhãn hiệu nào khác, chúng chỉ là tên mọi người đặt lên mọi thứ và thường sẽ có nghĩa là những thứ khác nhau cho những người khác nhau. Và bản thân nhãn ít quan trọng hơn các bit thịt mà nhãn đề cập đến.

Lưu ý đặc biệt rằng slf4j đặc biệt khuyên bạn không nên sử dụng dấu vết ( http://slf4j.org/faq.html#trace ):

Nói tóm lại, mặc dù chúng tôi vẫn không khuyến khích sử dụng cấp độ TRACE vì các lựa chọn thay thế tồn tại hoặc vì trong nhiều trường hợp, các yêu cầu nhật ký của cấp độ TRACE là lãng phí, do mọi người cứ yêu cầu, chúng tôi quyết định đáp ứng nhu cầu phổ biến.

Cá nhân, kỳ vọng của tôi sẽ là theo dõi để ghi nhật ký mọi thứ (ví dụ: ngay cả những thứ như "đã nhập hàm MyFunc với các đối số A, B, C tại thời điểm Y"). Nhược điểm của điều này là không chỉ gây ồn ào vô cùng mà còn có xu hướng gây ra các vấn đề về không gian đĩa; Tôi hy vọng việc đăng nhập như vậy sẽ bị vô hiệu hóa trong các hoạt động bình thường. Ưu điểm là điều này cung cấp cho bạn một mức thông tin tương tự như những gì bạn sẽ nhận được khi bước qua chương trình của mình trong trường hợp đính kèm trình gỡ lỗi có thể ít thực tế hơn.

Nói chung, tôi thấy rằng dấu vết thường là nỗ lực nhiều hơn so với các phương pháp khác.

Mức độ gỡ lỗi nói chung là hoàn toàn tùy ý và có thể khác nhau giữa các ngôn ngữ, thư viện và công ty.

Điều đó đang được nói, đây là cách tôi đã thấy chúng được sử dụng:

TRACE: được sử dụng để hiển thị luồng chương trình mức logic. Đã nhập một chức năng? Có phải một câu lệnh "nếu" chọn nhánh chính hoặc "khác" không? Đó là một ứng cử viên cho dấu vết. Nói cách khác, ghi nhật ký theo dõi thường được sử dụng để chỉ định "bạn đang ở đây". Điều này hữu ích trong ngữ cảnh của câu lệnh ghi nhật ký khác có thể ghi lại lỗi hoặc thông tin khác. Ghi nhật ký theo dõi có thể giúp xác định vị trí, trong mã, lỗi hoặc sự kiện khác được ghi ở cấp độ khác.

DEBUG: được sử dụng để đổ trạng thái biến, mã lỗi cụ thể, v.v. Ví dụ: một dịch vụ web có thể trả về mã lỗi 809214, có thể được ghi lại trong khi ứng dụng báo cho người dùng "giao tiếp không thành công". Hãy tưởng tượng một nhà phát triển nhận được nhật ký từ hệ thống của người dùng rất lâu sau khi xảy ra lỗi và tự hỏi " tại sao lại xảy ra lỗi?" đó là một điều tốt để đăng nhập ở cấp độ gỡ lỗi. Một ví dụ khác có thể là nếu một lỗi tiếp tục xảy ra trong sản xuất nhưng khó tái tạo, gỡ lỗi ghi nhật ký một số biến hoặc sự kiện trong mô-đun rắc rối để giúp thông báo cho nhà phát triển trạng thái chương trình khi xảy ra lỗi để giúp khắc phục sự cố.

Thông thường người ta sẽ cấu hình ứng dụng để đăng nhập ở một mức nhất định (hoặc cao hơn). Ví dụ, theo dõi thường là mức thấp nhất: đăng nhập ở cấp đó ghi lại mọi thứ. Mức gỡ lỗi sẽ bỏ qua dấu vết nhưng bao gồm các mức cao (ví dụ: cảnh báo và lỗi).

Lợi ích của việc phân tách các cấp độ nhật ký là kiểm soát số lượng nhật ký. Đối với một ứng dụng phức tạp, ghi nhật ký theo dõi có thể có khả năng ghi lại một lượng dữ liệu khổng lồ, phần lớn thời gian đó vô dụng. Tốt nhất là chỉ ghi nhật ký thông tin quan trọng (có thể là một số thông tin khởi động, sau đó chỉ là lỗi) trừ khi người ta cố gắng tìm hiểu cách gây ra lỗi. Hơn nữa, điều này thường chỉ hữu ích trong môi trường sản xuất là trình gỡ lỗi và các công cụ phát triển khác không có mặt.

Không có giới hạn thực sự về điều này, không có quy tắc nào nói rằng bạn phải đăng nhập một cách nhất định. Chỉ những quy ước rộng mà một số thư viện hoặc ứng dụng có thể hoặc không thể tuân theo.

Tôi nghĩ rằng câu trả lời tuyệt vời của Telastyn có thể được tóm tắt theo quy tắc ngắn của tôi:

• DEBUG đăng nhập phải có thể được sử dụng trong sản xuất (nhưng có xu hướng vẫn tắt bình thường)
• TRACE ghi nhật ký được phép sao cho sử dụng nó trong sản xuất (ngoài một phiên cụ thể / ngắn) là không khả thi

Đây là quy tắc của tôi

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

Giả định đằng sau điều này là nhóm ops sẽ

• luôn luôn đặt sản xuất thành thông tin cấp độ nhật ký
• có thể có bộ sản xuất được gỡ lỗi ở mức log
• không bao giờ có sản xuất được đặt thành theo dõi mức log

Với giả định đó, đây là cách bạn, với tư cách là nhà phát triển, có thể sử dụng các mức nhật ký ...

Vấn đề # 1) không làm chậm hiệu suất sản xuất quá nhiều

debuggiải quyết # 1. Đó là bạn, với tư cách là nhà phát triển, cố gắng hết sức để cân bằng thông tin bạn có thể cần trong quá trình sản xuất mà không có quá nhiều tiếng ồn, bạn làm chậm máy. Bạn đang nói "đó là một ý tưởng tốt để liên tục đăng nhập này trong sản xuất (nếu bạn muốn)."

Vấn đề # 2) có thông tin dài dòng trong khi phát triển

tracegiải quyết vấn đề # 2. Bạn hoàn toàn không quan tâm đến tác động của nó đối với máy sản xuất, nhưng bạn cần thông tin đó ngay bây giờ trong khi phát triển mã. Bạn đang nói "Tôi không hứa rằng sẽ luôn luôn ghi thông tin này vào sản xuất."

Cấp (như những người khác đã nói), những điều này là tùy ý; vì vậy chỉ cần đảm bảo nhóm phát triển của bạn (và ops / nhóm giám sát - bởi vì họ cũng là người dùng đăng nhập của bạn) đồng ý về điều gì đó.

Điều gì sẽ là một ví dụ điển hình của việc đăng nhập ở cấp độ TRACE?

Nhật ký ENTRY / EXIT từ một phương thức. Các nhật ký này giúp bạn theo dõi dòng chảy của chương trình và có xu hướng rất hữu ích khi:

1. Chương trình đột ngột gặp sự cố - bạn biết chính xác chức năng mà nó bị hỏng bằng cách nhìn vào dòng cuối cùng của nhật ký

2. Một số chức năng giả mạo âm thầm thất bại bằng cách hấp thụ một ngoại lệ

Họ đảm bảo một mức TRACE riêng thay vì chỉ sử dụng DEBUG vì việc kích hoạt nhật ký ENTRY / EXIT cho mọi phương thức trong cơ sở mã của bạn sẽ tạo ra một số lượng lớn các nhật ký bổ sung không hợp lý để luôn luôn bật , ngay cả trong ngữ cảnh DEBUG.