Thực hành tốt nhất để sử dụng Markers trong SLF4J / Logback

Hiện tại chúng tôi đang sử dụng kết hợp SLF4J + Logback tại dự án của chúng tôi và khá hài lòng với nó, nhưng chiến lược ghi nhật ký của chúng tôi khá đơn giản, sử dụng các logger dựa trên lớp đơn giản và không có công cụ ưa thích như MDC hoặc Markers.

Điều tôi muốn biết là liệu có ai trong cộng đồng thực sự sử dụng các tính năng này không và cách chúng được sử dụng để cải thiện việc ghi nhật ký / lọc.

Tôi đặc biệt quan tâm đến việc sử dụng ở đâu, tại sao và như thế nào ^[1] Markers để đăng nhập. Chúng tấn công tôi như một tính năng khá gọn gàng để thêm ngữ cảnh ngữ nghĩa vào ghi nhật ký - ví dụ: trong khi một lớp có thể xử lý nhiều mối quan tâm, người ta có thể sử dụng các dấu hiệu cụ thể của nhiệm vụ / mối quan tâm để phân biệt các báo cáo nhật ký.

Điều gì có thể là các thực tiễn, quy ước hoặc chiến lược tốt nhất để tạo và sử dụng các dấu hiệu trong ghi nhật ký.

Cập nhật: Tôi đoán, những gì tôi thực sự theo sau không phải là lý do tại sao nên sử dụng các điểm đánh dấu, mà là phần như thế nào - có một số cách thực hành tốt về cách đặt tên (ví dụ: sử dụng văn bản đơn giản với dấu cách hoặc dấu gạch ngang được phân cách bằng dấu gạch ngang ), nên có một số loại "tên tiêu chuẩn", đặt tên dựa trên các chức năng kinh doanh. Các câu hỏi tôi có thể tự mình tìm ra, nhưng nếu tôi muốn sử dụng các tính năng này một cách có hệ thống và giới thiệu chúng cho một nhóm các nhà phát triển, sẽ có một số hướng dẫn chính thức xung quanh ...

^[1] - Bằng cách hỏi làm thế nào để sử dụng các điểm đánh dấu, tôi không thực sự hỏi cách sử dụng API (nó thực sự khá đơn giản) - Tôi muốn nói đến mức độ chung hơn về cách một người sẽ thiết lập đăng nhập xung quanh bằng cách sử dụng các dấu hiệu một cách nhất quán

Đầu tiên, như @darioo nói:

• MDC được sử dụng để liên kết nhiều sự kiện với một vài "thực thể"
• [Markers] được sử dụng cho các sự kiện "đặc biệt" mà bạn muốn lọc từ những sự kiện thông thường

Vì vậy, khẳng định của bạn rằng bạn muốn sử dụng MDC cho việc này. Điểm đánh dấu là để làm nổi bật các sự kiện "đặc biệt" - lọc, nếu bạn muốn - chứ không phải là "cắt". Ví dụ: bạn có thể cắt dựa trên một người dùng cụ thể, nhưng lọc dựa trên bất kỳ trường hợp ngoại lệ không mong muốn nào. Trong trường hợp này, bạn sẽ tạo ra một tài khoản chiều MDC và một UnexpectedException Marker.

Nhưng điều này dường như không giải quyết được câu hỏi bạn có trong đầu. Bạn "đang đề cập đến mức độ chung hơn về cách một người sẽ thiết lập đăng nhập xung quanh bằng cách sử dụng các dấu hiệu một cách nhất quán." Vì vậy, hãy giải quyết rằng:

MDC là để cắt và thái hạt lựu , và Markers là để lọc . Những hoạt động này được thực hiện trong quá trình thử nghiệm và trong sản xuất . Do đó, bạn cần phải quyết định kích thước nào bạn mong đợi có thể hữu ích để cắt dữ liệu nhật ký và trường hợp nào có thể hữu ích để lọc dữ liệu đó, khi thử nghiệm / sản xuất xuất hiện. Mỗi kích thước được một kích thước MDC. Mỗi trường hợp được một Marker. Nó đơn giản như vậy.

Các nhà phát triển không cần đưa ra bất kỳ quyết định nào ở đây. Một người hoặc một nhóm nên quyết định, tại thời điểm thiết kế , loại cắt, thái hạt lựu và lọc cần được hỗ trợ. Điều này cần được thông báo bằng cách tưởng tượng loại nhiệm vụ phân tích nào mà người ta mong đợi họ có thể được yêu cầu thực hiện.

Điều này cùng một người hoặc nhóm nên quyết định về quy ước đặt tên. Nó hoàn toàn tùy ý . Chọn một cái gì đó đẹp về mặt thẩm mỹ, tự mô tả (quan trọng nhất) và đủ cụ thể để không có khả năng xung đột với các bổ sung sau này. Hyphens vs. undererscores là cực kỳ nitpicky và đáng báo động bên cạnh điểm, nhưng lưu ý rằng nhân viên của ESL có thể ít đọc nhầm hơn (ít nhất là so với CamelCase); đồng thời, điều này được báo cáo gây khó chịu cho một số nhà phát triển do sự lúng túng trong việc tiếp cận các khóa cần thiết.

