Praktik terbaik pembalakan [ditutup]

Saya ingin mendapatkan cerita tentang bagaimana orang menangani penelusuran dan masuk dalam aplikasi nyata. Berikut beberapa pertanyaan yang mungkin bisa membantu menjelaskan jawaban Anda.

Kerangka kerja

Kerangka apa yang Anda gunakan?

• log4net
• System.Diagnostics.Trace
• System.Diagnostics.TraceSource
• Blok aplikasi logging
• Lain?

Jika Anda menggunakan pelacakan, apakah Anda menggunakan Trace.Correlation.StartLogicalOperation?

Apakah Anda menulis kode ini secara manual, atau Anda menggunakan beberapa bentuk pemrograman berorientasi aspek untuk melakukannya? Ingin berbagi cuplikan kode?

Apakah Anda memberikan segala bentuk rincian atas sumber jejak? Misalnya, WPF TraceSources memungkinkan Anda untuk mengonfigurasinya di berbagai tingkatan:

• System.Windows - pengaturan untuk semua WPF
• System.Windows.Animation - menimpa khusus untuk Animasi.

Pendengar

Output log apa yang Anda gunakan?

• File teks
• File XML
• Log acara
• Lain?

Jika menggunakan file, apakah Anda menggunakan rolling log atau hanya satu file? Bagaimana Anda membuat log tersedia untuk dikonsumsi orang?

Melihat

Alat apa yang Anda gunakan untuk melihat log?

• Notepad
• Ekor
• Penampil acara
• Manajer Operasional Pusat Sistem / Manajer Operasi Microsoft
• Penampil Jejak Layanan WCF
• Lain?

Jika Anda sedang membangun solusi ASP.NET, apakah Anda juga menggunakan ASP.NET Health Monitoring? Apakah Anda menyertakan jejak keluaran dalam acara monitor kesehatan? Bagaimana dengan Trace.axd?

Bagaimana dengan penghitung kinerja khusus?

