-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible to declare multiple elasticsearch appenders with different jackson mixins? #41
Comments
Yes, it's possible. Resource-wise - it depends. Usually it's not efficient, as every It depends what you need. Could you describe what exactly you want to achieve? E.g. if you'd like to have mixins-per-index, I'd recommend programmatic config with:
asyncBatchDelivery.add(indexName, itemSourceFactory.create(logEvent, objectWriter)); or
asyncBatchDelivery.add(indexName, jacksonJsonLayout.serialize(logEvent)); |
I see. I'll change the focus of my question a bit (or a lot): How would i do that? |
If you want to use the same appender instance for multiple indices, for now, you'll have to write your own I'll think that If you need to be resource efficient, use |
That's not exactly what i want. I want to use different appenders, possibly with different filters and everything else log4j2 has to offer, and be resource efficient. (Specifically to be able to share the same client, or delivery mechanism). ps: Can i use hc with pattern layout? I think i tried that and it didn't work (something about using ItemSource api only). |
You can achieve that only if you configure multiple appenders programmatically. Filters are applied before LogEvent gets to the appender, so you should be fine there. Any layouts that produce raw Strings - including |
Will you consider adding support for that via configuration files? |
Short answer - no, never. With Log4j2, each appender has it's own lifecycle - all underlying components must be reliably stopped when requested to do so and release all resources, especially running threads, connections and thread locals(!) if used. They can't leak. With config files, even if you manage to share resources between multiple appenders, the main challenge is to identify that the last appender was stopped and shared resource can be released. Log4j2 has control over it so static registry with usage count is one of the ideas. Possible, but horrible - I'll never add support for that. However, programmatic config will allow you to do it - this library is highly extensible by design. You can extend How many appenders would you like to have? |
I'll probably start with 3 and go up from there, up to 10, give or take. I understand your concerns. In the scenario where a couple of Elasticsearch appenders share a common delivery mechanism, It seems unlikely that one would want to stop some of them, and not the others. Assuming that, you can forgo the reference count mechanism and close the first appender completely, which will mean for the other appenders that they will stop working, whereupon closing them, they will dispose of resources only if not already disposed. Making this partial capability will not jeopardize the library i think. On the contrary, you'll be adding, what i think, is a common and important feature. Elastic is very common logging platform nowdays, and using Elasticsearch appenders should be as easy as using file appenders, without taking a heavy toll on resources. |
You're right. However, it still doesn't allow a
That's exactly why I'd rather sacrifice a few megabytes of heap, close them properly, in order, allowing all logs in flight to be delivered safely. I don't want to jeopardize your data(!) If graceful shutdown can be executed, it should be.
They can as long as it doesn't lead to data loss and instability of client application.
I agree, that's why I started to work on |
It's logging data, and the fact that it is being channeled directly to ES, theoretically, puts it already in some jeopardy. It's a calculated risk.
Data loss perhaps, i don't see how it will lead to instability. There are other options as well. For example, two types of elasticsearch appenders. One type is what you have now available, the other is a Decorating elasticsearch appender, that gets by ref the other type. The Decorating appender will use the inner appender (by actually decorating ItemAppender) and only needs to transfer the index name to the inner appender. This will make it quite easy, i think, to implement reference count on the inner appender. Whenever some Decorating appender get an inner appender by ref, the counter goes up, and on dispose, it goes down, on zero, it is disposed. Even simpler, you can enforce order of disposal, Decorating appenders first, inner appenders last.
Well, yes and no. I have the need to write logs not only to ES, but to other sources as well. Also , the project that i'm currently working on has already a number of log4j2 xml configurations, and I don't want the logging configuration to be present in several places (code and xml). I'm a big fan of programmatic configuration myself, but It's not an acceptable excuse to move everything to code configuration.
Can you provide some absolute metrics for this? perhaps from tests that you conducted? |
I'm not willing to increase it.
If in any case resources are not closed properly or closed prematurely, some classes may not be unloaded in hot-deploy environments (this applies to most dangling resources)
Options are already available with Log4j2: Here are the measurements of GC times and memory allocation rate taken from Shenandoah (default, no tuning):
CMS (default, no tuning):
|
I don't see how they solve the problem we discussed. Through them its possible to implement context based routing, but they don't solve the problem of delivery mechanism sharing with different Elasticsearch indices. Thanks for performance metrics. It will help decide which client to use. |
You're welcome! :) Always a pleasure to do these kind of comparisons. As mentioned earlier, you can use your own, custom
IMHO, they are reasonably safe solutions to the problem you'd like to solve. All of these interfaces are battle proven, well tested and allow you to use everything that Log4j2 has to offer. I can add the optional |
This one will do, together with the IndexNameResolver and StrLookup. |
If yes, is that efficient resource-wise?
The text was updated successfully, but these errors were encountered: