Apakah boleh menggunakan tail -f pada file log besar

Saya ingin memonitor file log besar (hampir 1 GB) untuk kesalahan. Saya ingin ini mendekati waktu nyata (penundaan beberapa detik tidak masalah). Rencana saya adalah menggunakan tail -f | grep. Apakah ada masalah kinerja dengan menggunakan metode seperti itu ketika menjalankannya dalam waktu yang lama, katakanlah dari nol byte menjadi 1 GB? Apakah ada praktik standar yang digunakan untuk pemantauan semacam itu. Perhatikan bahwa saya ingin melakukan ini menggunakan perintah unix standar yang tersedia di Solaris 10.

Jika itu mungkin, file saya bahkan berguling dan saya punya satu masalah lagi untuk menyelesaikan :). menggunakan tail -F( --follow=name) bukan pilihan bagi saya karena -Ftidak didukung di server saya ingin menjalankan ini. Rencana saya adalah menggunakan skrip yang akan memulai ekor ini dan polling untuk mengetahui apakah file tersebut terguling. Jika ya, maka bunuh ekornya dan mulai lagi. Adakah pendekatan yang lebih baik?

logs monitoring tail

— Manoj NV
sumber

Maksudmu "bunuh tail", kan?

— Stéphane Gimenez

Ya, "bunuh ekor", tidak ditemukan. Terima kasih, edit pertanyaan

— Manoj NV

Jika file berukuran 2 GB tidak mengandung karakter baris baru, bagaimana cara kerja tail?

Jawaban:

Pada sistem linux saya (GNU coreutils 8.12), saya dapat memeriksa (menggunakan strace) bahwa tail -f¹ menggunakan lseekpanggilan sistem untuk melewatkan sebagian besar file dengan cepat:

lseek(3, 0, SEEK_CUR)                   = 0
lseek(3, 0, SEEK_END)                   = 194086
lseek(3, 188416, SEEK_SET)              = 188416

Ini berarti bahwa ukuran file yang dilacak seharusnya tidak menjadi masalah.

Mungkin Anda dapat memeriksa apakah hal yang sama berlaku pada sistem Anda. (Jelas, seharusnya begitu.)

-
^{1. Saya juga mencoba menonaktifkan dukungan tidak sah dengan yang tidak berdokumen ---disable-inotify, untuk berjaga-jaga.}

— Stéphane Gimenez
sumber

Pria Sejati membaca sumbernya (:

— Gilles 'SO- stop being evil'

@Gilles. Saya tidak bisa mengajari OP (atau pembaca) cara membaca sumbernya jika dia belum tahu. Jauh lebih mudah untuk memberitahunya untuk menggunakan strace;)

— Stéphane Gimenez

Sebenarnya, pada sistem di mana tail -Ftidak didukung, kemungkinan itu stracetidak tersedia ...

— Stéphane Gimenez

trussadalah utilitas yang sesuai pada Solaris.

— Gilles 'SO- stop being evil'

dan itu menunjukkan panggilan mencari serupa. llseek (0, 0, SEEK_CUR) = 0, llseek (0, 0xFFFFFFFFFFF5FFF6, SEEK_END) = 7923269

— jlliagre

Jika itu dipanggil pada file biasa (tidak seperti pipa), baik GNU tail dan OpenBSD tail (kecuali dipanggil dengan -n +N) mencari di akhir file, kemudian bekerja mundur untuk menemukan garis di mana ia harus mulai mencetak. Saya tidak tahu apakah Solaris melakukan hal yang sama, tetapi ini merupakan pendekatan yang masuk akal, jadi saya berharap sebagian besar persatuan melakukan hal yang sama. Oleh karena itu ukuran file tidak relevan untuk kinerja.

— Gilles 'SANGAT berhenti menjadi jahat'
sumber

Saya melakukan ini setiap hari. Saya biasanya memindai selusin log pada server pengujian dan produksi kami menggunakan tail -f logs/*.{log,err,out}. Pemuatan awal agak banyak (tergantung pada jumlah file di-globbed), tetapi setelah itu, streaming real-time.

Alih-alih mengirim ke grep, saya menggunakan execfungsionalitas di screenkarena saya ingin umumnya melihat semua output (untuk traceback penuh dan pesan yang terkait dengan masalah ini). Sebagai contoh,

!:sed -n s/.*Exception.*/\007/p

Untuk menyebabkan terminal berbunyi bip (atau flash) setiap kali kata Pengecualian ditemukan.

— Arcege
sumber