Mengapa sebagian besar file log menggunakan teks biasa daripada format biner?

Penebangan adalah sesuatu yang perlu tetapi jarang digunakan. Karena itu dapat dibuat jauh lebih kompak dalam hal penyimpanan.

Misalnya data yang paling umum dicatat seperti ip, tanggal, waktu dan data lain yang dapat direpresentasikan sebagai bilangan bulat sedang disimpan sebagai teks.

Jika logging disimpan sebagai data biner, banyak ruang dapat dipertahankan sehingga membutuhkan lebih sedikit rotasi dan meningkatkan masa pakai disk, terutama dengan SSD di mana penulisan terbatas.

Beberapa orang mungkin mengatakan bahwa ini adalah masalah kecil sehingga tidak terlalu penting, tetapi dengan mempertimbangkan upaya yang diperlukan untuk membangun mekanisme seperti itu, tidak masuk akal untuk tidak melakukannya. Siapa pun dapat membuat ini selama dua hari di waktu luangnya, mengapa orang tidak melakukannya?

systemdterkenal menyimpan file log-nya dalam format biner. Masalah utama yang saya dengar dengan itu adalah:

1. jika log rusak maka sulit dipulihkan karena membutuhkan perkakas khusus
2. mereka tidak dapat dibaca manusia, sehingga Anda tidak dapat menggunakan alat standar seperti vi, grep, taildll untuk menganalisis mereka

Alasan utama untuk menggunakan format biner (setahu saya) adalah karena itu dianggap lebih mudah untuk membuat indeks dll yaitu memperlakukannya lebih seperti file database.

Saya berpendapat bahwa keunggulan ruang disk relatif kecil (dan berkurang) dalam praktiknya. Jika Anda ingin menyimpan logging dalam jumlah besar, maka zipping log yang digulung benar-benar cukup efisien.

Pada keseimbangan, keuntungan dari tooling dan keakraban mungkin akan keliru di sisi pencatatan teks dalam banyak kasus.

Mengapa sebagian besar file log menggunakan teks biasa daripada format biner?

Cari kata "teks" di artikel Wikipedia filsafat Unix , misalnya Anda akan menemukan pernyataan seperti:

McIlroy, kemudian kepala Bell Labs CSRC (Computing Sciences Research Center), dan penemu pipa Unix, [9] merangkum filosofi Unix sebagai berikut: [10]

Ini adalah filosofi Unix: Menulis program yang melakukan satu hal dan melakukannya dengan baik. Menulis program untuk bekerja bersama. Menulis program untuk menangani aliran teks, karena itu adalah antarmuka universal.

Atau misalnya, dari Basics of the Unix Philosophy ,

Rule of Composition: Merancang program yang akan dihubungkan dengan program lain.

Sulit untuk menghindari pemrograman monolit yang terlalu rumit jika tidak ada program Anda yang dapat saling berbicara.

Tradisi Unix sangat mendorong program penulisan yang membaca dan menulis format sederhana, tekstual, berorientasi aliran, dan tidak tergantung pada perangkat. Di bawah Unix klasik, sebanyak mungkin program ditulis sebagai filter sederhana, yang mengambil aliran teks sederhana pada input dan memprosesnya menjadi aliran teks sederhana pada output.

Meskipun mitologi populer, praktik ini disukai bukan karena programmer Unix membenci antarmuka pengguna grafis. Itu karena jika Anda tidak menulis program yang menerima dan memancarkan aliran teks sederhana, itu jauh lebih sulit untuk menyatukan program.

Text stream adalah untuk alat Unix sebagai pesan ke objek dalam pengaturan berorientasi objek. Kesederhanaan antarmuka aliran teks memaksa enkapsulasi alat. Bentuk komunikasi antar proses yang lebih rumit, seperti panggilan prosedur jarak jauh, menunjukkan kecenderungan terlalu banyak melibatkan program dengan internal satu sama lain.

Siapa pun dapat membuat ini selama dua hari di waktu luangnya, mengapa orang tidak melakukannya?

Menyimpan file log dalam biner hanyalah awal (dan sepele). Anda kemudian perlu menulis alat untuk:

