正常处理Logstash插件过滤器错误 [英] Handling Logstash Plugin Filter errors gracefully

问题描述

因此，我正在为Logstash构建插件，但似乎找不到任何有关如何处理引发和/或挽救的异常的文档.到目前为止，与grok相似，我们添加了 event ["tag"] = ["_filter_error"] ，但是涉及元数据，例如堆栈跟踪，错误类型等.应该活着，还是应该忽略掉它们?

So, I'm building a plugin for logstash and I can't seem to find any documentation on how I should handle exceptions thrown and or rescued. So far, and similar to grok, we're adding a event["tag"] = ["_filter_error"], but in regards to metadata like a stacktrace, error type, etc... where should those live, or should they be omitted?

推荐答案

这是一个逐案的问题，因此很难回答.但是，我将分享我们最终的做法，以便对某人有所帮助.

This is sort of a case-by-case question, so admittedly hard to answer. But I'll share how we ended up doing it so it might help someone.

1. 救援所有异常(否则LogStash会挂起)
2. 在事件中添加标签 event ["tags"] = ["_filter_error"] ，以便以后可以查询这些标签
3. 忽略堆栈跟踪和错误消息(我们的决定-基本上使用标记代替)
4. 使用单个字段作为有关我们添加到事件中的标签的元数据.例如，如果我们的过滤器完全炸毁，请贴上标签，然后继续前进.如果我们的过滤器通过过滤失败1/2，请向事件中添加尽可能多的数据，在步骤2中添加标签，然后创建一个元数据字段(即 event ["unknown_tags"] = [1,6，7] ，我们的过滤器在标签1、6、7处爆炸，但在其他所有地方都通过了)

1. Rescue all the exceptions (LogStash will hang otherwise)
2. Add a tag to the event event["tags"] = ["_filter_error"] so these can be query-able down the road
3. Ignore the stacktrace and error message (our decision - basically use the tag instead)
4. Use a single field as metadata about the tag we added to the event. For instance, if our filter blew up altogether, honey-badger it and move on. If our filter failed 1/2 through filtering, add as much data to the event as you can, add the tag in step 2, then create a metadata field (i.e. event["unknown_tags"] = [1,6,7] where our filter blew up at tags 1,6,7 but passed for everything else)

这篇关于正常处理Logstash插件过滤器错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！