I made search in a list and only found one relevant message:
http://markmail.org/message/tdkr745eqf3vxqme
>From Michael Reinhold, Mar 19, 2014 5:45:23 pm:
> The method described for a disk-cached AsyncAppender of course
> makes perfect sense. I think it would make a good alternative to
> the current AsyncAppender for some scenarios and would be a solid
> addition to the current Logback appenders.
I am going to implement log collection into ElasticSearch and I would
like to achieve high level of delivery reliability. Not in sense of
latency but in sense of completeness.
Business processes operate on collected data and nothing should be
lost if remote log collector is down or my application
crashed/restarted.
Only local disk space the most safest place for write due to low
latency, persistence and availability (except rare cases of FS
corruption or disk is full error).
Network services definitely have downtime.
=========================
Is there persistence wrapper for log events to guaranty delivery at
later time if remote service is not available? Like AsyncAppender for
Appender?
Docs https://logback.qos.ch/manual/appenders.html doesn't show
possibility for error:
public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachable {
public String getName();
public void setName(String name);
void doAppend(E event);
}
but in sources I see:
void doAppend(E event) throws LogbackException;
Potentially it is possible to say that service unavailable via
LogbackException subclass and start collect data into memory buffer
until some limit, then fallback to disk media.
And try to send events to server with some defined pattern until
RecipientDownException is gone.
On application startup PersistentAppender should check for serialized
unpublished events and try to send them again.
As I see in https://logback.qos.ch/apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html
persister should store:
* timestamp
* level
* msg
* marker (not sure is full hierarchy is needed as market is just a string)
* MCD
* StackTraceElement[] (this information can be useful but require a lot of CPU)
Some get* method are strange, like getArgumentArray(), I am not sure
if this information is useful.
======================
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.
======================
Direct writer to ElasticSearch
https://github.com/internetitem/logback-elasticsearch-appender buffer
messages only in memory if ElasticSearch isn't available and
application should be restarted everything is lost.
