[RAC] Get o11y alerts in alerts table#109346
Conversation
|
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
weltenwort
left a comment
There was a problem hiding this comment.
Thanks for jumping on this so quickly!
The fact that we're using the ruleDataClient here leads to a few problems (that existed before, but are solidified through these changes):
- The field list is read using the internal user's permissions and not the current user's permissions.
- The addition of the
indexNamesargument togetReaderbreaks the abstraction, because the whole point of theRuleDataClientis to delegate the index name generation to theRuleDataService.
How about the following:
- The
dynamic_index_patternroute turns a list ofregistrationContexts and anamespaceinto an index name pattern (e.g.['.alerts-observability.logs.alerts-default', '.alerts-observability.metrics.alerts-default']). On the alerts page we then use Kibana'sIndexPatternServiceto requestgetFieldsForWildcardto get the field list for use as adynamicIndexPattern.
Does that make sense?
| } | ||
|
|
||
| public getReader(options: { namespace?: string } = {}): IRuleDataReader { | ||
| public getReader(options: { namespace?: string; indexNames?: string[] } = {}): IRuleDataReader { |
There was a problem hiding this comment.
Doesn't this break the abstraction layer the RuleDataClient represents?
| } | ||
|
|
||
| /** | ||
| * Initializes alerts-as-data index and starts index bootstrapping right away. |
There was a problem hiding this comment.
How does this comment correlate to the actual function?
|
@XavierM I took the liberty of removing the |
| endpoint: 'GET /api/observability/rules/alerts/dynamic_index_pattern', | ||
| params: { | ||
| query: { | ||
| namespace: 'default', |
There was a problem hiding this comment.
@weltenwort Is there a way to get the space id from the UI? This may not always be default, no?
We were pulling it off of the alerting framework rulesClient in the rules/alerts/dynamic_index_pattern route so we could ensure we acquired the correct space id on the request.. If observability doesn't plan on segmenting by space id I could understand why this would be hard coded to default then. Just looking for clarification here..
There was a problem hiding this comment.
This is intentionally fixed as default, because in observability we're not using the space id in the namespace. The filtering by space happens as part of the RBAC filter if I saw that correctly.
banderror
left a comment
There was a problem hiding this comment.
Looks good to me overall, I just left a few comments. Thank you @XavierM @dhurley14 @weltenwort
Also, mapConsumerToIndexName is still used by AlertsClient (RBAC), right?
| indexOptions, | ||
| }); | ||
|
|
||
| this.registeredIndices.set(indexOptions.registrationContext, indexInfo); |
There was a problem hiding this comment.
The full index name (indexInfo.baseName) is defined not only by registrationContext, but also by dataset (alerts or events).
I guess the proper key for this map would be ${indexOptions.registrationContext}.${indexOptions.dataset}, and getRegisteredIndexInfo would need to accept dataset as well.
There was a problem hiding this comment.
True, this only works because we assume alerts as a dataset implicitly. Would it be ok to add that as a follow-up to unblock this ASAP?
There was a problem hiding this comment.
Yep, of course 👍
TODO in the follow-up PR: let getRegisteredIndexInfo to accept dataset as well, generate keys of the registeredIndices map correctly.
| registrationContexts: [ | ||
| 'observability.apm', | ||
| 'observability.logs', | ||
| 'observability.infrastructure', |
There was a problem hiding this comment.
observability.infrastructure registration context doesn't exist in the code. What plugin is supposed to be defining it?
There was a problem hiding this comment.
I think this should be observability.metrics. The app is called infrastructure for historical reasons, but not the registration context.
There was a problem hiding this comment.
TODO in the follow-up PR: remove observability.infrastructure and make sure observability.metrics is there.
XavierM
left a comment
There was a problem hiding this comment.
@weltenwort, I agree with what you did and to be honest I was not really familiar with all the work and discussion around ruleDataClient or ruleDataService. So I am glad you fix it and make it good for everybody.
banderror
left a comment
There was a problem hiding this comment.
Approving to unblock and merge this PR ASAP.
I'll try to address these things in a follow-up PR:
weltenwort
left a comment
There was a problem hiding this comment.
LGTM, thanks everyone for the collaboration.
Known issues are the wrong observability.infrastructure registration context and the lack of dataset in the registered index info map.
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Unknown metric groupsAPI count
API count missing comments
Non-exported public API item count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
💔 Backport failed
Successful backport PRs will be merged automatically after passing CI. To backport manually run: |
|
The failed backport is probably due a chain of other backports failing. I'll keep track of those any retry later today: |
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de> Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com> Co-authored-by: Felix Stürmer <stuermer@weltenwort.de>
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de> # Conflicts: # x-pack/plugins/observability/public/pages/alerts/alerts_table_t_grid.tsx # x-pack/plugins/observability/public/pages/alerts/index.tsx
* get back index names in o11y * testing and integration * fix types * Avoid using the rule data client for field list * Remove left-over index argument * no needs of alert consumer anymore Co-authored-by: Felix Stürmer <stuermer@weltenwort.de> # Conflicts: # x-pack/plugins/observability/public/pages/alerts/alerts_table_t_grid.tsx # x-pack/plugins/observability/public/pages/alerts/index.tsx Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com>
…atures to index names (#109567) **Ticket:** #102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of #109346 and replaces #108872. TODO: - [x] Address #109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close #108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
…atures to index names (elastic#109567) **Ticket:** elastic#102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of elastic#109346 and replaces elastic#108872. TODO: - [x] Address elastic#109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close elastic#108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
…atures to index names (elastic#109567) **Ticket:** elastic#102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of elastic#109346 and replaces elastic#108872. TODO: - [x] Address elastic#109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close elastic#108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
…atures to index names (#109567) (#110068) **Ticket:** #102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of #109346 and replaces #108872. TODO: - [x] Address #109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close #108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
…atures to index names (#109567) (#110067) **Ticket:** #102089 🚨 **This PR is critical for Observability 7.15** 🚨 ## Summary This PR introduces changes that fix the usage of alerts-as-data index naming in RBAC. It builds on top of #109346 and replaces #108872. TODO: - [x] Address #109346 (review) - [x] Make changes to `AlertsClient.getAuthorizedAlertsIndices()` so it starts using `RuleDataService` to get index names by feature ids. - [x] Delete the hardcoded `mapConsumerToIndexName` where we had incorrect index names. - [x] Close #108872 ### Checklist Delete any items that are not applicable to this PR. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>

Summary
Fixes #109317
@dhurley14 and I pair to bring back o11y alerts in the table. Now, we are passing directly the indexes name in our alerts search strategy and count on the filter of the authorization to show the right alerts. The index names are saved in memory inside of the ruleServiceData.