Kapan harus menggunakan level log yang berbeda


520

Ada berbagai cara untuk mencatat pesan, dengan urutan kematian:

  1. FATAL

  2. ERROR

  3. WARN

  4. INFO

  5. DEBUG

  6. TRACE

Bagaimana saya memutuskan kapan akan menggunakan yang mana?

Apa heuristik yang baik untuk digunakan?


11
Pertanyaan yang cukup luas. Jadi lebih dari satu jawaban dimungkinkan, tergantung pada keadaan aktual logging. Seseorang akan ketinggalan noticedalam koleksi ini seseorang tidak akan ...
Wolf

@ Serigala di mana 'pemberitahuan' berada di bawah hierarki ini? Hanya sebagai catatan ...
pgblu

1
noticemungkin hilang karena beberapa layanan logging populer seperti log4j tidak menggunakannya.
pgblu

Jawaban:


750

Saya biasanya berlangganan ke konvensi berikut:

  • Trace - Hanya ketika saya akan "melacak" kode dan mencoba menemukan satu bagian dari suatu fungsi secara khusus.
  • Debug - Informasi yang secara diagnostik bermanfaat bagi orang lebih dari sekadar pengembang (TI, sysadmin, dll.).
  • Info - Informasi yang umumnya bermanfaat untuk dicatat (layanan mulai / berhenti, asumsi konfigurasi, dll). Info yang saya ingin selalu tersedia tetapi biasanya tidak peduli dalam keadaan normal. Ini adalah level konfigurasi out-of-the-box saya.
  • Peringatkan - Apa pun yang berpotensi menyebabkan keanehan aplikasi, tetapi untuk itu saya pulih secara otomatis. (Seperti beralih dari server primer ke cadangan, mencoba kembali operasi, kehilangan data sekunder, dll.)
  • Kesalahan - Kesalahan apa pun yang fatal pada operasi , tetapi bukan layanan atau aplikasi (tidak dapat membuka file yang diperlukan, data yang hilang, dll.). Kesalahan ini akan memaksa intervensi pengguna (administrator, atau pengguna langsung). Ini biasanya disediakan (di aplikasi saya) untuk string koneksi yang salah, layanan yang hilang, dll.
  • Fatal - Setiap kesalahan yang memaksa penutupan layanan atau aplikasi untuk mencegah kehilangan data (atau kehilangan data lebih lanjut). Saya mencadangkan ini hanya untuk kesalahan dan situasi paling kejam di mana ada jaminan telah terjadi kerusakan atau kehilangan data.

2
Mengapa Anda tidak bisa menggabungkan info dan memperingatkan! ??! Bukankah peringatan tentang sesuatu yang sebenarnya "info" ...
mP.

35
@ MP Anda bisa menggabungkan info dan memperingatkan, saya kira umumnya mereka terpisah karena prinsip "panik". Jika saya memiliki banyak info yang rutin dan hanya daftar menyatakan itu tidak benar-benar layak dilihat pada "pertama", tetapi jika ada banyak "peringatan" Saya ingin melihat yang diprioritaskan (setelah Kesalahan dan Fatals) sehingga saya dapat melihat ke dalam mereka. Saya akan lebih "panik" pada banyak peringatan daripada banyak pesan info.
GrayWizardx

3
@zieciou tergantung pada kebutuhan khusus Anda. Terkadang itu bisa berakibat fatal, terkadang peringatan. Jika saya mendapatkan 4xx dari layanan kritis saya bergantung pada dan tidak bisa melanjutkan itu akan menjadi Kesalahan / Fatal untuk desain saya. Jika saya mencoba untuk men-cache beberapa data untuk digunakan nanti, tetapi bisa hidup tanpanya itu akan menjadi PERINGATAN. Satu-satunya waktu saya melihatnya sebagai info adalah untuk sesuatu seperti aplikasi pemantauan yang melaporkan status cek URL-nya. Jadi saya akan INFO mencatat bahwa saya mendapat 4xx dari URL dan melanjutkan.
GrayWizardx

2
@ GrayWizardx, saya pikir faktor lainnya adalah apakah ini klien yang menerima 4xx atau server yang mengirimnya. Dalam kasus pertama, saya akan lebih bersedia untuk menggunakan ERROR (OMG, ini salah saya, saya tidak dapat menyiapkan permintaan yang benar), sedangkan dalam kasus terakhir saya akan mencatat PERINGATAN (Ini kesalahan klien mereka tidak dapat merumuskan permintaan dengan benar)
dzieciou

