Я делаю некоторую пользовательскую обработку ошибок / ведение журнала с Elasticsearch в среде .NET с использованием Elasticsearch.NET.Учитывая объект IResponse
, я пытаюсь найти лучшую стратегию для извлечения короткого, краткого и полезного сообщения «первопричины».Первоначально я пришел к этому, что прекрасно работает, когда мы сталкиваемся с ошибками индексации, в частности:
shortMsg = response.ServerError?.Error?.RootCause?.FirstOrDefault()?.Reason;
Но недавно я столкнулся с ошибкой времени запроса, когда вышеприведенное дало мне следующее:
"failed to create query: { ... }"
(Детали опущены, но он фактически отбросил весь запрос.)
Поскольку это не особенно полезно, я потратил немного времени на просмотр response
, чтобы посмотреть, что еще доступно.response.ServerError.Error.Reason
, например, возвращает "all shards failed"
- тоже не особо полезно.response.DebugInformation
намного больше, чем я хотел бы для этой конкретной цели, но я нашел иголку в стоге сена, которую искал ближе к концу:
"Can't parse boolean value [True], expected [true] or [false]"
Это прекрасно, и чтобы избежатьРазобрав его из DebugInfomation
Мне также удалось найти его здесь:
response.ServerError.Error.Metadata.FailedShards.First().Reason.CausedBy.Reason
Итак, на этом этапе я пришел к этой стратегии, чтобы получить shortMsg
:
shortMsg =
response.ServerError?.Error?.Metadata?.FailedShards?.FirstOrDefault()?.Reason?.CausedBy?.Reason ??
response.ServerError?.Error?.RootCause?.FirstOrDefault()?.Reason;
Меня беспокоит это то, что было бы наивно полагать, что если что-то существует на первом пути, оно будет всегда"лучше", чем второе.Лучшее понимание самой структуры ответа может быть ключом к достижению наилучшей стратегии здесь.
Есть предложения по улучшению этого?