Khi nào nên sử dụng các cấp độ nhật ký khác nhau

Có nhiều cách khác nhau để ghi nhật ký tin nhắn, theo thứ tự tử vong:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Làm thế nào để tôi quyết định khi sử dụng mà?

Heuristic tốt để sử dụng là gì?

Tôi thường đăng ký theo quy ước sau:

• Dấu vết - Chỉ khi tôi sẽ "truy tìm" mã và cố gắng tìm một phần cụ thể của hàm.
• Gỡ lỗi - Thông tin hữu ích về mặt chẩn đoán cho mọi người hơn là chỉ các nhà phát triển (CNTT, sysadins, v.v.).
• Thông tin - Thông tin hữu ích để ghi nhật ký (bắt đầu / dừng dịch vụ, giả định cấu hình, v.v.). Thông tin Tôi muốn luôn có sẵn nhưng thường không quan tâm trong các trường hợp thông thường. Đây là mức cấu hình ngoài luồng của tôi.
• Cảnh báo - Bất cứ điều gì có khả năng gây ra sự kỳ quặc cho ứng dụng, nhưng tôi sẽ tự động phục hồi. (Chẳng hạn như chuyển từ máy chủ chính sang máy chủ dự phòng, thử lại thao tác, thiếu dữ liệu thứ cấp, v.v.)
• Lỗi - Bất kỳ lỗi nào gây tử vong cho hoạt động , nhưng không phải là dịch vụ hoặc ứng dụng (không thể mở tệp yêu cầu, thiếu dữ liệu, v.v.). Những lỗi này sẽ buộc người dùng (quản trị viên hoặc người dùng trực tiếp) can thiệp. Chúng thường được dành riêng (trong ứng dụng của tôi) cho các chuỗi kết nối không chính xác, các dịch vụ bị thiếu, v.v.
• Gây tử vong - Bất kỳ lỗi nào buộc phải tắt dịch vụ hoặc ứng dụng để tránh mất dữ liệu (hoặc mất thêm dữ liệu). Tôi chỉ bảo lưu những lỗi này cho những lỗi và tình huống khủng khiếp nhất được bảo đảm là đã bị hỏng hoặc mất dữ liệu.

Bạn có muốn nhắn tin để đưa một quản trị viên hệ thống ra khỏi giường vào giữa đêm không?

• có -> lỗi
• không -> cảnh báo

Tôi thấy hữu ích hơn khi nghĩ về mức độ nghiêm trọng từ góc độ xem tệp nhật ký.

Gây tử vong / quan trọng : Ứng dụng tổng thể hoặc lỗi hệ thống cần được điều tra ngay lập tức. Vâng, đánh thức SysAdmin. Vì chúng tôi thích cảnh báo SysAdmins của chúng tôi và được nghỉ ngơi tốt, mức độ nghiêm trọng này nên được sử dụng rất ít khi. Nếu nó xảy ra hàng ngày và đó không phải là BFD, thì nó sẽ mất đi ý nghĩa của nó. Thông thường, một lỗi nghiêm trọng chỉ xảy ra một lần trong vòng đời của quy trình, vì vậy nếu tệp nhật ký được gắn với quy trình, đây thường là thông báo cuối cùng trong nhật ký.

Lỗi : Chắc chắn là một vấn đề cần được điều tra. SysAdmin sẽ được thông báo tự động, nhưng không cần phải kéo ra khỏi giường. Bằng cách lọc nhật ký để xem xét các lỗi và ở trên, bạn có được cái nhìn tổng quan về tần suất lỗi và có thể nhanh chóng xác định lỗi khởi tạo có thể dẫn đến một loạt các lỗi bổ sung. Theo dõi tỷ lệ lỗi so với việc sử dụng ứng dụng có thể mang lại các số liệu chất lượng hữu ích như MTBF có thể được sử dụng để đánh giá chất lượng tổng thể. Ví dụ: số liệu này có thể giúp thông báo các quyết định về việc có cần một chu kỳ thử nghiệm beta khác trước khi phát hành hay không.