4
Saya menduga ini benar - Debug - Information that is diagnostically helpful to people more than just developers (IT, sysadmins, etc.).. Logger.Debug hanya untuk pengembang untuk melacak masalah yang sangat buruk dalam produksi misalnyaIf you want to print the value of a variable at any given point inside a for loop against a condition
RBT

304

Apakah Anda ingin pesan untuk membuat administrator sistem keluar dari tempat tidur di tengah malam?

  • ya -> kesalahan
  • tidak -> peringatkan

11
Kecuali kebanyakan orang tidak peduli jika mereka membuat orang bangun tidur di malam hari. Kami telah meminta pelanggan menaikkan tingkat keparahan-1 dockets (dimaksudkan untuk pemadaman 100%, yaitu, nasional) karena satu situs tidak dapat melakukan pekerjaan mereka (alasan mereka adalah 100% dari situs itu). Kami telah sejak "mendidik" mereka pada skor itu.
paxdiablo

53
FATALadalah ketika sysadmin bangun, memutuskan dia tidak dibayar cukup untuk ini, dan kembali tidur.
Mateen Ulhaq

135

Saya merasa lebih membantu untuk memikirkan tingkat keparahan dari sudut pandang melihat file log.

Fatal / Kritis : Keseluruhan aplikasi atau kegagalan sistem yang harus segera diselidiki. Ya, bangunkan SysAdmin. Karena kami lebih suka peringatan SysAdmins kami dan cukup istirahat, tingkat keparahan ini harus digunakan sangat jarang. Jika itu terjadi setiap hari dan itu bukan BFD, hilang artinya. Biasanya, kesalahan fatal hanya terjadi sekali dalam masa proses, jadi jika file log terkait dengan proses, ini biasanya pesan terakhir dalam log.

Kesalahan : Pasti masalah yang harus diselidiki. SysAdmin harus diberitahu secara otomatis, tetapi tidak perlu diseret keluar dari tempat tidur. Dengan memfilter log untuk melihat kesalahan dan di atas Anda mendapatkan ikhtisar frekuensi kesalahan dan dapat dengan cepat mengidentifikasi kegagalan memulai yang mungkin telah mengakibatkan kaskade kesalahan tambahan. Melacak tingkat kesalahan dibandingkan penggunaan aplikasi dapat menghasilkan metrik kualitas yang berguna seperti MTBF yang dapat digunakan untuk menilai kualitas secara keseluruhan. Misalnya, metrik ini dapat membantu menginformasikan keputusan tentang perlu atau tidaknya siklus pengujian beta sebelum rilis.

Peringatan : Ini MUNGKIN bermasalah, atau mungkin tidak. Misalnya, kondisi lingkungan transien yang diharapkan seperti kehilangan jaringan atau konektivitas database yang singkat harus dicatat sebagai Peringatan, bukan Kesalahan. Melihat log yang difilter untuk hanya menampilkan peringatan dan kesalahan dapat memberikan wawasan cepat ke petunjuk awal tentang akar penyebab kesalahan berikutnya. Peringatan harus digunakan dengan hemat agar tidak menjadi tidak berarti. Misalnya, kehilangan akses jaringan harus menjadi peringatan atau bahkan kesalahan dalam aplikasi server, tetapi mungkin hanya Info di aplikasi desktop yang dirancang untuk pengguna laptop yang kadang-kadang terputus.

Info : Ini adalah informasi penting yang harus dicatat dalam kondisi normal seperti inisialisasi yang sukses, layanan mulai dan berhenti atau berhasil menyelesaikan transaksi yang signifikan. Melihat log yang menampilkan Info dan di atas harus memberikan tinjauan singkat tentang perubahan status utama dalam proses yang menyediakan konteks tingkat atas untuk memahami peringatan atau kesalahan yang juga terjadi. Tidak memiliki terlalu banyak pesan Info. Kami biasanya memiliki <5% Info info relatif terhadap Trace.