• Tampilkan seluruh file log ( edit)
• Tampilkan akhir log, tanpa membaca bagian awal ( tail -f)
• Cari barang di file ( grep)
• Filter untuk hanya menampilkan hal-hal yang dipilih / menarik (menggunakan ekspresi filter yang rumit rumit)
• Email log ke orang lain yang tidak memiliki perangkat lunak log-file-decoder Anda
• Salin dan tempel fragmen file log
• Baca file log saat program (yang membuat file log) masih dikembangkan dan didebug
• Baca file log dari versi lama perangkat lunak (yang digunakan di situs pelanggan dan berjalan).

Jelas perangkat lunak dapat dan memang menggunakan format file biner juga (misalnya untuk database relasional) tetapi tidak bermanfaat (dalam arti YAGNI ), biasanya tidak layak dilakukan, untuk file log.

Ada banyak anggapan yang bisa diperdebatkan di sini.

Penebangan telah menjadi bagian integral dari (hampir) setiap pekerjaan yang saya miliki. Sangat penting jika Anda ingin segala jenis visibilitas pada kesehatan aplikasi Anda. Saya ragu bahwa ini adalah penggunaan "pinggiran"; kebanyakan organisasi yang pernah saya ikuti menganggap log sangat penting.

Menyimpan log sebagai biner berarti Anda harus memecahkan kode sebelum dapat membacanya. Log teks memiliki keutamaan kesederhanaan dan kemudahan penggunaan. Jika Anda merenungkan rute biner, Anda sebaiknya menyimpan log dalam database sebagai gantinya, di mana Anda dapat menginterogasinya dan menganalisisnya secara statistik.

SSD lebih dapat diandalkan daripada HDD saat ini, dan argumen terhadap banyak penulisan sebagian besar diperdebatkan. Jika Anda benar-benar khawatir tentang hal itu, simpan log Anda pada HDD biasa.

File log adalah bagian penting dari setiap aplikasi serius: jika login dalam aplikasi itu bagus, maka mereka membiarkan Anda melihat peristiwa kunci yang telah terjadi dan kapan; kesalahan apa yang terjadi; dan kesehatan aplikasi umum yang melampaui pemantauan apa pun yang telah dirancang. Biasanya mendengar masalah, memeriksa diagnostik bawaan aplikasi (buka konsol web-nya atau gunakan alat diagnostik seperti JMX), lalu gunakan untuk memeriksa file log.

Jika Anda menggunakan format non-teks, maka Anda segera dihadapkan dengan rintangan: bagaimana Anda membaca log biner? Dengan alat membaca log, yang tidak ada di server produksi Anda! Atau itu, tapi oh sayang, kami telah menambahkan bidang baru dan ini adalah pembaca lama. Bukankah kita menguji ini? Ya, tapi tidak ada yang menyebarkannya di sini. Sementara itu, layar Anda mulai menyala dengan pengguna mem-ping Anda.

Atau mungkin ini bukan aplikasi Anda, tetapi Anda sedang melakukan dukungan dan Anda pikir Anda tahu itu adalah sistem lain ini, dan WTF? log dalam format biner? Oke, mulailah membaca halaman wiki, dan dari mana Anda memulai? Sekarang saya sudah menyalinnya ke mesin lokal saya, tetapi - mereka rusak? Sudahkah saya melakukan semacam transfer non-biner? Atau apakah alat baca log kacau?

Singkatnya, alat membaca teks bersifat lintas platform dan ada di mana-mana, dan log sering kali berumur panjang dan kadang-kadang perlu dibaca dengan tergesa-gesa . Jika Anda menemukan format biner, maka Anda terputus dari seluruh dunia alat yang dimengerti dan mudah digunakan. Hilangnya fungsi serius hanya saat Anda membutuhkannya.

Sebagian besar lingkungan pencatatan mendapat kompromi: menjaga agar log saat ini dapat dibaca dan ada, dan kompres yang lama. Itu berarti Anda mendapatkan manfaat kompresi - lebih dari itu, sebenarnya, karena format biner tidak akan menyusutkan pesan log. Pada saat yang sama, Anda dapat menggunakan lebih sedikit dan grep dan sebagainya.