Cảnh báo : MIGHT này có vấn đề, hoặc có thể không. Ví dụ: các điều kiện môi trường thoáng qua dự kiến ​​như mất kết nối mạng hoặc cơ sở dữ liệu ngắn phải được ghi lại dưới dạng Cảnh báo, không phải Lỗi. Xem nhật ký được lọc để chỉ hiển thị các cảnh báo và lỗi có thể cung cấp cái nhìn sâu sắc nhanh chóng về các gợi ý sớm ở nguyên nhân gốc của lỗi tiếp theo. Cảnh báo nên được sử dụng một cách tiết kiệm để chúng không trở nên vô nghĩa. Ví dụ: mất quyền truy cập mạng phải là một cảnh báo hoặc thậm chí là lỗi trong ứng dụng máy chủ, nhưng có thể chỉ là Thông tin trong ứng dụng dành cho máy tính để bàn được thiết kế cho người dùng máy tính xách tay thỉnh thoảng bị ngắt kết nối.

Thông tin : Đây là thông tin quan trọng cần được ghi lại trong các điều kiện bình thường như khởi tạo thành công, bắt đầu và dừng dịch vụ hoặc hoàn thành thành công các giao dịch quan trọng. Xem nhật ký hiển thị Thông tin trở lên sẽ cung cấp tổng quan nhanh về các thay đổi trạng thái chính trong quy trình cung cấp ngữ cảnh cấp cao nhất để hiểu bất kỳ cảnh báo hoặc lỗi nào cũng xảy ra. Đừng có quá nhiều thông tin. Chúng tôi thường có <5% thông tin Thông tin liên quan đến Dấu vết.

Trace : Trace cho đến nay là mức độ nghiêm trọng được sử dụng phổ biến nhất và nên cung cấp ngữ cảnh để hiểu các bước dẫn đến lỗi và cảnh báo. Có mật độ đúng của các thông điệp Trace làm cho phần mềm dễ bảo trì hơn nhiều nhưng đòi hỏi sự siêng năng vì giá trị của các câu lệnh Trace riêng lẻ có thể thay đổi theo thời gian khi các chương trình phát triển. Cách tốt nhất để đạt được điều này là bằng cách đưa nhóm phát triển theo thói quen thường xuyên xem xét nhật ký như một phần tiêu chuẩn để khắc phục sự cố được báo cáo của khách hàng. Khuyến khích nhóm cắt tỉa các tin nhắn Trace không còn cung cấp ngữ cảnh hữu ích và thêm các tin nhắn cần thiết để hiểu ngữ cảnh của các tin nhắn tiếp theo. Ví dụ, thường hữu ích khi ghi nhật ký nhập của người dùng như thay đổi hiển thị hoặc tab.

Gỡ lỗi : Chúng tôi xem xét Gỡ lỗi <Dấu vết. Điểm khác biệt là các thông báo Debug được biên dịch từ các bản dựng Phát hành. Điều đó nói rằng, chúng tôi không khuyến khích sử dụng các thông báo Debug. Cho phép các thông báo Gỡ lỗi có xu hướng dẫn đến ngày càng nhiều thông báo Gỡ lỗi được thêm vào và không có thông báo nào bị xóa. Theo thời gian, điều này làm cho các tệp nhật ký gần như vô dụng vì quá khó để lọc tín hiệu từ nhiễu. Điều đó khiến các nhà phát triển không sử dụng các bản ghi tiếp tục vòng xoáy tử thần. Ngược lại, liên tục cắt tỉa tin nhắn Trace khuyến khích các nhà phát triển sử dụng chúng, kết quả là một vòng xoáy đạo đức. Ngoài ra, điều này giúp loại bỏ khả năng các lỗi được giới thiệu do các tác dụng phụ cần thiết trong mã gỡ lỗi không có trong bản phát hành. Vâng, tôi biết rằng không nên xảy ra trong mã tốt, nhưng tốt hơn là an toàn thì xin lỗi.