Jejak : Jejak sejauh ini keparahan yang paling umum digunakan dan harus menyediakan konteks untuk memahami langkah-langkah menuju kesalahan dan peringatan. Memiliki kepadatan yang tepat dari pesan Trace membuat perangkat lunak jauh lebih mudah dikelola tetapi membutuhkan beberapa ketekunan karena nilai pernyataan Trace individu dapat berubah dari waktu ke waktu seiring program berkembang. Cara terbaik untuk mencapai hal ini adalah dengan membiasakan tim pengembang kebiasaan meninjau log sebagai bagian standar dari pemecahan masalah yang dilaporkan pelanggan. Dorong tim untuk memangkas pesan Trace yang tidak lagi menyediakan konteks yang berguna dan untuk menambahkan pesan di mana diperlukan untuk memahami konteks pesan berikutnya. Misalnya, sering kali membantu untuk mencatat input pengguna seperti mengubah tampilan atau tab.

Debug : Kami menganggap Debug <Trace. Perbedaannya adalah bahwa pesan Debug dikompilasi dari rilis Rilis. Karena itu, kami mencegah penggunaan pesan Debug. Mengizinkan pesan Debug cenderung mengarah pada semakin banyak pesan Debug yang ditambahkan dan tidak pernah dihapus. Pada waktunya, ini membuat file log hampir tidak berguna karena terlalu sulit untuk menyaring sinyal dari noise. Itu menyebabkan devs tidak menggunakan log yang melanjutkan spiral kematian. Sebaliknya, pesan Trace yang terus dipangkas mendorong para dev untuk menggunakannya yang menghasilkan spiral yang baik. Juga, ini menghilangkan kemungkinan bug yang diperkenalkan karena efek samping yang diperlukan dalam kode debug yang tidak termasuk dalam rilis rilis. Ya, saya tahu itu seharusnya tidak terjadi dalam kode yang baik, tetapi lebih baik aman daripada menyesal.


3
Saya suka itu menekankan untuk berpikir tentang penonton. Kunci dalam komunikasi apa pun (dan pesan log adalah bentuk komunikasi) adalah untuk memikirkan audiens Anda dan apa yang dibutuhkannya.
sleske

18
Tentang Debug <-> Jejak: Perhatikan bahwa setidaknya di Java-land, urutan prioritas adalah "debug> jejak". Itulah konvensi yang digunakan semua kerangka pencatatan (SLF4J, Logback, log4j, Apache Commons Logging, Log4Net, NLog). Jadi Debug <Trace sepertinya tidak biasa bagiku.
sleske

1
@ Jay Cincotta Jawaban yang bagus. Saya pikir Debug / Jejak adalah masalah preferensi tetapi tentu saja rincian semacam ini cenderung khusus aplikasi / perusahaan sehingga bagus untuk melihat pendapat yang berbeda.
GrayWizardx

5
Saya baru saja melakukan survei terhadap 7 kerangka kerja logging di beberapa bahasa. Dari ketiganya yang menyertakan tingkat keparahan "jejak", semuanya menganggapnya tidak separah debug. yaitu, lacak <debug; Saya tidak punya kasus dunia nyata di mana yang sebaliknya adalah benar. @RBT Tidak selalu mungkin untuk masuk ke debugger. Misalnya, server web harus melayani permintaan dalam jumlah waktu yang terbatas, atau ada di lingkungan multithreaded dan / atau server yang mungkin sulit untuk diinstrumentasi, atau bug mungkin cukup langka sehingga debugger bukanlah suatu pilihan. Atau Anda tidak tahu apa yang Anda cari.
Thanatos

5
@RBT Saya telah bekerja dengan sistem Java selama lebih dari 4 tahun. Saya dapat memberi tahu Anda bahwa apa yang Anda minta sama sekali tidak praktis. Debugging IDE hanya bisa membawa Anda sejauh ini. Pada titik tertentu, Anda hanya perlu men - debug log dari sistem lain (seringkali server produksi ) untuk memahami apa yang terjadi dan memperbaiki bug. Anda mungkin berpikir bahwa itu harus direproduksi dalam IDE lokal Anda, tetapi jika Anda bekerja dengan sistem nyata, Anda akan menemukan bahwa seringkali banyak bug unik untuk server produksi.
ADTC

30

Berikut daftar apa yang dimiliki "para penebang".


