Hi Bob,
I'm curious to better understand your objective:
> [some docker container] logs contain a textual severity level based on the
> log4j levels:
> DEBUG, INFO, WARN, ERROR, CRITICAL, FATAL.
>
> The docker syslog integration dumps all the stdout of a container into
> syslog with a severity of LOG_INFO, and stderr with LOG_ERR.
>
> I'd like to parse the incoming json and map the level names to syslog
> severity numbers.
Is it correct that you're trying to maintain the distinction between the
LOG_INFO and LOG_ERR streams coming out of the docker containers? If that's
*all* you're trying to achieve, would just adding another property to your JSON
output to store the info/err value be sufficient?
Or... do you have existing downstream log processing that depends on the syslog
severity values, so mapping the log4j {DEBUG, INFO, WARN, ERROR, CRITICAL,
FATAL} text values onto syslog {Debug, Info, Notice, Warning, Error, Critical,
Alert, Emergency} severities is the critical part?
(Or some other scenario I haven't understood yet ...?)
--
Dave Caplinger | Director, Technical Product Management
Solutionary — An NTT Group Security Company
> On Feb 4, 2016, at 7:16 AM, Bob Gregory <[email protected]> wrote:
>
> Hi David,
>
> We ran logstash-forwarder in a separate container, and shared volumes
> between app containers and a forwarding container. That's problematic as we
> move toward a clustered environment, because it means running multiple
> instances of logstash forwarder, or doing something peculiar with user
> permissions. Instead we'd like to delegate the log routing and filtering to
> the host OS via Docker's log driver.
>
>
> On 4 February 2016 at 11:40, David Lang <[email protected]> wrote:
>
>> On Thu, 4 Feb 2016, Bob Gregory wrote:
>>
>> can you syslog over the network to localhost? rsyslog can be pretty
>>>>
>>> lightweight if you set queue sizes smaller than the default 500K messages.
>>> If you were running logstash-forwarder, rsyslog should be lighter.
>>>
>>> That's an interesting idea, but it would mean running a syslog daemon in
>>> each container. Generally, we stick to a single foreground process per
>>> container, so there's no init system for managing daemonised services, but
>>> that might change in the future.
>>>
>>
>> how were you running the logstash forwarder then?
>>
>>
>> David Lang
>> _______________________________________________
>> 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.
>>
>
>
>
> --
>
> ----
>
> *Bob Gregory*
>
> Application Architect
>
> MADE.COM <http://www.made.com/>
>
> Skype: flinkywistypomm
>
>
> [image: MADE]
>
>
>
> Made.com Design Limited is a company registered in England and Wales.
>
> Registered number: 07101408 | Registered office: 100 Charing Cross Road,
> London WC2H 0HG
> _______________________________________________
> 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.
_______________________________________________
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.
