rsyslog với logrotate: tải lại rsyslog vs copytruncate

Tôi đang làm việc trên Ubuntu 14 với tiện ích rsyslog và logrotate mặc định.

Trong /etc/logrotate.d/rsyslogcấu hình rsyslog logrotate mặc định tôi thấy như sau:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Theo những gì tôi hiểu, nên sử dụng copytruncate trong tất cả các kịch bản logrotate, vì nó không di chuyển nhật ký hiện tại, nhưng cắt ngắn nhật ký để bất kỳ quy trình nào với trình xử lý tệp mở sẽ có thể tiếp tục ghi vào nó.

Vì vậy, làm thế nào đến cấu hình mặc định sử dụng tính năng tải lại rsyslog thay thế?

Để trả lời câu hỏi của bạn, trước tiên bạn cần hiểu sự đánh đổi khác nhau của tải lại và sao chép:

• tải lại : tệp nhật ký cũ được đổi tên và quá trình ghi vào nhật ký đó được thông báo (thông qua tín hiệu Unix) để tạo lại tệp nhật ký của nó. Đây là phương pháp nhanh nhất / thấp hơn: hoạt động đổi tên / di chuyển rất nhanh và có thời gian thực hiện liên tục. Hơn nữa, đây là một hoạt động gần như nguyên tử: điều này có nghĩa là (gần như) không có mục nhật ký nào sẽ bị mất trong quá trình di chuyển / tải lại. Mặt khác, bạn cần một quy trình có khả năng tải lại và mở lại tệp nhật ký của nó. Rsyslog là một quá trình như vậy, vì vậy cấu hình logrotate mặc định sử dụng phương thức tải lại. Sử dụng chế độ này với rsyslog được khuyến khích mạnh mẽ bởi rsyslog ngược dòng.
• copytruncate : tệp nhật ký cũ được sao chép vào một tệp lưu trữ, và sau đó nó được cắt bớt để "xóa" các dòng nhật ký cũ. Mặc dù thao tác cắt ngắn rất nhanh, bản sao có thể khá dài (tùy thuộc vào mức độ lớn của tệp logfile của bạn). Hơn nữa, một số mục nhật ký có thể bị mất trong thời gian giữa thao tác sao chép (hãy nhớ rằng nó có thể bị chậm) và cắt ngắn. Vì những lý do này, copytruncate không được sử dụng theo mặc định cho các dịch vụ có khả năng tải lại và tạo lại tệp nhật ký của chúng. Mặt khác, nếu một máy chủ không có khả năng tải lại / tạo lại các tệp nhật ký, copytruncate là đặt cược an toàn nhất của bạn. Nói cách khác, nó không yêu cầu bất kỳ hỗ trợ cấp dịch vụ nào. Dự án ngược dòng rsyslog khuyên không nên sử dụng chế độ này.

Nói như tác giả rsyslog, copytruncate thực sự là một lựa chọn rất, rất, rất xấu. Nó vốn dĩ không phù hợp và sử dụng nó gần như là một đảm bảo rằng bạn sẽ mất dữ liệu nhật ký. Tập tin được viết càng thường xuyên, bạn sẽ càng mất nhiều hơn. Và đây không chỉ là một phần của dòng cuối cùng, mà có thể là vài trăm cái, tùy thuộc vào thời gian và trạng thái chính xác của hệ thống tại thời điểm xoay vòng xảy ra.

Khi tệp được di chuyển và một nút (tệp) mới được tạo, rsyslog sẽ theo dõi tệp trước đó và xử lý hoàn tất. Vì vậy, bạn không có bất kỳ mất mát trong trường hợp này. Được đảm bảo (trừ khi bạn ngắt kết nối hệ thống tệp ...).

Trên "reopenOnTruncate": Cá nhân tôi đã thấy reopenOnTruncate cũng không phù hợp, đặc biệt là với NFS và tương tự. Cách đây một thời gian, tôi đã loại bỏ hoàn toàn chức năng đó, nhưng sau đó đã thuyết phục được hợp nhất chức năng tương tự trở lại. Nó sẽ tồn tại "thử nghiệm" nhất có thể mãi mãi, vì tôi thực sự biết mọi người gặp rắc rối trên các hệ thống được tải rất nặng. "copytruncate" đơn giản là không có chế độ phù hợp để làm việc với các tệp nhật ký.

Tôi hiện đang làm việc về tái cấu trúc imfile (ETA 8.34 hoặc 8.35). Phiên bản được cấu trúc lại có thể sẽ ngăn chặn việc gửi lại ngẫu nhiên do cuộc đua API, nhưng cũng không thể bảo vệ chống mất dữ liệu - bởi vì điều này về mặt khái niệm là không thể.

Điều này phụ thuộc hoàn toàn vào quá trình viết nhật ký.
copytruncatechỉ hoạt động, nếu các thông điệp log sẽ được nối vào tập tin (ví dụ whatever >> logfile.
Và không phải khi nó được chuyển hướng đầu ra (ví dụ whatever > logfile).

Vì phiên bản 8.16 rsyslog có tùy chọn reopenOnTruncateimfile xử lý vấn đề copytruncte.

Đối với rsyslog cụ thể, có lẽ sẽ có ý nghĩa hơn khi để mọi thứ như hiện tại.

Lý do cơ bản là rsyslog có hàng đợi nội bộ mà nó có thể sử dụng trong trường hợp xử lý đầu ra của nó không khả dụng.

Việc tải lại sẽ a) khiến rsyslog tạo lại tệp nhật ký của chính nó và b) khiến bất kỳ sự kiện xếp hàng nào được chuyển sang tệp khi tạo.

Nó có thể là copytruncate không gây hại (mặc dù tôi sẽ lo lắng về việc các dòng được viết một phần bị cắt bớt), nhưng tôi có xu hướng nghĩ rằng sao chép / xóa / tải lại là 'an toàn hơn' từ quan điểm toàn vẹn.

Như được đề cập bởi @ faker , vì rsyslog có thể xử lý tình huống khi tệp của nó không khả dụng, nên không có lý do thuyết phục để sử dụng copytruncate.

Và như được đề cập bởi @ SelivanovPavel , rsyslog thực sự yêu cầu cấu hình cụ thể để xử lý việc sao chép chính xác.

Vì vậy, nếu chỉ vì sử dụng cách reloadtiếp cận yêu cầu ít sai lệch so với cấu hình mặc định, tôi sẽ giữ nó.