Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create sap error history index #859

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

riysaxen-amzn
Copy link
Collaborator

@riysaxen-amzn riysaxen-amzn commented Feb 16, 2024

Description

  • This PR creates a SAP history index, the index is generated whenever the detector encounters failure scenarios during the create/update flow.
  • Index name: .opensearch-sap-error-history
    Field     | Type   | Description
    _id       | String |  Random uuid
    detectorId| String | Id of the detector
    exception | String | Exception/error in case of detector creation/update failure
    timestamp | String  | UTC timestamp when the failure happened
    operation | String  | CREATE_DETECTOR/UPDATE_DETECTOR
    logType   | String  | rule Topic
    user      | String  | name of the user
  • Scope is currently limited to create/update detector flows, can be later on expanded to errors related to correlations and delete detector workflows

Issues Resolved

  • Presently, Security Analytics lacks a system to record errors associated with detectors, including failure scenarios. This index will act as a crucial resource for troubleshooting, offering insights into the reasons behind detector failures at specific timestamps.

Check List

  • New functionality includes testing.
    • All tests pass
  • New functionality has been documented.
    • New functionality has javadoc added
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@@ -1573,6 +1576,44 @@ private Map<String, String> mapMonitorIds(List<IndexMonitorResponse> monitorResp
}
}

private void createSAPHistoryIndex(IndexDetectorRequest request, String exception) throws IOException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

plz move this logic to separate class. you can chekc rule indices handling for reference

try {
createSAPHistoryIndex(request, t.toString());
} catch (IOException e) {
throw new RuntimeException(e);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. plz dont ever throw runtime exceptions.
  2. no need to throw exception at all here imo since this is not a customer facing feature.
  3. plz add error log for failure and continue execution

builder.field("user", user);
builder.endObject();
log.info("Index name is: {}", indexName);
IndexRequest indexRequest = new IndexRequest(indexName)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this method is not even creating an index. plz rename method correcty.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IndexRequest Creates or updates a document in an index. It also creates an index if it doesn't already exists.

Copy link
Member

@eirsep eirsep left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. plz add mapping for system index.
  2. maintain separate class for system index management. use the right index settings at creation time by referring other system indices' behaviour

@riysaxen-amzn
Copy link
Collaborator Author

  1. plz add mapping for system index.
  2. maintain separate class for system index management. use the right index settings at creation time by referring other system indices' behaviour

So, the idea was to create this index whenever we encounter any failure and then upserting it with failure docs. Since this will be an Ops feature, i don't see the utility of creating this index at the beginning. But I see the point since this is a system index it not intended for direct access or modification. So, having a proper system index management for this make sense.

Copy link

codecov bot commented Feb 17, 2024

Codecov Report

Attention: 37 lines in your changes are missing coverage. Please review.

Comparison is base (e3362f6) 24.83% compared to head (fcc53be) 24.75%.
Report is 2 commits behind head on main.

❗ Current head fcc53be differs from pull request most recent head 844c2f9. Consider uploading reports for the commit 844c2f9 to get more accurate results

Files Patch % Lines
...lytics/transport/TransportIndexDetectorAction.java 0.00% 37 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main     #859      +/-   ##
============================================
- Coverage     24.83%   24.75%   -0.08%     
  Complexity     1030     1030              
============================================
  Files           277      277              
  Lines         12713    12754      +41     
  Branches       1401     1404       +3     
============================================
  Hits           3157     3157              
- Misses         9292     9333      +41     
  Partials        264      264              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

riysaxen-amzn pushed a commit to riysaxen-amzn/security-analytics that referenced this pull request Mar 25, 2024
…-project#859)

Signed-off-by: Ashish Agrawal <[email protected]>
(cherry picked from commit fcdcdcbf13a6df32693fb7b063c2819c6a80f85e)

Co-authored-by: Ashish Agrawal <[email protected]>
import org.opensearch.securityanalytics.util.RuleTopicIndices;
import org.opensearch.securityanalytics.util.SecurityAnalyticsException;
import org.opensearch.securityanalytics.util.WorkflowService;
import org.opensearch.securityanalytics.util.*;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: we should avoid wildcard imports

@@ -1522,9 +1519,15 @@ private void onOperation(IndexResponse response, Detector detector) {
}

private void onFailures(Exception t) {
log.info("Exception failures while creating detector: {}", t.toString());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's log this as error level. Same comment for 1529. We can then avoid the t.toString() with just

log.error("Exception failures while creating detector", t);

@@ -1573,6 +1576,50 @@ private Map<String, String> mapMonitorIds(List<IndexMonitorResponse> monitorResp
}
}

private void initErrorHistoryIndexAndAddErrors(IndexDetectorRequest request, String exceptionMessage) throws IOException {

if (!errorHistoryIndex.errorHistoryIndexExists()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take it or leave it - negating conditions is a bit harder to read than testing for the non-negated condition first. In a case like this where the method is an 'either or', I find it's easiest to read as

private void method() {
  if (condition) {
    // logic
    return;
  }

  // logic for !condition
}

}
@Override
public void onFailure(Exception ex) {
log.debug("Exception while creating error history index: {}", ex);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

debug -> error

}
@Override
public void onFailure(Exception ex) {
log.info("Exception while inserting a document in error history index: {}", ex);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

info -> error

}
@Override
public void onFailure(Exception e) {
log.debug("Exception while creating error history index: {}", e);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

debug -> error

@Override
public void onResponse(CreateIndexResponse response) {
errorHistoryIndex.onCreateMappingsResponse(response);
try {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style nit: the pattern of nesting these action listeners is tough to read imo. This is far from the most flagrant use of it in the codebase but I would still advocate for a private method to handle the try/catch and inner logic. In this case it would also reduce duplication with the else condition below

builder.field("user", user);
builder.endObject();
IndexRequest indexRequest = new IndexRequest(indexName)
.id(UUIDs.base64UUID())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we let OpenSearch generate the ID rather than creating a UUID?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

4 participants