Level logging - Logback - aturan praktis untuk menetapkan level log

Saya menggunakan logback di proyek saya saat ini.

Ia menawarkan enam level logging: TRACE DEBUG INFO WARN ERROR OFF

Saya mencari aturan praktis untuk menentukan level log untuk aktivitas umum. Misalnya, jika utas terkunci, haruskah pesan log diatur ke tingkat debug atau tingkat info. Atau jika soket sedang digunakan, haruskah id spesifiknya dicatat pada level debug atau level jejak.

Saya akan menghargai jawaban dengan lebih banyak contoh untuk setiap level logging.

Saya kebanyakan membangun sistem tipe ketersediaan besar, jadi jawaban saya cenderung memandangnya dari sudut pandang dukungan produksi; yang mengatakan, kami menetapkan kira-kira sebagai berikut:

• kesalahan : sistem dalam kesulitan, pelanggan mungkin terpengaruh (atau akan segera) dan perbaikan mungkin memerlukan intervensi manusia. "Aturan 2AM" berlaku di sini- jika Anda sedang menelepon, apakah Anda ingin dibangunkan pada jam 2 pagi jika kondisi ini terjadi? Jika ya, maka catat sebagai "kesalahan".

• memperingatkan : peristiwa teknis atau bisnis yang tidak terduga terjadi, pelanggan mungkin terpengaruh, tetapi mungkin tidak diperlukan intervensi manusia segera. Pada panggilan orang tidak akan dipanggil segera, tetapi personel pendukung akan ingin meninjau masalah ini secepatnya untuk memahami apa dampaknya. Pada dasarnya setiap masalah yang perlu dilacak tetapi mungkin tidak memerlukan intervensi segera.

• info : hal-hal yang ingin kita lihat pada volume tinggi jika kita perlu menganalisis masalah secara forensik. Peristiwa siklus hidup sistem (sistem start, stop) buka di sini. Acara siklus hidup "Sesi" (masuk, keluar, dll.) Buka di sini. Peristiwa batas yang signifikan harus dipertimbangkan juga (misalnya panggilan basis data, panggilan API jarak jauh). Pengecualian bisnis yang umum dapat dilakukan di sini (mis. Proses masuk gagal karena kredensial buruk). Peristiwa lain yang menurut Anda perlu dilihat dalam produksi dengan volume tinggi ada di sini.

• debug : hampir semua yang tidak membuat "info" terpotong ... pesan apa pun yang membantu melacak aliran melalui sistem dan mengisolasi masalah, terutama selama fase pengembangan dan QA. Kami menggunakan log tingkat "debug" untuk masuk / keluar dari sebagian besar metode non-sepele dan menandai peristiwa menarik dan poin keputusan di dalam metode.

• trace : kami tidak sering menggunakannya, tetapi ini untuk log volume tinggi yang sangat terperinci dan berpotensi tinggi yang biasanya tidak ingin Anda aktifkan bahkan selama pengembangan normal. Contohnya termasuk membuang hirarki objek penuh, mencatat beberapa negara selama setiap iterasi dari loop besar, dll.

Sebagai atau lebih penting daripada memilih level log yang tepat adalah memastikan bahwa log tersebut bermakna dan memiliki konteks yang dibutuhkan. Misalnya, Anda hampir selalu ingin memasukkan ID utas dalam log sehingga Anda dapat mengikuti utas tunggal jika diperlukan. Anda mungkin juga ingin menggunakan mekanisme untuk mengaitkan info bisnis (mis. ID pengguna) ke utas sehingga akan dicatat juga. Dalam pesan log Anda, Anda harus memasukkan cukup info untuk memastikan pesan tersebut dapat ditindaklanjuti. Log seperti "Pengecualian FileNotFound tertangkap" tidak terlalu membantu. Pesan yang lebih baik adalah "Pengecualian FileNotFound ditangkap saat mencoba membuka file konfigurasi: /usr/local/app/somefile.txt. UserId = 12344."

Ada juga sejumlah panduan logging yang bagus di luar sana ... misalnya, berikut ini cuplikan yang diedit dari JCL (Jakarta Commons Logging) :

• error - Kesalahan runtime lain atau kondisi yang tidak terduga. Harapkan ini akan segera terlihat pada konsol status.
• warning - Penggunaan API usang, buruknya penggunaan API, kesalahan 'hampir', situasi runtime lain yang tidak diinginkan atau tidak terduga, tetapi tidak selalu "salah". Harapkan ini akan segera terlihat pada konsol status.
• info - Acara runtime yang menarik (startup / shutdown). Harapkan ini akan segera terlihat pada konsol, jadi konservatif dan tetap seminimal mungkin.
• debug - informasi terperinci tentang aliran melalui sistem. Harapkan ini ditulis hanya untuk log.
• jejak - informasi lebih rinci. Harapkan ini ditulis hanya untuk log.

Pendekatan saya, saya pikir berasal lebih dari pengembangan dari sudut pandang operasi, adalah:

• Kesalahan berarti bahwa pelaksanaan beberapa tugas tidak dapat diselesaikan; email tidak bisa dikirim, halaman tidak bisa dirender, beberapa data tidak bisa disimpan ke database, semacam itu. Pasti ada yang salah.
• Peringatan berarti sesuatu yang tidak terduga terjadi, tetapi eksekusi itu dapat berlanjut, mungkin dalam mode terdegradasi; file konfigurasi tidak ada tetapi standar digunakan, harga dihitung sebagai negatif, jadi dijepit ke nol, dll. Sesuatu tidak benar, tetapi belum salah dengan benar - peringatan sering merupakan tanda bahwa akan ada kesalahan segera.
• Info berarti sesuatu yang normal tetapi signifikan terjadi; sistem dimulai, sistem berhenti, pekerjaan pembaruan inventaris harian berjalan, dll. Seharusnya tidak ada torrent yang berkelanjutan, jika tidak, terlalu banyak yang harus dibaca.
• Debug berarti sesuatu yang normal dan tidak penting terjadi; pengguna baru datang ke situs, halaman diberikan, pesanan diambil, harga diperbarui. Ini adalah hal-hal yang dikecualikan dari info karena akan ada terlalu banyak.
• Jejak adalah sesuatu yang saya belum pernah benar-benar digunakan.

Ini juga dapat secara tangensial membantu, untuk memahami jika permintaan logging (dari kode) pada tingkat tertentu akan menghasilkan itu benar-benar dicatat mengingat tingkat logging yang efektif yang penyebaran dikonfigurasi dengan penyebaran. Putuskan level efektif apa yang ingin Anda konfigurasikan untuk penyebaran Anda dari Jawaban lain di sini, dan kemudian lihat ini untuk melihat apakah permintaan logging tertentu dari kode Anda benar-benar akan dicatat kemudian ...

Sebagai contoh :

• "Apakah baris kode logging yang log di WARN akan benar-benar masuk pada penerapan saya yang dikonfigurasi dengan ERROR?" Tabel mengatakan, TIDAK.
• "Apakah baris kode logging yang log di WARN akan benar-benar masuk pada penerapan saya yang dikonfigurasi dengan DEBUG?" Tabel mengatakan, YA.

dari dokumentasi logback :

Dengan cara yang lebih grafis, berikut adalah cara kerja aturan seleksi. Dalam tabel berikut ini, tajuk vertikal menunjukkan tingkat permintaan pencatatan, yang ditunjuk oleh p, sedangkan tajuk horizontal menunjukkan tingkat efektif dari pencatat, yang ditunjuk oleh q. Perpotongan baris (permintaan level) dan kolom (level efektif) adalah boolean yang dihasilkan dari aturan pemilihan dasar.

Jadi baris kode yang meminta logging hanya benar-benar akan dicatat jika tingkat logging yang efektif dari penyebarannya kurang dari atau sama dengan tingkat keparahan yang diminta oleh kode baris itu .

Saya menjawab ini berasal dari arsitektur berbasis komponen, di mana suatu organisasi dapat menjalankan banyak komponen yang dapat saling bergantung. Selama kegagalan penyebaran, level logging harus membantu mengidentifikasi komponen mana yang terpengaruh dan mana yang merupakan akar penyebab.

• GALAT - Komponen ini mengalami kegagalan dan penyebabnya diyakini internal (setiap pengecualian internal, tidak tertangani, kegagalan dependensi yang dienkapsulasi ... misalnya database, contoh REST akan menerima kesalahan 4xx dari dependensi). Keluarkan aku (pengelola komponen ini) dari tempat tidur.

• PERINGATAN - Komponen ini memiliki kegagalan yang diyakini disebabkan oleh komponen dependen (contoh REST adalah status 5xx dari dependensi). Dapatkan pengelola komponen ITU dari tempat tidur.

• INFO - Hal lain yang ingin kami sampaikan kepada operator. Jika Anda memutuskan untuk mencatat jalur bahagia maka saya sarankan membatasi 1 pesan log per operasi yang signifikan (misalnya per permintaan http masuk).

Untuk semua pesan log, pastikan untuk mencatat konteks yang bermanfaat (dan memprioritaskan membuat pesan menjadi dapat dibaca / berguna daripada memiliki rim "kode kesalahan")

• DEBUG (dan di bawah) - Tidak boleh digunakan sama sekali (dan tentu saja tidak dalam produksi). Dalam pengembangan saya akan menyarankan menggunakan kombinasi TDD dan Debugging (bila perlu) yang bertentangan dengan kode polusi dengan pernyataan log. Dalam produksi, logging INFO di atas, dikombinasikan dengan metrik lain harus memadai.

Cara yang bagus untuk memvisualisasikan level logging di atas adalah dengan membayangkan satu set layar pemantauan untuk setiap komponen. Ketika semua berjalan dengan baik mereka berwarna hijau, jika komponen mencatat PERINGATAN maka itu akan menjadi oranye (kuning) jika ada yang mencatat KESALAHAN maka akan menjadi merah.

Jika terjadi insiden Anda harus memiliki satu (akar penyebab) komponen menjadi merah dan semua komponen yang terkena dampak harus oranye / kuning.

Tidak berbeda dengan jawaban lain, kerangka kerja saya memiliki level yang hampir sama:

1. Kesalahan: kesalahan logis kritis pada aplikasi, seperti batas waktu koneksi basis data. Hal-hal yang membutuhkan perbaikan bug dalam waktu dekat
2. Peringatkan: masalah yang tidak melanggar, tapi hal-hal yang harus diperhatikan. Seperti halaman yang diminta tidak ditemukan
3. Info: digunakan dalam fungsi / metode baris pertama, untuk menunjukkan prosedur yang telah dipanggil atau langkah sudah ok, seperti memasukkan kueri yang dilakukan
4. log: informasi logika, seperti hasil dari pernyataan if
5. debug: konten variabel yang relevan untuk ditonton secara permanen