Apache log4j: §1 , §2

  1. FATAL:

    [ v1.2 : ..] peristiwa kesalahan sangat parah yang mungkin akan menyebabkan aplikasi dibatalkan.

    [ v2.0 : ..] kesalahan parah yang akan mencegah aplikasi melanjutkan.

  2. ERROR:

    [ v1.2 : ..] acara kesalahan yang mungkin masih memungkinkan aplikasi untuk terus berjalan.

    [ v2.0 : ..] kesalahan dalam aplikasi, mungkin dapat dipulihkan.

  3. WARN:

    [ v1.2 : ..] situasi yang berpotensi berbahaya.

    [ v2.0 : ..] acara yang mungkin [ sic ] menyebabkan kesalahan.

  4. INFO:

    [ v1.2 : ..] pesan informasi yang menyoroti kemajuan aplikasi pada tingkat berbutir kasar.

    [ v2.0 : ..] acara untuk tujuan informasi.

  5. DEBUG:

    [ v1.2 : ..] Peristiwa informasi berbutir halus yang paling berguna untuk men-debug aplikasi.

    [ v2.0 : ..] acara debugging umum.

  6. TRACE:

    [ v1.2 : ..] peristiwa informasi yang lebih halus daripada DEBUG.

    [ v2.0 : ..] pesan debug halus, biasanya menangkap aliran melalui aplikasi.


Apache Httpd (seperti biasa) suka menggunakan terlalu banyak alasan: §

  1. muncul :

    Keadaan darurat - sistem tidak dapat digunakan.

  2. waspada :

    Tindakan harus segera diambil [tetapi sistem masih dapat digunakan].

  3. kritik :

    Kondisi Kritis [tetapi tindakan tidak perlu segera diambil].

    • " soket: Gagal mendapatkan soket, keluar anak "
  4. kesalahan :

    Kondisi kesalahan [tetapi tidak kritis].

    • " Akhir skrip header yang prematur "
  5. memperingatkan :

    Kondisi peringatan [dekat dengan kesalahan, tetapi bukan kesalahan]

  6. perhatikan :

    Normal tetapi signifikan [ terkenal kondisi].

    • " httpd: tertangkap SIGBUS, mencoba untuk membuang inti di ... "
  7. info :

    Informasi [dan tidak diketahui].

    • [" Server telah berjalan selama x jam. "]
  8. debug :

    Pesan tingkat debug [, yaitu pesan yang dicatat untuk menghilangkan bug )].

    • " Membuka file konfigurasi ... "
  9. trace1trace6 :

    Lacak pesan [, yaitu pesan yang dicatat untuk melacak ].

    • " proksi: FTP: kontrol koneksi selesai "
    • " proxy: CONNECT: mengirim permintaan CONNECT ke proxy jarak jauh "
    • " openssl: Jabat tangan: mulai "
    • " baca dari brigade SSL yang disangga, mode 0, 17 byte "
    • " pencarian peta GAGAL:map=rewritemap key=keyname "
    • " pencarian cache GAGAL, ​​memaksa pencarian peta baru "
  10. trace7trace8 :

    Lacak pesan, buang data dalam jumlah besar

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache commons-logging: §

  1. fatal :

    Kesalahan parah yang menyebabkan penghentian prematur. Harapkan ini akan segera terlihat pada konsol status.

  2. kesalahan :

    Kesalahan runtime lain atau kondisi yang tidak terduga. Harapkan ini akan segera terlihat pada konsol status.

  3. memperingatkan :

    Penggunaan API yang sudah usang, penggunaan API yang buruk, kesalahan 'hampir', situasi runtime lain yang tidak diinginkan atau tidak terduga, tetapi tidak selalu "salah". Harapkan ini akan segera terlihat pada konsol status.

  4. info :

    Acara runtime yang menarik (startup / shutdown). Harapkan ini akan segera terlihat pada konsol, jadi konservatif dan tetap seminimal mungkin.

  5. debug :

    informasi terperinci tentang aliran melalui sistem. Harapkan ini ditulis hanya untuk log.

  6. melacak :

    informasi lebih rinci. Harapkan ini ditulis hanya untuk log.

Apache commons-logging "praktik terbaik" untuk penggunaan perusahaan membuat perbedaan antara debug dan info berdasarkan batasan apa yang mereka lewati.

Batas termasuk:

  • Batas Eksternal - Pengecualian yang Diharapkan.

  • Batas Eksternal - Pengecualian Tak Terduga.

  • Batas internal.

  • Batas Internal Yang Signifikan.

(Lihat panduan pembalakan bersama untuk info lebih lanjut tentang ini.)


24

Jika Anda dapat pulih dari masalah maka itu peringatan. Jika itu mencegah melanjutkan eksekusi maka itu adalah kesalahan.


5
Namun, apa perbedaan antara kesalahan dan kesalahan fatal?
user192472