Đây là danh sách những gì "loggers" có.

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] các sự kiện lỗi rất nghiêm trọng có thể sẽ khiến ứng dụng hủy bỏ.

   [ v2.0 : ..] lỗi nghiêm trọng sẽ ngăn ứng dụng tiếp tục.

2. ERROR:

   [ v1.2 : ..] các sự kiện lỗi vẫn có thể cho phép ứng dụng tiếp tục chạy.

   [ v2.0 : ..] lỗi trong ứng dụng, có thể phục hồi được.

3. WARN:

   [ v1.2 : ..] các tình huống có thể gây hại.

   [ v2.0 : ..] sự kiện có thể [ sic ] có thể dẫn đến lỗi.

4. INFO:

   [ v1.2 : ..] thông báo thông tin làm nổi bật tiến trình của ứng dụng ở mức độ chi tiết.

   [ v2.0 : ..] sự kiện cho mục đích thông tin.

5. DEBUG:

   [ v1.2 : ..] các sự kiện thông tin chi tiết hữu ích nhất để gỡ lỗi một ứng dụng.

   [ v2.0 : ..] sự kiện gỡ lỗi chung.

6. TRACE:

   [ v1.2 : ..] các sự kiện thông tin chi tiết hơn so với DEBUG.

   [ v2.0 : ..] thông báo gỡ lỗi chi tiết, thường nắm bắt luồng thông qua ứng dụng.

Apache httpd (như thường lệ) thích sử dụng quá mức cần thiết: §

1. nổi lên :

   Trường hợp khẩn cấp - hệ thống là không thể sử dụng.

2. cảnh báo :

   Hành động phải được thực hiện ngay lập tức [nhưng hệ thống vẫn có thể sử dụng được].

3. crit :

   Điều kiện quan trọng [nhưng hành động không cần phải được thực hiện ngay lập tức].

   • " socket: Không thể lấy socket, thoát con "

4. lỗi :

   Điều kiện lỗi [nhưng không nghiêm trọng].

   • " Kết thúc sớm của tiêu đề kịch bản "

5. cảnh báo :

   Điều kiện cảnh báo. [gần với lỗi, nhưng không phải lỗi]

6. thông báo :

   Điều kiện bình thường nhưng đáng kể [ đáng chú ý ].

   • " httpd: bị bắt SIGBUS, đang cố gắng đổ lõi vào ... "

7. thông tin :

   Thông tin [và không thể chú ý].

   • [" Máy chủ đã chạy trong x giờ. "]

8. gỡ lỗi :

   Thông điệp debug cấp [, tức là thông điệp đăng nhập vì lợi ích của de-bugging )].

   • " Mở tập tin cấu hình ... "

9. dấu vết1 → dấu vết6 :

   Tin nhắn theo dõi [, tức là tin nhắn được ghi lại để truy tìm ].

   • " proxy: FTP: kiểm soát kết nối hoàn tất "
   • " proxy: CONNECT: gửi yêu cầu CONNECT đến proxy từ xa "
   • " openssl: Bắt tay: bắt đầu "
   • " đọc từ lữ đoàn SSL được đệm, chế độ 0, 17 byte "
   • " tra cứu bản đồ KHÔNG CÓ:map=rewritemap key=keyname "
   • " tra cứu bộ nhớ cache FAILED, buộc tra cứu bản đồ mới "

10. dấu vết7 → dấu vết8 :

    Theo dõi tin nhắn, đổ một lượng lớn dữ liệu

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Đăng nhập chung của Apache: §

1. gây tử vong :

   Lỗi nghiêm trọng gây ra chấm dứt sớm. 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.

2. lỗi :

   Lỗi thời gian chạy khác hoặc điều kiện bất ngờ. 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.

3. 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.

4. 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.

5. 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ý.

6. dấu vết :

   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ý.

