metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <>
Subject Re: [DISCUSS] Recurrent Large Indexing Error Messages
Date Wed, 05 Dec 2018 12:44:58 GMT
Why not have a second indexing topology configured just for errors?
We can load the same code with two different configurations in two

On December 5, 2018 at 03:55:59, Ali Nazemian ( wrote:

I think if you look at the indexing error management, it is pretty much
similar to parser and enrichment error use cases. It is even more common to
expect something ended up in error topics. I think a wider independent job
can be used to take care of error management. It can be decided to add a
separate topology later on to manage error logs and create
alert/notifications separately.
It can be even integrated with log feeder and log search.
The scenario of sending solution operational logs to the same solution is a
bit weird and not enterprise friendly. Normally platform operation team
would be a separate team with different objectives and probably they have
got a separate monitoring/notification solution in placed already.

I don't think it is the end of the world if this part is left to be managed
by users. So I prefer option 2 as a short term. Long term solution can be
discussed separately.


On Sat, 20 Oct. 2018, 05:20 Nick Allen < wrote:

> I want to discuss solutions for the problem that I have described in
> METRON-1832; Recurrent Large Indexing Error Messages. I feel this is a
> easy trap to fall into when using the default settings that currently
> with Metron.
> ## Problem
> If any index destination like HDFS, Elasticsearch, or Solr goes down
> the Indexing topology is running, an error message is created and sent
> to the user-defined error topic. By default, this is defined to also be
> the 'indexing' topic.
> The Indexing topology then consumes this error message and attempts to
> write it again. If the index destination is still down, another error
> occurs and another error message is created that encapsulates the
> error message. That message is then sent to the 'indexing' topic, which
> later consumed, yet again, by the Indexing topology.
> These error messages will continue to be recycled and grow larger and
> larger as each new error message encapsulates all previous error messages
> in the "raw_message" field.
> Once the index destination recovers, one giant error message will finally
> be written that contains massively duplicated, useless information which
> can further negatively impact performance of the index destination.
> Also, the escape character '\' continually compounds one another leading
> long strings of '\' characters in the error message.
> ## Background
> There was some discussion on how to handle this on the original PR #453
> ## Solutions
> (1) The first, easiest option is to just do nothing. There was already a
> discussion around this and this is the solution that we landed on in
> Pros: Really easy; do nothing.
> Cons: Intermittent problems with ES/Solr can easily create very large
> messages that can significantly impact both search and ingest
> (2) Change the default indexing error topic to 'indexing_errors' to avoid
> recycling error messages. Nothing will consume from the 'indexing_errors'
> topic, thus preventing a cycle.
> Pros: Simple, easy change that prevents the cycle.
> Cons: Recoverable indexing errors are not visible to users as they will
> never be indexed in ES/Solr.
> (2) Add logic to limit the number times a message can be 'recycled'
> the Indexing topology. This effectively sets a maximum number of retry
> attempts. If a message fails N times, then write the message to a
> unrecoverable, error topic.
> Pros: Recoverable errors are visible to users in ES/Solr.
> Cons: More complex. Users still need to check the unrecoverable, error
> topic for potential problems.
> (4) Do not further encapsulate error messages in the 'raw_message' field.
> If an error message fails, don't encapsulate it in another error message.
> Just push it to the error topic as-is. Could add a field that indicates
> how many times the message has failed.
> Pros: Prevents giant error messages from being created from recoverable
> errors.
> Cons: Extended outages would still cause the Indexing topology to
> repeatedly recycle these error messages, which would ultimately exhaust
> resources in Storm.
> What other ways can we solve this?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message