Jadi, manfaat apa yang mungkin muncul dari menggunakan biner? Sejumlah kecil efisiensi ruang - semakin tidak penting. Lebih sedikit (atau lebih kecil) menulis? Yah, mungkin - sebenarnya, jumlah penulisan akan berhubungan dengan jumlah disk-commit, jadi jika log-line secara signifikan lebih kecil dari ukuran disk, maka SSD akan menetapkan blok baru berulang-ulang. Jadi, biner adalah pilihan yang tepat jika:

• Anda menulis sejumlah besar data terstruktur
• log harus dibuat dengan cepat
• Anda tidak perlu menganalisisnya di bawah "kondisi dukungan"

tapi ini terdengar kurang seperti aplikasi logging; ini adalah file output atau catatan aktivitas. Menempatkan mereka di file mungkin hanya satu langkah lagi dari menulisnya ke database.

SUNTING

Saya pikir ada kebingungan umum di sini antara "log program" (sesuai kerangka kerja logging) vs "catatan" (seperti dalam log akses, catatan login dll). Saya kira pertanyaannya berkaitan paling dekat dengan yang terakhir, dan dalam hal ini masalahnya jauh lebih tidak jelas. Sangat dapat diterima untuk catatan pesan atau log aktivitas dalam format yang ringkas, terutama karena itu cenderung didefinisikan dengan baik dan digunakan untuk analisis daripada pemecahan masalah. Alat yang melakukan ini termasuk tcpdumpdan monitor sistem Unix sar. Log program di sisi lain cenderung lebih ad hoc.

Contoh log biner agak tersebar luas: log peristiwa Windows. Di sisi pro, ini memungkinkan pesan log menjadi cukup bertele-tele (dan dengan demikian mudah-mudahan bermanfaat) dengan hampir tanpa biaya, mungkin sesuatu seperti

Peringatan: Antrian foobars untuk dilakukan telah bertambah sebanyak 517 item selama 90 detik terakhir. Jika ini terjadi sekali sehari, tidak ada yang perlu dikhawatirkan. Jika itu terjadi lebih sering atau berturut-turut cepat, Anda mungkin ingin memeriksa jumlah RAM yang tersedia untuk aplikasi foobar. Namun, jika itu terjadi bersamaan dengan peristiwa 12345, Anda tampaknya menggunakan basis data usang dan Anda sebaiknya menghubungi dukungan di + 1-555-12345 untuk mencegah kehilangan data.

Bagian utama dari pesan ini hanya ada satu kali sebagai sumber daya yang diinstal dengan aplikasi. Namun, jika sumber daya ini tidak diinstal dengan benar (misalnya, karena sementara itu versi yang lebih baru telah diinstal yang tidak lagi mendukung pesan usang ini), semua yang Anda lihat di log peristiwa adalah pesan standar yang hanya ingin dituliskan untuk

Entahlah, sesuatu dengan "517" dan "90".

dan tidak lagi membantu dengan cara apa pun.

Dua pertanyaan utama yang ingin Anda tanyakan sebelum memilih antara teks dan biner adalah:

• Siapa audiens saya?
• Konten apa yang perlu saya sampaikan?

Pendapat umum adalah bahwa pemirsa pesan log adalah manusia. Ini jelas bukan asumsi yang sempurna, karena ada banyak skrip perayapan log di luar sana, tetapi itu adalah yang umum. Dalam hal ini, masuk akal untuk menyampaikan informasi dalam media yang nyaman bagi manusia. Teks memiliki tradisi lama sebagai medium ini.

Adapun konten, pertimbangkan bahwa log biner harus memiliki format yang terdefinisi dengan baik. Formatnya harus cukup jelas bagi orang lain untuk menulis perangkat lunak yang beroperasi pada log tersebut. Beberapa log terstruktur dengan cukup baik (pertanyaan Anda mencantumkan beberapa). Log lain membutuhkan kemampuan untuk menyampaikan konten dalam bentuk bahasa alami yang kurang jelas. Kasus bahasa alami semacam itu tidak cocok untuk format biner.

