CẬP NHẬT 2: Tôi đã trả lời câu hỏi này qua câu hỏi mới của mình tại liên kết bên dưới. Nguyên nhân gốc rễ là hành vi của telegraf trong đó theo mặc định, nó sẽ ngắt kết nối TCP 5 giây sau khi nhận được tin nhắn cuối cùng. Điều này có thể là do thiết kế, tuy nhiên tôi gặp vấn đề với tài liệu của họ khiến tôi khó phát hiện ra đây là một giải pháp khắc phục tiềm năng.
Có lẽ câu hỏi này bây giờ có thể bị xóa?
CẬP NHẬT 1: thay vì chỉnh sửa rộng rãi câu hỏi này, làm cho các câu trả lời hiện tại trở nên vô nghĩa, tôi đã đặt một câu hỏi mới dựa trên thông tin mới mà tôi nhận được do đăng câu hỏi này.
syslog-ng/telegraf: EOF xảy ra khi không hoạt động - không tương thích?
Tôi đang sử dụng syslog-ng Open-Source Edition (OSE) v3.31.2 trong ngăn xếp docker-compose.
Tôi có các thông báo nhật ký hệ thống đến qua mạng từ nhiều máy chủ khác nhau thông qua UDP (tôi bị hạn chế bởi vì khách hàng của tôi sử dụng Boost::Log và điều này không hỗ trợ nhật ký hệ thống qua TCP, chỉ UDP) và tôi đã đặt syslog-ng để chuyển tiếp những thứ này đến một dịch vụ khác ở hạ lưu. Điều này xảy ra là telegraf sử dụng một đầu vào.syslog mô-đun, nhưng tôi không chắc điều đó có quan trọng không.
Cấu hình của tôi trông như thế này:
phiên bản @: 3.29
@bao gồm "scl.conf"
tùy chọn {
flush-lines(1);
};
nguồn s_mạng {
udp(ip(0.0.0.0) cổng(514));
};
đích d_file {
tệp ("/var/log/tin nhắn");
};
điểm đến d_telegraf {
nhật ký hệ thống (cổng "telegraf" (6514) vận chuyển (tcp));
};
nhật ký {
nguồn(s_mạng);
điểm đến (d_telegraf);
đích (d_file);
};
Tôi đã thiết lập rõ ràng toàn cầu tuôn ra dòng giá trị thành 1. Tôi nghĩ đây là giá trị mặc định, nhưng tôi muốn chắc chắn. Tôi muốn thông báo tường trình được chuyển tiếp ngay khi nhận được.
Hầu hết thời gian điều này hoạt động - các "dòng" nhật ký riêng lẻ đến syslog-ng qua UDP 514 và ngay lập tức được ghi vào tệp /var/log/tin nhắnvà trong hầu hết các trường hợp, chúng cũng được chuyển tiếp ngay lập tức tới telegraf trên cổng TCP 6514.
Vấn đề tôi đang thấy là khá thường xuyên syslog-ng giữ lại nhiều dòng nhật ký đến trong khoảng 30-60 giây, sau đó gửi chúng đến telegraf trong một đoạn lớn. Dường như không có nhiều khuôn mẫu cho điều này, nhưng nó xảy ra rất nhiều. Điều kỳ lạ là /var/log/tin nhắn tệp có các mục nhật ký bị thiếu được ghi ngay lập tức, đó chỉ là quá trình phân phối mạng bị trì hoãn. tôi đã nghĩ rằng đường xả(1) sẽ tránh được bộ đệm này, nhưng có vẻ như không.
Tôi đã sử dụng Wireshark để xác định vị trí của độ trễ và nó nằm ở đầu ra của các gói từ syslog-ng, giữa syslog-ng và cổng TCP 6514 của telegraf.
Tôi đã tự hỏi liệu đây có phải là Thuật toán của TCP Nagle hay không - nếu vậy, có cách nào để bật tùy chọn ổ cắm TCP_NO_DELAY cho trình điều khiển đích nhật ký hệ thống của syslog-ng không?
Cuối cùng, những gì tôi đang tìm kiếm là một dịch vụ nhật ký hệ thống nhanh, độ trễ thấp có thể tổng hợp và chuyển tiếp nhật ký nhanh nhất có thể để xem xét theo thời gian thực ở hạ lưu.
CHỈNH SỬA: Tôi đã thử chuyển sang vận chuyển UDP giữa syslog-ng và phép đo từ xa và điều này có vẻ phản hồi nhanh hơn nhiều và sự chậm trễ kéo dài, không thường xuyên đã biến mất. Tuy nhiên, điều này sẽ gây khó khăn cho việc bảo mật kết nối trong tương lai.
