Maillist crops my message a little bit.
> imfile already has the ability to read a couple multi-line formats (every
> line after the first starts with whitespace and blank line between logs)
>
> tcp octet mode has the ability to deliver message containing embedded
> newlines from one machine to another
>
> But overall, rsyslog (like all log processing software) has a lot of places
> where it's assumed that each line is a separate log.
>
> Handling a multi-line log like this gets tricky, how do you tell where one
> log ends and the next begins? can you conclude that a log has finished
> being written and can be processed before the next log is written? If the
> log is written infrequently, this can be a _really_ long delay, so which
> timestamp do you put on the log message, when it starts or when it
'ends'?
>
> In general, your best bet is to have an external program scrape your
> multi-line input and convert it to a single line before handing it to
> rsyslog (escape the newlines, tabs, and other special characters so that
> you can get them back if needed)
Ok, clear. If so, this preparser also could create CEE JSON.
> I think this is a great idea that I haven't seen mentioned before.
Thanks, this field type is really needed.
> why not just change your parser?
>
> Or, you can do
> set $!CmdbEximAclHistory = $!acl_history;
> unset $!acl_history;
>
> I think the mapping file adds significant complexity without a lot of value.
We are thinking about Scala variables naming in our loggitoring
application, this mapping is one of approaches we discussing about. Yes,
others are "set"/"unset" and Scala-side vars remap.
> This has been requested many times, the problem is that evaluating the
> variable every time for all of these fields would be a very significant
> slowdown as well as adding a lot of complexity.
>
> You have to ask, is it really that useful to have the these things be
> variables? how many different ones are you going to have? and why
would you
> change them?
>
> It may be better to have multiple rulesets, each differing only by name
and
> destination and select between which ruleset to run based on a
> if..then..else tree instead (remember that if the rulesets are defined in
> external files and then included, they can be auto-generated from a
> template, they just would require a restart to take effect).
right now we have three omrelp actions:
QUEUE PARAMETERS - queue.highwatermark="10000"
queue.lowwatermark="500" queue.size="12000000"
queue.discardmark="10000000" queue.type="linkedlist"
queue.saveonshutdown="on" queue.checkpointinterval="30"
queue.timeoutshutdown="2000" queue.workerthreads="2"
##RELP RULESET
ruleset(name="relp_cee" filename="relp_cee" ..... {QUEUE
PARAMETERS}.... ) {
action(type="omrelp" Template="cee" Target="core"
Port="20514")
}
ruleset(name="relp_msg" queue.filename="relp_msg" ..... {QUEUE
PARAMETERS}....) {
action(type="omrelp" Template="msg" Target="core"
Port="20514")
}
ruleset(name="relp_gate" queue.filename="relp_gate" ..... {QUEUE
PARAMETERS}....)
{
action(type="omrelp" Template="gate" Target="core_next"
Port="20514")
}
The question is in flexible routing based on data in CEE JSON - for ex. if we
have field like $!_msg_next_ip filled up in sender side - we can implement
routing based on sender data (also choosing a template based on sender
data).
Thanks
_______________________________________________
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.