Untuk log yang bisa dideskripsikan dengan baik dalam biner, Anda harus membuat pilihan. Karena teks berfungsi untuk semua orang, ini sering dilihat sebagai pilihan default. Jika Anda mencatat hasil Anda dalam teks, orang-orang dapat bekerja dengan log Anda. Sudah terbukti ribuan kali. File biner lebih rumit. Akibatnya, mungkin para pengembang membuat teks hanya karena semua orang tahu seperti apa perilakunya.

TL; DR: Ukuran tidak terlalu penting, tetapi kenyamanan dalam menggunakannya tidak masalah

Pertama-tama, sementara membandingkan keunggulan masing-masing format teks dan biner untuk penyimpanan log jangka pendek adalah pertanyaan penting, ukurannya tidak terlalu menjadi masalah. Dua alasan untuk ini adalah:

1. Log adalah informasi yang sangat berlebihan yang akan memampatkan dengan sangat baik: menurut pengalaman saya, tidak jarang melihat file log terkompresi yang ukurannya 5% atau kurang dari ukuran file asli. Akibatnya, menggunakan teks atau format biner seharusnya tidak memiliki dampak yang terukur pada penyimpanan lama log.

2. Apa pun format yang kita pilih, log akan dengan cepat mengisi disk server jika kita tidak menerapkan "log files sink" yang memampatkan dan mengirim file log ke platform penyimpanan jangka panjang. Menggunakan format biner bisa memperlambat ini sedikit tetapi bahkan perubahan dengan faktor 10 tidak akan menjadi masalah banyak.

Teks versus format log biner

Janji dari sistem Unix adalah bahwa, jika kita belajar menggunakan toolset standar yang bekerja pada file teks yang terstruktur dalam garis - seperti grep , sortir , gabung , sed dan awk - kita akan dapat menggunakannya untuk dengan cepat mengumpulkan prototipe yang melakukan pekerjaan apa pun kami ingin, meskipun lambat dan kasar. Setelah prototipe menunjukkan kegunaannya, kita dapat memilih untuk mengubahnya menjadi perangkat lunak yang benar-benar dirancang untuk mendapatkan kinerja atau menambahkan fitur bermanfaat lainnya. Ini, setidaknya dalam pemahaman saya, esensi dari filosofi Unix.

Dengan kata lain, jika kita perlu melakukan perawatan dan analisis, kita tidak dapat mengetahuinya hari ini, jika kita tidak tahu siapa yang harus mengimplementasikan analisis ini, dll. Maka kita berada pada tahap di mana prototipe harus digunakan dan format teks untuk log mungkin optimal. Jika kita perlu berulang kali melakukan serangkaian kecil perawatan yang teridentifikasi dengan baik, maka kita berada dalam situasi di mana kita harus merekayasa sistem perangkat lunak abadi untuk melakukan analisis ini dan format biner atau terstruktur untuk log, seperti database relasional, kemungkinan akan menjadi optimal.

(Beberapa waktu yang lalu, saya menulis posting blog tentang ini.)

File log dalam format teks karena mereka dapat dengan mudah dibaca menggunakan semua jenis editor teks atau dengan menampilkan konten melalui perintah konsol.

Namun, beberapa file log dalam format biner jika ada banyak data. Sebagai contoh, produk yang saya kerjakan menyimpan maksimum 15000 catatan. Untuk menyimpan catatan dalam jumlah kamar paling sedikit, mereka disimpan dalam biner. Namun, aplikasi khusus harus ditulis untuk melihat catatan atau mengonversinya menjadi format yang dapat digunakan (mis. Spreadsheet).

Singkatnya, tidak semua file log dalam format teks. Format teks memiliki keuntungan bahwa alat kustom tidak diperlukan untuk melihat konten. Di mana ada banyak data, file tersebut mungkin dalam format biner . Format biner akan membutuhkan aplikasi (khusus) untuk membaca data dan menampilkannya dalam format yang dapat dibaca manusia. Lebih banyak data dapat dikemas ke dalam format biner. Apakah akan menggunakan format teks atau format biner adalah keputusan berdasarkan jumlah data dan kemudahan melihat konten.

