You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by merrimanr <gi...@git.apache.org> on 2018/10/16 18:38:40 UTC
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
GitHub user merrimanr opened a pull request:
https://github.com/apache/metron/pull/1239
METRON-1829: Large Error Message Causes Slow Search Performance
## Contributor Comments
When a failure happens in the BulkWriterComponent, all pending messages in a batch are combined into a single error message. This results in a single large objects being written to ES and causes performance problems. This PR attempts to solve this issue by instead creating separate error messages for each message in the batch.
### Testing
This has been tested and verified in full dev:
1. Spin up full dev and verify data is being indexed into ES
2. Stop HDFS in Ambari. This will cause a failure in the BulkWriterComponent. By default the batch size for OOTB sensors is set to 5.
3. After HDFS has stopped, verify that documents are being written to an ES error index
4. Retrieve a single document from the ES error index. There should only be a single `raw_message` field. Subsequent documents in ES should also only contain a single `raw_message` field. Before there would have been 5 `raw_message_*` fields in a single document.
5. Verify error documents are displayed properly in Kibana.
## Pull Request Checklist
Thank you for submitting a contribution to Apache Metron.
Please refer to our [Development Guidelines](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61332235) for the complete guide to follow for contributions.
Please refer also to our [Build Verification Guidelines](https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds?show-miniview) for complete smoke testing guides.
In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? If not one needs to be created at [Metron Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel).
- [x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [x] Has your PR been rebased against the latest commit within the target branch (typically master)?
### For code changes:
- [x] Have you included steps to reproduce the behavior or problem that is being changed or addressed?
- [x] Have you included steps or a guide to how the change may be verified and tested manually?
- [x] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
```
mvn -q clean integration-test install && dev-utilities/build-utils/verify_licenses.sh
```
- [x] Have you written or updated unit tests and or integration tests to verify your changes?
- [x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?
### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via `site-book/target/site/index.html`:
```
cd site-book
mvn site
```
#### Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that [travis-ci](https://travis-ci.org) is set up for your personal repository such that your branches are built there before submitting a pull request.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/merrimanr/incubator-metron METRON-1829
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/metron/pull/1239.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1239
----
commit d674d9afbf7f5a230737dbcfe4ab10a70106f4ed
Author: merrimanr <me...@...>
Date: 2018-10-15T20:46:31Z
initial commit
----
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226380891
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
It might also be useful to discuss on this PR, if the other similar method `error(Throwable, Iterable<Tuple>)` needs updated. That method gets called if messages are unparsable. And in that case we send only a single error, instead of one for each error'd message. Is that what we want?
It might be what we want, but at the very least it would be useful to comment in there as to why we treat it differently, if indeed it should be different. Could be something like this.
```
public void error(Throwable e, Iterable<Tuple> tuples) {
LOG.error(format("Failing %d tuple(s) due to invalid message; sensorType unknown", Iterables.size(tuples)), e);
// emit only a single error message, even though many failed because ...
MetronError error = new MetronError()
.withErrorType(Constants.ErrorType.INDEXING_ERROR)
.withThrowable(e);
collector.emit(Constants.ERROR_STREAM, new Values(error.getJSONObject()));
tuples.forEach(t -> collector.ack(t));
// there is only one error to report for all of the failed tuples
collector.reportError(e);
}
```
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226466569
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
> This method only deals with a single tuple so it is misleading that the error method accepts multiple tuples. Would changing that to accept a single tuple make it less confusing?
Yes, agreed. That would help clarify things.
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226386542
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
> You're right! My mistake. I changed it to pass in just the current tuple to handleError
Your latest commit was my first thought of a fix too; it is much simpler. But I don't think it solves the second problem that I mentioned.
> There is also the nuisance that we report the error to the collector for each and every failed message, instead of just once for the batch. There is only one Throwable error to report, so we should just report it once.
I think reporting the error once is both a usability and performance improvement.
I had to unravel the code base a bit more in my suggested code snippet so that it only reports the error once.
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226369605
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
Seems like this will ack the same tuples repetitively. If 500 messages in a batch fail, then we will ack all 500 of them, 500 times.
There is also the nuisance that we report the error to the collector for each and every failed message, instead of just once for the batch. There is only one `Throwable` error to report, so we should just report it once.
We may need something like this.
```suggestion
// emit one error for each failed message
tuples.forEach(t -> {
MetronError error = new MetronError()
.withSensorType(Collections.singleton(sensorType))
.withErrorType(Constants.ErrorType.INDEXING_ERROR)
.withThrowable(e)
.addRawMessage(messageGetStrategy.get(t));
collector.emit(Constants.ERROR_STREAM, new Values(error.getJSONObject()));
collector.ack(t);
});
// there is only one error to report for all of the failed tuples
collector.reportError(e);
}
```
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226725656
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +119,18 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
+ MetronError error = new MetronError()
+ .withSensorType(Collections.singleton(sensorType))
+ .withErrorType(Constants.ErrorType.INDEXING_ERROR)
+ .withThrowable(e)
+ .addRawMessage(messageGetStrategy.get(t));
--- End diff --
Thinking more about this some more... I feel that what I have described in METRON-1832 is a pre-existing condition. I don't think this PR makes that pre-existing condition any worse. This PR is a solid, necessary fix. I am in favor of merging this and I will open a discuss thread on a resolution for METRON-1832.
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by merrimanr <gi...@git.apache.org>.
Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226479283
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
Done.
---
[GitHub] metron issue #1239: METRON-1829: Large Error Message Causes Slow Search Perf...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/1239
+1 Works as advertised. Thanks for the fix
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226675652
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
Looks great. I'm just going to spin it up and do some manual testing now.
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by merrimanr <gi...@git.apache.org>.
Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226460423
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
You're right again. I agree, we shouldn't be reporting the same exception for every message in the batch. I changed it to what you suggested in the initial comment and updated the tests.
For the other issue you bring up with `error(Throwable, Iterable<Tuple>)`, it looks like it gets called from only one place: `BulkMessageWriterBolt.handleMissingMessage`. This method only deals with a single tuple so it is misleading that the `error` method accepts multiple tuples. Would changing that to accept a single tuple make it less confusing?
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226371234
--- Diff: metron-platform/metron-writer/src/test/java/org/apache/metron/writer/BulkWriterComponentTest.java ---
@@ -161,9 +165,12 @@ public void writeShouldThrowExceptionWhenHandleErrorIsFalse() throws Exception {
@Test
public void writeShouldProperlyHandleWriterException() throws Exception {
Throwable e = new Exception("test exception");
- MetronError error = new MetronError()
+ MetronError expectedError1 = new MetronError()
.withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR).withThrowable(e).withRawMessages(Arrays.asList(message1, message2));
+ .withErrorType(Constants.ErrorType.INDEXING_ERROR).withThrowable(e).withRawMessages(Collections.singletonList(message1));
--- End diff --
Small nit. While we are in here, do you think it is easier to read with newlines?
```suggestion
.withErrorType(Constants.ErrorType.INDEXING_ERROR)
.withThrowable(e)
.withRawMessages(Collections.singletonList(message1));
```
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by nickwallen <gi...@git.apache.org>.
Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226720064
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +119,18 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
+ MetronError error = new MetronError()
+ .withSensorType(Collections.singleton(sensorType))
+ .withErrorType(Constants.ErrorType.INDEXING_ERROR)
+ .withThrowable(e)
+ .addRawMessage(messageGetStrategy.get(t));
--- End diff --
While testing this, I am seeing a problem. I am trying to decide whether we should call that a pre-existing condition and fix that problem after this PR goes in or whether the change here makes things any worse. Let me know what you think.
I have described the problem in [METRON-1832](https://issues.apache.org/jira/browse/METRON-1832). If any index destination goes down, error messages are continually recycled and grow larger and larger. In addition, long sequence of escape characters are created.
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/metron/pull/1239
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by merrimanr <gi...@git.apache.org>.
Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226377917
--- Diff: metron-platform/metron-writer/src/main/java/org/apache/metron/writer/BulkWriterComponent.java ---
@@ -118,12 +118,15 @@ public void commit(BulkWriterResponse response) {
public void error(String sensorType, Throwable e, Iterable<Tuple> tuples, MessageGetStrategy messageGetStrategy) {
LOG.error(format("Failing %d tuple(s); sensorType=%s", Iterables.size(tuples), sensorType), e);
- MetronError error = new MetronError()
- .withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR)
- .withThrowable(e);
- tuples.forEach(t -> error.addRawMessage(messageGetStrategy.get(t)));
- handleError(tuples, error);
+ tuples.forEach(t -> {
--- End diff --
You're right! My mistake. I changed it to pass in just the current tuple to `handleError`. Let me know if that works.
---
[GitHub] metron pull request #1239: METRON-1829: Large Error Message Causes Slow Sear...
Posted by merrimanr <gi...@git.apache.org>.
Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/1239#discussion_r226378008
--- Diff: metron-platform/metron-writer/src/test/java/org/apache/metron/writer/BulkWriterComponentTest.java ---
@@ -161,9 +165,12 @@ public void writeShouldThrowExceptionWhenHandleErrorIsFalse() throws Exception {
@Test
public void writeShouldProperlyHandleWriterException() throws Exception {
Throwable e = new Exception("test exception");
- MetronError error = new MetronError()
+ MetronError expectedError1 = new MetronError()
.withSensorType(Collections.singleton(sensorType))
- .withErrorType(Constants.ErrorType.INDEXING_ERROR).withThrowable(e).withRawMessages(Arrays.asList(message1, message2));
+ .withErrorType(Constants.ErrorType.INDEXING_ERROR).withThrowable(e).withRawMessages(Collections.singletonList(message1));
--- End diff --
I agree. Done.
---