37
Kesalahan adalah sesuatu yang Anda lakukan (mis. Membaca file yang tidak ada), kesalahan fatal adalah sesuatu yang dilakukan kepada Anda (misalnya kehabisan memori).
Ignacio Vazquez-Abrams

@ IgnacioVazquez-Abrams Saya suka cara Anda membedakan. Tapi apa komentar Anda didasarkan pada apa? AFIAK di antara pengembang iOS biasanya menulis pernyataan yang berhubungan dengan fatalErrorketika file tidak ada. Pada dasarnya itu kebalikan dari apa yang Anda katakan.
Sayang

@ Honey: Dalam situasi seluler, masuk akal untuk menganggap file yang hilang sebagai kesalahan fatal.
Ignacio Vazquez-Abrams

23

Saya akan merekomendasikan mengadopsi tingkat keparahan Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Lihat http://en.wikipedia.org/wiki/Syslog#Severity_levels

Mereka harus memberikan tingkat keparahan yang cukup halus untuk sebagian besar kasus penggunaan dan diakui oleh parser log yang ada. Meskipun Anda tentu saja memiliki kebebasan untuk hanya mengimplementasikan subset, misalnya DEBUG, ERROR, EMERGENCYtergantung pada persyaratan aplikasi Anda.

Mari kita standarisasi pada sesuatu yang sudah ada sejak lama alih-alih menghasilkan standar kita sendiri untuk setiap aplikasi berbeda yang kita buat. Setelah Anda mulai mengumpulkan log dan mencoba untuk mendeteksi pola di berbagai yang berbeda itu sangat membantu.


1
Saya memerlukan log jejak karena saya ingin melihat bagaimana hal-hal mengeksekusi dalam kode saya. Apa yang dilakukan syslog untuk memperbaikinya?
K - Keracunan dalam SO tumbuh.

Jejak biasanya bukan sesuatu yang ingin Anda transmisikan melalui syslog dan saya pikir Anda bebas menambahkan level ini untuk sesi debugging interaktif Anda sendiri?
kvz

2
Semua level yang diperluas ini meningkatkan kompleksitas logging IMO. Yang terbaik adalah tetap pada set paling sederhana yang melayani kebutuhan aplikasi tertentu. Bagi saya, Anda harus mulai dengan DEBUG, INFO, WARNINGdan ERROR. Pengembang harus melihat semua level. SysAdmins hingga INFO, dan Pengguna Akhir dapat melihat peringatan dan kesalahan tetapi hanya jika ada kerangka kerja untuk mengingatkan mereka tentang hal itu .
ADTC

1
(lanjutkan) Saat aplikasi matang, Anda dapat memperluas ke level yang lebih tinggi jika diperlukan. Seperti keduanya DEBUGdan TRACEbagi pengembang untuk mengontrol rincian. Dan ERRORdiperluas ke tingkat lain seperti CRITICAL, ALERT, EMERGENCYuntuk membedakan tingkat keparahan kesalahan dan menentukan tindakan berdasarkan tingkat keparahan.
ADTC

17

Peringatan yang bisa Anda pulihkan. Kesalahan Anda tidak bisa. Itu heuristik saya, orang lain mungkin punya ide lain.

Sebagai contoh, katakanlah Anda memasukkan / mengimpor nama "Angela Müller"ke dalam aplikasi Anda (perhatikan umlaut di atas u). Kode / basis data Anda mungkin hanya dalam bahasa Inggris (meskipun mungkin tidak semestinya di zaman sekarang) dan karenanya dapat memperingatkan bahwa semua karakter "tidak biasa" telah dikonversi ke karakter bahasa Inggris biasa.

Bandingkan dengan mencoba menuliskan informasi itu ke database dan mendapatkan kembali pesan jaringan selama 60 detik berturut-turut. Itu lebih merupakan kesalahan daripada peringatan.


Jika basis data dalam rangkaian karakter tertentu yang tidak termasuk umlaut, input ini harus ditolak.
Cochise Ruhulessin

Cochise, dunia jarang yang hitam dan putih :-)
paxdiablo

6

Seperti yang orang lain katakan, kesalahan adalah masalah; peringatan adalah masalah potensial.

Dalam pengembangan, saya sering menggunakan peringatan di mana saya dapat menempatkan setara dengan kegagalan pernyataan tetapi aplikasi dapat terus bekerja; ini memungkinkan saya untuk mengetahui apakah kasus itu benar-benar terjadi, atau apakah itu hanya imajinasi saya.

