On 06/25/2013 05:45 PM, Rainer Gerhards wrote:
On Tue, Jun 25, 2013 at 3:33 PM, Risto Vaarandi<[email protected]>wrote:
hi all,
I was thinking what would be the best way for submitting events to the
local rsyslog server. Quite often, piping one or more lines to
/usr/bin/logger, or calling openlog(3) and syslog(3) are sufficient for the
job. There are cases, however, when they are not good enough, since they
restrict logging with a single tag.
As an alternative, one could communicate with rsyslog directly over the
/dev/log UNIX domain socket. I was wondering what would be the best event
format for writing to /dev/log. Typically, each call to syslog(3) uses the
following format:<priority>timestamp tag: messagetext
(in other words, BSD syslog format without the hostname field)
However, rsyslog also has the ability to provide the incoming event with a
timestamp if it is not present, and according to my observations, the
following format is also handled properly by rsyslog:
<priority>tag: messagetext
I was wondering if the format without timestamp is something which can be
safely used over different versions of rsyslog, and is supported alongside
with regular format used by syslog(3).
That's actually part of the heuristic we use to handle malformed messages
properly. Note that RFC3164 specifically tells that such messages may be
sent to a syslogd (3164 is informative and tells what is done in the
field). So for relatively recent versions of rsyslog, this should work.
Actually, this is a very basic part of the heuristic, so I would not expect
any problems with that. Whenever I am asked to change the heuristic, I try
to weigh the importance of that change over what problems it may cause. In
recent time, this usually meant we did not change it, as it has become very
mature. For custom formats, we can also use specific message parsers, which
is the way I usually suggest for strange format (and with that I don't mean
what you propose, jsut to be clear ;)).
Does that help?
Rainer
hi Rainer,
this helps a lot. In fact, I wanted to include this information in a FAQ
entry about SEC and rsyslog integration. Before doing this, I wanted to
make sure that the FAQ is not suggesting anything which might not work
across all versions of rsyslog, or which might break down in the future.
So thanks a lot for providing this insight into rsyslog message handling
heuristics.
kind regards,
risto
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
