![]() ![]() Don't enable throwExceptions (disabled by default).If you afraid that logging could break your application: If async is enabled, check the overflow/queue settings - discard is enabled by default (to protect from CPU or memory overload).Optional, use a fallbackgroupwrapper (in case of an error when writing to the target).Write to multiple targets (from NLog), e.g.If you are afraid if you lose some log messages Not sure what should be reliable, running the program or not losing a log message, so for those cases: There is nothing to worry about, but correct configuration of NLog is important. will additional threads be started? (this will flood connection pool).what happens when the queueLimit is reached?.will subsequent requests reuse thread and queue the logging requests?.Using async wrapper for elasticsearch target with queueLimit="10000" batchSize="100" what happens with the main thread when target can't be reached?.Request comes in and ES cluster is unavailable. To give a bit more context the "app" is a set of APIs (WebAPI and WCF) which get 10 - 15K RPM. Using latest NLog and throwExceptions is set to false and not using async targets at this point but considering this as we have a lot of async code. Main concern is app availability and to prevent missing logs secondary target is used. I am considering using a different target for NLog that sends the logs to a more reliable destination (File, S3 ?) and then having something else (Logstash, AWS Lambda) pick them up and sending them to ES, this way minimising risks on the application itself. This works fine but I am concerned about using this in production due to ES cluster availability and the impact a cluster failover has, when the logs are sent using the elasticsearch-net client via HTTP. Using NLog with Elasticsearch target to forward logs to AWS Elasticsearch as a Service cluster for visualisations in Kibana. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |