Syslog messages with numeric length prefix fail to parse, vCenter Server
Article ID: 448407
Updated On:
Products
Issue/Introduction
When forwarding logs from vCenter Server to third-party syslog collectors (such as Elastic or Logstash) via TCP, the receiving parser fails to process the messages.
- Log messages arrive at the destination with an unexpected numeric prefix (e.g., 363).
- The third-party parser rejects the message as malformed or fails to recognize the syslog priority tag.
- Example log format:
[363 <134>1 2026-07-06T10:27:49.680341+02:00 #### sso-tomcat-localhost-access - - - ...]
Environment
- VMware vCenter Server 8.x
- Third-party syslog collectors (Elastic, Logstash, Splunk)
Cause
vCenter Server uses Octet Counting framing (defined in RFC 6587) when sending syslog over TCP. In Octet Counting, each syslog message is prefixed by an integer representing the length of the message (in octets) followed by a space. This ensures that the receiving server can accurately identify message boundaries. Many third-party parsers default to Non-Transparent-Framing (
Resolution
Resolution: Adjust the configuration of the third-party syslog collector to support RFC 6587/Octet Counting framing.
- Modify the input configuration of the third-party collector (e.g., Logstash input) to handle the RFC 6587 framing method.
- If using a custom parser, account for the leading integer and space delimiter before the <PRI> tag.
- Verify that the receiver is configured to recognize the start of a new message based on the length prefix rather than a newline character.
Note: It is not recommended to disable Octet Counting on vCenter Server as it is the standard for reliable syslog delivery over a stream-oriented protocol.
Additional Information
Feedback
