# Backport
This will backport the following commits from `main` to `8.16`:
- [[Synthetics] Show rules created in Obs Rules page !!
(#197215)](https://github.com/elastic/kibana/pull/197215)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT
[{"author":{"name":"Shahzad","email":"shahzad31comp@gmail.com"},"sourceCommit":{"committedDate":"2024-10-23T11:22:24Z","message":"[Synthetics]
Show rules created in Obs Rules page !! (#197215)\n\n##
Summary\r\n\r\nFixes
https://github.com/elastic/kibana/issues/197071\r\n\r\n---------\r\n\r\nCo-authored-by:
Christos Nasikas
<christos.nasikas@elastic.co>","sha":"9c4e67c985cf917a3664151d427a4fcdef0563d6","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-major","ci:project-deploy-observability","Team:obs-ux-management"],"title":"[Synthetics]
Show rules created in Obs Rules page
!!","number":197215,"url":"https://github.com/elastic/kibana/pull/197215","mergeCommit":{"message":"[Synthetics]
Show rules created in Obs Rules page !! (#197215)\n\n##
Summary\r\n\r\nFixes
https://github.com/elastic/kibana/issues/197071\r\n\r\n---------\r\n\r\nCo-authored-by:
Christos Nasikas
<christos.nasikas@elastic.co>","sha":"9c4e67c985cf917a3664151d427a4fcdef0563d6"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/197215","number":197215,"mergeCommit":{"message":"[Synthetics]
Show rules created in Obs Rules page !! (#197215)\n\n##
Summary\r\n\r\nFixes
https://github.com/elastic/kibana/issues/197071\r\n\r\n---------\r\n\r\nCo-authored-by:
Christos Nasikas
<christos.nasikas@elastic.co>","sha":"9c4e67c985cf917a3664151d427a4fcdef0563d6"}}]}]
BACKPORT-->
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
# Backport
This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Rules] Add New Rule Form to Stack Management
(#194655)](https://github.com/elastic/kibana/pull/194655)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Jiawei
Wu","email":"74562234+JiaweiWu@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-15T10:17:59Z","message":"[Response
Ops][Rules] Add New Rule Form to Stack Management (#194655)\n\n##
Summary\r\n\r\nEnables and adds the new rule form to stack management.
We are only\r\ngoing to turn this on for stack management for now until
we are\r\nconfident that this is fairly bug free.\r\n\r\n### To
test:\r\n\r\n1. Switch `USE_NEW_RULE_FORM_FEATURE_FLAG` to true\r\n2.
Navigate to stack management -> rules list\r\n3. Click \"Create rule\"
\r\n4. Assert the user is navigated to the new form\r\n5. Create
rule\r\n6. Assert the user is navigated to the rule details page\r\n7.
Click \"Edit\"\r\n8. Edit rule\r\n9. Assert the user is navigated to the
rule details page\r\n10. Try editing a rule in the rules list and assert
everything works as\r\nexpected\r\n\r\nWe should also make sure this
rule form is not enabled in other\r\nsolutions.\r\n\r\n###
Checklist\r\n- [ ] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by: Christos
Nasikas
<christos.nasikas@elastic.co>","sha":"5c2df6347d779f577946634e972d30224299079a","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:ResponseOps","v9.0.0","backport:prev-minor","v8.16.0"],"number":194655,"url":"https://github.com/elastic/kibana/pull/194655","mergeCommit":{"message":"[Response
Ops][Rules] Add New Rule Form to Stack Management (#194655)\n\n##
Summary\r\n\r\nEnables and adds the new rule form to stack management.
We are only\r\ngoing to turn this on for stack management for now until
we are\r\nconfident that this is fairly bug free.\r\n\r\n### To
test:\r\n\r\n1. Switch `USE_NEW_RULE_FORM_FEATURE_FLAG` to true\r\n2.
Navigate to stack management -> rules list\r\n3. Click \"Create rule\"
\r\n4. Assert the user is navigated to the new form\r\n5. Create
rule\r\n6. Assert the user is navigated to the rule details page\r\n7.
Click \"Edit\"\r\n8. Edit rule\r\n9. Assert the user is navigated to the
rule details page\r\n10. Try editing a rule in the rules list and assert
everything works as\r\nexpected\r\n\r\nWe should also make sure this
rule form is not enabled in other\r\nsolutions.\r\n\r\n###
Checklist\r\n- [ ] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by: Christos
Nasikas
<christos.nasikas@elastic.co>","sha":"5c2df6347d779f577946634e972d30224299079a"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/194655","number":194655,"mergeCommit":{"message":"[Response
Ops][Rules] Add New Rule Form to Stack Management (#194655)\n\n##
Summary\r\n\r\nEnables and adds the new rule form to stack management.
We are only\r\ngoing to turn this on for stack management for now until
we are\r\nconfident that this is fairly bug free.\r\n\r\n### To
test:\r\n\r\n1. Switch `USE_NEW_RULE_FORM_FEATURE_FLAG` to true\r\n2.
Navigate to stack management -> rules list\r\n3. Click \"Create rule\"
\r\n4. Assert the user is navigated to the new form\r\n5. Create
rule\r\n6. Assert the user is navigated to the rule details page\r\n7.
Click \"Edit\"\r\n8. Edit rule\r\n9. Assert the user is navigated to the
rule details page\r\n10. Try editing a rule in the rules list and assert
everything works as\r\nexpected\r\n\r\nWe should also make sure this
rule form is not enabled in other\r\nsolutions.\r\n\r\n###
Checklist\r\n- [ ] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by: Christos
Nasikas
<christos.nasikas@elastic.co>","sha":"5c2df6347d779f577946634e972d30224299079a"}},{"branch":"8.x","label":"v8.16.0","labelRegex":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
# Backport
This will backport the following commits from `main` to `8.x`:
- [Execution type field
(#195884)](https://github.com/elastic/kibana/pull/195884)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Khristinin
Nikita","email":"nikita.khristinin@elastic.co"},"sourceCommit":{"committedDate":"2024-10-14T14:29:12Z","message":"Execution
type field (#195884)\n\n## Added new field - execution type for
alerts\r\n\r\nAdded new field only for security type
alerts:\r\n\r\n`kibana.alert.rule.execution.type` - can be `manual` or
`scheduled`\r\n\r\nAlso, move intended timestamp settings
from\r\n`create_persistence_rule_type_wrapper` to
`build_alert`\r\n\r\nAlso added those new field to Alert schema and
types.\r\n\r\n\r\n\r\nhttps://github.com/user-attachments/assets/c5b021a6-4763-47ae-b46c-814a138be65a\r\n\r\n\r\n\r\nFor
tests:\r\n\r\n- tests all rule types with and without
suppression:\r\n`kibana.alert.rule.execution.type` - should be
`scheduled`,\r\n`kibana.alert.intended_timestamp` - should equal alert
timestamp\r\n\r\n- tests all rules with and without suppression with
manual run -\r\n`kibana.alert.rule.execution.type` - should be
`manual`,\r\n`kibana.alert.intended_timestamp` - should equal date
inside you manual\r\nrule run date
range\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"3d466a72a8ab181aadf562ab6c27a5affa32dc96","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor"],"title":"Execution
type
field","number":195884,"url":"https://github.com/elastic/kibana/pull/195884","mergeCommit":{"message":"Execution
type field (#195884)\n\n## Added new field - execution type for
alerts\r\n\r\nAdded new field only for security type
alerts:\r\n\r\n`kibana.alert.rule.execution.type` - can be `manual` or
`scheduled`\r\n\r\nAlso, move intended timestamp settings
from\r\n`create_persistence_rule_type_wrapper` to
`build_alert`\r\n\r\nAlso added those new field to Alert schema and
types.\r\n\r\n\r\n\r\nhttps://github.com/user-attachments/assets/c5b021a6-4763-47ae-b46c-814a138be65a\r\n\r\n\r\n\r\nFor
tests:\r\n\r\n- tests all rule types with and without
suppression:\r\n`kibana.alert.rule.execution.type` - should be
`scheduled`,\r\n`kibana.alert.intended_timestamp` - should equal alert
timestamp\r\n\r\n- tests all rules with and without suppression with
manual run -\r\n`kibana.alert.rule.execution.type` - should be
`manual`,\r\n`kibana.alert.intended_timestamp` - should equal date
inside you manual\r\nrule run date
range\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"3d466a72a8ab181aadf562ab6c27a5affa32dc96"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195884","number":195884,"mergeCommit":{"message":"Execution
type field (#195884)\n\n## Added new field - execution type for
alerts\r\n\r\nAdded new field only for security type
alerts:\r\n\r\n`kibana.alert.rule.execution.type` - can be `manual` or
`scheduled`\r\n\r\nAlso, move intended timestamp settings
from\r\n`create_persistence_rule_type_wrapper` to
`build_alert`\r\n\r\nAlso added those new field to Alert schema and
types.\r\n\r\n\r\n\r\nhttps://github.com/user-attachments/assets/c5b021a6-4763-47ae-b46c-814a138be65a\r\n\r\n\r\n\r\nFor
tests:\r\n\r\n- tests all rule types with and without
suppression:\r\n`kibana.alert.rule.execution.type` - should be
`scheduled`,\r\n`kibana.alert.intended_timestamp` - should equal alert
timestamp\r\n\r\n- tests all rules with and without suppression with
manual run -\r\n`kibana.alert.rule.execution.type` - should be
`manual`,\r\n`kibana.alert.intended_timestamp` - should equal date
inside you manual\r\nrule run date
range\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"3d466a72a8ab181aadf562ab6c27a5affa32dc96"}}]}]
BACKPORT-->
Co-authored-by: Khristinin Nikita <nikita.khristinin@elastic.co>
## Add new field to alert
Add optional `kibana.alert.intended_timestamp`. For scheduled rules it
has the same values as ALERT_RULE_EXECUTION_TIMESTAMP
(`kibana.alert.rule.execution.timestamp`)
for manual rule runs (backfill) it - will get the startedAtOverridden
For example if i have event at 14:30
And if we run manual rule run from 14:00-15:00, then alert will have
`kibana.alert.intended_timestamp` at 15:00
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
- https://github.com/elastic/kibana/issues/187630
- https://github.com/elastic/kibana/issues/187768
These changes fix the error on saving the alert
> An error occurred during rule execution: message: "[1:6952] failed to
parse field [event.original] of type [keyword] in document with id
'330b17dc2ac382dbdd2f2577c28e83b42c5dc66eaf95e857ec0f222abfc486fa'..."
The issue happens when source index has non-ECS compliant text field
which is expected to be a keyword. If the text value is longer than
32766 bytes and keyword field does not have ignore_above parameter set,
then on trying to store the text value in keyword field we will hit the
Lucene's term byte-length limit (for more details see [this
page](https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html)).
See the main ticket for steps to reproduce the issue.
---------
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
## Summary
* Adds optional severity levels to action group definition
* Determines whether alert severity "is improving" based on previous
action group and current action group of alert if severity levels are
defined for action groups.
* Persists this as `kibana.alert.severity_improving` inside the alert
document
* Persists `kibana.alert.previous_action_group` inside the alert
document
## To Verify
I've created a verification branch:
https://github.com/elastic/kibana/pull/184523 that updates the metric
threshold rule type to have action group severity levels. Verification
instructions in that PR summary.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
It fixes#179039
### Logs:
<img width="1210" alt="Screenshot 2024-04-11 at 18 59 27"
src="1795895a-f759-4bd4-a803-abec32dfed03">
### Infra:
<img width="1215" alt="Screenshot 2024-04-11 at 19 00 05"
src="74fede30-3ca4-4971-8e31-d9534bb66204">
### Release notes:
Warn the user when changing the index pattern while at least one rule
relies on the current one.
---------
Co-authored-by: Bena Kansara <bena.kansara@elastic.co>
Resolves https://github.com/elastic/kibana/issues/175998
## Summary
Follow on work from the alert creation delay feature. This PR adds
consecutive_matches, which is the count of active alerts that is used to
determine the alert delay, to the aad doc and to the action variables.
### Checklist
- [x] [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
### To verify
- Create a new rule with an alert delay
- Add the new `alert.consecutiveMatches` action variable to the action
message. Verify that when the alert fires the action variable is
populated in the message.
- To verify that the alert docs are as expected, go to [Dev
Tools](http://localhost:5601/app/dev_tools#/console) and run the
following `GET .internal.alerts-*/_search`
- Go back to the rule alerts table, and add the
`kibana.alert.consecutive_matches` field to the table. Verify that it is
populated and looks as expected.
Closes#153867
## Summary
This PR deprecates the following feature flag for the Custom threshold
rule alert details page.
```
xpack.observability.unsafe.alertDetails.observability.enabled
```
## 🧪 How to test
- Remove `xpack.observability.unsafe.alertDetails.observability.enabled`
from Kibana config
- Create a custom threshold rule
- Check the alert details page
- From alert table's flyout
- From action variables
- Add `xpack.observability.unsafe.alertDetails.observability.enabled` to
the Kibana config
- You should see the following warning
```
[WARN ][config.deprecation] You no longer need to configure
"xpack.observability.unsafe.alertDetails.observability.enabled".
```
## Release note
- Adds a dedicated alert details page for the Custom threshold rule.
When a threshold is breached, the alert details page helps users quickly
triage the alert, showing details and context around that alert such as
when the alert started, its current status, and other details. When a
log rate-based threshold is breached, the alert details page also
includes an automatic log rate analysis depicting shared characteristics
among log messages contributing to this change and in-context
Observability AI Assistant to provide further insight and remedy
suggestions.
Adds a global alerts page to the Stack management section to allow users
to browse alerts across different solutions/apps through a unified UX.
Refs #166709Closes#173647Closes#173650Closes#173648
Towards https://github.com/elastic/response-ops-team/issues/164
## Summary
Registering alerting example rules with framework AAD. This creates a
new alerts index `.alerts-default.alerts-default` that will eventually
hold alerts for all rules that have not customized their registration.
This index contains only the mappings for the basic alerts as data
documents, no custom context or payload fields.
## To Verify
Run kibana using `--run-examples` flag. Create one of the example rule
types and let it alert and then resolve and see an alert document get
created in the `.alerts-default.alerts-default` index.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
From the rule management page in observability, user will be able to
create an anomaly detection rule.
<img width="1789" alt="image"
src="9ce84628-bf1b-44f6-a51b-5bd2ad94d9bd">
<img width="1792" alt="image"
src="0add536c-2e62-4de5-9e06-2beedd0c0fe2">
## Summary
Add the `sideEffects` meta to packages without side effects to optimize
tree-shaking on browser-side bundles.
Notes:
- it mostly impacts the `securitySolution` app (almost 2mb reduction)
- it's not always beneficial for all apps, some apps gain some weight,
likely related to the way webpack optimizes the chunks, but I feel like
it's still overall beneficial (don't hesitate to say if you think
otherwise)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes#168472
## Summary
Replaces the old alerts list with the alerts table in the rule details
page, only for supported rule types.
<img width="1464" alt="image"
src="e556438a-3c01-4460-bfa8-2ff32d15a077">
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] [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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
---------
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR populates the existing `kibana.alert.workflow_user` field in the
alerts-as-data mappings with the `profile_uid` of the last user to
modify the status of the alert. It also adds a new field,
`kibana.alert.workflow_status_updated_at`, to track the last time the
workflow status was updated and populates it with a timestamp.
Similar to the alert assignment PR, `workflow_user` renders in the table
with a user avatar instead of the raw `profile_uid` value stored in the
alert. The filter in/out buttons on the row cell automatically add a
filter that uses the raw value so that filtering works correctly.
Due to limitations of Kibana's user profile implementation,
`workflow_user` is only populated if a user changes the alert status
using the alert status route (`POST
/api/detection_engine/signals/status`) within an interactive session,
i.e. logs in rather than passes credentials with each API request
([related issue](https://github.com/elastic/kibana/issues/167459)).
## Alerts table
## Alert details
### Checklist
- [ ] Functional changes are hidden behind a feature flag. If not
hidden, the PR explains why these changes are being implemented in a
long-living feature branch.
- [x] Functional changes are covered with a test plan and automated
tests.
- [x] Stability of new and changed tests is verified using the [Flaky
Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner).
- Flaky test run:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4130
- [ ] Comprehensive manual testing is done by two engineers: the PR
author and one of the PR reviewers. Changes are tested in both ESS and
Serverless.
- [x] Mapping changes are accompanied by a technical design document. It
can be a GitHub issue or an RFC explaining the changes. The design
document is shared with and approved by the appropriate teams and
individual stakeholders.
- https://github.com/elastic/security-team/issues/4820
- [x] Functional changes are communicated to the Docs team. A ticket or
PR is opened in https://github.com/elastic/security-docs. The following
information is included: any feature flags used, affected environments
(Serverless, ESS, or both).
- https://github.com/elastic/security-docs/issues/4325
## Summary
Closes#170497
<img width="483" alt="Screenshot 2023-11-16 at 1 25 18 PM"
src="4d974eab-9641-4618-b52a-2facf4c07667">
Adds scope dropdown to ES Query rules created from Discovery. If Logs or
Metrics are selected, rules created here will be visible in
Observability.
Also makes `Logs` the default consumer when creating a rule from either
Discovery and Observability.
### Checklist
- [x] [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
With this PR we introduce a new Alert User Assignment feature:
- It is possible to assign a user/s to alert/s
- There is a new "Assignees" column in the alerts table which displays
avatars of assigned users
- There is a bulk action to update assignees for multiple alerts
- It is possible to see and update assignees inside the alert details
flyout component
- There is an "Assignees" filter button on the Alerts page which allows
to filter alerts by assignees
We decided to develop this feature on a separate branch. This gives us
ability to make sure that it is thoroughly tested and we did not break
anything in production. Since there is a data scheme changes involved we
decided that it will be a better approach. cc @yctercero
## Testing notes
In order to test assignments you need to create a few users. Then for
users to appear in user profiles dropdown menu you need to activate them
by login into those account at least once.
8eeb13f3-2d16-4fba-acdf-755024a59fc2
Main ticket https://github.com/elastic/security-team/issues/2504
## Bugfixes
- [x] https://github.com/elastic/security-team/issues/8028
- [x] https://github.com/elastic/security-team/issues/8034
- [x] https://github.com/elastic/security-team/issues/8006
- [x] https://github.com/elastic/security-team/issues/8025
## Enhancements
- [x] https://github.com/elastic/security-team/issues/8033
### Checklist
- [x] Functional changes are hidden behind a feature flag. If not
hidden, the PR explains why these changes are being implemented in a
long-living feature branch.
- [x] Functional changes are covered with a test plan and automated
tests.
- [x] https://github.com/elastic/kibana/issues/171306
- [x] https://github.com/elastic/kibana/issues/171307
- [x] Stability of new and changed tests is verified using the [Flaky
Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner).
- [x]
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4091
- [x] Comprehensive manual testing is done by two engineers: the PR
author and one of the PR reviewers. Changes are tested in both ESS and
Serverless.
- [x] Mapping changes are accompanied by a technical design document. It
can be a GitHub issue or an RFC explaining the changes. The design
document is shared with and approved by the appropriate teams and
individual stakeholders.
* https://github.com/elastic/security-team/issues/7647
- [x] Functional changes are communicated to the Docs team. A ticket or
PR is opened in https://github.com/elastic/security-docs. The following
information is included: any feature flags used, affected environments
(Serverless, ESS, or both). **NOTE: as discussed we will wait until docs
are ready to merge this PR**.
* https://github.com/elastic/security-docs/issues/4226
* https://github.com/elastic/staging-serverless-security-docs/pull/232
---------
Co-authored-by: Marshall Main <marshall.main@elastic.co>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@gmail.com>
## Summary
With alerts-as-data integration added in
https://github.com/elastic/kibana/pull/166349, we're enabled to
incorporate alerts historical data into views in the ML UI to see how it
correlates with the anomaly results.
This PR add alerts data to the Anomaly Explorer page. If selected
anomaly detection jobs have associated alerting rules, we show a new
"Alerts" panel.
It contains:
<img width="1675" alt="image"
src="1945d1f1-7f12-4a03-8ebd-e0b36c8fce68">
#### A line chart with alerts count over time using the Lens embeddable
It support sync cursor with the Anomaly swim lane making it easier to
align anomalous buckets with alerts spikes.
<img width="1189" alt="image"
src="343b9bcf-bfa4-479d-bf8f-c1572402aa42">
#### Summary of the alerting rules
Shows an aggregated information for each alerting rule associated with
the current job selection:
- An indicator if alerting rule is active
- Total number of alerts
- Duration of the latest alerts
- Start time for active rules and Recovery time for recovered
Rules summary has a descending order based on the following criteria:
- Number of active alerts in rule
- Total number of alerts in rule
- Duration of the most recent alert in rule
<img width="1032" alt="image"
src="899f37f3-dd8c-4cb6-b7f6-263ed86d20ee">
#### Alert details
It contains an alerts table provided by `triggersActionsUI` plugin. For
each alert the user can:
- Open alerts details page
- Attach an alert to a new case
- Attach n alert to an existing case
<img width="1177" alt="image"
src="d3b7768a-bae2-404f-b364-ff7d7493cb9b">
#### Alert context menu
When an anomaly swim lane cells are selected, and there are alerts
within the chosen time range, a context menu displaying alert details is
shown.
<img width="1202" alt="image"
src="2b684c51-db5a-4f8c-bda9-c3e9aabde0d4">
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
Closes#170531
## Summary
This PR adds the query delay mechanism to the inventory rule type.
This PR also changes the inventory rule type consumer from
`infrastructure` to `observability`:
<img
src="e93da707-0e4e-4e49-80eb-17c4aebbb188"
width=400 />
## 🧪 How to test
- On serverless
- Create an inventory rule and make sure,
- by default, the query execution has 15s delay
- consumer field in alert is `observability`
- Change the query settings delay in the Observability rule setting and
ensure the specified delay is applied to the related query
- On stateful
- This mechanism is not applied to stateful, so the query execution time
should not have any delay
- Make sure consumer for inventory rule is `infrastructure` as before
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Updates new teams as codeowners for Observability team changes.
Also took the opportunity to:
- Delete some paths that no longer exist
- Split infra code ownership between teams (from #168992)
Closes#161758
## Summary
In this PR, I am saving the groupings information for the new threshold
in AAD in a similar format as the security team does, you can check the
format in the following screenshots. (Please check this
[RFC](https://docs.google.com/document/d/1DlykydM8Hk7-VAPOcuoUXp0L_qSi2jCZabJkPdO44tQ/edit#heading=h.2b1v1tr0ep8m)
for more information)
### Alert as data document
### Groupings action variable
### Alert table
It is also possible to search based on these new variables:
f07b39c2-52e8-4f50-b713-577da7ab1c42
## Summary
This PR is updating Discover's rule to be created under the
`stackAlerts` consumer and we created an [breaking change
issue](https://github.com/elastic/dev/issues/2344) to explain the
consequences of this update.
We also fix the rule's consumer for all rule types created under the
observability rule management to use their producer instead of `alerts`.
Also, we add the ability for the ES Query and new Generic Threshold
rules type to pick the consumer associated to the rule. The
`ensureAuthorized` and the `filter` functions have modified and
simplified to support this use case please check the newest unit test
added in
`x-pack/plugins/alerting/server/authorization/alerting_authorization.test.ts`.
There is now a dropdown in the rule form to prompt the user when
creating ES Query/Generic threshold rules to select the consumer based
on their authorized consumers (we can no longer use `alerts` for these).
If there is only 1 option, then the dropdown will not be shown and the
option will be chosen automatically.
Generic threshold rules will have the following possible consumers:
- infrastructure
- logs
ES query rules will have the following possible consumers:
- infrastructure
- logs
- stackAlerts (only from the stack management rule page)
## To Test:
### Single Consumer:
1. Create a user with only `logs` feature enabled (ensuring
`stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. Assert that the rule created has `logs` set in the `consumer` field
7. Repeat 5-6 for the generic threshold rule
8. Repeat 2-7 but on the Stack Management rules page
9. Repeat 1-8 for the `infrastructure` feature.
### Multiple Consumers:
1. Create a user with `logs`, `infrastructure` and `apm` features
enabled (ensuring `stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. A dropdown should prompt the user to select between 1 of the 3
consumers, select 1
7. Assert that the rule was created with the selected consumer
8. Repeat 5-7 for the generic threshold rule
9. Repeat 2-8 but on the Stack Management rules page
### Checklist
- [x] [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: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes#155083 with the following changes:
- Create a new field to store the action context for an alert under
`ALERT_CONTEXT` (`kibana.alert.context`) for Log Threshold Rule.
- Change the alert detail page to reference the `groupByKeys` under
`ALERT_CONTEXT` for the group by section
- Change the history chart to only display `12h` buckets
I plan to do a follow up PR to add the ALERT_CONTEXT to the other
Observability Rules which we will also need for our alert details pages.
### How to test
1. Index data using:
https://github.com/elastic/high-cardinality-cluster/tree/main/high_cardinality_indexer
by running the following command:
```
DATASET="fake_stack" EVENTS_PER_CYCLE=1 INDEX_INTERVAL=60000 ELASTICSEARCH_HOSTS=http://localhost:9200 node src/run.js
```
2. Create a DataView for named "Admin Console" with the index pattern of
`high-cardinality-data-fake_stack.admin-console-*` and the timestamp
field set to `@timestamp`
3. Go to the Log Stream in Observability and change the index pattern to
"Admin Console"
4. Create a rule that looks like:
<img width="600" alt="image"
src="https://user-images.githubusercontent.com/41702/232578891-e65a3f1a-457c-459a-8d7f-cadc85e7067c.png">
5. Create a rule WITHOUT a group by that will trigger and check the
alert detail page
6. Create a rule with a ratio WITHOUT a group by that will trigger and
check the alert detail page
7. Create a rule with a ratio WITH a group by that will trigger and
check the alert detail page
---------
Co-authored-by: Kevin Delemme <kdelemme@gmail.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces the field `kibana.alert.url` to the alerts generated
by al alert rule types. Functionality was added in [this
PR](https://github.com/elastic/kibana/pull/148800) for 8.8 to allow
users to link directly to the alert flyout. To be able to provide users
with this field via our connectors, we are adding the url under the
field `kibana.alert.url`.
To test, create an alert of any type and you should see this field set
in the alert flyout:
<img width="838" alt="image"
src="https://user-images.githubusercontent.com/17211684/233993880-fc7fd790-105e-4c16-947e-e2f5a2965936.png">
The url provided is a redirect path that contains the necessary
information (space, id, index, and timestamp) to be able to redirect the
user to a filtered alert page for the given alert and the detail flyout
opened. This allows us to retain flexibility in the future for any
changes that may occur with the alert flyout or an alert page. More on
that can be found in the earlier pr:
https://github.com/elastic/kibana/pull/148800
### Testing
1. The `kibana.alert.url` field makes use of the `publicBaseUrl`
configuration which must be set in your kibana.dev.yml for this field to
be generated. Add the following to your yaml file. Note that if you use
a `basePath`, it will have to be appended to the end of your
`publicBaseUrl` path.
```
server.publicBaseUrl: 'http://localhost:5601'
```
with basePath:
```
server.basePath: '/someBasePath'
server.publicBaseUrl: 'http://localhost:5601/someBasePath'
```
2. Generate data and enable any rule type to get alerts.
3. Go to the alert page, click expand detail, and search for
`kibana.alert.url` in the table.
4. Visit that url and you should see a filtered alert page with the
details flyout opened
***Caveat - when grouping is enabled, the details flyout will not open
as the table that it is attached to is not actually loaded at that point
in time. When the table is loaded by either disabling grouping or
opening the group, the details flyout will open
Closes#153877
## Summary
This PR adds a new field called `kibana.alert.evaluation.values` to the
alert document for metric threshold and inventory rules. This is an
array of numbers but depending on the result of the rule execution, the
value might be `null` too.
We want to use this result in the metric threshold alert details page,
so I checked whether this value can be retrieved correctly there or not:
**Note**
I will add tests later, I would like to get feedback about the
implementation first.
## 🧪 How to test
- Add xpack.observability.unsafe.alertDetails.metrics.enabled: true to
the Kibana config
- Create a metric threshold and inventory rule that generates an alert
- Check the alert document for the `kibana.alert.evaluation.values`
field, it should be an array with the result of evaluation for the
related criteria
- If you are using metricbeat, stop it so the value of evaluation will
be null
- Go to the alert details page, you should be able to see the main chart
even when the evaluation value is null
- Check the alert document for the `kibana.alert.evaluation.values`
field, it should be an array including a null value
Resolves https://github.com/elastic/kibana/issues/150358
## Summary
In a previous [PR](https://github.com/elastic/kibana/pull/145581) we
started installing a common component template for framework alerts as
data when the `xpack.alerting.enableFrameworkAlerts` config flag is set
to true. In that PR we used a different naming pattern than what is used
by the rule registry for its component templates.
In this PR we are doing the following:
* Renaming the installed `alerts-common-component-template` to
`.alerts-framework-mappings`.
* Creating and installing `.alerts-legacy-alert-mappings` component
template when `enableFrameworkAlerts: true` on alerting plugin setup
* The combination of the two component templates creates the same set of
mappings as the rule registry technical component template
* Creating and installing `.alerts-ecs-mappings` component template when
`enableFrameworkAlerts: true` on alerting plugin setup (when
`enableFrameworkAlerts: false`, the rule registry continues to install
this component template
* Using the `@kbn/ecs` package provided by core to generate the ECS
field map. The rule registry will continue to install the existing ECS
field map which is actually a subset of ECS fields
* Adding `useLegacy` and `useEcs` flags that allow rule types to specify
whether to include the legacy alerts component template and the ECS
component template when registering with framework alerts-as-data.
* Moved some common functions to alerting framework from the rule
registry
## Things to note
* When generating the ECS field map, we are now including the
`ignore_above` setting from the `@kbn/ecs` package. This changes the ECS
component template to include those settings. I tested updating an index
with just `"type":"keyword"` mappings to add the `ignore_above` field to
the mapping and had no issues so this seems like an additive change to
the mapping that will hopefully prevent problems in the future.
* The rule registry ECS component template also includes the technical
fields which is redundant because the technical component template is
automatically installed for all index templates so the framework ECS
component template only contains ECS fields.
| Previous mapping | Updated mapping |
| ----------- | ----------- |
| `{ "organization": { "type": "keyword" } }` | `{ "organization": {
"type": "keyword", "ignore_above": 1024 } }` |
## To Verify
### Verify that the generated component templates are as expected:
Get the following
**While running `main`:**
1. Get the ECS component template `GET
_component_template/.alerts-ecs-mappings`
2. Get the technical component template `GET
_component_template/.alerts-technical-mappings`
3. Create a detection rule that creates an alert and then get the index
mapping for the concrete security alert index `GET
.internal.alerts-security.alerts-default-000001/_mapping`
**While running this branch with `xpack.alerting.enableFrameworkAlerts:
false`:**
4. Get the ECS component template `GET
_component_template/.alerts-ecs-mappings`
5. Get the technical component template `GET
_component_template/.alerts-technical-mappings`
6. Create a detection rule that creates an alert and then get the index
mapping for the concrete security alert index `GET
.internal.alerts-security.alerts-default-000001/_mapping`
**While running this branch with `xpack.alerting.enableFrameworkAlerts:
true`:**
7. Get the ECS component template `GET
_component_template/.alerts-ecs-mappings`
8. Get the technical component template `GET
_component_template/.alerts-technical-mappings`
9. Create a detection rule that creates an alert and then get the index
mapping for the concrete security alert index `GET
.internal.alerts-security.alerts-default-000001/_mapping`
10. Verify that component templates exist for
`.alerts-framework-mappings` and `.alerts-legacy-alert-mappings`
**Compare the ECS component templates**
Compare 1 and 4 (ECS component template from `main` and installed by
rule registry in this branch). The difference should be:
* no difference in ECS fields
* because the rule registry ECS component template also includes
technical fields, you will see the 2 new technical fields in this branch
Compare 4 and 7 (ECS component template from rule registry & alerting
framework in this branch).
* some new ECS fields for alerting installed template
* each `keyword` mapped field for alerting installed template should
have `ignore_above` setting
* no `kibana.*` fields in the alerting installed template
**Compare the technical component templates**
Compare 2 and 5 (technical component template from `main` and installed
by rule registry in this branch). The difference should be:
* 2 new `kibana.alert` fields (`flapping_history` and `last_detected`)
Compare 5 and 8 (technical component template from rule registry &
alerting framework in this branch).
* there should be no difference!
**Compare the index mappings**
Compare 3 and 6 (index mapping from `main` and installed by rule
registry in this branch). The difference should be:
* 2 new `kibana.alert` fields (`flapping_history` and `last_detected`)
Compare 6 and 9 (index mapping from rule registry & alerting framework
in this branch).
* some new ECS fields
* each `keyword` mapped ECS field should have `ignore_above` setting
### Verify that the generated component templates work with existing
rule registry index templates & indices:
1. Run `main` or a previous version and create a rule that uses both ECS
component templates & technical component templates (detection rules use
both). Let it run a few times.
2. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts
with no rule registry errors and the rule continues to run as expected.
3. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts
with no alerting or rule registry errors and the rule continues to run
as expected. Verify that the mapping on the existing
`.internal.alerts-security.alerts-default-000001` has been updated to
include the latest ECS mappings and the two new technical fields.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Mike Côté <mikecote@users.noreply.github.com>
## Summary
PR https://github.com/elastic/kibana/pull/147013 extended the alert's
schema to be able to store the case id an alert is attached to. This PR
adds the ability to update the `case_ids` field of the alert when an
alert is attached to a case. It also limits the number of cases an alert
can be attached to ten.
### Permissions
A user to attach an alert to a case needs a) to have read access to the
solution via the kibana feature privileges and b) to have write access
to the case. The user that did the request should not need to have
written access to the alert for Cases to add the case ID to the alert's
data. For that reason, the alert data client is extended to cover this
particular need: update an alert even if the user has read access.
## Alerts client aside
For future reference, the alerts client uses the request to check the
kibana feature authorization but uses the internal system user to
perform any write and get operations on the alert indices themselves.
For security solution this means that a user with only read access to
the security solution kibana feature, write access to cases, and no read
or write access to the alert indices could attach an alert to a case and
have the case id stored in the alert.
For observability, users intentionally do not have access to the alert
indices so we want to bypass the authorization check on the indices
which is why the current alerts client uses an es client that is an
internal system user.
Related issue: https://github.com/elastic/kibana/issues/146864
### Checklist
Delete any items that are not applicable to this PR.
- [x] [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
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Resolves https://github.com/elastic/kibana/issues/145100
## Summary
* Adds alerting config for `enableFrameworkAlerts`
* When `xpack.alerting.enableFrameworkAlerts=true`, `AlertsService` is
initialized during the alerting plugin setup phase
* Adds optional `alerts` definition to the `RuleType` definition which
allows a rule type to specify a context and a field mapping for that
context
* `AlertsService.initialize()`
* installs an ILM policy that will be used by all alerts-as-data indices
- `alerts-default-ilm-policy`
* installs a component template that will be used by all alerts-as-data
indices - `alerts-common-component-template`, including all the mappings
for fields needed by the framework
* Rule type registration - when a rule type with an `alerts` definition
is registered, the context and field map are registered with the
`AlertService`. When `AlertsService` initialization is completed
successfully, context specific resources are installed.
* Context specific resources:
* installs context specific component template that reflects the
registered field map - `alerts-${context}-component-template`
* installs context specific index template for the default namespace -
`.alerts-${context}-default-template`
* creates context specific concrete write index for the default
namespace - `.alerts-${context}-default-000001`
* Resource installation retries for transient ES errors and
short-circuits when a timeout value is reached
## Notes
* We explore the possibility of creating a single index template per
context and re-using it for space-aware concrete indices but a rollover
alias (which must be space-aware) must be attached to an index template
so it is not feasible to only have a single index template
* There will be a followup issue for create space-specific index
templates/indices as needed to support detection rules desire to
separate alerts by space.
## To Verify
* set `xpack.alerting.enableFrameworkAlerts: true` in your kibana.yml
* modify
`x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type.ts` to
define a custom field mapping for the `stack` context
```
--- a/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type.ts
+++ b/x-pack/plugins/stack_alerts/server/rule_types/es_query/rule_type.ts
@@ -187,5 +187,14 @@ export function getRuleType(
},
producer: STACK_ALERTS_FEATURE_ID,
doesSetRecoveryContext: true,
+ alerts: {
+ context: 'stack',
+ fieldMap: {
+ 'kibana.alert.threshold': {
+ required: false,
+ type: 'long',
+ },
+ },
+ },
};
}
```
* start up ES and Kibana and verify that the correct resources are
installed. The following should be created:
* ILM policy - `alerts-default-ilm-policy`
* Common component template - `alerts-common-component-template`
* Stack component template - `alerts-stack-component-template`
* Stack index template for default space -
`.alerts-stack-default-template`
* Stack write index for default space - `.alerts-stack-default-000001`
* verify that the index template uses both component templates and that
the expected mappings are applied to the index
* try making non-destructive, additive only changes to the common
component template or the stack context field mapping and verify that
the concrete index mappings are updated.
### Checklist
- [x] [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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Addresses https://github.com/elastic/kibana/issues/130699
This PR implements alert throttling per rule execution for query and
saved query rules. The implementation is very similar in concept to
threshold rules. We allow users to pick one or more fields to group
source documents by and use a composite aggregation to collect documents
bucketed by those fields. We create 1 alert for each bucket based on the
first document in the bucket and add metadata to the alert that
represents how to retrieve the rest of the documents in the bucket.
The metadata fields are:
- `kibana.alert.suppression.terms`: `{field: string; value: Array<string
| number>}` An array of objects, each object represents one of the terms
used to group these alerts
- `kibana.alert.suppression.start`: `Date` The timestamp of the first
document in the bucket
- `kibana.alert.suppression.end`: `Date` The timestamp of the last
document in the bucket
- `kibana.alert.suppression.docs_count`: `number` The number of
suppressed alerts
There is one new rule parameter, currently implemented at the solution
level, to enable this feature: `alertSuppression.groupBy`: `string[]`.
Similar to threshold rules, the throttled query rules keep track of
created alerts in the rule state in order to filter out duplicate
documents in subsequent rule executions. When a throttled alert is
created, we store the bucket information including field names, values,
and end date in the rule state. Subsequent rule executions convert this
state into a filter that excludes documents that have already been
covered by existing alerts. This is necessary because consecutive rule
executions will typically query overlapping time ranges.
## Screenshots
### Rule Create/Edit With License
<details>
</details>
### Rule Details With License
<details>
</details>
### Rule Create, or Rule Edit of a rule without existing suppression
configuration, Without License
<details>
</details>
### Editing a rule that has existing suppression configuration, but
without the correct license, still allows changing the configuration (to
allow removing the params)
<details>
</details>
### Rule Details Without License
<details>
</details>
### Alerts table
<details>
</details>
### Known issues
- The layers icon in the rule name for suppressed alerts does not show
up in the rule preview table
Co-authored-by: Madi Caldwell <madison.caldwell@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* move flapping to kibana.alerting in event log
* move flapping back to under kibana.alert. Add integration tests
* add default flapping state to alert logs
