[RAC] [APM] removes hardcoded alerts as data index from apm integration test#109715
[RAC] [APM] removes hardcoded alerts as data index from apm integration test#109715dhurley14 merged 4 commits intoelastic:masterfrom
Conversation
936eeba to
eb85af6
Compare
| name: APMFtrConfigName; | ||
| license: 'basic' | 'trial'; | ||
| kibanaConfig?: Record<string, string>; | ||
| kibanaConfig?: Record<string, string | string[]>; |
There was a problem hiding this comment.
Added the above while I was debugging the integration tests using the following as part of the FTR kibana config and needed to pass in an array of values instead of just a string. I can remove this but figured it might be useful going forward for anybody who is debugging tests in the future.
--logging.verbose=true,
--logging.events.log=${JSON.stringify([ 'alerts', 'ruleRegistry', 'apm', 'securitySolution', 'info', 'warning', 'error', 'fatal', ])},
--logging.events.request=${JSON.stringify(['info', 'warning', 'error', 'fatal'])},
--logging.events.error='*',
--logging.events.ops=__no-ops__,
| ? Object.entries(kibanaConfig).map(([key, value]) => | ||
| Array.isArray(value) ? `--${key}=${JSON.stringify(value)}` : `--${key}=${value}` | ||
| ) |
There was a problem hiding this comment.
related to my above comment
| index: targetIndices[0], | ||
| }); | ||
| // eslint-disable-next-line no-empty | ||
| } catch (exc) {} |
There was a problem hiding this comment.
can you leave a comment here why it's okay for this to fail?
There was a problem hiding this comment.
For sure I can add a comment to the code. Essentially it boils down to this:
When calling refresh on an index pattern .alerts-observability.apm.alerts* (as was originally the hard-coded string in this test) The response from Elasticsearch is a 200, even if no indices which match that index pattern have been created.
When calling refresh on a concrete index alias .alerts-observability.apm.alerts-default for instance, we receive a 404 error index_not_found_exception when no indices have been created which match that alias (obviously).
Since we are receiving a concrete index alias from the observability api instead of a kibana index pattern and we understand / expect that this index does not exist at certain points of the test, we can try-catch at certain points without caring if the call fails. There are points in the code where we do want to ensure we get the appropriate error message back (such as this expect you commented on)
Example..
# This request yields a 200 response
GET thisdoesnotexist*/_refresh
# Response
{
"_shards" : {
"total" : 0,
"successful" : 0,
"failed" : 0
}
}
# This request yields a 404 error
GET thisdoesnotexist/_refresh
# Response
{
"error" : {
"root_cause" : [
{
"type" : "index_not_found_exception",
"reason" : "no such index [thisdoesnotexist]",
"resource.type" : "index_or_alias",
"resource.id" : "thisdoesnotexist",
"index_uuid" : "_na_",
"index" : "thisdoesnotexist"
}
],
"type" : "index_not_found_exception",
"reason" : "no such index [thisdoesnotexist]",
"resource.type" : "index_or_alias",
"resource.id" : "thisdoesnotexist",
"index_uuid" : "_na_",
"index" : "thisdoesnotexist"
},
"status" : 404
}
There was a problem hiding this comment.
is allow_no_indices not good enough here?
There was a problem hiding this comment.
or maybe we can just add an asterisk to the end?
| allow_no_indices: true, | ||
| }); | ||
| } catch (exc) { | ||
| expect(exc.statusCode).to.eql(404); |
There was a problem hiding this comment.
there's no assertion here when the request succeeds, no?
There was a problem hiding this comment.
Good catch I'll update this to fail if a 200 response is received.
| index: APM_METRIC_INDEX_NAME, | ||
| }); | ||
| // eslint-disable-next-line no-empty | ||
| } catch (exc) {} |
There was a problem hiding this comment.
same here, comment would be great
There was a problem hiding this comment.
Ah yeah I think I can undo this.
| refresh: true, | ||
| }); | ||
| // eslint-disable-next-line no-empty | ||
| } catch (exc) {} |
| expect(beforeDataResponse.body.hits.hits.length).to.be(0); | ||
| }); | ||
| } catch (exc) { | ||
| expect(exc.message).contain('index_not_found_exception'); |
There was a problem hiding this comment.
same here, there's only an assertion when the request fails
There was a problem hiding this comment.
Yup I'll update this to fail if a 200 is received as well.
There was a problem hiding this comment.
I am wondering if this is necessary. I think the intent here was to ensure there was no data written before the alert executed, and before violations were indexed, I don't think we need to test whether the index exists here, as long as we have a different test for that (which I think we do?). My concern here would be a) that these assertions are adding to the complexity of the test, b) might cause some false negatives to trigger in certain scenarios (e.g. when the index is not cleaned up after a test run, or the implementation changes).
…x refresh catch block is empty
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @dhurley14 |
banderror
left a comment
There was a problem hiding this comment.
Changes in x-pack/test/apm_api_integration/tests/alerts/rule_registry.ts LGTM 👍
| const TEST_URL = '/internal/rac/alerts'; | ||
| const ALERTS_INDEX_URL = `${TEST_URL}/index`; | ||
| const SPACE1 = 'space1'; | ||
| const APM_ALERT_INDEX = '.alerts-observability-apm'; |
There was a problem hiding this comment.
Note for myself: I will need to fix this name in #109567
| .get(`/api/alerts/alert/${alert.id}`) | ||
| .set('kbn-xsrf', 'foo'); | ||
|
|
||
| const { body: targetIndices, status: targetIndicesStatus } = await getAlertsTargetIndices(); |
There was a problem hiding this comment.
what's the purpose of this exactly? This function only cares about whether the rule was executed. There might be a scenario where the alert index does not exist, but it's okay because no alerts were written.
dgieselaar
left a comment
There was a problem hiding this comment.
LGTM, some questions/concerns but nothing blocking. Thanks!
…on test (elastic#109715) * removes hardcoded index from apm integration tests * adds integration tests for rule registry's get index route * more cleanup * fail try-catch if response is not empty, adds comments as to why index refresh catch block is empty
…on test (elastic#109715) * removes hardcoded index from apm integration tests * adds integration tests for rule registry's get index route * more cleanup * fail try-catch if response is not empty, adds comments as to why index refresh catch block is empty
…tegration test (#109715) (#110108) * [RAC] [APM] removes hardcoded alerts as data index from apm integration test (#109715) * removes hardcoded index from apm integration tests * adds integration tests for rule registry's get index route * more cleanup * fail try-catch if response is not empty, adds comments as to why index refresh catch block is empty * fix name of index Co-authored-by: Devin W. Hurley <devin.hurley@elastic.co>
…egration test (#109715) (#110109) * [RAC] [APM] removes hardcoded alerts as data index from apm integration test (#109715) * removes hardcoded index from apm integration tests * adds integration tests for rule registry's get index route * more cleanup * fail try-catch if response is not empty, adds comments as to why index refresh catch block is empty * fix index name Co-authored-by: Devin W. Hurley <devin.hurley@elastic.co>
Summary
removes hardcoded alerts as data index from apm integration test and adds integration tests for getting alerts index from rule registry route.
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers