You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This library appears to be sending messages as per the BSD syslog protocol (RFC3164), however the timestamp appears to be incorrectly formatted.
Rather than fix the timestamp to adhere to RFC3164, I propose updating the logs to instead adhere to the newer RFC5424 syslog protocol. This allows for a more precise timestamp (essentially the format already in use) and has fields for the application name, process ID, message ID, and even a whole section of custom "structured data."
As already mentioned, the timestamp does not match the specification:
The TIMESTAMP field is the local time and is in the format of "Mmm dd
hh:mm:ss" (without the quote marks) where:
Mmm is the English language abbreviation for the month of the
year with the first character in uppercase and the other two
characters in lowercase. The following are the only acceptable
values:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
dd is the day of the month. If the day of the month is less
than 10, then it MUST be represented as a space and then the
number. For example, the 7th day of August would be
represented as "Aug 7", with two spaces between the "g" and
the "7".
hh:mm:ss is the local time. The hour (hh) is represented in a
24-hour format. Valid entries are between 00 and 23,
inclusive. The minute (mm) and second (ss) entries are between
00 and 59 inclusive.
Interestingly enough, the spec does allow for a more precise timestamp, however it specifies that this should go into the CONTENT field at the end of the message and not replace the existing TIMESTAMP field:
If implementers wish to contain a more specific date and time stamp
within the transmitted message, it should be within the CONTENT
field. Implementers may wish to utilize the ISO 8601 [7] date and
time formats if they want to include more explicit date and time
information.
Ironically, I acutally find such an imprecise timestamp as prescribed by RFC3164 quite indesirable, and the current implementation seems to work quite well with Graylog. If it were actually adhering to the spec, it would be much worse since the millisecond precision would be lost and the logs would likely be out of order in Graylog.
Thanks!
The text was updated successfully, but these errors were encountered:
Summary
This library appears to be sending messages as per the BSD syslog protocol (RFC3164), however the timestamp appears to be incorrectly formatted.
Rather than fix the timestamp to adhere to RFC3164, I propose updating the logs to instead adhere to the newer RFC5424 syslog protocol. This allows for a more precise timestamp (essentially the format already in use) and has fields for the application name, process ID, message ID, and even a whole section of custom "structured data."
Details
This library currently formats logs like this:
As already mentioned, the timestamp does not match the specification:
(https://datatracker.ietf.org/doc/html/rfc3164#section-4.1.2)
Interestingly enough, the spec does allow for a more precise timestamp, however it specifies that this should go into the
CONTENT
field at the end of the message and not replace the existingTIMESTAMP
field:(https://datatracker.ietf.org/doc/html/rfc3164#section-5.1)
Ironically, I acutally find such an imprecise timestamp as prescribed by RFC3164 quite indesirable, and the current implementation seems to work quite well with Graylog. If it were actually adhering to the spec, it would be much worse since the millisecond precision would be lost and the logs would likely be out of order in Graylog.
Thanks!
The text was updated successfully, but these errors were encountered: