Praktik terbaik untuk menggunakan Penanda di SLF4J / Logback

Kami menggunakan kombinasi SLF4J + Logback di proyek kami untuk sementara waktu sekarang dan cukup senang dengan itu, tetapi strategi logging kami cukup sederhana, menggunakan penebang berbasis kelas langsung dan tidak ada hal-hal mewah seperti MDC atau Marker.

Yang ingin saya ketahui adalah apakah ada orang di komunitas yang benar-benar menggunakan fitur ini dan bagaimana mereka digunakan untuk meningkatkan pencatatan log / penyaringan.

Saya secara khusus tertarik pada di mana, mengapa dan bagaimana seseorang akan menggunakan ^[1] Marker untuk login. Mereka menganggap saya sebagai fitur yang cukup rapi untuk menambahkan konteks semantik ke dalam logging - misalnya ketika kelas mungkin menangani beberapa masalah, orang dapat menggunakan penanda spesifik tugas / masalah untuk membedakan pernyataan log.

Apa yang mungkin menjadi praktik terbaik, konvensi atau strategi untuk membuat dan menggunakan spidol dalam logging.

Pembaruan: Saya kira, apa yang benar-benar saya cari bukanlah alasan untuk menggunakan marker, tetapi bagaimana bagiannya - apakah ada beberapa praktik yang baik dalam marker penamaan (mis. Menggunakan teks biasa dengan spasi atau tanda garis / garis bawah / tanda baca dibatasi nama gaya kata kunci yang dibatasi ), haruskah ada semacam kumpulan "nama standar", penamaan barang berdasarkan fungsi bisnis. Pertanyaan-pertanyaan yang mungkin dapat saya pecahkan sendiri, tetapi jika saya ingin menggunakan fitur-fitur ini secara sistematis dan memperkenalkannya kepada tim pengembang, masuk akal untuk memiliki beberapa pedoman yang dapat diformalkan di sekitar ...

^[1] - Dengan bertanya bagaimana menggunakan spidol saya tidak benar-benar bertanya bagaimana menggunakan API (ini benar-benar sangat lurus ke depan) - Saya lebih mengacu pada tingkat yang lebih umum tentang bagaimana seseorang mengatur logging sekitar menggunakan spidol secara konsisten

Pertama, seperti yang dikatakan @darioo:

• MDC digunakan untuk mengaitkan banyak acara dengan beberapa "entitas"
• [Penanda] digunakan untuk acara "khusus" yang ingin Anda filter dari yang biasa

Jadi pernyataan Anda bahwa Anda ingin menggunakan MDC untuk ini. Penanda adalah untuk menyoroti acara "khusus" - pemfilteran, jika Anda mau - daripada "mengiris". Misalnya, Anda dapat mengiris berdasarkan pengguna tertentu, tetapi memfilter berdasarkan pada pengecualian yang tidak terduga. Dalam hal ini, Anda akan membuat dimensi MDC Pengguna dan Penanda UnexpectedException .

Tapi ini rupanya tidak menjawab pertanyaan yang ada dalam pikiran Anda. Anda "lebih mengacu pada tingkat yang lebih umum tentang bagaimana seseorang mengatur log-in menggunakan penanda secara konsisten." Jadi mari kita bahas itu:

MDC untuk mengiris dan dicing , dan Marker untuk penyaringan . Kegiatan ini dilakukan selama pengujian dan produksi . Dengan demikian, Anda perlu memutuskan dimensi mana yang Anda harapkan dapat berguna untuk mengiris data log, dan kasus mana yang mungkin berguna untuk menyaringnya, ketika pengujian / produksi muncul. Setiap dimensi mendapatkan dimensi MDC. Setiap case mendapatkan Marker. Sesederhana itu.

Pengembang tidak perlu membuat keputusan apa pun di sini. Satu orang atau tim harus memutuskan, pada waktu desain , jenis pengirisan, dicing, dan penyaringan apa yang perlu didukung. Ini harus diinformasikan dengan membayangkan tugas analisis seperti apa yang diharapkan dilakukan oleh mereka.

Orang atau tim yang sama ini harus memutuskan konvensi penamaan. Ini sepenuhnya sewenang-wenang . Pilih sesuatu yang menyenangkan secara estetika, deskriptif diri (paling penting), dan cukup spesifik agar tidak bertentangan dengan penambahan selanjutnya. Tanda hubung vs garis bawah adalah sangat membingungkan dan mengkhawatirkan di samping itu, tetapi perhatikan bahwa karyawan ESL mungkin kurang membingungkan untuk membaca garis bawah (setidaknya dibandingkan dengan CamelCase); pada saat yang sama, ini dilaporkan mengganggu beberapa pengembang karena kecanggungan mencapai kunci yang diperlukan.