Tapi ya, itu turun ke aspek pemulihan dan aktualitas. Jika Anda dapat pulih, itu mungkin peringatan; jika itu menyebabkan sesuatu gagal, itu adalah kesalahan.


5

Saya pikir tingkat SYSLOG PEMBERITAHUAN dan PERINGATAN / DARURAT sebagian besar berlebihan untuk pencatatan tingkat aplikasi - sementara CRITICAL / ALERT / DARURAT mungkin tingkat peringatan berguna untuk operator yang dapat memicu tindakan dan pemberitahuan yang berbeda, untuk admin aplikasi semuanya sama seperti FATAL. Dan saya tidak bisa membedakan antara diberi pemberitahuan atau informasi. Jika informasi itu tidak penting, itu bukan benar-benar informasi :)

Saya suka interpretasi Jay Cincotta yang terbaik - melacak eksekusi kode Anda adalah sesuatu yang sangat berguna dalam dukungan teknis, dan mendorong pernyataan jejak ke dalam kode secara bebas harus didorong - terutama dalam kombinasi dengan mekanisme penyaringan dinamis untuk mencatat pesan jejak dari komponen aplikasi tertentu. Namun level DEBUG bagi saya menunjukkan bahwa kami masih dalam proses mencari tahu apa yang sedang terjadi - saya melihat output level DEBUG sebagai opsi pengembangan saja, bukan sebagai sesuatu yang seharusnya muncul dalam log produksi.

Namun ada tingkat logging yang saya suka lihat di log kesalahan saya ketika mengenakan topi sysadmin sebanyak dukungan teknis, atau bahkan pengembang: OPER, untuk pesan OPERASIONAL. Ini saya gunakan untuk mencatat cap waktu, jenis operasi yang digunakan, argumen yang diberikan, mungkin pengidentifikasi tugas (unik), dan penyelesaian tugas. Ini digunakan ketika misalnya tugas mandiri dilepaskan, sesuatu yang benar-benar merupakan doa dari dalam aplikasi yang sudah berjalan lama. Ini adalah hal yang saya ingin selalu masuk, tidak peduli apakah ada yang salah atau tidak, jadi saya menganggap tingkat OPER lebih tinggi daripada FATAL, jadi Anda hanya dapat mematikannya dengan masuk ke mode yang benar-benar hening. Dan itu jauh lebih dari sekadar data log INFO - tingkat log sering disalahgunakan untuk mengirim spam log dengan pesan operasional kecil yang tidak memiliki nilai historis apa pun.

Karena kasus menentukan informasi ini dapat diarahkan ke log doa terpisah, atau dapat diperoleh dengan menyaringnya dari log besar yang merekam informasi lebih lanjut. Tapi itu selalu diperlukan, sebagai info historis, untuk mengetahui apa yang sedang dilakukan - tanpa turun ke level AUDIT, level log lain yang benar-benar terpisah yang tidak ada hubungannya dengan kegagalan fungsi atau operasi sistem, tidak benar-benar cocok dengan level di atas ( karena perlu saklar kontrol sendiri, bukan klasifikasi tingkat keparahan) dan yang pasti membutuhkan file log yang terpisah.


5

Dari RFC 5424, Protokol Syslog (IETF) - Halaman 10:

Setiap pesan Prioritas juga memiliki indikator tingkat Severitas desimal. Ini dijelaskan dalam tabel berikut bersama dengan nilai numeriknya. Nilai keparahan HARUS berada dalam kisaran 0 hingga 7 inklusif.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

4

Hari,

Sebagai akibat wajar dari pertanyaan ini, komunikasikan interpretasi Anda tentang level log dan pastikan bahwa semua orang dalam suatu proyek selaras dalam interpretasi level tersebut.

Sangat menyakitkan untuk melihat berbagai macam pesan log di mana tingkat keparahan dan tingkat log yang dipilih tidak konsisten.

Berikan contoh jika mungkin dari berbagai tingkat logging. Dan konsistenlah dengan info yang akan dicatat.

HTH


4

Saya sepenuhnya setuju dengan yang lain, dan berpikir bahwa GrayWizardx mengatakan yang terbaik.

Yang bisa saya tambahkan adalah bahwa level-level ini umumnya sesuai dengan definisi kamus mereka, jadi tidak sulit. Jika ragu, perlakukan itu seperti puzzle. Untuk proyek khusus Anda, pikirkan segala sesuatu yang mungkin ingin Anda catat.