Apache commons-log "thực hành tốt nhất" cho việc sử dụng doanh nghiệp tạo ra sự khác biệt giữa gỡ lỗi và thông tin dựa trên loại ranh giới mà chúng vượt qua.

Ranh giới bao gồm:

• Ranh giới bên ngoài - Ngoại lệ dự kiến.

• Ranh giới bên ngoài - Trường hợp ngoại lệ không mong đợi.

• Ranh giới nội bộ.

• Ranh giới nội bộ đáng kể.

(Xem hướng dẫn đăng nhập chung để biết thêm thông tin về điều này.)

Nếu bạn có thể phục hồi từ vấn đề thì đó là một cảnh báo. Nếu nó ngăn cản việc tiếp tục thực hiện thì đó là một lỗi.

Tôi khuyên bạn nên áp dụng mức độ nghiêm trọng của Syslog : DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Xem http://en.wikipedia.org/wiki/Syslog#Severity_levels

Họ nên cung cấp đủ mức độ nghiêm trọng hạt mịn cho hầu hết các trường hợp sử dụng và được công nhận bởi các trình phân tích cú pháp log hiện có. Tất nhiên, trong khi bạn có quyền tự do chỉ thực hiện một tập hợp con, ví dụ DEBUG, ERROR, EMERGENCYtùy thuộc vào yêu cầu của ứng dụng.

Hãy chuẩn hóa một thứ gì đó đã có từ rất lâu thay vì đưa ra tiêu chuẩn của riêng chúng tôi cho mọi ứng dụng khác nhau mà chúng tôi tạo ra. Khi bạn bắt đầu tổng hợp các bản ghi và đang cố gắng phát hiện các mẫu trên các mẫu khác nhau, nó thực sự có ích.

Cảnh báo bạn có thể phục hồi từ. Lỗi bạn không thể. Đó là heuristic của tôi, những người khác có thể có ý tưởng khác.

Ví dụ: giả sử bạn nhập / nhập tên "Angela Müller"vào ứng dụng của bạn (lưu ý âm sắc trên u). Mã / cơ sở dữ liệu của bạn có thể chỉ bằng tiếng Anh (mặc dù có lẽ không nên ở thời đại ngày nay) và do đó có thể cảnh báo rằng tất cả các ký tự "bất thường" đã được chuyển đổi thành các ký tự tiếng Anh thông thường.

Ngược lại với việc cố gắng ghi thông tin đó vào cơ sở dữ liệu và nhận lại tin nhắn mạng trong 60 giây liên tục. Đó là một lỗi nhiều hơn là một cảnh báo.

Như những người khác đã nói, lỗi là vấn đề; cảnh báo là những vấn đề tiềm ẩn.

Trong quá trình phát triển, tôi thường xuyên sử dụng các cảnh báo trong đó tôi có thể đặt tương đương với lỗi xác nhận nhưng ứng dụng có thể tiếp tục hoạt động; điều này cho phép tôi tìm hiểu xem trường hợp đó có thực sự xảy ra không, hoặc nếu đó là trí tưởng tượng của tôi.

Nhưng có, nó đi xuống các khía cạnh phục hồi và thực tế. Nếu bạn có thể phục hồi, đó có thể là một cảnh báo; nếu nó khiến một cái gì đó thực sự thất bại, đó là một lỗi.

Tôi nghĩ rằng các mức SYSLOG THÔNG BÁO và ALERT / KHẨN CẤP phần lớn là không cần thiết cho ghi nhật ký cấp ứng dụng - trong khi CRITICS / ALERT / EMERGENCY có thể là các mức cảnh báo hữu ích cho một nhà điều hành có thể kích hoạt các hành động và thông báo khác nhau, cho quản trị viên ứng dụng, nó giống như BẠC. Và tôi chỉ không thể phân biệt đầy đủ giữa việc được thông báo hoặc một số thông tin. Nếu thông tin không đáng chú ý, thì đó không thực sự là thông tin :)