Sejauh memutuskan kebijakan, ini hanya berarti mendefinisikan dalam kasus mana dimensi Marker atau MDC tertentu perlu digunakan . Jaga ini tetap (terpusat, disengaja), tetapi memungkinkan umpan balik dari pengembang jika mereka merasa set dimensi dan spidol tidak cukup untuk tugas yang dihadapi. Merevisi / menambah dimensi dan / atau atribut yang sesuai.

Memahami kebijakan ini hampir pasti bersifat spesifik proyek . Tidak setiap proyek membutuhkan jenis analisis logging yang sama. Bayangkan beberapa skenario mimpi buruk. Lalu bayangkan bagaimana Anda ingin dapat menganalisis log dalam skenario itu. Anda mungkin tidak ingin harus menulis skrip yang rumit untuk mencoba dan melacak pesan mana yang termasuk dalam konteks mana, dan negara mana yang pada saat mana, kan? Menyandikan informasi apa pun yang diperlukan sebagai dimensi dan Penanda, dan selamatkan diri Anda dari kerepotan jika terjadi kesalahan.

Pertama, MDC.

MDC sangat berguna dalam lingkungan di mana Anda memiliki satu "entitas" yang dikaitkan dengan beberapa perilaku. Contoh khas: pengguna berinteraksi dengan aplikasi web. Jadi, katakanlah Anda memiliki banyak pengguna yang bermain-main dengan aplikasi web Anda. Dengan menggunakan MDC, Anda dapat dengan mudah melacaknya tanpa terlalu banyak kesulitan. Contoh sederhana:

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

Di sini, Anda menggunakan MDC di dua tempat: untuk nama pengguna dan untuk ID sesi. Dengan cara ini, Anda dapat dengan mudah menangkap sesi satu pengguna untuk melihat semua yang telah mereka lakukan.

Kedua, spidol.

Penanda biasanya digunakan untuk keadaan "khusus", seperti mengirim email ke administrator untuk beberapa kesalahan serius. Tidak semua kesalahan selalu termasuk dalam kategori yang sama; beberapa harus ditangani dengan cara yang tepat.

Atau, ketika pengguna berhenti dari layanan Anda, biasanya masuk ke log INFO, tetapi Anda juga dapat menggunakan penanda untuk kejadian seperti itu, jika Anda ingin acara seperti ini masuk dalam file log yang terpisah, sehingga Anda dapat memonitornya lebih mudah untuk mengumpulkan statistik pengguna yang berhenti.

Aturan praktis:

• MDC digunakan untuk mengaitkan banyak acara dengan beberapa "entitas"
• spidol digunakan untuk acara "khusus" yang ingin Anda filter dari yang biasa

Marker dapat digunakan untuk mewarnai atau menandai satu pernyataan log. Apa yang Anda lakukan dengan warna-warna ini, yaitu spidol, sepenuhnya terserah Anda. Namun, dua pola tampaknya umum (yang pertama lebih umum daripada yang kedua) untuk penggunaan marker.

1. Memicu : Beberapa append dapat diminta untuk mengambil tindakan di hadapan penanda tertentu. Misalnya, SMTPAppenderdapat dikonfigurasikan untuk mengirim email setiap kali acara logging ditandai dengan NOTIFY_ADMINmarker terlepas dari level log. Lihat pemicu berbasis marker dalam dokumentasi logback. Anda juga dapat menggabungkan level dan penanda log untuk memicu.

2. Pemfilteran : Misalnya, Anda dapat menandai / menandai semua log terkait kegigihan Anda (dalam berbagai dan beberapa file kelas) dengan warna "DB". Anda kemudian dapat memfilter untuk "DB": menonaktifkan pencatatan kecuali untuk laporan log yang ditandai dengan DB. Lihat bab tentang filter dalam dokumentasi logback untuk informasi lebih lanjut (cari MarkerFilter).

Sama seperti tambahan, jika Anda menggunakan logstash dan mengaktifkan json logging, ada potensi lain penggunaan Marker - untuk variabel logging untuk dikaitkan dengan pesan log tertentu. Ini lebih konsisten dan lebih mudah diurai daripada memasukkannya ke dalam badan pesan. Sangat berguna, jika sesuai dengan use case Anda.

Lihat detailnya di sini:

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