Các tệp nhật ký rất lớn, tôi nên làm gì?

( Câu hỏi này liên quan đến một vấn đề tương tự, nhưng nó nói về một tệp nhật ký được xoay.)

Hôm nay tôi nhận được một tin nhắn hệ thống liên quan đến /varkhông gian rất thấp .

Như thường lệ, tôi thực hiện các lệnh trong dòng sudo apt-get cleanchỉ cải thiện kịch bản một chút. Sau đó, tôi đã xóa các tệp nhật ký xoay mà một lần nữa cung cấp rất ít cải tiến.

Khi kiểm tra tôi thấy rằng một số tệp nhật ký trong đó /var/logđã phát triển thành những tệp rất lớn. Cụ thể, ls -lSh /var/logcho,

total 28G
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 kern.log
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 syslog
-rw-rw-r-- 1 root              utmp    390K Aug 23 21:47 wtmp
-rw-r--r-- 1 root              root    287K Aug 23 21:42 dpkg.log
-rw-rw-r-- 1 root              utmp    287K Aug 23 20:43 lastlog

Như chúng ta có thể thấy, hai người đầu tiên là những người vi phạm. Tôi hơi ngạc nhiên tại sao các tập tin lớn như vậy đã không được xoay.

Vậy, tôi nên làm gì? Đơn giản chỉ cần xóa các tập tin và sau đó khởi động lại? Hoặc đi cho một số bước thận trọng hơn?

Tôi đang sử dụng Ubuntu 14.04.

CẬP NHẬT 1

Để bắt đầu, hệ thống chỉ mới vài tháng. Tôi đã phải cài đặt hệ thống từ đầu vài tháng trước sau khi gặp sự cố với đĩa cứng.

Bây giờ, như đã khuyên trong câu trả lời này , trước tiên tôi đã kiểm tra các tệp nhật ký vi phạm bằng cách sử dụng tail, không có gì bất ngờ ở đó. Sau đó, để kiểm tra sâu hơn, tôi đã thực hiện kịch bản này từ cùng một câu trả lời .

for log in /var/log/{syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

Quá trình này mất vài giờ. Đầu ra là trong dòng,

/var/log/syslog :
71209229  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
53929977  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
17280298  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024)
       <snipped>

/var/log/kern.log.1 :
71210257  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
71209212  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)

( /dev/sda3là thư mục nhà của tôi. Như chúng ta có thể tìm thấy,

lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0 122.1G  0 part /
├─sda2   8:2    0   7.6G  0 part [SWAP]
└─sda3   8:3    0 801.8G  0 part /home

Tại sao một quá trình sẽ muốn viết vượt quá giới hạn thực sự nằm ngoài phạm vi hiểu biết của tôi. Có lẽ tôi sẽ muốn hỏi một câu hỏi khác trong diễn đàn này nếu điều này tiếp tục ngay cả sau khi cập nhật hệ thống.)

Sau đó, từ câu trả lời này (bạn có thể muốn kiểm tra điều này để hiểu sâu hơn), tôi đã thực hiện,

sudo su -
> kern.log
> syslog

Bây giờ, những tập tin này có kích thước bằng không. Hệ thống đang chạy tốt trước và sau khi khởi động lại.

Tôi sẽ xem các tệp này (cùng với các tệp khác) trong vài ngày tới và báo cáo lại nếu
chúng hoạt động ngoài luồng.

Như một lưu ý cuối cùng, cả hai tệp vi phạm ( kern.logvà syslog), được đặt thành xoay, khi kiểm tra các tệp (được greptrợ giúp) bên trong /etc/logrotate.d/hiển thị.

CẬP NHẬT 2

Các tập tin nhật ký được thực sự xoay. Có vẻ như kích thước lớn đã đạt được trong một ngày.

Đơn giản chỉ cần xóa các tập tin và sau đó khởi động lại?

Không. Làm trống chúng nhưng không sử dụng rmvì nó có thể bị hỏng thứ gì đó trong khi bạn đang gõ touchlệnh để tạo lại nó.

Phương pháp ngắn nhất:

cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

Nếu không root nó sẽ yêu cầu sudo. Lấy từ một câu trả lời khác trên AU.

TRƯỚC KHI BẠN LÀM ĐIỀU NÀY. Làm một tail {logfile}và kiểm tra nếu có một lý do cho họ là rất lớn. Trừ khi hệ thống này đã được vài năm tuổi, không nên có lý do cho việc này và khắc phục vấn đề tốt hơn là để điều này tiếp diễn.

Cả kern.log và syslog thường không nên lớn như vậy. Nhưng như tôi đã nói: nếu hệ thống này hoạt động trong nhiều năm và nhiều năm thì nó có thể là bình thường và các tập tin chỉ cần được xóa.

Và để ngăn chặn nó trở nên lớn trong tương lai: thiết lập logrotate. Nó khá đơn giản và sẽ nén logfile khi nó trở nên lớn hơn sau đó kích thước bạn đặt nó thành.

1 điều khác: nếu bạn không muốn xóa nội dung, bạn có thể nén các tập tin bằng cách tarring hoặc gzipping chúng. Điều đó sẽ khiến bạn kết thúc với các tập tin có thể là 10% so với hiện tại. Đó là nếu vẫn còn chỗ trên đĩa để làm điều đó.

Có lẽ đáng để thử thiết lập những gì đang điền (các) nhật ký - bằng cách kiểm tra chúng một cách trực quan bằng cách sử dụng lệnh lesshoặctail

tail -n 100 /var/log/syslog

hoặc nếu các dòng vi phạm bị chôn quá sâu để dễ dàng nhìn thấy những gì đang xảy ra, đại loại như

for log in /var/log/{dmesg,syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

(lưu ý: việc này có thể mất một chút thời gian, với các tệp lớn như vậy) sẽ cố gắng loại bỏ dấu thời gian và sau đó đếm các tin nhắn thường xuyên xảy ra nhất.

Phương pháp của tôi cho các tệp nhật ký hệ thống sạch là đây. Bước 1 và 2 là tùy chọn, nhưng đôi khi bạn cần kiểm tra nhật ký cũ và sao lưu đôi khi hữu ích. ;-)

1. Tùy chọn: Sao chép tệp nhật ký

   cp -av --backup=numbered file.log file.log.old
   

2. Tùy chọn: Sử dụng Gzip trên bản sao nhật ký

   gzip file.log.old
   

3. Sử dụng / dev / null cho tệp sạch

   cat /dev/null > file.log
   

Và chúng tôi sử dụng cho nhật ký này (chỉ trên một số máy chủ) logrotate và thực thi hàng tuần bằng tập lệnh cron mà tất cả các tệp có * .1 (hoặc xoay tiếp theo) được nén bằng gzip.

Tôi đã cài đặt Ubuntu 16.04 ngày hôm nay và tôi nhận thấy vấn đề tương tự. Tuy nhiên, tôi đã sửa lỗi này với busybox-syslogd. Vâng Tôi vừa cài đặt gói đó và vấn đề đã được giải quyết. :)

$ sudo apt-get install busybox-syslogd

Sau khi cài đặt gói đó, đặt lại syslogvà kern.log:

sudo tee /var/log/syslog /var/log/kern.log </dev/null

Tôi hy vọng giải pháp đơn giản này hữu ích cho những người xung quanh.