Tôi thích cách giải thích nhất của Jay Cincotta - theo dõi việc thực thi mã của bạn là một điều rất hữu ích trong hỗ trợ công nghệ và nên đưa các tuyên bố theo dõi vào mã một cách tự do - đặc biệt là kết hợp với cơ chế lọc động để ghi thông điệp theo dõi từ các thành phần ứng dụng cụ thể. Tuy nhiên, mức DEBUG đối với tôi chỉ ra rằng chúng tôi vẫn đang trong quá trình tìm hiểu điều gì đang xảy ra - Tôi thấy đầu ra mức DEBUG là một tùy chọn chỉ phát triển, không phải là thứ sẽ xuất hiện trong nhật ký sản xuất.

Tuy nhiên, có một mức ghi nhật ký mà tôi muốn thấy trong nhật ký lỗi của mình khi đội mũ của một sysadmin nhiều như mức hỗ trợ công nghệ, hoặc thậm chí là nhà phát triển: OPER, cho các thông báo HOẠT ĐỘNG. Cái này tôi sử dụng để ghi lại dấu thời gian, loại hoạt động được gọi, các đối số được cung cấp, có thể là định danh tác vụ (duy nhất) và hoàn thành nhiệm vụ. Nó được sử dụng khi ví dụ: một tác vụ độc lập bị loại bỏ, một thứ gọi là thực sự từ bên trong ứng dụng chạy dài hơn. Đó là thứ tôi muốn luôn luôn đăng nhập, bất kể có vấn đề gì xảy ra hay không, vì vậy tôi cho rằng mức độ OPER cao hơn FATAL, vì vậy bạn chỉ có thể tắt nó bằng cách chuyển sang chế độ hoàn toàn im lặng. Và nó không chỉ đơn thuần là dữ liệu nhật ký INFO - một mức nhật ký thường bị lạm dụng để spam nhật ký với các thông điệp hoạt động nhỏ không có giá trị lịch sử nào.

Vì trường hợp ra lệnh, thông tin này có thể được chuyển đến một nhật ký gọi riêng hoặc có thể thu được bằng cách lọc nó ra khỏi nhật ký lớn ghi thêm thông tin. Nhưng thông tin lịch sử luôn luôn cần thiết để biết những gì đã được thực hiện - mà không giảm xuống mức AUDIT, một mức nhật ký hoàn toàn riêng biệt khác không liên quan đến sự cố hoặc vận hành hệ thống, không thực sự phù hợp với các cấp độ trên ( vì nó cần công tắc điều khiển riêng, không phải phân loại mức độ nghiêm trọng) và chắc chắn cần tệp nhật ký riêng.

Từ RFC 5424, Giao thức Syslog (IETF) - Trang 10:

Mỗi thông báo Ưu tiên cũng có một chỉ báo mức độ nghiêm trọng thập phân. Chúng được mô tả trong bảng sau cùng với các giá trị số của chúng. Giá trị nghiêm trọng PHẢI nằm trong phạm vi từ 0 đến 7.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

Ngày mai

Như một hệ quả tất yếu cho câu hỏi này, hãy truyền đạt những diễn giải của bạn về các cấp độ nhật ký và đảm bảo rằng tất cả mọi người trong một dự án đều được căn chỉnh theo cách giải thích của họ về các cấp độ.

Thật đau đớn khi thấy một loạt các thông điệp tường trình trong đó mức độ nghiêm trọng và mức độ nhật ký được chọn không nhất quán.

Cung cấp các ví dụ nếu có thể của các cấp ghi nhật ký khác nhau. Và nhất quán trong thông tin để đăng nhập vào một tin nhắn.

HTH

Tôi hoàn toàn đồng ý với những người khác và nghĩ rằng GrayWizardx đã nói điều đó tốt nhất.