Sekarang, bisakah Anda mencari tahu apa yang mungkin berakibat fatal? Anda tahu apa artinya fatal, bukan? Jadi, item mana dalam daftar Anda yang fatal.

Ok, itu yang fatal, sekarang mari kita lihat kesalahan ... bilas dan ulangi.

Di bawah Fatal, atau mungkin Kesalahan, saya akan menyarankan bahwa lebih banyak informasi selalu lebih baik daripada kurang, jadi kesalahan "ke atas". Tidak yakin apakah itu Info atau Peringatan? Lalu buat peringatan.

Saya berpikir bahwa Fatal dan kesalahan harus jelas bagi kita semua. Yang lain mungkin lebih fuzzier, tetapi bisa dibilang kurang penting untuk memperbaikinya.

Berikut ini beberapa contohnya:

Fatal - tidak dapat mengalokasikan memori, database, dll - tidak dapat melanjutkan.

Kesalahan - tidak ada balasan untuk pesan, transaksi dibatalkan, tidak dapat menyimpan file, dll.

Peringatan - alokasi sumber daya mencapai X% (katakanlah 80%) - itu adalah tanda bahwa Anda mungkin ingin mengubah dimensi.

Info - pengguna log in / out, transaksi baru, file crated, bidang d / b baru, atau bidang dihapus.

Debug - dump struktur data internal, level Jejak Apa Pun dengan nama file & nomor baris.
Jejak - tindakan berhasil / gagal, d / b diperbarui.


3

Kesalahan adalah sesuatu yang salah, jelas salah, tidak ada jalan lain, perlu diperbaiki.

Peringatan adalah tanda dari pola yang mungkin salah, tetapi mungkin juga tidak.

Karena itu, saya tidak bisa memberikan contoh yang baik dari peringatan yang juga bukan kesalahan. Yang saya maksud dengan itu adalah bahwa jika Anda mengalami kesulitan mencatat peringatan, Anda mungkin juga memperbaiki masalah yang mendasarinya.

Namun, hal-hal seperti "eksekusi sql memakan waktu terlalu lama" mungkin menjadi peringatan, sementara "deadlock eksekusi sql" adalah kesalahan, jadi mungkin ada beberapa kasus.


1
Contoh peringatan yang baik adalah bahwa di MySQL, secara default, jika Anda mencoba memasukkan lebih banyak karakter dalam varchardaripada yang didefinisikan, itu memperingatkan Anda bahwa nilainya terpotong, tetapi masih menyisipkannya. Tetapi peringatan satu orang mungkin merupakan kesalahan orang lain: Dalam kasus saya, ini adalah kesalahan; itu berarti saya membuat kesalahan dalam kode validasi saya dengan mendefinisikan panjang yang tidak sesuai dengan database. Dan saya tidak akan sangat terkejut jika mesin DB lain menganggap ini sebagai kesalahan, dan saya tidak punya hak nyata untuk marah, setelah semua, itu salah.
Crast

Saya juga akan menganggap itu sebagai kesalahan. Dalam beberapa kasus, isinya adalah "teks" (bukan dalam makna tipe data), yang berarti bahwa mungkin OK untuk memotongnya. Dalam kasus lain itu adalah kode, di mana memotong bit akan merusaknya atau mengubah artinya, yang tidak OK. Menurut pendapat saya, tidak tergantung pada perangkat lunak untuk mencoba menebak apa yang saya maksud. Jika saya mencoba memaksa string 200 karakter ke dalam kolom yang hanya membutuhkan 150 karakter, itu masalah yang ingin saya ketahui. Namun, saya suka perbedaan yang dibuat oleh orang lain di sini, bahwa jika Anda dapat memulihkannya, itu peringatan, tapi kemudian ... apakah Anda perlu login?
Lasse V. Karlsen

Satu contoh yang bisa saya pikirkan adalah: Beberapa pesan butuh waktu lebih lama untuk diproses daripada biasanya. Ini mungkin merupakan indikasi bahwa ada sesuatu yang salah (mungkin beberapa sistem lain kelebihan beban atau sumber daya eksternal untuk sementara waktu turun).
Laradda

3