Dalam sistem tertanam di mana saya mungkin tidak memiliki saluran output yang tersedia selama waktu berjalan, aplikasi tidak mampu membayar kecepatan yang dikenakan oleh logging, atau logging akan mengubah atau menutupi efek yang saya coba rekam, saya sudah sering terpaksa memasukkan data biner ke dalam array atau buffer cincin, dan mencetaknya pada akhir uji coba atau membuangnya mentah-mentah dan menulis penerjemah untuk mencetaknya agar dapat dibaca. Either way, saya ingin berakhir dengan data yang dapat dibaca.

Dalam sistem dengan lebih banyak sumber daya, mengapa menemukan skema untuk mengoptimalkan apa yang tidak perlu dioptimalkan?

File log dimaksudkan untuk membantu debugging masalah. Biasanya, ruang hard drive jauh lebih murah daripada waktu rekayasa. File log menggunakan teks karena ada banyak alat untuk bekerja dengan teks (seperti tail -f). Bahkan HTTP menggunakan teks biasa (lihat juga mengapa kita tidak mengirim biner alih-alih teks pada http ).

Selain itu, lebih murah untuk mengembangkan sistem pencatatan teks biasa dan memverifikasi bahwa sistem itu berfungsi, lebih mudah untuk debug jika terjadi kesalahan, dan lebih mudah untuk memulihkan informasi yang berguna jika sistem gagal dan merusak bagian dari log.

File teks yang rusak masih dapat dibaca di sekitar bagian yang rusak. File biner yang rusak mungkin dapat dipulihkan, tetapi mungkin juga tidak. Bahkan jika itu dapat dihidupkan kembali, itu akan membutuhkan sedikit lebih banyak pekerjaan. Alasan lainnya adalah bahwa format pencatatan biner membuatnya lebih kecil kemungkinannya ketika terburu-buru untuk membuat "perbaikan sementara" (alias "yang paling permanen dari semua perbaikan") solusi pencatatan akan digunakan alih-alih sesuatu yang dapat dibuat lebih cepat.

Kami mengandalkan pengujian unit untuk mencapai dan mempertahankan kekokohan perangkat lunak kami. (Sebagian besar kode kami berjalan di server, tanpa kepala; analisis file log pasca operasi adalah strategi utama.). Hampir setiap kelas dalam implementasi kami melakukan logging. Bagian penting dari pengujian unit kami adalah penggunaan penebang 'tiruan' yang digunakan saat pengujian unit. Tes unit membuat logger tiruan dan menyediakannya untuk item yang sedang diuji. Kemudian (bila berguna / sesuai) menganalisis apa yang dicatat (terutama kesalahan dan peringatan). Menggunakan format log berbasis teks membuat ini jauh lebih mudah karena alasan yang sama seperti analisis yang dilakukan pada log 'nyata': ada lebih banyak alat yang Anda inginkan yang cepat digunakan dan beradaptasi.

Secara historis, Log adalah catatan acara resmi, tulisan tangan, dan berurutan. Ketika mesin menjadi mampu merekam peristiwa, ini ditulis ke perangkat output hard-copy seperti printer teletype, yang menghasilkan catatan sekuensial permanen tetapi yang hanya bisa memproses teks, dan kadang-kadang ...

Kembali di masa mainframe saya, kami menggunakan format log biner yang dirancang khusus. Alasan utama bukan untuk menghemat ruang, itu karena kami ingin log menempati ruang terbatas dengan menimpa entri lama dengan yang baru; hal terakhir yang kami inginkan adalah tidak dapat mendiagnosis masalah yang disebabkan oleh disk menjadi penuh (pada tahun 1980 ruang disk digunakan untuk biaya $ 1000 / Mb, sehingga orang tidak membeli lebih dari yang mereka butuhkan).

Sekarang saya masih menyukai gagasan file log bundar, dan jika sistem operasi menawarkan binatang seperti itu saya akan menggunakannya tanpa ragu-ragu. Tapi biner adalah ide yang buruk. Anda benar-benar tidak ingin membuang waktu untuk menemukan perintah yang tepat untuk menguraikan file log ketika Anda memiliki masalah kritis untuk dipecahkan.