
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div style="font-family:Arial;">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. <br></div>

<div style="font-family:Arial;"><br></div>

<div style="font-family:Arial;">If the above doesn't apply then ignore the rest of this reply. </div>

<div style="font-family:Arial;"><br></div>

<div style="font-family:Arial;">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. <br></div>

<div style="font-family:Arial;"><br></div>

<div style="font-family:Arial;">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. </div>

<div style="font-family:Arial;"><br></div>

<div style="font-family:Arial;"><br></div>

<div style="font-family:Arial;">On Fri, Jun 2, 2017, at 19:05, Oleksandr Gavenko wrote:<br></div>

<div style="font-family:Arial;">> On Fri, Jun 2, 2017 at 8:01 PM, Oleksandr Gavenko <gavenkoa@gmail.com><br></div>

<div style="font-family:Arial;">> wrote:<br></div>

<div style="font-family:Arial;">> ><br></div>

<div style="font-family:Arial;">> > Alternative approach is to write log and later parse it. Like this<br></div>

<div style="font-family:Arial;">> > done with Filebeat https://www.elastic.co/products/beats/filebeat that<br></div>

<div style="font-family:Arial;">> > complement to ElasticSearch.<br></div>

<div style="font-family:Arial;">> ><br></div>

<div style="font-family:Arial;">> > The problem with such solution is necessity to invent or follow file<br></div>

<div style="font-family:Arial;">> > format. Formatting log with MDC and Markers that can be tricky.<br></div>

<div style="font-family:Arial;">> ><br></div>

<div style="font-family:Arial;">> What I forgot to add is that parsing stack traces with filebeat is not<br></div>

<div style="font-family:Arial;">> a pleasure.<br></div>

<div style="font-family:Arial;">><br></div>

<div style="font-family:Arial;">> Also it's tricky to manage file rotation, from<br></div>

<div style="font-family:Arial;">> https://discuss.elastic.co/t/will-filebeat-handle-properly-the-underlying-log-file-rotation/56119/4<br></div>

<div style="font-family:Arial;">><br></div>

<div style="font-family:Arial;">> > 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.<br></div>

<div style="font-family:Arial;">> > The prospectors can only find files by path and do check inode/device id against known set of inodes.<br></div>

<div style="font-family:Arial;">><br></div>

<div style="font-family:Arial;">> > If a file is simply renamed or closed by the logger, but still open by filebeat,<br></div>

<div style="font-family:Arial;">> > filebeat will process until end (will not close file handle yet).<br></div>

<div style="font-family:Arial;">> > But if filebeat gets restarted in between, it needs to find the renamed files again.<br></div>

<div style="font-family:Arial;">> > In order to find renamed files, the glob pattern must match rotated files too. So to say, it's better use pattern mysqld.log*.<br></div>

<div style="font-family:Arial;">><br></div>

<div style="font-family:Arial;">> That is not reliable solution in my view.<br></div>

<div style="font-family:Arial;">> _______________________________________________<br></div>

<div style="font-family:Arial;">> logback-user mailing list<br></div>

<div style="font-family:Arial;">> logback-user@qos.ch<br></div>

<div style="font-family:Arial;">> http://mailman.qos.ch/mailman/listinfo/logback-user<br></div>

<div style="font-family:Arial;"><br></div>

</body>

</html>