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

GetFindingsAction new optional parameters #563

Merged
merged 10 commits into from
Sep 23, 2022
Merged

GetFindingsAction new optional parameters #563

merged 10 commits into from
Sep 23, 2022

Conversation

petardz
Copy link
Contributor

@petardz petardz commented Sep 20, 2022

Signed-off-by: Petar Dzepina petar.dzepina@vroom.com

Issue #, if available:

Description of changes:
Added monitorId and findingsIndexName optinal params to GetFindings Action. These will be used to reference finding index, instead of default hardcoded one. findingsIndexName has higher priority over monitorId

CheckList:
[ ] 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.

…tion

Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
@petardz petardz requested a review from a team September 20, 2022 18:47
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
@@ -57,7 +58,9 @@ class RestGetFindingsAction : BaseRestHandler() {

val getFindingsSearchRequest = GetFindingsRequest(
findingID,
table
Copy link
Member

Choose a reason for hiding this comment

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

Custom data sources are not exposed in rest layer. Let's limit the changes to transport layer.

Copy link
Member

Choose a reason for hiding this comment

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

Alerting Rest level action should not be impact with this change, as SAP will introduce its own rest layer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
@@ -57,7 +58,9 @@ class RestGetFindingsAction : BaseRestHandler() {

val getFindingsSearchRequest = GetFindingsRequest(
findingID,
table
Copy link
Member

Choose a reason for hiding this comment

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

Alerting Rest level action should not be impact with this change, as SAP will introduce its own rest layer.

@@ -131,10 +137,34 @@ class TransportGetFindingsSearchAction @Inject constructor(
}
}

suspend fun search(searchSourceBuilder: SearchSourceBuilder): GetFindingsResponse {
suspend fun resolveFindingsIndexName(findingsRequest: GetFindingsRequest): String {
var indexName = ""
Copy link
Member

Choose a reason for hiding this comment

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

We should start with the default one here, and override based on the availability of the other information being present.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Comment on lines +151 to +154
val getMonitorResponse: GetMonitorResponse =
this@TransportGetFindingsSearchAction.client.suspendUntil {
execute(GetMonitorAction.INSTANCE, getMonitorRequest, it)
}
Copy link
Member

Choose a reason for hiding this comment

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

How do we handle the failure scenarios here? We would want to log and fallback to the default maybe?
Also moving the fetch config information to a common utility might be a good way to use across. such as for #561

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Exception is caught on line 134 and sent back to caller.

Hmm falling back to default one might lead to spurious behavior. It would be better if user knows that GetMonitor Action failed and is retryable then to get back NOT_FOUND without knowing if the desired finding index was searched or not

Comment on lines 196 to 215
// fetch findings - pass monitorId as reference to finding_index
val findingsFromAPI1 = getFindings(findings.get(0).id, monitorId, null)
assertEquals(
"Findings mismatch between manually searched and fetched via GetFindingsAction",
findings.get(0).id,
findingsFromAPI1.get(0).id
)
// fetch findings - pass both monitorId and findingIndexName name. Monitor id should be ignored
val findingsFromAPI2 = getFindings(findings.get(0).id, "incorrect_monitor_id", customFindingsIndex)
assertEquals(
"Findings mismatch between manually searched and fetched via GetFindingsAction",
findings.get(0).id,
findingsFromAPI2.get(0).id
)
// fetch findings - don't send monitorId or findingIndexName. It should fall back to hardcoded finding index name
val findingsFromAPI3 = getFindings(findings.get(0).id, null, null)
assertEquals(
"Unexpected result when fetching findings from default finding index",
0,
findingsFromAPI3.size
Copy link
Member

Choose a reason for hiding this comment

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

We should break these into individual findings scenarios - also to include the failure mode tests such as fallback if the name is present while the index is not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done and added more tests

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.

Thanks for making these changes, Peter.

Left a few minor comments.

suspend fun resolveFindingsIndexName(findingsRequest: GetFindingsRequest): String {
var indexName = ""

if (findingsRequest.findingIndexName.isNullOrEmpty() == false) {
Copy link
Member

Choose a reason for hiding this comment

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

nit: let's call its findingsIndex instead of findingsIndexName for consistence with DataSources class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@@ -165,6 +165,57 @@ class MonitorDataSourcesIT : AlertingSingleNodeTestCase() {
assertTrue("Findings saved for test monitor", findings[0].relatedDocIds.contains("1"))
}

fun `test execute monitor with custom findings index and GetFindingsAction`() {
Copy link
Member

Choose a reason for hiding this comment

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

this is not incorrect but instead could we add to existing test methods in this test class where custom findings are being verified

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

if (findingsRequest.findingIndexName.isNullOrEmpty() == false) {
// findingIndexName has highest priority, so use that if available
indexName = findingsRequest.findingIndexName
} else if (findingsRequest.monitorId != null) {
Copy link
Member

Choose a reason for hiding this comment

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

let's do an monitorId.isNullOrEmpty() == false check here too similar to above

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

val inputResultsStr = "{\"_shards\":{\"total\":1,\"failed\":0,\"successful\":1,\"skipped\":0},\"hits\":{\"hits\":[{\"_index\":\"sample-http-responses\",\"_type\":\"http\",\"_source\":{\"status_code\":100,\"http_4xx\":0,\"http_3xx\":0,\"http_5xx\":0,\"http_2xx\":0,\"timestamp\":100000,\"http_1xx\":1},\"_id\":1,\"_score\":1}],\"total\":{\"value\":4,\"relation\":\"eq\"},\"max_score\":1},\"took\":37,\"timed_out\":false,\"aggregations\":{\"status_code\":{\"doc_count_error_upper_bound\":0,\"sum_other_doc_count\":0,\"buckets\":[{\"doc_count\":2,\"key\":100},{\"doc_count\":1,\"key\":102},{\"doc_count\":1,\"key\":201}]},\"${trigger.id}\":{\"parent_bucket_path\":\"status_code\",\"bucket_indices\":[0,1,2]}}}"

val parser = XContentType.JSON.xContent().createParser(NamedXContentRegistry.EMPTY, DeprecationHandler.THROW_UNSUPPORTED_OPERATION, inputResultsStr)
val inputResultsStr = "{\"_shards\":" +
Copy link
Member

Choose a reason for hiding this comment

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

thank you for doing this :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

np!

// We will use it to fetch monitor and then read indexName from dataSources field of monitor
withContext(Dispatchers.IO) {
val getMonitorRequest = GetMonitorRequest(findingsRequest.monitorId, -3L, RestRequest.Method.GET, null)
val getMonitorResponse: GetMonitorResponse =
Copy link
Member

Choose a reason for hiding this comment

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

we should catch exceptiton if GetmonitorAction fails and fail the get findings action overall?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should be happening on line 134 right now. I'll add IT for this

Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
@@ -122,7 +127,8 @@ class TransportGetFindingsSearchAction @Inject constructor(
client.threadPool().threadContext.stashContext().use {
scope.launch {
try {
val getFindingsResponse = search(searchSourceBuilder)
val indexName = resolveFindingsIndexName(getFindingsRequest)
val getFindingsResponse = search(searchSourceBuilder, indexName)
actionListener.onResponse(getFindingsResponse)
} catch (t: Exception) {
actionListener.onFailure(AlertingException.wrap(t))
Copy link
Member

Choose a reason for hiding this comment

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

if get monitor fails we would already receive the alerting exception

would we need to do something like



if (t is AlertingException) {
    actionListener.onFailure(t)
} else {
      actionListener.onFailure(AlertingException.wrap(t))
 }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added another catch for AlertingException

Petar Dzepina added 3 commits September 21, 2022 01:07
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
@codecov-commenter
Copy link

codecov-commenter commented Sep 21, 2022

Codecov Report

Merging #563 (1e54b0c) into main (5074f7b) will increase coverage by 0.02%.
The diff coverage is 90.62%.

@@             Coverage Diff              @@
##               main     #563      +/-   ##
============================================
+ Coverage     76.83%   76.85%   +0.02%     
  Complexity      178      178              
============================================
  Files           167      167              
  Lines          8497     8526      +29     
  Branches       1261     1264       +3     
============================================
+ Hits           6529     6553      +24     
- Misses         1337     1341       +4     
- Partials        631      632       +1     
Impacted Files Coverage Δ
...h/alerting/transport/TransportGetFindingsAction.kt 92.23% <85.71%> (+1.64%) ⬆️
...g/opensearch/alerting/action/GetFindingsRequest.kt 100.00% <100.00%> (+50.00%) ⬆️
...ing/model/destination/DestinationContextFactory.kt 75.00% <0.00%> (-3.58%) ⬇️
.../alerting/transport/TransportIndexMonitorAction.kt 68.29% <0.00%> (-3.14%) ⬇️
.../kotlin/org/opensearch/alerting/util/IndexUtils.kt 70.83% <0.00%> (-2.09%) ⬇️
...ain/kotlin/org/opensearch/alerting/AlertService.kt 78.19% <0.00%> (-0.48%) ⬇️
...destinationmigration/DestinationConversionUtils.kt 71.11% <0.00%> (+1.11%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Petar Dzepina added 3 commits September 21, 2022 22:16
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
@eirsep eirsep merged commit 4ca0fb0 into opensearch-project:main Sep 23, 2022
toepkerd-zz pushed a commit to toepkerd-zz/alerting that referenced this pull request Sep 28, 2022
* added monitorId and findingsIndexName optinal params to GetFindingsAction

Signed-off-by: Petar Dzepina <petar.dzepina@vroom.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants