Dependency on Elasticsearch.Net is not needed about serilog-sinks-elasticsearch

[mivano]

Good point, the functionality used at the moment to interact with ES is relatively small, mostly sending data to it (events and the template). Low coupling would certainly be good, the recent upgrade we did fixed the ES 2 compatibility but dropped ES 1 support due to libraries. So certainly interesting to find out if possible. Maybe @Mpdreamz has some feedback/tips?

[Mpdreamz]

I'd be +1 on internalising the LowLevel client through ILMerge or something similar.

ES 2.x introduced formatted structured error responses and Elasticsearch.Net supports it. The LowLevel client most likely still "works" against 1.x but we do not test this on our CI and thus do not support it. There will always be a chance where Elasticsearch itself introduces a breaking change in serilog's footprint, using the client or not :)

Also the connectivity bits are not easy to reimplemented IMO and is something we test extensively it be a mistake to split efforts here.

But yeah huge +1 to ILMerge.

[Mpdreamz]

In fact Elasticsearch 5.0 will break the template and we need to bump majors again :D

[mivano]

Thanks for your feedback. IL merging it would certainly be an option. Or we need to drop support for the connectivity part, keep the sink pretty simple and just post json to the ES index. Hard to imagine that this will change in new versions. However that removes a lot of functionality from the sink which is also not optimal and desirable.

And ES 5? Skipping some versions in between?

[legigor]

The configuration class ElasticsearchSinkOptions has a property Serializer of Elasticsearch.Net.Serialization.IElasticsearchSerializer from the package Elasticsearch.Net. Thus, the ILMerged client won't really help because the low-level client stuff is not encapsulated within the lib it will still impose this dependency to the client.

This construct really makes the things much more complex than seemed. If we agree that we can use raw HTTP Post to the _bulk endpoint, then we will have to split this lib into the two separated libs, introduce some abstract client to keep the client applications working after the upgrade. The primary package won't use any dependencies and the second package will hide all the ES low-level client stuff.

[mivano]

It will certainly be a breaking change that might even warrant to be a new sink all together. A lightweight ES Serilog sink that uses no external libraries to send data to ES. Might not have the connection capabilities or serialization support, but just uses the batched endpoint to send the data. It might be hard to get it in this sink without breaking too much, but a fork of this one can be possible. Is that an option to explore?

[mivano]

Old issue, cleaning up