Найти максимальную длину сообщения системного журнала

Question

Большинство программистов Unix будут использовать интерфейс, определенный syslog.h, и многие реализации (такие как glibc) не имеют реального ограничения на размер сообщения системного журнала, отправляемого ему, но обычно есть ограничение наприложение слушает /dev/log.

Интересно, кто-нибудь знает способ найти максимальный размер сообщения для системного журнала?Или какая-то хорошая документация о том, что на самом деле (или обычно) это предел?

Редактировать:

Пока я нашел эти RFC по теме:

• http://www.faqs.org/rfcs/rfc3164.html
• http://www.faqs.org/rfcs/rfc5426.html

Answer 1

Имейте в виду, syslog - это протокол, который означает, что он устанавливает минимумы и дает рекомендации.Я не могу найти источник для этого, но я считаю, что минимальная длина, которая должна поддерживаться, составляет 1 КБ, при этом рекомендуется 64 КБ.

Каждая реализация свободна делать то, что хочет, т.е. если вы хотите 16 МБмаксимум и писали сервер системного журнала, вы можете это сделать.Я не уверен, почему вы это сделаете, но вы могли бы.

Насколько я знаю, не существует стандартного programatic способа выяснить это, поэтому хранение сообщений на уровне менее 1 КБ было бы идеальным для переносимости.

Обновление

Пользователь MuMind указано в комментариях, что rsyslog усечено до 2097 символов, включая тип журнала / отметку времени.Так как это широко используемая реализация протокола, это подтверждает, что длина должна поддерживаться в пределах от 1 кОм до 1,5 кБ для максимальной переносимости.

Честно говоря, единственной причиной превышения этого будетрегистрировать дополнительные выходные данные отладки / сбоя; намного лучше вместо этого поместить это где-то в /var/log и просто указать, что вы сделали это, когда общались с системным журналом (да, есть сценарии, когда вы не можете, но многие библиотеки прилагают все усилия'встроенная регистрация, чтобы справиться с этим).

Answer 2

Так как syslog - это протокол, который будет использоваться по UDP, в этом случае пределом является размер датаграммы UDP минус несколько байтов для заголовков, который составляет около 65 КБ. Сокет домена / dev / log unix может быть либо датаграммой, либо сокетом потока (SOCK_STREAM или SOCK_DGRAM), в первом случае ограничение в 64 КБ не применяется, но лучше всего рассматривать размер UDP-дейтаграммы в качестве ограничения, если вы не Автор программы читает сообщения.

Answer 3

«Старый» системный журнал

Для "старого" (RFC 3164) системного журнала максимальная длина полезной нагрузки дейтаграммы системного журнала (включая кодированный приоритет и временную метку) составляет 1024 октета, как в разделе 4.1 , и минимальной длины не существует, хотя пустые пакеты системного журнала должны быть отброшены. Кроме того, более длинные датаграммы никогда не должны пересылаться согласно разделу 6.1 . (Реле должны урезать пакеты, если они добавляют информацию о метке времени, которая увеличивает длину; раздел 4.3.2 .)

Это действительно старое, и никто больше не следует этому, но об этом следует помнить, если вы работаете с очень старыми системами.

"Современный" системный журнал

Современные системы следуют (более или менее) RFC 5424, где в разделе 6.1 он устанавливает минимальный размер, который каждый должен иметь возможность обрабатывать, до 480 октетов, предполагает, что каждый может обрабатывать по крайней мере 2048 октетов. и не имеет максимума.

Очень часто используемым транспортом является UDP, определенный в RFC 5426, где раздел 3.2 подробно описывает размер сообщения. Максимально допустимое значение настолько велико, насколько вы можете поместиться в дейтаграмму, которую вы можете получить через сеть (в зависимости от этого она будет немного меньше 64 КБ). Однако для IPv4 требуется минимум 480 октетов, и предпочтительно системы должны принимать не менее 2048 октетов. Тем не менее, есть еще кое-что о MTU и тому подобном, поэтому, в общем, если вы не уверены в системах, с которыми вы имеете дело, вы, вероятно, захотите ограничить размер, чтобы он был ниже самого низкого MTU вашего пути, когда все заголовки и тому подобное включены; 1300 октетов было бы хорошим предположением, если вы не уверены.

Хотя это только для UDP; по каналу TLS получатели должны иметь возможность обрабатывать как минимум 2048 октетных сообщений и предпочтительно 8192 октета ( RFC 5425, раздел 4.3.1 . Но, конечно, с этим нужно быть осторожным, поскольку, если сообщение оказывается переадресовывается через транспорт UDP позже, применяются длины UDP.

Rsyslog

Rsyslog (извините, Раньер, но «правильная» форма в верхнем регистре отвлекает), вероятно, самый популярный демон syslog в наши дни. (Даже системы, использующие systemd / journald, по-прежнему используют rsyslogd для сетевого приема и передачи сообщений журнала в формате syslog.)

Rsyslog добавил возможность устанавливать максимальный размер сообщения, используемый во многих областях программы (параметр конфигурации maxMessageSize) в версии 6.3.4 в 2011 году, и в это время по умолчанию было установлено значение 8096 октетов, где оно остался с тех пор.