Tất cả những gì tôi có thể thêm là các mức này thường tương ứng với định nghĩa từ điển của chúng, vì vậy nó không khó đến thế. Nếu nghi ngờ, hãy coi nó như một câu đố. Đối với dự án cụ thể của bạn, hãy nghĩ về mọi thứ mà bạn có thể muốn đăng nhập.

Bây giờ, bạn có thể tìm ra những gì có thể gây tử vong? Bạn biết những gì có nghĩa là gây tử vong, phải không? Vì vậy, những mục trong danh sách của bạn là gây tử vong.

Ok, đó là vấn đề nghiêm trọng, bây giờ hãy xem xét các lỗi ... rửa và lặp lại.

Bên dưới Fatal, hoặc có thể là Lỗi, tôi sẽ đề xuất rằng nhiều thông tin luôn tốt hơn ít hơn, do đó, "lỗi" trở lên. Không chắc chắn nếu đó là Thông tin hoặc Cảnh báo? Sau đó làm cho nó một cảnh báo.

Tôi nghĩ rằng Fatal và lỗi phải rõ ràng cho tất cả chúng ta. Những người khác có thể là mờ hơn, nhưng có thể ít quan trọng hơn để làm cho họ đúng.

Dưới đây là một số ví dụ:

Gây tử vong - không thể phân bổ bộ nhớ, cơ sở dữ liệu, v.v. - không thể tiếp tục.

Lỗi - không trả lời tin nhắn, giao dịch bị hủy bỏ, không thể lưu tệp, v.v.

Cảnh báo - phân bổ tài nguyên đạt X% (giả sử là 80%) - đó là dấu hiệu bạn có thể muốn định lại kích thước của mình.

Thông tin - người dùng đăng nhập / đăng xuất, giao dịch mới, tập tin, trường d / b mới hoặc trường bị xóa.

Gỡ lỗi - kết xuất cấu trúc dữ liệu nội bộ, Bất kỳ mức nào theo dõi với tên tệp và số dòng.
Dấu vết - hành động thành công / thất bại, d / b cập nhật.

Một lỗi là một cái gì đó sai, sai rõ ràng, không có cách nào xung quanh nó, nó cần phải được sửa chữa.

Một cảnh báo là một dấu hiệu của một mẫu có thể sai, nhưng sau đó cũng có thể không.

Phải nói rằng, tôi không thể đưa ra một ví dụ hay về cảnh báo không phải là lỗi. Điều tôi muốn nói là nếu bạn gặp rắc rối khi đăng nhập cảnh báo, bạn cũng có thể khắc phục vấn đề tiềm ẩn.

Tuy nhiên, những thứ như "thực thi sql mất quá nhiều thời gian" có thể là một cảnh báo, trong khi "bế tắc thực thi sql" là một lỗi, vì vậy có lẽ có một số trường hợp sau tất cả.

Tôi đã luôn xem xét cảnh báo cấp độ nhật ký đầu tiên rằng chắc chắn có vấn đề (ví dụ: có lẽ tệp cấu hình không phải là nơi cần thiết và chúng tôi sẽ phải chạy với cài đặt mặc định). Đối với tôi, một lỗi ngụ ý, điều gì đó có nghĩa là mục tiêu chính của phần mềm hiện không thể thực hiện được và chúng tôi sẽ cố gắng tắt sạch.

Tôi đã xây dựng các hệ thống trước đó sử dụng như sau:

1. LRI - có nghĩa là một cái gì đó sai nghiêm trọng và chủ đề / quy trình / trình tự cụ thể đó không thể tiếp tục. Cần có sự can thiệp của người dùng / quản trị viên
2. CẢNH BÁO - điều gì đó không đúng, nhưng quá trình có thể tiếp tục như trước đây (ví dụ: một công việc trong bộ 100 đã thất bại, nhưng phần còn lại có thể được xử lý)

Trong các hệ thống tôi đã xây dựng quản trị viên theo hướng dẫn để phản ứng với ERROR. Mặt khác, chúng tôi sẽ theo dõi CẢNH BÁO và xác định cho từng trường hợp xem có cần thay đổi hệ thống, cấu hình lại hay không.

