[logback-user] Log events delivery guarantee.

[David Roussel]

If you absolutely want to be sure that logs are recorded, to the extent
that a failure to log should mean the transaction should be retried then
log back is not he right choice of API.
If the above doesn't apply then ignore the rest of this reply. 

Logback API was designed with this property in mind. No IO error will
ever propagate to the application. And the Unix API philosophy is that
any IO call can fail, and should be retried.
Sure you can get local daemons that will successfully replicate your
logs from disk to another machine, but there are plenty of things that
can go wrong locally that you should consider.

On Fri, Jun 2, 2017, at 19:05, Oleksandr Gavenko wrote:
> On Fri, Jun 2, 2017 at 8:01 PM, Oleksandr Gavenko <gavenkoa at gmail.com>> wrote:
> >
> > Alternative approach is to write log and later parse it. Like this
> > done with Filebeat
> > https://www.elastic.co/products/beats/filebeat that> > complement to ElasticSearch.
> >
> > The problem with such solution is necessity to invent or follow file> > format. Formatting log with MDC and Markers that can be tricky.
> >
> What I forgot to add is that parsing stack traces with filebeat is not> a pleasure.
>
> Also it's tricky to manage file rotation, from
> https://discuss.elastic.co/t/will-filebeat-handle-properly-the-underlying-log-file-rotation/56119/4>
> > while filebeat uses file metadata like inode and device id in order
> > to track files, it still requires the full path in order to open
> > files.> > The prospectors can only find files by path and do check
> > inode/device id against known set of inodes.>
> > If a file is simply renamed or closed by the logger, but still open
> > by filebeat,> > filebeat will process until end (will not close file handle yet).
> > But if filebeat gets restarted in between, it needs to find the
> > renamed files again.> > In order to find renamed files, the glob pattern must match rotated
> > files too. So to say, it's better use pattern mysqld.log*.>
> That is not reliable solution in my view.
> _______________________________________________
> logback-user mailing list
> logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20170602/d8255bd8/attachment.html>