查找系统日志最大消息长度
大多数 Unix 程序员都会习惯 syslog.h 定义的接口，并且许多实现（例如 glibc）对发送给它的 syslog 消息的大小没有真正的限制，但通常有对侦听 /dev/log 的应用程序的限制。
我想知道是否有人知道如何找到系统日志的最大消息大小？或者一些关于实际（或通常）限制是什么的好文档？
编辑：
到目前为止，我已经找到了有关该主题的这些 RFC：
Most Unix programmers would be used to the interface defined by syslog.h, and many implementations (such as glibc) have no real limit on the size of the syslog message being sent to it, but there is usually a limit on the application listening to /dev/log.
I'm wondering if anyone knows a way to find the maximum message size for the syslog? Or some good documentation of what the limit actually (or usually) is?
Edit:
So far I've found these RFCs on the topic:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
请记住，系统日志是一种协议，这意味着它设置最小值并提出建议。我找不到这方面的来源，但我相信应该支持的最小长度是 1k，建议使用 64k。
每个实现都可以自由地做他们想做的事情，即如果您想要最大 16MB 并且正在编写系统日志服务器，您可以自由地这样做。我不知道你为什么会这样做，但你可以。
据我所知，没有标准的编程方法可以确定这一点，因此将消息保持在 1k 以下对于可移植性来说是理想的选择。
更新
用户MuMind在评论中指出
rsyslog截断于2097 个字符，包括日志类型/时间戳。由于它是协议的广泛实现，因此长度应保持在 1k - 1.5k 之间，以实现最大的可移植性。老实说，超过这个值的唯一原因是记录额外的调试/崩溃输出；最好将其放在
/var/log中的某个位置，并且仅表明您在与 syslog 通信时这样做了（当然，在某些情况下您无法做到这一点） ，但很多库都内置了“尽力而为”日志来处理这个问题）。Keep in mind syslog is a protocol, which means it sets minimums and makes recommendations. I can't find a source to this, but I believe the minimum length that should be supported is 1k, with 64k being recommended.
Each implementation is free to do what they want, i.e. if you wanted a 16MB maximum and were writing a syslog server, you're free to do that. I'm not sure why you would, but you could.
As far as I know, there is no standard
programaticway of ascertaining this, so keeping messages at just under 1k would be ideal for portability.Update
User MuMind indicated in comments that
rsyslogtruncated at 2097 characters, including log type / time stamp. As it is a widely used implementation of the protocol, this reinforces that length should be kept to between 1k - 1.5k for maximum portability.Honestly, the only reason to exceed that would be to log additional debug / crash output; it's much better to put that somewhere in
/var/loginstead, and just indicate that you did so when talking to syslog (granted, there are scenarios when you couldn't, but plenty of libraries have 'best effort' logging built in to deal with that).“旧”系统日志
对于“旧”(RFC 3164) 系统日志，系统日志数据报负载的最大长度（包括编码优先级和时间戳）为 1024 个八位位组，根据 第 4.1 节 并且没有最小长度，但应丢弃空系统日志数据包。此外，不应根据第 6.1 节转发较长的数据报。 （如果中继添加会增加长度的时间戳信息，则必须截断数据包；第 4.3.2 节。）
这确实很旧，没有人再真正遵循它，但如果您使用的是非常旧的系统，则需要记住这一点。
“现代”Syslog
现代系统（或多或少）遵循 RFC 5424，其中 第 6.1 节 它将每个人必须能够处理的最小大小设置为 480 个八位位组，建议每个人至少能够处理 2048 个八位位组，并且没有最大值。
一种非常常用的传输方式是 UDP，在 RFC 5426 中定义，其中 第 3.2 节 详细介绍消息大小。允许的最大大小与您可以通过网络获取的数据报一样大（根据具体情况，该数据报将略低于 64k）。然而，IPv4 所需的最小字节数是 480 个八位字节，系统最好至少接受 2048 个八位字节。不过，还有一些关于 MTU 等的进一步内容，因此一般来说，如果您不确定正在处理的系统，则可能希望将大小限制在路径的最低 MTU 以下包括所有标题等；如果您不确定，大约 1300 个八位字节是一个不错的猜测。
不过，这仅适用于 UDP；通过 TLS 链接，接收方必须能够处理至少 2048 个八位字节消息，最好是 8192 个八位字节 (RFC 5425 第 4.3.1 节。但是当然您需要小心这一点，因为如果消息稍后恰好通过 UDP 传输转发，则 UDP 长度适用。
Rsyslog
Rsyslog（抱歉，Ranier，但是“正确的”全大写形式会分散注意力）可能是最流行的 syslog 守护进程（即使使用 systemd/journald 的系统仍然使用 rsyslogd 以 syslog 格式进行网络接收和传输日志消息。）
Rsyslog 添加了设置程序许多区域中使用的最大消息大小的功能（
maxMessageSize< /code> 配置参数）在 2011 年的 6.3.4 版本中，此时默认值设置为 8096 八位字节，此后一直保留。"Old" Syslog
For "old" (RFC 3164) syslog the maximum length of a syslog datagram's payload (including the encoded priority and timestamp) is 1024 octets, as per section 4.1 and there is no minimum length, though empty syslog packets should be dropped. Further, longer datagrams should never be forwarded as per section 6.1. (Relays must truncate packets if they add timestamp information that would increases the length; section 4.3.2.)
This is really old and nobody really follows this any more, but it's something to keep in mind if you're working with very old systems.
"Modern" Syslog
Modern systems follow (more or less) RFC 5424 where in section 6.1 it sets the minimum size that everybody must be able to handle to 480 octets, suggests that everybody be able to handle at least 2048 octets, and has no maximum.
A very frequently used transport is UDP, defined in RFC 5426, where section 3.2 goes into detail about the message size. The maximum permissible is as big as you can fit in a datagram that you can get through the network (which will be a bit under 64k, depending). However, the minimum required is 480 octets for IPv4, and preferably systems should accept at least 2048 octets. There's a bit of further stuff about MTUs and the like, though, so in general, if you're not sure about the systems you're dealing with, you probably want to restrict the size to be under the lowest MTU of your path when all headers and the like are included; about 1300 octets would be a good guess if you're not sure.
That's just for UDP, though; over a TLS link receivers must be able to process at least 2048 octet messages and preferably 8192 octets (RFC 5425 section 4.3.1. But of course you need to be careful with this because if the message happens to be forwarded over a UDP transport later, the UDP lengths apply.
Rsyslog
Rsyslog (sorry, Ranier, but the "proper" all-upper-case form is distracting) is probably the most popular syslog daemon these days. (Even systems that use systemd/journald still use rsyslogd for network reception and transmission of log messages in syslog format.)
Rsyslog added the ability to set the maximum message size used in many areas of the program (the
maxMessageSizeconfiguration parameter) in version 6.3.4 in 2011 and at this time the default value was set to 8096 octets, where it has remained since.由于 syslog 是通过 UDP 使用的协议，因此在本例中，限制是 UDP 数据报大小减去标头的几个字节，约为 65k。
/dev/log unix 域套接字可以是数据报或流套接字（SOCK_STREAM 或 SOCK_DGRAM），在前一种情况下，64k 限制不适用，但如果您不是 UDP 数据报大小，最好将 UDP 数据报大小视为限制。阅读消息的程序的作者。
Since syslog is a protocol to be used over UDP, in this case the limit is the UDP datagram size minus a few bytes for the headers which is around 65k.
The /dev/log unix domain socket can be either a datagram or stream socket (SOCK_STREAM or SOCK_DGRAM), in the former case the 64k limit does not apply but it is best to consider the UDP datagram size as the limit if you are not the author of the program reading the messages.