search

markmcdowell / NLog.Targets.ElasticSearch

NLog target for Elasticsearch
MIT License
176 stars 89 forks source link

Problem with exception serialization #175

Closed FixRM closed 11 months ago

FixRM commented 1 year ago

Hello and thank you for your work. I have very specific exception type that cause

illegal_argument_exception Reason: "mapper [exception.detail.ErrorDetails.Value] cannot be changed from type [text] to [long]

error. It is WCF's FaultException of type Microsoft.Xrm.Sdk.OrganizationServiceFault. Last one has ErrorDetails collection of string-object pairs. Some of the values are strings other are not. Not sure what Value in exception.detail.ErrorDetails.Value is, but it looks like it was "mapped" by Elastic as text for the first time and can't accept other types.

Am I right that this target follow it's own exception formatting and serialization? How can I customize/skip serializing this member? I know that excludedProperties exist but setting it to exception.detail.ErrorDetails doesn't work because, I guess this is not a regular property. Setting maxRecursionLimit is not a good option as well as my exception type has useful information on the same level as ErrorDetails member.

Any suggestions?

snakefoot commented 1 year ago

Maybe an option could be enableJsonLayout = "true" with Elastic.CommonSchema.NLog. See also #125

Alternative you can define the complete Elastic-Common-Schema using pure NLog JsonLayout. https://github.com/NLog/NLog/issues/4982#issue-1278665843 . Then you can then override the Exception-serialization to your liking - https://github.com/NLog/NLog/wiki/How-to-use-structured-logging#customize-object-reflection

FixRM commented 1 year ago

Thanks for the suggestion, @snakefoot. It turns out that maxRecursionLimit works well for my case, but I'll keep enableJsonLayout option in mind for the future.