Loggingfromanapplication.
You can use Log::Dispatch, or any log system which will output into Log::Dispatch.
use Log::Dispatch;
use Log::Dispatch::Message::Passing;
use Message::Passing::Filter::Encoder::JSON;
use Message::Passing::Output::ZeroMQ;
my $log = Log::Dispatch->new;
$log->add(Log::Dispatch::Message::Passing->new(
name => 'myapp_aggregate_log',
min_level => 'debug',
output => Message::Passing::Filter::Encoder::JSON->new(
output_to => Message::Passing::Output::ZeroMQ->new(
connect => 'tcp://192.168.0.1:5558',
),
),
));
$log->warn($_) for qw/ foo bar baz /;
Aggregatingthislog
As simple as using the command line interface:
message-pass --input ZeroMQ --input_options '{"socket_bind":"tcp://192.168.0.1:5558"}' \
--output File --output_options '{"filename":"/tmp/mylog"}'
And you've now got a multi-host log aggregation system for your application!
Doingitmanually
You don't have to do any of the above, if you don't want to - you can easily reuse the ZeroMQ output
yourself:
my $log = Message::Passing::Output::ZeroMQ->new(
connect => 'tcp://192.168.0.1:5558',
linger => 1, # make sure message is sent (flushed) before thread dies
);
$log->consume("A log message");
Anoteaboutoutputs
ZeroMQ is the recommended output for sending messages from within your application. This is because
ZeroMQ uses a different (POSIX) thread to send messages - meaning that it transports messages
independently to whatever your perl code is doing.
This is not the case for other message outputs, and therefore they are unlikely to work well, or at all,
unless your application is already asynchronous and using an AnyEvent supported event library.
AnoteaboutZeroMQ
By default Message::Passing::ZeroMQ will use PUB/SUB sockets for logging, with a finite 'high water
mark'.
This means that if your application logs significantly more data than you can fit down the network, you
willdroplogs.
If your application needs to do this, you can either increase this high water mark, or disable it (so
ZeroMQ will buffer an infinite number of messages at the sending client - potentially using infinite
RAM).
The default setting is for the output to buffer up to 10000 messages on the output side, which should be
enough to manage short term peaks, but is low enough to be reasonably safe in terms of memory consumption
for buffering