Bagaimana saya harus menangani kegagalan logger?

Di beberapa aplikasi perusahaan kami, kami menggunakan logger khusus. Ini cukup kuat, meskipun kami dapat menggantinya dengan sesuatu seperti NLog di masa depan. Salah satu tugas logger adalah mencatat pengecualian yang ditemukan dalam aplikasi.

Satu kekhawatiran yang selalu saya miliki adalah bahwa penanganan pengecualian di dalam logger memungkinkan kegagalan diam. Yaitu, jika log tidak ditulis untuk pengecualian yang diberikan (karena kesalahan dalam logger), bagaimana saya harus menanganinya dan (entah bagaimana) mencatat pengecualian di logger itu sendiri ?

Katakanlah fungsi WriteLog melempar pengecualian. Haruskah saya mencoba memanggil fungsi beberapa kali atau sampai pengecualian tidak dibuang? Haruskah saya mencoba menulis pengecualian yang dilemparkan dengan logger (yang kemungkinan besar akan menghasilkan pengecualian sepanjang jalan ...)? Saya cukup beruntung tidak mengalami situasi ini kecuali ketika kami pertama kali mengimplementasikan logger kustom. Di sisi lain, saya tidak memiliki cara untuk mengetahui saat ini apakah logger telah gagal untuk log pengecualian aplikasi (karena pengecualian sendiri).

Saya telah mencoba mencari secara online dan di beberapa situs SE, tetapi sejauh ini tidak membuahkan hasil karena semua tulisan berurusan dengan kesalahan dalam logger (tetapi tidak ada pengecualian potensial dan cara mencatatnya) atau dengan pengecualian di luar logger.

Saat Anda menemukan pengecualian di dalam pencatat itu sendiri, Anda seharusnya tidak menggunakan pencatat untuk mencatat pengecualiannya sendiri. Alasan untuk itu adalah:

• Anda mungkin terjebak dalam loop tak terbatas. Bayangkan bahwa di dalam logger Anda, Anda memiliki cabang bersyarat yang tidak diuji (dan menghasilkan pengecualian). Bayangkan bahwa setelah kondisi terpenuhi, pengecualian yang dilaporkan lebih lanjut ditangani oleh cabang yang sama. Ini berarti bahwa sejak cabang dieksekusi, Anda berada dalam loop tak terbatas.

• Anda mungkin terjebak dalam lingkaran sementara, menghasilkan ribuan pengecualian per detik. Bayangkan Anda melaporkan pengecualian ke server jauh. Masalah dengan server menyebabkan pengecualian lain, yang menyebabkan yang lain, dan seterusnya, hingga koneksi kembali.

Yang harus Anda lakukan adalah mundur ke cara yang lebih aman untuk mencatat pengecualian. Misalnya, jika logger Anda mengirim pengecualian ke server jauh, kirimkan pengecualian dalam logger ke sysloggantinya. Jika pencatat Anda mencatat pengecualian di Windows Events dan tindakan ini gagal, simpan pengecualian kegagalan dalam file teks sederhana.

Setelah Anda memilikinya, pertanyaan berikutnya adalah bagaimana Anda tahu bahwa pengecualian itu terjadi: jika Anda memiliki lusinan aplikasi yang berjalan di ribuan server, Anda tidak mungkin dapat SSH masing-masing secara teratur untuk memeriksa apakah mereka melakukan logging secara lokal .

Salah satu caranya adalah memiliki pekerjaan cron yang memeriksa "log luar biasa" tersebut dan mendorongnya ke lokasi di mana pengecualian lain disimpan (akhirnya menggunakan logger Anda, tetapi waspadalah terhadap loop tak terbatas atau sementara!).

Jika logging sangat penting untuk aplikasi Anda, maka seseorang harus menghentikan aplikasi jika logging gagal.

Jika tidak kritis, maka menjadi agak defensif, orang dapat memiliki komponen sekunder untuk menangani kegagalan penebangan yang mencatat / memperingatkan sumber sekunder. Tetapi bahkan itu bukan bukti bodoh dan Anda harus mempertimbangkan apa yang terjadi jika logger sekunder gagal saat sedang memantau logger primer.

Strategi yang baik adalah masuk ke file lokal dan jika itu gagal, mungkin mencatat kegagalan itu ke log peristiwa, menghasilkan peringatan email, menyimpan ke database, dll. Dengan kerangka kerja logging yang tersedia ini harus aman kecuali jika mesin berjalan keluar dari ruang disk atau kondisi langka lainnya.

Idealnya, Anda lebih baik gagal diam-diam karena itu akan membuat aplikasi kurang kompleks.

Lebih penting lagi, untuk menangani kegagalan logging, seseorang harus memantau log dari pihak ketiga. Seiring waktu Anda harus dapat melihat berapa banyak peristiwa yang dicatat oleh aplikasi yang sehat. Jika mulai mencatat rendah atau tidak ada kejadian, maka melalui pemantauan Anda dapat melihat masalah yang terjadi dan berpotensi mengingatkan melalui mekanisme pihak ke-3 itu.