TCP framing rsyslog: многострочное сообщение может превратиться в несколько записей
Фотография конкретного исполнения не приложена.
Установленный TCP-сеанс передаёт поток байтов и сам не определяет границы syslog-сообщений. Передающая и принимающая стороны должны одинаково разделять записи. Иначе сетевой обмен выглядит исправным, но содержимое меняется уже при разборе потока.
В traditional framing модуля omfwd границей служит LF. Если полезное сообщение содержит реальные переводы строк, получатель может разделить его на несколько записей. Только первая часть при этом сохраняет ожидаемый заголовок, а остальные способны выглядеть повреждёнными событиями. Проверка обычной однострочной записи такую проблему не обнаруживает.
Octet-counted framing передаёт длину перед содержимым, позволяя сохранить многострочную запись. Этот режим должен поддерживать и фактический получатель. Самовольное переключение только отправителя может сделать поток непонятным другой стороне. Документация относит параметр к TCP-протоколам; на UDP его действие не распространяют.
В приёмке предлагают примеры с переводом строки, пустой строкой, не ASCII символами и длинным содержимым. Сравнивают количество сообщений и точные границы полезных данных после приёма. Отдельно проверяют повторное соединение и сохранение в приложении. Правильный framing решает задачу разделения потока, но не доказывает подтверждённую долговечную запись каждого сообщения у конечного потребителя.
Основание — Official rsyslog8 daily stable documentation snapshot; exact installed release not inferred, разделы TCP_Framing; TCP_FrameDelimiter. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Использован снимок официальной документации rsyslog 8 daily stable. Это обновляемая ветка, а не комплект руководств конкретного установленного выпуска. Экспериментальные segmentedDisk и local queue scope в рекомендации не включены; установленная версия, очередь и получатель не проверялись.