Pembaruan: Untuk ekstensi ke System.Diagnostics, menyediakan beberapa pendengar yang hilang yang mungkin Anda inginkan, lihat Essential.Diagnostics pada CodePlex ( http://essentialdiagnostics.codeplex.com/ )

Kerangka kerja

T: Kerangka apa yang Anda gunakan?

A: System.Diagnostics.TraceSource, bawaan untuk .NET 2.0.

Ini memberikan logging yang kuat, fleksibel, kinerja tinggi untuk aplikasi, namun banyak pengembang tidak menyadari kemampuannya dan tidak menggunakannya secara penuh.

Ada beberapa area di mana fungsionalitas tambahan berguna, atau kadang-kadang fungsionalitas ada tetapi tidak terdokumentasi dengan baik, namun ini tidak berarti bahwa seluruh kerangka logging (yang dirancang agar dapat diperluas) harus dibuang dan diganti sepenuhnya seperti beberapa alternatif populer (NLog, log4net, Common.Logging, dan bahkan EntLib Logging).

Daripada mengubah cara Anda menambahkan pernyataan logging ke aplikasi Anda dan menciptakan kembali roda, cukup rentangkan kerangka kerja System.Diagnostics di beberapa tempat yang Anda butuhkan.

Menurut saya kerangka kerja lain, bahkan EntLib, hanya menderita Sindrom Not Invented Here, dan saya pikir mereka membuang-buang waktu untuk menemukan kembali dasar-dasar yang sudah bekerja dengan baik di System.Diagnostics (seperti bagaimana Anda menulis laporan log), daripada mengisi beberapa celah yang ada. Singkatnya, jangan menggunakannya - mereka tidak diperlukan.

Fitur yang mungkin belum Anda ketahui:

• Menggunakan kelebihan TraceEvent yang mengambil string format dan args dapat membantu kinerja karena parameter disimpan sebagai referensi terpisah sampai setelah Filter.ShouldTrace () berhasil. Ini berarti tidak ada panggilan mahal ke ToString () pada nilai parameter sampai setelah sistem mengkonfirmasi pesan akan benar-benar dicatat.
• Trace.CorrelationManager memungkinkan Anda untuk mengkorelasikan pernyataan log tentang operasi logis yang sama (lihat di bawah).
• VisualBasic.Logging.FileLogTraceListener baik untuk menulis file log dan mendukung rotasi file. Meskipun dalam namespace VisualBasic, itu dapat dengan mudah digunakan dalam proyek C # (atau bahasa lain) hanya dengan memasukkan DLL.
• Saat menggunakan EventLogTraceListener jika Anda memanggil TraceEvent dengan beberapa argumen dan dengan string format kosong atau nol, maka args diteruskan langsung ke EventLog.WriteEntry () jika Anda menggunakan sumber daya pesan lokal.
• Alat Service Trace Viewer (dari WCF) berguna untuk melihat grafik file log yang terkait aktivitas (bahkan jika Anda tidak menggunakan WCF). Ini benar-benar dapat membantu men-debug masalah kompleks di mana banyak utas / aktivitas terlibat.
• Hindari overhead dengan membersihkan semua pendengar (atau menghapus Default); jika tidak, Default akan meneruskan semuanya ke sistem jejak (dan mengeluarkan semua biaya overhead ToString ()).

Area yang Anda mungkin ingin lihat meluas (jika perlu):

• Pendengar jejak basis data
• Pendengar jejak konsol berwarna
• Pendengar jejak MSMQ / Email / WMI (jika perlu)
• Terapkan FileSystemWatcher untuk memanggil Trace.Refresh untuk perubahan konfigurasi dinamis

Rekomendasi lain:

Gunakan id acara terstruktur, dan simpan daftar referensi (mis. Dokumentasikan dalam enum).

Memiliki id acara unik untuk setiap acara (signifikan) di sistem Anda sangat berguna untuk menghubungkan dan menemukan masalah tertentu. Mudah untuk melacak kembali ke kode spesifik yang mencatat / menggunakan id acara, dan dapat membuatnya mudah untuk memberikan panduan untuk kesalahan umum, misalnya kesalahan 5178 berarti string koneksi basis data Anda salah, dll.

ID acara harus mengikuti beberapa jenis struktur (mirip dengan Teori Kode Balasan yang digunakan dalam email dan HTTP), yang memungkinkan Anda memperlakukannya berdasarkan kategori tanpa mengetahui kode tertentu.

mis. Digit pertama dapat merinci kelas umum: 1xxx dapat digunakan untuk operasi 'Mulai', 2xxx untuk perilaku normal, 3xxx untuk pelacakan aktivitas, 4xxx untuk peringatan, 5xxx untuk kesalahan, 8xxx untuk operasi 'Stop', 9xxx untuk kesalahan fatal, dll.

Digit kedua dapat merinci area, mis. 21xx untuk informasi basis data (41xx untuk peringatan basis data, 51xx untuk kesalahan basis data), 22xx untuk mode perhitungan (42xx untuk peringatan perhitungan, dll), 23xx untuk modul lain, dll.

Ditugaskan, id acara terstruktur juga memungkinkan Anda menggunakannya dalam filter.

T: Jika Anda menggunakan pelacakan, apakah Anda menggunakan Trace.Correlation.StartLogicalOperation?

A: Trace.CorrelationManager sangat berguna untuk mengkorelasikan laporan log dalam segala jenis lingkungan multi-threaded (yang mana saja saat ini).

Anda setidaknya perlu menetapkan ActivityId sekali untuk setiap operasi logis untuk berkorelasi.

Mulai / Hentikan dan LogicalOperationStack kemudian dapat digunakan untuk konteks berbasis tumpukan sederhana. Untuk konteks yang lebih kompleks (mis. Operasi asinkron), menggunakan TraceTransfer ke ActivityId baru (sebelum mengubahnya), memungkinkan korelasi.

Alat Penilik Jejak Layanan dapat berguna untuk melihat grafik aktivitas (bahkan jika Anda tidak menggunakan WCF).

T: Apakah Anda menulis kode ini secara manual, atau Anda menggunakan beberapa bentuk pemrograman berorientasi aspek untuk melakukannya? Ingin berbagi cuplikan kode?

A: Anda mungkin ingin membuat kelas lingkup, misalnya LogicalOperationScope, yang (a) mengatur konteks saat dibuat dan (b) mengatur ulang konteks saat dibuang.

Ini memungkinkan Anda untuk menulis kode seperti yang berikut untuk membungkus operasi secara otomatis:

  using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
  {
    // .. do work here
  }

Pada pembuatan, ruang lingkup pertama dapat mengatur ActivityId jika diperlukan, panggil StartLogicalOperation dan kemudian log pesan TraceEventType.Start. Pada Buang, itu bisa mencatat pesan Stop, dan kemudian memanggil StopLogicalOperation.

T: Apakah Anda memberikan segala bentuk rincian atas sumber jejak? Misalnya, WPF TraceSources memungkinkan Anda untuk mengonfigurasinya di berbagai tingkatan.

A: Ya, banyak Sumber Jejak berguna / penting karena sistem semakin besar.

Sementara Anda mungkin ingin secara konsisten mencatat semua Peringatan & di atas, atau semua Informasi & pesan di atas, untuk sistem berukuran apa pun, volume Pelacakan Aktivitas (Mulai, Berhenti, dll.) Dan Verbose logging menjadi terlalu banyak.

Daripada hanya memiliki satu sakelar yang menghidupkan atau mematikan semuanya, ada baiknya untuk mengaktifkan informasi ini untuk satu bagian dari sistem Anda sekaligus.

Dengan cara ini, Anda dapat menemukan masalah signifikan dari biasanya masuk (semua peringatan, kesalahan, dll), dan kemudian "memperbesar" pada bagian yang Anda inginkan dan mengaturnya ke Pelacakan Aktivitas atau bahkan tingkat Debug.

Jumlah sumber jejak yang Anda butuhkan tergantung pada aplikasi Anda, mis. Anda mungkin menginginkan satu sumber jejak per perakitan atau per bagian utama aplikasi Anda.

Jika Anda bahkan membutuhkan kontrol yang lebih baik, tambahkan sakelar boolean terpisah untuk menghidupkan / mematikan penelusuran volume tinggi tertentu, misalnya dump pesan mentah. (Atau sumber penelusuran terpisah dapat digunakan, mirip dengan WCF / WPF).

Anda mungkin juga ingin mempertimbangkan sumber penelusuran terpisah untuk Pelacakan Kegiatan vs pencatatan umum (lainnya), karena hal ini dapat membuatnya sedikit lebih mudah untuk mengonfigurasi filter persis seperti yang Anda inginkan.

Perhatikan bahwa pesan masih dapat dikorelasikan melalui ActivityId bahkan jika sumber yang berbeda digunakan, jadi gunakan sebanyak yang Anda butuhkan.

Pendengar

T: Output log apa yang Anda gunakan?

Ini dapat bergantung pada jenis aplikasi apa yang Anda tulis, dan hal-hal apa yang sedang dicatat. Biasanya hal yang berbeda terjadi di tempat yang berbeda (yaitu beberapa output).

Saya biasanya mengklasifikasikan output menjadi tiga kelompok:

(1) Acara - Windows Event Log (dan lacak file)

mis. Jika menulis server / layanan, maka praktik terbaik pada Windows adalah dengan menggunakan Windows Event Log (Anda tidak memiliki UI untuk melapor).

Dalam hal ini semua peristiwa Informasi Fatal, Kesalahan, Peringatan, dan (tingkat layanan) harus masuk ke Windows Event Log. Level Informasi harus disediakan untuk jenis peristiwa tingkat tinggi ini, yang ingin Anda masuki dalam log peristiwa, mis. "Layanan Dimulai", "Layanan Berhenti", "Terhubung ke Xyz", dan mungkin bahkan "Jadwal Diprakarsai" , "Pengguna Masuk", dll.

Dalam beberapa kasus, Anda mungkin ingin membuat penulisan ke log peristiwa sebagai bagian bawaan dari aplikasi Anda dan tidak melalui sistem penelusuran (yaitu, menulis entri Log Event secara langsung). Ini berarti tidak dapat dimatikan secara tidak sengaja. (Perhatikan bahwa Anda juga masih ingin mencatat peristiwa yang sama di sistem penelusuran Anda sehingga Anda dapat berkorelasi).

Sebaliknya, aplikasi Windows GUI umumnya akan melaporkan ini kepada pengguna (meskipun mereka juga dapat masuk ke Windows Event Log).

Peristiwa mungkin juga memiliki penghitung kinerja terkait (mis. Jumlah kesalahan / detik), dan penting untuk mengkoordinasikan setiap penulisan langsung ke Log Peristiwa, penghitung kinerja, penulisan ke sistem penelusuran dan pelaporan kepada pengguna sehingga terjadi di waktu yang sama.

yaitu Jika pengguna melihat pesan kesalahan pada waktu tertentu, Anda harus dapat menemukan pesan kesalahan yang sama di Windows Event Log, dan kemudian acara yang sama dengan stempel waktu yang sama di log jejak (bersama dengan rincian jejak lainnya).

(2) Kegiatan - File Log Aplikasi atau tabel database (dan melacak file)

Ini adalah aktivitas reguler yang dilakukan oleh suatu sistem, misalnya halaman web yang dilayani, perdagangan pasar saham yang diajukan, pesanan yang diambil, perhitungan yang dilakukan, dll.

Pelacakan Aktivitas (mulai, berhenti, dll) berguna di sini (pada granualitas yang tepat).

Juga, sangat umum untuk menggunakan Log Aplikasi tertentu (kadang-kadang disebut Log Audit). Biasanya ini adalah tabel database atau file log aplikasi dan berisi data terstruktur (yaitu seperangkat bidang).

Hal-hal bisa menjadi sedikit kabur di sini tergantung pada aplikasi Anda. Contoh yang baik mungkin server web yang menulis setiap permintaan ke log web; contoh serupa mungkin sistem pesan atau sistem perhitungan di mana setiap operasi dicatat bersama dengan rincian khusus aplikasi.

Contoh yang tidak begitu baik adalah perdagangan pasar saham atau sistem pemesanan penjualan. Dalam sistem ini, Anda mungkin sudah mencatat aktivitas karena memiliki nilai bisnis yang penting, namun prinsip menghubungkannya dengan tindakan lain masih penting.

Selain log aplikasi khusus, kegiatan juga sering memiliki penghitung kinerja terkait, misalnya jumlah transaksi per detik.

Secara umum Anda harus mengoordinasikan pencatatan aktivitas di berbagai sistem yang berbeda, yaitu menulis ke log aplikasi Anda pada saat yang sama saat Anda meningkatkan penghitung kinerja dan masuk ke sistem penelusuran Anda. Jika Anda melakukan semuanya pada waktu yang bersamaan (atau saling berhadapan dalam kode), maka masalah debug lebih mudah (daripada jika semuanya terjadi pada waktu / lokasi yang berbeda dalam kode).

(3) Debug Trace - File teks, atau mungkin XML atau database.

Ini adalah informasi pada level Verbose dan lebih rendah (mis. Sakelar boolean khusus untuk menghidupkan / mematikan dump data mentah). Ini memberikan nyali atau detail tentang apa yang dilakukan sistem pada tingkat sub-aktivitas.

Ini adalah level yang Anda inginkan untuk menghidupkan / mematikan untuk setiap bagian dari aplikasi Anda (karenanya berbagai sumber). Anda tidak ingin barang-barang ini mengacaukan Windows Event Log. Kadang-kadang database digunakan, tetapi lebih mungkin menggulung file log yang dibersihkan setelah waktu tertentu.

Perbedaan besar antara informasi ini dan file Log Aplikasi adalah tidak terstruktur. Sementara Log Aplikasi mungkin memiliki bidang Untuk, Dari, Jumlah, dll., Jejak debug Verbose dapat berupa apa pun yang dimasukkan oleh programmer, misalnya "memeriksa nilai X = {value}, Y = false", atau komentar / penanda acak seperti " Selesai, coba lagi ".

Salah satu praktik penting adalah memastikan hal-hal yang Anda masukkan ke file log aplikasi atau Windows Event Log juga masuk ke sistem penelusuran dengan detail yang sama (mis. Stempel waktu). Ini memungkinkan Anda untuk mengkorelasikan log yang berbeda saat menyelidiki.

Jika Anda berencana untuk menggunakan penampil log tertentu karena Anda memiliki korelasi yang kompleks, misalnya Penampil Jejak Layanan, maka Anda perlu menggunakan format yang sesuai yaitu XML. Jika tidak, file teks sederhana biasanya cukup baik - pada level yang lebih rendah informasi sebagian besar tidak terstruktur, sehingga Anda mungkin menemukan dump array, stack stack, dll. Asalkan Anda dapat dikorelasikan kembali ke log yang lebih terstruktur pada level yang lebih tinggi, hal-hal yang harus baiklah.

T: Jika menggunakan file, apakah Anda menggunakan rolling log atau hanya satu file? Bagaimana Anda membuat log tersedia untuk dikonsumsi orang?

A: Untuk file, umumnya Anda ingin menggulirkan file log dari sudut pandang pengelolaan (dengan System.Diagnostics cukup gunakan VisualBasic.Logging.FileLogTraceListener).

Ketersediaan lagi tergantung pada sistem. Jika Anda hanya berbicara tentang file maka untuk server / layanan, file bergulir hanya dapat diakses saat diperlukan. (Windows Event Log atau Log Aplikasi Database akan memiliki mekanisme aksesnya sendiri).

Jika Anda tidak memiliki akses yang mudah ke sistem file, maka debug penelusuran ke database mungkin lebih mudah. [yaitu mengimplementasikan TraceListener basis data].

Salah satu solusi menarik yang saya lihat untuk aplikasi Windows GUI adalah bahwa ia mencatat informasi penelusuran yang sangat rinci ke "perekam penerbangan" ketika sedang berjalan dan kemudian ketika Anda mematikannya jika tidak ada masalah, maka ia hanya menghapus file.

Namun, jika macet atau mengalami masalah maka file tidak terhapus. Entah jika itu menangkap kesalahan, atau waktu berikutnya dijalankan akan melihat file, dan kemudian dapat mengambil tindakan, misalnya kompres (mis. 7zip) dan kirimkan melalui email atau jika tidak tersedia.

Banyak sistem saat ini menggabungkan pelaporan kegagalan otomatis ke server pusat (setelah memeriksa dengan pengguna, misalnya untuk alasan privasi).

Melihat

T: Alat apa yang Anda gunakan untuk melihat log?

A: Jika Anda memiliki banyak log untuk alasan yang berbeda, maka Anda akan menggunakan banyak pemirsa.

Notepad / vi / Notepad ++ atau editor teks lainnya adalah dasar untuk log teks biasa.

Jika Anda memiliki operasi yang kompleks, misalnya aktivitas dengan transfer, maka Anda tentu saja akan menggunakan alat khusus seperti Service Trace Viewer. (Tetapi jika Anda tidak membutuhkannya, maka editor teks lebih mudah).

Karena saya biasanya mencatat informasi tingkat tinggi ke Windows Event Log, maka ia menyediakan cara cepat untuk mendapatkan gambaran umum, secara terstruktur (mencari ikon kesalahan / peringatan yang cantik). Anda hanya perlu mulai berburu melalui file teks jika tidak ada cukup dalam log, meskipun setidaknya log memberi Anda titik awal. (Pada titik ini, memastikan log Anda telah mengkoordinasikan entires menjadi berguna).

Secara umum, Windows Event Log juga membuat peristiwa penting ini tersedia untuk alat pemantauan seperti MOM atau OpenView.

Lainnya -

Jika Anda masuk ke Database, mudah untuk memfilter dan mengurutkan informatio (mis. Memperbesar id aktivitas tertentu. (Dengan file teks, Anda dapat menggunakan Grep / PowerShell atau serupa dengan memfilter pada GUID partiular yang Anda inginkan)

MS Excel (atau program spreadsheet lain). Ini dapat berguna untuk menganalisis informasi terstruktur atau semi-terstruktur jika Anda dapat mengimpornya dengan pembatas yang tepat sehingga nilai yang berbeda masuk dalam kolom yang berbeda.

Saat menjalankan layanan dalam debug / tes saya biasanya menyimpannya di aplikasi konsol untuk kesederhanaan saya menemukan logger konsol berwarna berguna (misalnya merah untuk kesalahan, kuning untuk peringatan, dll). Anda perlu menerapkan pendengar jejak khusus.

Perhatikan bahwa framework tidak menyertakan logger konsol berwarna atau logger database jadi, saat ini, Anda perlu menulis ini jika Anda membutuhkannya (tidak terlalu sulit).

Ini benar-benar mengganggu saya bahwa beberapa kerangka kerja (log4net, EntLib, dll) telah membuang-buang waktu menciptakan kembali roda dan mengimplementasikan kembali pencatatan, penyaringan, dan pencatatan dasar ke file teks, Windows Event Log, dan file XML, masing-masing dalam dirinya sendiri cara yang berbeda (masing-masing pernyataan log berbeda); masing-masing kemudian menerapkan versi mereka sendiri, misalnya, logger basis data, ketika sebagian besar sudah ada dan semua yang diperlukan adalah beberapa lebih banyak pendengar jejak untuk System.Diagnostics. Bicara tentang upaya duplikat yang sangat besar.

T: Jika Anda sedang membangun solusi ASP.NET, apakah Anda juga menggunakan ASP.NET Health Monitoring? Apakah Anda menyertakan jejak keluaran dalam acara monitor kesehatan? Bagaimana dengan Trace.axd?

Hal-hal ini dapat dinyalakan / dimatikan sesuai kebutuhan. Saya menemukan Trace.axd cukup berguna untuk men-debug bagaimana server merespons hal-hal tertentu, tetapi umumnya tidak berguna dalam lingkungan yang banyak digunakan atau untuk penelusuran jangka panjang.

T: Bagaimana dengan penghitung kinerja khusus?

Untuk aplikasi profesional, terutama server / layanan, saya berharap melihatnya sepenuhnya terinstal dengan penghitung Monitor Kinerja dan masuk ke Windows Event Log. Ini adalah alat standar di Windows dan harus digunakan.

Anda harus memastikan bahwa Anda menyertakan pemasang untuk penghitung kinerja dan log peristiwa yang Anda gunakan; ini harus dibuat pada waktu instalasi (saat menginstal sebagai administrator). Ketika aplikasi Anda berjalan dengan normal, aplikasi itu seharusnya tidak perlu memiliki hak administrasi (sehingga tidak akan dapat membuat log yang hilang).

Ini adalah alasan yang bagus untuk berlatih mengembangkan sebagai non-administrator (memiliki akun admin terpisah ketika Anda perlu menginstal layanan, dll). Jika menulis ke Log Kejadian, .NET akan secara otomatis membuat log yang hilang saat pertama kali Anda menulisnya; jika Anda berkembang sebagai non-admin, Anda akan mengetahui hal ini lebih awal dan menghindari kejutan yang tidak menyenangkan ketika pelanggan menginstal sistem Anda dan kemudian tidak dapat menggunakannya karena mereka tidak berjalan sebagai administrator.

Saya harus bergabung dengan chorus merekomendasikan log4net, dalam kasus saya berasal dari fleksibilitas platform (desktop .Net / Compact Framework, 32/64-bit) sudut pandang.

Namun, membungkusnya dalam private-label API adalah anti-pola utama . log4net.ILoggeradalah Net mitra dari Commons Logging wrapper API sudah, jadi kopling sudah diminimalkan untuk Anda, dan karena itu juga merupakan perpustakaan Apache, yang biasanya bahkan tidak menjadi perhatian karena Anda tidak menyerah kontrol: garpu jika Anda harus.

Sebagian besar perpustakaan pembungkus rumah yang saya lihat juga melakukan satu atau lebih dari satu litani kesalahan:

42. Menggunakan global singleton logger (atau ekuivalen dengan entry point statis) yang kehilangan resolusi baik dari pola logger-per-kelas yang disarankan tanpa keuntungan selektivitas lainnya.
43. Gagal mengekspos Exceptionargumen opsional , yang mengarah ke beberapa masalah:
    • Itu membuat pengecualian kebijakan logging semakin sulit untuk dipertahankan, sehingga tidak ada yang dilakukan secara konsisten dengan pengecualian.
    • Bahkan dengan kebijakan yang konsisten, memformat pengecualian menjadi string akan kehilangan data sebelum waktunya. Saya telah menulis ILayoutdekorator khusus yang melakukan rincian pencarian untuk mengetahui rangkaian kejadian.
44. Gagal mengekspos propertiIsLevelEnabled , yang membuang kemampuan untuk melewatkan kode pemformatan saat area atau level logging dimatikan.

Saya tidak sering berkembang di asp.net, namun ketika menyangkut penebang, saya pikir banyak praktik terbaik bersifat universal. Berikut adalah beberapa pemikiran acak saya tentang penebangan yang telah saya pelajari selama bertahun-tahun:

Kerangka kerja

• Gunakan kerangka kerja abstraksi logger - seperti slf4j (atau roll sendiri), sehingga Anda memisahkan implementasi logger dari API Anda. Saya telah melihat sejumlah framework logger datang dan pergi dan Anda lebih baik bisa mengadopsi yang baru tanpa banyak kesulitan.
• Cobalah untuk menemukan kerangka kerja yang mendukung berbagai format output.
• Cobalah untuk menemukan kerangka kerja yang mendukung plugin / filter kustom.
• Gunakan kerangka kerja yang dapat dikonfigurasi oleh file eksternal, sehingga pelanggan Anda / konsumen dapat men-tweak output log dengan mudah sehingga dapat dibaca oleh aplikasi manajemen log komersial dengan mudah.
• Pastikan untuk tidak masuk pada level logging kustom, jika tidak, Anda mungkin tidak dapat pindah ke kerangka logging yang berbeda.

Output Logger

• Cobalah untuk menghindari log gaya XML / RSS untuk masuk yang dapat mengalami kegagalan katastropik. Ini penting karena jika saklar daya dimatikan tanpa logger Anda menulis </xxx>tag penutup , log Anda rusak.
• Log utas. Kalau tidak, akan sangat sulit untuk melacak aliran program Anda.
• Jika Anda harus menginternasionalkan log Anda, Anda mungkin ingin memiliki pengembang hanya login dalam Bahasa Inggris (atau bahasa pilihan Anda).
• Terkadang memiliki opsi untuk memasukkan pernyataan logging ke dalam query SQL dapat menjadi penyelamat dalam situasi debugging. Seperti:

    - Kelas Pemanggilan: com.foocorp.foopackage.FooClass: 9021
    PILIH * DARI foo;

• Anda ingin logging tingkat kelas. Anda biasanya tidak ingin contoh statis dari penebang juga - itu tidak sebanding dengan optimasi mikro.
• Menandai dan mengelompokkan pengecualian yang dicatat terkadang berguna karena tidak semua pengecualian dibuat sama. Jadi mengetahui subset pengecualian penting, kepala waktu sangat membantu, jika Anda memiliki monitor log yang perlu mengirim pemberitahuan pada kondisi kritis.
• Filter duplikasi akan menghemat penglihatan dan hard disk Anda. Apakah Anda benar-benar ingin melihat pernyataan logging yang sama diulang 10 ^ 10.000.000 kali? Bukankah lebih baik mendapatkan pesan seperti: This is my logging statement - Repeated 100 times

Lihat juga pertanyaan saya ini .

Saya tidak memenuhi syarat untuk mengomentari logging untuk. Net, karena roti dan mentega saya adalah Jawa, tetapi kami telah melakukan migrasi dalam logging kami selama 8 tahun terakhir, Anda mungkin menemukan analogi yang berguna untuk pertanyaan Anda.

Kami mulai dengan Singleton logger yang digunakan oleh setiap utas dalam JVM, dan mengatur level logging untuk seluruh proses. Ini menghasilkan log yang sangat besar jika kami harus melakukan debug bahkan pada bagian yang sangat spesifik dari sistem, jadi pelajaran nomor satu adalah mengelompokkan logging Anda.

Inkarnasi logger kami saat ini memungkinkan beberapa instance dengan satu didefinisikan sebagai default. Kami dapat membuat instance sejumlah penebang anak yang memiliki tingkat logging berbeda, tetapi aspek paling berguna dari arsitektur ini adalah kemampuan untuk membuat penebang untuk setiap paket dan kelas dengan hanya mengubah properti logging. Pelajaran nomor dua adalah menciptakan sistem yang fleksibel yang memungkinkan mengesampingkan perilakunya tanpa mengubah kode.

Kami menggunakan pustaka log logging commons Apache yang melilit Log4J.

Semoga ini membantu!

* Edit *

Setelah membaca posting Jeffrey Hantin di bawah ini, saya menyadari bahwa saya seharusnya mencatat apa sebenarnya pembungkus logging internal kami. Ini sekarang pada dasarnya sebuah pabrik dan secara ketat digunakan untuk mendapatkan logger yang berfungsi menggunakan file properti yang benar (yang karena alasan sebelumnya belum dipindahkan ke posisi default). Karena Anda dapat menentukan file konfigurasi logging pada baris perintah sekarang, saya menduga itu akan menjadi lebih ramping dan jika Anda memulai aplikasi baru, saya pasti setuju dengan pernyataannya bahwa Anda bahkan tidak perlu repot-repot membungkus logger.

Kami menggunakan Log4Net di tempat kerja sebagai penyedia logging, dengan pembungkus singleton untuk instance log (meskipun singleton sedang ditinjau, mempertanyakan apakah mereka ide yang baik atau tidak).

Kami memilihnya karena alasan berikut:

• Konfigurasi / rekonfigurasi sederhana pada berbagai lingkungan
• Sejumlah append built-in yang baik
• Salah satu CMS yang kami gunakan sudah ada di dalamnya
• Jumlah tingkat log dan konfigurasi yang bagus di sekitar mereka

Saya harus menyebutkan, ini berbicara dari sudut pandang pengembangan ASP.NET

Saya dapat melihat beberapa manfaat dalam menggunakan Jejak yang ada dalam kerangka NET. Tapi saya tidak sepenuhnya dijual di atasnya, terutama karena komponen saya bekerja dengan tidak benar-benar melakukan panggilan Jejak. Satu-satunya hal yang sering saya gunakan adalah System.Net.Maildari apa yang bisa saya katakan.

Jadi kami memiliki pustaka yang membungkus log4net dan dalam kode kami, kami hanya perlu hal-hal seperti ini:

Logger.Instance.Warn("Something to warn about");
Logger.Instance.Fatal("Something went bad!", new Exception());

try {
  var i = int.Parse("Hello World");
} catch(FormatException, ex) {
  Logger.Instance.Error(ex);
}

Dalam metode kami melakukan pemeriksaan untuk melihat apakah tingkat logging diaktifkan, sehingga Anda tidak memiliki panggilan berlebihan ke API log4net (jadi jika Debug tidak diaktifkan, pernyataan debug diabaikan), tetapi ketika saya mendapatkan waktu Saya akan memperbarui untuk mengekspos mereka sehingga Anda dapat melakukan pemeriksaan sendiri. Ini akan mencegah evaluasi dilakukan ketika tidak seharusnya, misalnya:

Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

Ini akan menjadi:

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

(Menghemat sedikit waktu eksekusi)

Secara default kami login di dua lokasi:

1. Sistem file situs web (dalam ekstensi file yang tidak ditayangkan)
2. Pengiriman email untuk Kesalahan & Fatal

File dilakukan sebagai penggulungan setiap hari atau 10mb (IIRC). Kami tidak menggunakan EventLog karena memerlukan keamanan yang lebih tinggi daripada yang sering ingin kami berikan situs.

Saya menemukan Notepad berfungsi dengan baik untuk membaca log.

Kerangka apa yang Anda gunakan?

Kami menggunakan campuran dari blok aplikasi logging, dan bantuan logging kustom yang bekerja di sekitar bit framework .Net. LAB dikonfigurasi untuk menghasilkan file log yang cukup luas termasuk file jejak umum yang terpisah untuk entri / keluar metode layanan dan file kesalahan khusus untuk masalah yang tidak terduga. Konfigurasi mencakup tanggal / waktu, utas, pId, dll. Untuk bantuan debug serta detail dan tumpukan pengecualian lengkap (dalam kasus pengecualian yang tidak terduga).

Helper logging kustom menggunakan Trace.Correlation dan sangat berguna dalam konteks logging di WF. Sebagai contoh, kami memiliki mesin negara yang memanggil serangkaian alur kerja berurutan. Pada setiap aktivitas yang dipanggil ini, kami mencatat awal (menggunakan StartLogicalOperation) dan kemudian pada akhirnya kami menghentikan operasi logis dengan pengendali event gereric return.

Ini telah terbukti bermanfaat beberapa kali ketika mencoba untuk men-debug kegagalan dalam urutan bisnis yang kompleks karena memungkinkan kita untuk menentukan hal-hal seperti keputusan cabang If / Else dll. Lebih cepat berdasarkan urutan eksekusi aktivitas.

Output log apa yang Anda gunakan?

Kami menggunakan file teks dan file XML. File teks dikonfigurasi melalui blok aplikasi tetapi kami juga mendapatkan output XML dari layanan WF kami. Ini memungkinkan kami untuk menangkap peristiwa runtime (kegigihan, dll.) Serta pengecualian tipe bisnis umum. File teks adalah log bergulir yang digulung berdasarkan hari dan ukuran (saya percaya ukuran total 1MB adalah titik rollover).

Alat apa yang Anda gunakan untuk melihat log?

Kami menggunakan Notepad dan WCF Service Trace Viewer tergantung pada kelompok output mana yang kami lihat. WCF Service Trace Viewer sangat berguna jika Anda memiliki pengaturan output dengan benar dan dapat membuat pembacaan output menjadi lebih mudah. Yang mengatakan, jika saya tahu kira-kira di mana kesalahannya - hanya membaca file teks yang baik juga.

Log dikirim ke direktori tunggal yang kemudian dipecah menjadi sub-dir berdasarkan layanan sumber. Dir root diekspos melalui situs web yang aksesnya dikendalikan oleh grup pengguna dukungan. Ini memungkinkan kami untuk melihat log produksi tanpa harus memasukkan permintaan dan melalui proses pita merah yang panjang untuk data produksi.

Sebagai penulis alat ini, kami tentu saja menggunakan SmartInspect untuk masuk dan melacak aplikasi .NET. Kami biasanya menggunakan protokol pipa bernama untuk pencatatan langsung dan file log biner (terenkripsi) untuk log pengguna akhir. Kami menggunakan SmartInspect Console sebagai alat penampil dan pemantauan.

Sebenarnya ada beberapa kerangka kerja logging dan alat untuk .NET di luar sana. Ada ikhtisar dan perbandingan berbagai alat di DotNetLogging.com .

Ada banyak rekomendasi bagus dalam jawabannya.

Praktik terbaik umum adalah mempertimbangkan siapa yang akan membaca log. Dalam kasus saya ini akan menjadi administrator di situs klien. Jadi saya mencatat pesan yang memberi mereka sesuatu yang bisa mereka lakukan. Misalnya, "Tidak dapat menginisialisasi aplikasi. Ini biasanya disebabkan oleh ......"

Kami menggunakan log4net pada aplikasi web kami.

Kemampuan untuk menyesuaikan penebangan pada saat run-time dengan mengubah file konfigurasi XML sangat berguna ketika aplikasi tidak berfungsi pada saat run-time dan Anda perlu melihat informasi lebih lanjut.

Ini juga memungkinkan Anda untuk menargetkan kelas atau atribut tertentu untuk masuk. Ini sangat berguna ketika Anda memiliki ide di mana kesalahan terjadi. Contoh klasik adalah NHibernate di mana Anda ingin melihat hanya SQL yang masuk ke database.

Edit:

Kami menulis semua acara ke database dan sistem Jejak. Log peristiwa yang kami gunakan untuk kesalahan atau pengecualian. Kami mencatat sebagian besar peristiwa ke basis data sehingga kami dapat membuat laporan khusus dan membiarkan pengguna melihat log jika mereka ingin langsung dari aplikasi.

Sejauh menyangkut aspek logging, saya direkomendasikan PostSharp pada pertanyaan SO lainnya -

Pencatatan Berorientasi Aspek dengan Persatuan \ T4 \ apa pun

Tautan yang disediakan dalam jawaban patut dikunjungi jika Anda mengevaluasi kerangka kerja logging.