Btw, tôi là một fan hâm mộ tuyệt vời của việc nắm bắt mọi thứ và lọc thông tin sau này.

Điều gì sẽ xảy ra nếu bạn đang chụp ở cấp Cảnh báo và muốn một số thông tin Gỡ lỗi liên quan đến cảnh báo, nhưng không thể tạo lại cảnh báo?

Nắm bắt mọi thứ và lọc sau!

Điều này đúng ngay cả đối với phần mềm nhúng trừ khi bạn thấy rằng bộ xử lý của bạn không thể theo kịp, trong trường hợp đó bạn có thể muốn thiết kế lại theo dõi của mình để làm cho nó hiệu quả hơn hoặc theo dõi đang can thiệp vào thời gian (bạn có thể xem xét gỡ lỗi một bộ xử lý mạnh hơn, nhưng điều đó sẽ mở ra cả một con giun.

Nắm bắt mọi thứ và lọc sau !!

(btw, nắm bắt mọi thứ cũng tốt vì nó cho phép bạn phát triển các công cụ để làm nhiều việc hơn là chỉ hiển thị dấu vết gỡ lỗi (Tôi vẽ Biểu đồ trình tự tin nhắn từ tôi và biểu đồ sử dụng bộ nhớ. Nó cũng cung cấp cho bạn cơ sở để so sánh nếu có sự cố xảy ra tương lai (giữ tất cả các bản ghi, cho dù vượt qua hay thất bại, và chắc chắn bao gồm số bản dựng trong tệp nhật ký)).

Hai xu của tôi về FATALvà TRACEmức độ nhật ký lỗi.

ERROR là khi một số FAULT (ngoại lệ) xảy ra.

FATAL thực sự là NHÂN ĐÔI NHÂN ĐÔI: khi ngoại lệ xảy ra trong khi xử lý ngoại lệ.

Thật dễ hiểu cho dịch vụ web.

1. Yêu cầu đến. Sự kiện được ghi lại dưới dạngINFO
2. Hệ thống phát hiện không gian đĩa thấp. Sự kiện được ghi lại dưới dạngWARN
3. Một số chức năng được gọi để xử lý yêu cầu. Trong khi xử lý phân chia bằng không xảy ra. Sự kiện được ghi lại dưới dạngERROR
4. Trình xử lý ngoại lệ của dịch vụ web được gọi để xử lý chia cho số không. Dịch vụ web / khung sẽ gửi email, nhưng không thể vì dịch vụ gửi thư hiện đang ngoại tuyến. Ngoại lệ thứ hai này không thể được xử lý bình thường, vì trình xử lý ngoại lệ của dịch vụ Web không thể xử lý ngoại lệ.
5. Xử lý ngoại lệ khác nhau được gọi. Sự kiện được ghi lại dưới dạngFATAL

TRACElà khi chúng ta có thể theo dõi chức năng nhập / thoát. Đây không phải là về đăng nhập, bởi vì thông báo này có thể được tạo bởi một số trình gỡ lỗi và mã của bạn hoàn toàn không gọi đến log. Vì vậy, tin nhắn không phải từ ứng dụng của bạn được đánh dấu như TRACEcấp độ. Ví dụ: bạn chạy ứng dụng của bạn bằngstrace

Vì vậy, nói chung trong chương trình của bạn, bạn làm DEBUG, INFOvà WARNkhai thác gỗ. Và chỉ khi bạn đang viết một số dịch vụ / khung web bạn sẽ sử dụng FATAL. Và khi bạn gỡ lỗi ứng dụng, bạn sẽ nhận được TRACEđăng nhập từ loại phần mềm này.

Tôi đề nghị chỉ sử dụng ba cấp độ

1. Gây tử vong - Điều này sẽ phá vỡ ứng dụng.
2. Thông tin - Thông tin
3. Gỡ lỗi - Thông tin ít quan trọng