## 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
Part of https://github.com/elastic/kibana/issues/138222
in @types/react@18 types [have become more
strict](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/56210).
This PR addresses a bunch of easy fixes. The most common are:
### 1 Removal of implicit children
For components that do implement children but relied on their implicit
declaration from React.FunctionComponent or React.Component:
```diff
interface Props {
+ children?: React.ReactNode;
}
class SomeClassComponents React.Component<Props> {
render() {
return <div>{this.props.children}</div>
}
}
const SomeFunctionComponent: React.FunctionComponent<Props> = props => <div>{props.children}</div>
```
or
```diff
- const SomeFunctionComponent: React.FunctionComponent<Props> = props => <div>{props.children}</div>
+ const SomeFunctionComponent: React.FunctionComponent<React.PropsWithChildren<Props>> = props => <div>{props.children}</div>
```
*Note 1:*
The most common change occurs in unit tests where `renderHook` and
`wrapper` are used. I had to re-type the props so that `children` were
there
```diff
const { result } = renderHook(
() => {
return useLicense();
},
{
- wrapper: ({ children }) => (
+ wrapper: ({ children }: React.PropsWithChildren<{}>) => (
<TestProviders license={license}>{children}</TestProviders>
),
}
);
```
```diff
- const { result } = renderHook<GetCasesColumn, UseCasesColumnsReturnValue>(
+ const { result } = renderHook<React.PropsWithChildren<GetCasesColumn>, UseCasesColumnsReturnValue>(
() => useCasesColumns(defaultColumnArgs),
{
wrapper: ({ children }) => <TestProviders>{children}</TestProviders>,
}
);
```
*Note 2:*
With @types/react@17 the components that don't have any props apart from
`children` I had to use `React.PropsWithChildren<{}>`, whereas in
@types/react@18 the argument becomes optional, so it can be omitted, and
type simpler with `React.PropsWithChildren` without an argument
### 2 `this.context` becomes `unknown` (was `any`)
In a couple of places where `this.context` is used, I had to type it
### 3 `ComponentType` from enzyme is no longer compatible with
`ComponentType` from react
This one is a bummer, but where `wrappingComponent` with enzyme is used
I had to cast it to type from `enzyme`
```diff
- import { mount } from 'enzyme'
+ import { mount, ComponentType } from 'enzyme'
wrapper = mount(<ClosureOptions {...props} />, {
- wrappingComponent: TestProviders,
+ wrappingComponent: TestProviders as ComponentType<{}>,
});
```
## Summary
This PR adds a new functionality to the `kbn-expandable-flyout` package
and its usage in the Security Solution application.
The package's flyout now support to be rendered in `overlay` or `push`
mode, following [EUI's
recommendation](https://eui.elastic.co/#/layout/flyout#push-versus-overlay).
A gear icon button is rendered in the top right corner, next to the
close button. When clicked, a menu appears where users can select `push`
or `overlay` values. `overlay` is the default value. If `push` is
selected, a `Reset to default` empty button can be used to reset to
`overlay`.
Overlay option selected (by default)
Push option selected
The flyout should be toggled between `overlay` and `push` mode in all
the pages it's been currently used in:
- alerts page
- rule creation page
- explore pages (host, users...)
- case detail page
https://github.com/user-attachments/assets/b4cec138-802c-430d-8f37-01258e6afef3
But the flyout cannot be set to `push` mode when opened from Timeline.
Timeline is a modal (an EUI Portal to be precise), and getting the
portal as well as the overlay mask to correctly resize according to the
flyout's width (which is dynamic, changes with the screen size and also
changes if the flyout is in collapsed or expanded mode) is very
difficult.
A future PR might add this functionality to TImeline. At this time, the
flyout offers the option to disable the `push/overlay` toggle as well as
an icon to show a tooltip to explain why.
https://github.com/user-attachments/assets/e00961c8-cc75-4eb9-b34d-544bc4391d5c
#### Notes
The package also offers a way to hide the gear icon entirely. In the
future, we might need a bit more flexibility if we want to be able to
show the gear icon with options others than the `push/overlay` entry.
Finally the state of the flyout type (`overlay` vs `push`) is saved in
local storage so that users don't have to set the value over and over
again. This state is persisted within the `kbn-expandable-flyout`
package so that developers don't have to worry about setting it up. The
package uses its internal `urlKey` to guarantee that the key used to
save in localStorage is unique. This means that `memory` flyouts cannot
persist the `push` or `overlay` states, this is expected.
500315b5-07d4-4498-aab9-ee2e2be0253b
### Notes
The package's README has been updated.
New Storybook stories have been added to reflect the new push/overlay
functionality.
https://github.com/elastic/kibana/issues/182593
## Summary
This PR updates the structure of the Dashboards docs and refreshes some
outdated parts of the content.
More updates will be made in future PRs to refresh screenshots and to
refresh the content more in depth.
This new structure and edits:
- distribute the pages in more user-oriented identified themes, for
better findability, scanning, and to ease possible integration of some
of these pages into in-app documentation.
- are more future proof to evolve along with upcoming features.
~I'll leave this PR as a draft until I resolve some link dependencies
coming from other docs sources and check some additional bits of
content.~
Preview available on demand on Slack.
Closes: https://github.com/elastic/platform-docs-team/issues/408 (I'll
create separate issues for remaining items)
Closes: https://github.com/elastic/platform-docs-team/issues/413
Closes: https://github.com/elastic/platform-docs-team/issues/418
## Summary
Creates CLI script tooling for building data, rules, exceptions, and
lists in any (local, cloud, serverless) environment for manual testing.
The initial commits here add generated clients for accessing security
solution, exceptions, and lists APIs and a placeholder script where
those clients are set up for use. See README for more details.
Much of the code in this PR is auto-generated clients. The hand written
code is intended to be primarily in `quickstart/modules/`, where we can
add wrapper code to simplify the process for common test environment
setup. For example, `createValueListException` takes an array of items
and some metadata and automatically creates a new value list and an
exception that references that value list. `/modules/data/` contains
functions to generate documents of arbitrary size, and we can add more
functions to create various other types of documents.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
fixes [#191806](https://github.com/elastic/kibana/issues/191806)
## Summary
It was a weird problem that could only be reproduced by running the
host_view test after the node_details test. The cause was that the
synthtrace data was not fully cleaned in between tests
Closes https://github.com/elastic/kibana/issues/187249
Closes https://github.com/elastic/kibana/issues/190792
Closes https://github.com/elastic/kibana/issues/190793
This change adds a new Firehose quickstart flow and replaces the old one
in the onboarding recommendations.
The new card is only visible on Cloud deployments, but you can still
access the flow locally via `app/observabilityOnboarding/firehose` path
if needed.
### How to test
You going to need an AWS account. You can use just a personal one or
"Elastic Observability" account which you can access through Okta (type
"AWS" in Okta's search and you should see "AWS - Elastic
Observability").
In case you decide to use the shared "Elastic Observability" account,
make sure it does not already has
`Elastic-CloudwatchLogsAndMetricsToFirehose` CloudFormation stack left
from the previous tester. Feel free to delete it if it's there.
You also need to [install and setup AWS
CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
In case you use "Elastic Observability" account here is [the instruction
to get CLI
credentials.](https://github.com/elastic/observability-dev/blob/main/docs/how-we-work/aws-onboarding.md#programmatic-access-for-developers).
1. In AWS account, create a few entities that generate logs and put them
into a CloudWatch log group (see instructions below for a few services).
2. Generate some logs by accessing the entities that you've created and
make sure they appear in CloudWatch (mind that there is a ~1 minute
delay). **If you don't see anything in CloudWatch, there is no point in
proceeding further, make sure to fix your AWS setup before starting the
flow in Kibana.**
3. Go to the [serverless Kibana instance deployed from this
PR](https://issue-serverless-skhgw-pr187904-e0f30a.kb.eu-west-1.aws.qa.elastic.cloud)
4. Add Data → Collect and analyze logs → View AWS Collection → Firehose
quickstart
5. Open the Firehose flow and copy the command snippet
6. Run the command in your terminal. It should succeed and output the
new Stack ID.
7. Wait for the stack to finish creating. The quickstart flow screen in
Kibana has a command to check current status or you can monitor it
directly in AWS.
8. Generate some some logs by accessing the AWS services you've created.
9. Go back to the Kibana screen, after a minute or so incoming logs
should be detected and corresponding AWS service will be highlighted.
10. Expand one of the detected services and navigate the the suggested
dashboard, make sure you see some data there.
### Example AWS Services Configs
**Before creating any resources, make sure you're in the same region
(top right corner in AWS Console) you've used while configuring AWS
CLI.**
#### API Gateway
1. [Create an IAM
role](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html#set-up-access-logging-permissions)
to grant API Gateway permissions to write into a CloudWatch log groups
1. Copy the ARN of the created role
1. Open "CloudWatch" in AWS and select "Log groups" in the sidebar
1. Create a new log group with default parameters
1. Copy the ARN of the new group
1. Open **API Gateway** in AWS
1. Navigate to "Settings" in the sidebar
1. In the "Logging" section click "Edit" and paste the ARN of the IAM
role you created in step 1. Hit "Save changes"
1. Now go back to "APIs" in the sidebar and click "Create API"
1. In "REST API" click "Build"
1. Select "Example API" and click "Create API"
1. Click on "Deploy API"
1. For "Stage" dropdown select "New stage", give it any name and click
"Deploy"
1. You will now see "Invoke URL", you can use it later to access this
API and generate logs
1. Scroll to "Logs and tracing" section and click "Edit"
1. In the dropdown select "Full request and response logs"
1. Toggle "Custom access logging"
1. Paste the ARN of the CloudWatch log group you've created in step 4.
But make sure to not include ":*" symbols at the end.
1. In the log format input paste [this format from our
docs](https://www.elastic.co/docs/current/integrations/aws/apigateway#data-streams)
and click "Save"
```
{"requestId":"$context.requestId","ip":"$context.identity.sourceIp","caller":"$context.identity.caller","user":"$context.identity.user","requestTime":"$context.requestTime","httpMethod":"$context.httpMethod","resourcePath":"$context.resourcePath","status":"$context.status","protocol":"$context.protocol","responseLength":"$context.responseLength","apiId":"$context.apiId","domainName":"$context.domainName","stage":"$context.stage"}
```
1. Now when you access this API, you should see logs coming into the
CloudWatch group.
#### WAF
**This sets up WAF for an API Gateway, see above if you don't have one
already.**
1. Open WAF in AWS
3. Click "Web ACLs" in the sidebar
4. Click "Create web ACL"
5. Select the region where you've created your API Gateway and give ACL
any name
6. In the "Associated AWS resources" section click "Add AWS resources"
7. Select you API Gateway and click "Add"
8. Click "Next"
9. Create some basic rule, for example to block requests that have a
specific parameter in the URL
10. Click through the other configuration step leaving everything as is
and then finally click "Create web ACL"
11. Select the created ACL and click on the "Logging and metrics" tab
12. Click "Edit" in "Logging" section
13. Click "Create new" in the "Amazon CloudWatch Logs log group" section
14. Create a new log group. **The log group name should start with
`aws-waf-logs-`**.
15. Select the new group in the dropdown and click "Save"
16. Now you should have logs generated and saved into the log group when
you access your API gateway
#### VPC
1. [Create an IAM
role](https://docs.aws.amazon.com/vpc/latest/tgw/flow-logs-cwl.html#flow-logs-iam)
to write flow logs to CloudWatch log groups.
3. Create and EC2 instance and configure there some HTTP server like
Nginx. Using Docker would probably be the fastest way.
4. Create a CloudWatch log group with default parameters
5. Open "VPC" in AWS and select the VPC where you've created the EC2
instance.
6. Click the "Flow logs" tab and click "Create flow logs"
7. In "Maximum aggregation interval" select 1 minute to see logs faster
8. In "Destination log group" select the log group you've created in
step 3
9. In "IAM role" select the role you've created in step 1
10. Click "Create flow log"
11. Now when you access your EC2 instance, you should see logs in the
CloudWatch log group
**Relates to:** https://github.com/elastic/kibana/issues/186356
## Summary
This PR implements proper tags sorting when a custom tag's `x-displayName` property is set. It allows to display tags properly at the API reference documentation page where `x-displayName` instead of tag's name when it's presented.
## Summary
closes [#10176](https://github.com/elastic/security-team/issues/10176)
I've been looking into a few of our flaky tests and come up with a
couple of actions, I will comment on them individually.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
---------
Co-authored-by: Drew Tate <andrew.tate@elastic.co>
## Summary
This adds a publicBaseUrl to the Elasticsearch plugin config so users
can set a publicly accessible URL for Elasticsearch.
---------
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
## Summary
Closes - https://github.com/elastic/kibana/issues/190328
Delivered as part of this PR
- [x] Added a new Degraded Field Flyout with a basic List of data point
for the degraded Field
- [x] A new endpoint to display possible values. This endpoint will
query to get the latest values, maximum 4
- [x] URL supports Flyout state
- [x] API Tests for the new endpoint
- [x] E2E tests for the flyout
## Screenshot
<img width="1903" alt="image"
src="https://github.com/user-attachments/assets/9bc20d15-d52b-4d1e-827f-ab1444e27128">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is a follow up to the work that's been done to make it
relatively straight forward to backport puppeteer updates to the 7.17
branch in https://github.com/elastic/kibana/pull/188390.
This change ensures the archive path for chromium doesn't get installed
outside of the kibana directory, the previous expression resulted in an
archive path outside of the kibana directory which unfortunately could
result in a resolution of a path that kibana has no permissions to write
to, depending on where kibana is being executed from.
## How to test
- Pull this PR and delete the `.chromium` directory, for whatever
platform this PR is is been tested on we should get no errors about
installing the chromium and we should see the appropriate chromium
archive for the os platform available in the `.chromium` that would get
created.
<!--
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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
- [ ] [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] 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))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] 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))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### 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:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] 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)
-->
closes [3759](https://github.com/elastic/observability-dev/issues/3759)
## 📝 Summary
This PR creates a new scenario with different non ECS fields as below :
- log.level-> severity
- message -> msg
- service.name -> svc
- host.name -> hostname
- New field:
thisisaverylongfieldnamethatevendoesnotcontainanyspaceswhyitcouldpotentiallybreakouruiinseveralplaces
The above fields are applied with different variances as below :
- In DSNS data stream with @timestamp
- Outside of DSNS with @timestamp (e.g. cloud-logs-*, etc.)
- Outside of DSNS without @timestamp (replaced by “date”)
## 🎥 Demo
`node scripts/synthtrace simple_non_ecs_logs.ts`
https://github.com/user-attachments/assets/d86cadeb-fd2a-4c42-8dfe-0375ecfd9622
Resolves#191917
## Summary
Splits up the Agent config generated during auto-detect based onboarding
into multiple files.
This makes it easier for users to make changes following the initial
onboarding.
The backup feature has also been updated to include files inside
`inputs.d` directory.
## Example
Before this change the auto-detect script would write all settings to
`elastic-agent.yml` file.
After this change the script writes one separate config file for each
integrations that was detected, for example:
1. `elastic-agent.yml` - Contains global settings
2. `inputs.d/system.yml` - Contains inputs config for System integration
3. `inputs.d/docker.yml` - Contains inputs config for Docker integration
## Screenshot
<img width="1039" alt="Screenshot 2024-08-23 at 16 49 34"
src="https://github.com/user-attachments/assets/17bb7b01-d40e-4491-8bb5-20daf115938a">
- Closes https://github.com/elastic/kibana/issues/188178
## Summary
This PR makes sure to resolve profiles on:
- [x] Single document page (also added doc viewer extension support)
- [x] Surrounding documents page (also added cell renderes support)
### 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: Davis McPhee <davis.mcphee@elastic.co>
This PR improves logic for autocomplete suggestions to suggest new
function args based on previous values. For example:
https://github.com/user-attachments/assets/b597cd52-1ca9-479c-b7f0-67ed464b5659
It also adds a new snippet 'Add date histogram' for `stats ... by <>`
https://github.com/user-attachments/assets/994cbc5a-1760-446e-80e5-d9faeae2ba73
As part of this PR, test cases for eval functions were also updated to
cover all possible arguments while avoiding running the same test cases
repetitively. For example:
'st_contains( / )',
'st_contains(cartesianPointField, / )',
'st_contains(cartesianPointField, cartesianPointField, / )',
'st_contains(cartesianPointField, cartesianShapeField, / )',
'st_contains(cartesianShapeField, / )',
'st_contains(cartesianShapeField, cartesianPointField, / )',
'st_contains(cartesianShapeField, cartesianShapeField, / )',
'st_contains(geoPointField, / )',
'st_contains(geoPointField, geoPointField, / )',
'st_contains(geoPointField, geoShapeField, / )',
'st_contains(geoShapeField, / )',
'st_contains(geoShapeField, geoPointField, / )',
'st_contains(geoShapeField, geoShapeField, / )'
'mv_slice( / )',
'mv_slice(booleanField, / )',
'mv_slice(booleanField, integerField, / )',
'mv_slice(booleanField, integerField, integerField, / )',
'mv_slice(cartesianPointField, / )',
'mv_slice(cartesianPointField, integerField, / )',
'mv_slice(cartesianPointField, integerField, integerField, / )',
'mv_slice(cartesianShapeField, / )',
'mv_slice(cartesianShapeField, integerField, / )',
'mv_slice(cartesianShapeField, integerField, integerField, / )',
'mv_slice(dateField, / )',
'mv_slice(dateField, integerField, / )',
'mv_slice(dateField, integerField, integerField, / )',
'mv_slice(doubleField, / )',
'mv_slice(doubleField, integerField, / )',
'mv_slice(doubleField, integerField, integerField, / )',
'mv_slice(geoPointField, / )',
'mv_slice(geoPointField, integerField, / )',
'mv_slice(geoPointField, integerField, integerField, / )',
'mv_slice(geoShapeField, / )',
'mv_slice(geoShapeField, integerField, / )',
'mv_slice(geoShapeField, integerField, integerField, / )',
'mv_slice(integerField, / )',
'mv_slice(integerField, integerField, / )',
'mv_slice(integerField, integerField, integerField, / )',
'mv_slice(ipField, / )',
'mv_slice(ipField, integerField, / )',
'mv_slice(ipField, integerField, integerField, / )',
'mv_slice(keywordField, / )',
'mv_slice(keywordField, integerField, / )',
'mv_slice(keywordField, integerField, integerField, / )',
'mv_slice(longField, / )',
'mv_slice(longField, integerField, / )',
'mv_slice(longField, integerField, integerField, / )',
'mv_slice(textField, / )',
'mv_slice(textField, integerField, / )',
'mv_slice(textField, integerField, integerField, / )',
'mv_slice(versionField, / )',
'mv_slice(versionField, integerField, / )',
'mv_slice(versionField, integerField, integerField, / )'
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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
- [ ] [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] 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))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] 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))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### 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:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] 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)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