Theo như quyết định về một chính sách, điều này chỉ có nghĩa là xác định trong trường hợp nào một thứ nguyên Marker hoặc MDC nhất định cần phải được sử dụng . Giữ chặt chẽ điều này (tập trung, có chủ ý), nhưng cho phép phản hồi từ các nhà phát triển nếu họ cảm thấy bộ kích thước và điểm đánh dấu là không đủ cho nhiệm vụ trong tay. Sửa đổi / thêm kích thước và / hoặc thuộc tính nếu thích hợp.

Hiểu chính sách này sẽ gần như nhất thiết phải là dự án cụ thể . Không phải mọi dự án đều cần cùng một loại phân tích đăng nhập. Hình ảnh một số kịch bản ác mộng. Sau đó tưởng tượng làm thế nào bạn muốn có thể phân tích các bản ghi trong kịch bản đó. Có lẽ bạn không muốn phải viết một kịch bản phức tạp để thử và theo dõi tin nhắn nào thuộc về bối cảnh nào, và trạng thái nào vào lúc nào, phải không? Mã hóa bất cứ thông tin nào như vậy là cần thiết như kích thước và Điểm đánh dấu, và tự cứu mình một số rắc rối nếu có sự cố xảy ra.

Đầu tiên, MDC.

MDC thực sự hữu ích trong môi trường nơi bạn có một "thực thể" có liên quan đến một số hành vi. Một ví dụ điển hình: người dùng tương tác với một ứng dụng web. Vì vậy, giả sử bạn có nhiều người dùng đang loay hoay với ứng dụng web của mình. Sử dụng MDC, bạn có thể dễ dàng theo dõi chúng mà không gặp quá nhiều rắc rối. Ví dụ đơn giản:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Tại đây, bạn đang sử dụng MDC ở hai nơi: cho tên người dùng và ID phiên. Bằng cách này, bạn có thể dễ dàng grep một phiên của người dùng để xem mọi thứ họ đang làm.

Thứ hai, đánh dấu.

Điểm đánh dấu thường được sử dụng cho các trường hợp "đặc biệt", chẳng hạn như gửi email đến quản trị viên đối với một số lỗi nghiêm trọng. Không phải tất cả các lỗi luôn thuộc cùng một loại; một số phải được xử lý một cách thích hợp.

Hoặc, khi người dùng thoát khỏi dịch vụ của bạn, nó thường chuyển đến nhật ký INFO, nhưng bạn cũng có thể sử dụng điểm đánh dấu cho các trường hợp đó, nếu bạn muốn các sự kiện như thế này đi vào một tệp nhật ký riêng, vì vậy bạn có thể theo dõi nó dễ dàng hơn để thu thập thống kê của người dùng bỏ.

Quy tắc của ngón tay cái:

• MDC được sử dụng để liên kết nhiều sự kiện với một vài "thực thể"
• các điểm đánh dấu được sử dụng cho các sự kiện "đặc biệt" mà bạn muốn lọc từ các sự kiện thông thường

Điểm đánh dấu có thể được sử dụng để tô màu hoặc đánh dấu một tuyên bố nhật ký duy nhất . Những gì bạn làm với những màu này, tức là các điểm đánh dấu, hoàn toàn phụ thuộc vào bạn. Tuy nhiên, hai mẫu dường như là phổ biến (mẫu đầu tiên phổ biến hơn mẫu thứ hai) cho việc sử dụng đánh dấu.

1. Kích hoạt : Một số ứng dụng có thể được hướng dẫn thực hiện một hành động với sự có mặt của một điểm đánh dấu nhất định. Ví dụ: SMTPAppendercó thể được cấu hình để gửi email bất cứ khi nào sự kiện đăng nhập được đánh dấu bằng NOTIFY_ADMINđiểm đánh dấu bất kể mức độ nhật ký. Xem kích hoạt dựa trên đánh dấu trong tài liệu đăng nhập lại. Bạn cũng có thể kết hợp các cấp độ nhật ký và đánh dấu để kích hoạt.

2. Lọc : Ví dụ: bạn có thể tô màu / đánh dấu tất cả các nhật ký liên quan đến tính bền vững của bạn (trong các tệp khác nhau và nhiều lớp) bằng màu "DB". Sau đó, bạn có thể lọc "DB": vô hiệu hóa ghi nhật ký trừ các báo cáo nhật ký được đánh dấu bằng DB. Xem chương về các bộ lọc trong tài liệu đăng nhập để biết thêm thông tin (tìm kiếm MarkerFilter).

Cũng giống như một phụ lục, nếu bạn đang sử dụng logstash và bật tính năng ghi nhật ký json, có một cách sử dụng Marker khác - để ghi nhật ký các biến để liên kết với một thông điệp tường trình cụ thể. Điều này phù hợp và dễ phân tích hơn là đưa nó vào phần thân thông điệp. Rất hữu ích, nếu nó phù hợp với trường hợp sử dụng của bạn.

Xem chi tiết tại đây:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event