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@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@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user