构造系统日志消息时的输出混乱

Question

I was writing a program which could convert a standard syslog message that is already logged in the file, for eg:

Mar  9 15:51:36 ldaptestserver slapd[392]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

to a syslog message including the PRI, header etc.

I was able to do this from a syslog message stored in my kafka test cluster, which visually looked like

2017-03-09T15:22:00.642769+00:00 ldaptestserver slapd[392]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

by prepending the priority and initiating a tcp connection to the syslog port, and writing the message as a []byte slice to the socket. The final message before sending it to syslog, after subscribing from kafka looked like

<13>2017-03-09T15:22:00.642769+00:00 ldaptestserver slapd[392]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

where only <13> is prepended to the entire log.

Now, instead of kafka, I try to open and read the /var/log/syslog, and constructed the same message that looked like the above,

<13>2017-03-08T12:29:02.231335+00:00 ldaptestserver slapd[392]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 // Original one from kafka that worked
<13>2017-00-01T16:18:04.000000+00:00 ldaptestserver slapd[392]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 // The message that is hand crafted.

But when I write the []byte message to the syslog connection socket, it produces a scrambled output.

(Notice that the IP is the localhost IP, instead of the hostname in the message. In the case where the similar kafka message was used, it logged perfectly with the original hostname.)

Can someone help me understand where is it messed up, and what should I do to get it without being scrambled?

I was using golang to program this.

-- Scott.

Answer 1

Instead of printing the working log extracted from kafka as string(), try to dump the []byte slice itself as it is. This will give you a bunch of numbers, which you can translate to its corresponding ascii characters, and you can see if there are any separators like carriage return or line feed that is separating the end of each section in the header and end of line of the message. This wouldn't be visible if you are casting it to string() when printing. Chances are that the syslog server's parser is expecting a line terminator to distinguish between header sections or end of a message, which it is failing to find, and keeps on appending subsequent messages until the parser's buffer runs out.