Saya selalu mempertimbangkan peringatan tingkat log pertama yang pasti berarti ada masalah (misalnya, mungkin file konfigurasi tidak berada di tempat yang seharusnya dan kita harus menjalankannya dengan pengaturan default). Sebuah kesalahan menyiratkan bagi saya, sesuatu yang berarti tujuan utama dari perangkat lunak sekarang tidak mungkin dan kita akan mencoba untuk mematikannya.


1

Saya telah membangun sistem sebelum itu menggunakan yang berikut:

  1. GALAT - berarti ada sesuatu yang sangat salah dan bahwa utas / proses / urutan tertentu tidak dapat melanjutkan. Diperlukan beberapa intervensi pengguna / admin
  2. PERINGATAN - ada sesuatu yang tidak beres, tetapi proses dapat berjalan seperti sebelumnya (misalnya satu pekerjaan dalam set 100 telah gagal, tetapi sisanya dapat diproses)

Dalam sistem saya telah membangun admin di bawah instruksi untuk bereaksi terhadap KESALAHAN. Di sisi lain, kami akan mengawasi PERINGATAN dan menentukan untuk setiap kasus apakah diperlukan perubahan sistem, konfigurasi ulang dll.


1

Btw, saya penggemar berat menangkap semuanya dan memfilter informasi nanti.

Apa yang akan terjadi jika Anda menangkap pada tingkat Peringatan dan ingin beberapa informasi Debug terkait dengan peringatan, tetapi tidak dapat membuat ulang peringatan?

Tangkap semuanya dan saring nanti!

Ini berlaku bahkan untuk perangkat lunak tertanam kecuali jika Anda menemukan bahwa prosesor Anda tidak dapat mengikuti, dalam hal ini Anda mungkin ingin mendesain ulang pelacakan Anda untuk membuatnya lebih efisien, atau pelacakan tersebut mengganggu waktu (Anda mungkin mempertimbangkan debugging pada prosesor yang lebih kuat, tetapi membuka seluruh kaleng cacing).

Tangkap semuanya dan saring nanti !!

(btw, tangkap semuanya juga bagus karena memungkinkan Anda mengembangkan alat untuk melakukan lebih dari sekedar menunjukkan jejak debug (Saya menggambar Bagan Urutan Pesan dari tambang, dan histogram penggunaan memori. Ini juga memberi Anda dasar untuk perbandingan jika ada kesalahan dalam di masa depan (simpan semua log, baik lulus atau gagal, dan pastikan untuk memasukkan nomor build dalam file log)).


1

Dua sen saya tentang FATALdan TRACEtingkat kesalahan log.

ERROR adalah saat beberapa KESALAHAN (pengecualian) terjadi.

FATAL sebenarnya DOUBLE FAULT: ketika pengecualian terjadi saat menangani pengecualian.

Sangat mudah dimengerti untuk layanan web.

  1. Minta datang. Acara dicatat sebagaiINFO
  2. Sistem mendeteksi ruang disk yang rendah. Acara dicatat sebagaiWARN
  3. Beberapa fungsi dipanggil untuk menangani permintaan. Sementara pemrosesan pembagian dengan nol terjadi. Acara dicatat sebagaiERROR
  4. Handler pengecualian layanan web dipanggil untuk menangani pembagian dengan nol. Layanan web / kerangka kerja akan mengirim email, tetapi tidak bisa karena layanan pengiriman surat sedang offline sekarang. Pengecualian kedua ini tidak dapat ditangani secara normal, karena penangan pengecualian layanan Web tidak dapat memproses pengecualian.
  5. Handler pengecualian berbeda disebut. Acara dicatat sebagaiFATAL

TRACEadalah saat kita dapat melacak fungsi masuk / keluar. Ini bukan tentang pencatatan, karena pesan ini dapat dibuat oleh beberapa debugger dan kode Anda belum memanggil logsama sekali. Jadi pesan yang bukan dari aplikasi Anda ditandai seperti TRACElevel. Misalnya Anda menjalankan aplikasi Anda denganstrace

Jadi secara umum dalam program Anda DEBUG, Anda lakukan , INFOdan WARNlogging. Dan hanya jika Anda menulis beberapa layanan web / kerangka kerja yang akan Anda gunakan FATAL. Dan ketika Anda sedang men-debug aplikasi, Anda akan mendapatkan TRACEpencatatan dari perangkat lunak jenis ini.


0

Saya sarankan hanya menggunakan tiga level

  1. Fatal - Yang akan merusak aplikasi.
  2. Info - Info
  3. Debug - Info kurang penting
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.