# Backport
This will backport the following commits from `main` to `8.x`:
- [[Response Ops][Event Log] Updating event log mappings if data stream
and index template already exist
(#193205)](https://github.com/elastic/kibana/pull/193205)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Ying
Mao","email":"ying.mao@elastic.co"},"sourceCommit":{"committedDate":"2024-09-20T13:55:48Z","message":"[Response
Ops][Event Log] Updating event log mappings if data stream and index
template already exist (#193205)\n\nResolves
https://github.com/elastic/kibana/issues/192682\r\n\r\n##
Summary\r\n\r\nAs of 8.8, we started writing all event log documents to
the\r\n`.kibana-event-log-ds` index. Prior to this, we created a new
index\r\ntemplate and data stream for every version
(`.kibana-event-log-8.7` for\r\nexample) so any mapping updates that
were added for the version were\r\ncreated in the new index on
upgrade.\r\n\r\nWith the static index name and serverless, we need a way
to update\r\nmappings in existing indices. This PR uses the same
mechanism that we\r\nuse for the alerts index to update the index
template mappings and the\r\nmappings for the concrete backing indices
of a datastream.\r\n\r\n## To Verify\r\n\r\nRun ES and Kibana in `main`
to test the upgrade path for serverless \r\na. Check out `main`, run ES:
`yarn es snapshot --license trial --ssl
-E\r\npath.data=../test_el_upgrade` and Kibana `yarn start --ssl`\r\n b.
Create a rule and let it run to populate the event log index\r\nc.
Switch to this PR branch. Make a mapping update to the event
log\r\nindex:\r\n\r\n```\r\n---
a/x-pack/plugins/event_log/generated/mappings.json\r\n+++
b/x-pack/plugins/event_log/generated/mappings.json\r\n@@ -172,6 +172,9
@@\r\n },\r\n \"rule\": {\r\n \"properties\": {\r\n+ \"test\": {\r\n+
\"type\": \"keyword\"\r\n+ },\r\n \"author\": {\r\n \"ignore_above\":
1024,\r\n \"type\": \"keyword\",\r\n```\r\n d. Start ES and Kibana with
the same commands as above\r\ne. Verify that the `.kibana-event-log-ds`
index is created and has the\r\nupdated
mapping:\r\n-\r\nhttps://localhost:5601/app/management/data/index_management/templates/.kibana-event-log-template\r\n-\r\nhttps://localhost:5601/app/management/data/index_management/indices/index_details?indexName=.ds-.kibana-event-log-ds-2024.09.17-000001&filter=.kibana-&includeHiddenIndices=true&tab=mappings\r\n\r\nI
also verified the following:\r\n1. Run ES and Kibana in 8.7 to test the
upgrade path from 8.7 (when\r\nevent log indices were versioned) to
now\r\n2. Run ES and Kibana in 8.15 to test the upgrade path from the
previous\r\nrelease to now\r\n\r\nHowever, I had to create an 8.x branch
and cherry pick this commit\r\nbecause `main` is now on 9.0 and we can't
upgrade directly from older\r\n8.x version to
9.0!\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"e2798def07d50595806748dd64cccaa216c5e234","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","Feature:EventLog","backport:prev-minor","v8.16.0"],"title":"[Response
Ops][Event Log] Updating event log mappings if data stream and index
template already
exist","number":193205,"url":"https://github.com/elastic/kibana/pull/193205","mergeCommit":{"message":"[Response
Ops][Event Log] Updating event log mappings if data stream and index
template already exist (#193205)\n\nResolves
https://github.com/elastic/kibana/issues/192682\r\n\r\n##
Summary\r\n\r\nAs of 8.8, we started writing all event log documents to
the\r\n`.kibana-event-log-ds` index. Prior to this, we created a new
index\r\ntemplate and data stream for every version
(`.kibana-event-log-8.7` for\r\nexample) so any mapping updates that
were added for the version were\r\ncreated in the new index on
upgrade.\r\n\r\nWith the static index name and serverless, we need a way
to update\r\nmappings in existing indices. This PR uses the same
mechanism that we\r\nuse for the alerts index to update the index
template mappings and the\r\nmappings for the concrete backing indices
of a datastream.\r\n\r\n## To Verify\r\n\r\nRun ES and Kibana in `main`
to test the upgrade path for serverless \r\na. Check out `main`, run ES:
`yarn es snapshot --license trial --ssl
-E\r\npath.data=../test_el_upgrade` and Kibana `yarn start --ssl`\r\n b.
Create a rule and let it run to populate the event log index\r\nc.
Switch to this PR branch. Make a mapping update to the event
log\r\nindex:\r\n\r\n```\r\n---
a/x-pack/plugins/event_log/generated/mappings.json\r\n+++
b/x-pack/plugins/event_log/generated/mappings.json\r\n@@ -172,6 +172,9
@@\r\n },\r\n \"rule\": {\r\n \"properties\": {\r\n+ \"test\": {\r\n+
\"type\": \"keyword\"\r\n+ },\r\n \"author\": {\r\n \"ignore_above\":
1024,\r\n \"type\": \"keyword\",\r\n```\r\n d. Start ES and Kibana with
the same commands as above\r\ne. Verify that the `.kibana-event-log-ds`
index is created and has the\r\nupdated
mapping:\r\n-\r\nhttps://localhost:5601/app/management/data/index_management/templates/.kibana-event-log-template\r\n-\r\nhttps://localhost:5601/app/management/data/index_management/indices/index_details?indexName=.ds-.kibana-event-log-ds-2024.09.17-000001&filter=.kibana-&includeHiddenIndices=true&tab=mappings\r\n\r\nI
also verified the following:\r\n1. Run ES and Kibana in 8.7 to test the
upgrade path from 8.7 (when\r\nevent log indices were versioned) to
now\r\n2. Run ES and Kibana in 8.15 to test the upgrade path from the
previous\r\nrelease to now\r\n\r\nHowever, I had to create an 8.x branch
and cherry pick this commit\r\nbecause `main` is now on 9.0 and we can't
upgrade directly from older\r\n8.x version to
9.0!\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"e2798def07d50595806748dd64cccaa216c5e234"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/193205","number":193205,"mergeCommit":{"message":"[Response
Ops][Event Log] Updating event log mappings if data stream and index
template already exist (#193205)\n\nResolves
https://github.com/elastic/kibana/issues/192682\r\n\r\n##
Summary\r\n\r\nAs of 8.8, we started writing all event log documents to
the\r\n`.kibana-event-log-ds` index. Prior to this, we created a new
index\r\ntemplate and data stream for every version
(`.kibana-event-log-8.7` for\r\nexample) so any mapping updates that
were added for the version were\r\ncreated in the new index on
upgrade.\r\n\r\nWith the static index name and serverless, we need a way
to update\r\nmappings in existing indices. This PR uses the same
mechanism that we\r\nuse for the alerts index to update the index
template mappings and the\r\nmappings for the concrete backing indices
of a datastream.\r\n\r\n## To Verify\r\n\r\nRun ES and Kibana in `main`
to test the upgrade path for serverless \r\na. Check out `main`, run ES:
`yarn es snapshot --license trial --ssl
-E\r\npath.data=../test_el_upgrade` and Kibana `yarn start --ssl`\r\n b.
Create a rule and let it run to populate the event log index\r\nc.
Switch to this PR branch. Make a mapping update to the event
log\r\nindex:\r\n\r\n```\r\n---
a/x-pack/plugins/event_log/generated/mappings.json\r\n+++
b/x-pack/plugins/event_log/generated/mappings.json\r\n@@ -172,6 +172,9
@@\r\n },\r\n \"rule\": {\r\n \"properties\": {\r\n+ \"test\": {\r\n+
\"type\": \"keyword\"\r\n+ },\r\n \"author\": {\r\n \"ignore_above\":
1024,\r\n \"type\": \"keyword\",\r\n```\r\n d. Start ES and Kibana with
the same commands as above\r\ne. Verify that the `.kibana-event-log-ds`
index is created and has the\r\nupdated
mapping:\r\n-\r\nhttps://localhost:5601/app/management/data/index_management/templates/.kibana-event-log-template\r\n-\r\nhttps://localhost:5601/app/management/data/index_management/indices/index_details?indexName=.ds-.kibana-event-log-ds-2024.09.17-000001&filter=.kibana-&includeHiddenIndices=true&tab=mappings\r\n\r\nI
also verified the following:\r\n1. Run ES and Kibana in 8.7 to test the
upgrade path from 8.7 (when\r\nevent log indices were versioned) to
now\r\n2. Run ES and Kibana in 8.15 to test the upgrade path from the
previous\r\nrelease to now\r\n\r\nHowever, I had to create an 8.x branch
and cherry pick this commit\r\nbecause `main` is now on 9.0 and we can't
upgrade directly from older\r\n8.x version to
9.0!\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"e2798def07d50595806748dd64cccaa216c5e234"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Ying Mao <ying.mao@elastic.co>
Towards: https://github.com/elastic/response-ops-team/issues/209
This PR collects body-bytes from the requests made by the connectors to
the 3rd parties and saves them in the event-log.
There is a new metric collector: `ConnectorMetricsCollector`
Action TaskRunner, creates a new instance of it on each action execution
and passes it to the actionType.executor.
Then the actionType.executor passes it to the request function provided
by the actions plugin.
Request function passes the response (or the error) from axios to
`addRequestBodyBytes` method of the `ConnectorMetricsCollector`.
Since axios always returns `request.headers['Content-Length']` either in
success result or error, metric collector uses its value to get the
request body bytes.
In case there is no `Content-Length` header, `addRequestBodyBytes`
method fallbacks to the body object that we pass as the second param. So
It calculates the body bytes by using `Buffer.byteLength(body,
'utf8');`, which is also used by axios to populate
`request.headers['Content-Length']`
For the connectors or the subActions that we don't use the request
function or axios:
addRequestBodyBytes method is called just before making the request only
with the body param in order to force it to use the fallback.
Note: If there are more than one requests in an execution, the bytes are
summed.
## To verify:
Create a rule with a connector that you would like to test.
Let the rule run and check the event-log of your connector, request body
bytes should be saved in:
`kibana.action.execution.metrics.request_body_bytes`
Alternatively:
You can create a connector and run it on its test tab.
You can use the below query to check the event-log:
```
{
"query": {
"bool": {
"must": [
{ "match": { "event.provider":"actions"}},
{ "match": { "kibana.action.type_id":"{**your-action-type-id**}"}}
],
"filter": [
{ "term": { "event.action": "execute" }}
]
}
},
"size" : 100
}
```
## Summary
*(Yeah, the title is pretty bad I apologize, I couldn't find something
sexy. OTOH, "sexy" and "logging" are usually antonyms, like "sport car"
and "fiat panda", or "server language" and "javascript")*
### 1. Provide a more developer-friendly alternative to
`Logger.isLevelEnabled`.
**With `isLevelEnabled`**
```ts
if(logger.isLevelEnabled('info')) {
const message = someExpensiveMessageProbablyBasedOnJsonStringifyOrSomething();
logger.info(message);
}
```
**With this PR:**
```ts
logger.info(() => someExpensiveMessageProbablyBasedOnJsonStringifyOrSomething());
```
### 2. Adapt calls to `log.debug` (arguably) costly to use this syntax
Aka any call relying on `JSON.stringify` or function calls.
I used the new syntax for those, except when the tests were too
complicated to fix or when the code did not allow it (e.g. untyped let
variables infered from return from assignations don't play well with
closures)
Towards: https://github.com/elastic/kibana/issues/176585
This PR is a follow-on of https://github.com/elastic/kibana/pull/177244
and removes the task skipping logic from the Alerting plugin.
## To verify
Rules should run as expected and `prepare_to_run_duration_ms` should not
be in the event-log metrics.
Below query can be used to check metrics.
```
GET /.kibana-event-log-*/_search
{
"query": {
"bool" : {
"must" : [
{ "term" : { "event.action" : "execute" } },
{ "term" : { "event.provider" : "alerting" } }
]
}
},
"size": 100
}
```
## Summary
To support the creation of a backfill rule run task runner, I would like
to extract out certain parts of the alerting task runner for reuse,
specifically some items in the `runRule` function that initialize the
alerts client, call the rule type executors and call the alerts client
to process and persist alerts. While doing this, I also moved around
some other stuff in task runner. Descriptions below:
This PR refactors the following in task runner:
- in the `run()` function, consolidated everything that occurs before
calling `this.runRule()` into the `prepareToRun()` function - in this
commit
8c64963757
- in the `run()` function, consolidated everything that occurs after
calling `this.runRule()` into the `processRunResults()` function - in
this commit
856a78484e
- moved around some maintenance window handling code in this commit
205e3e3f87
- extract initialization of alerts client into helper function in this
commit
b057e0a617
- extract out most of `runRule()` function into `RuleTypeRunner` class.
this will be shared between the alerting task runner and the backfill
task runner - in this commit
b057e0a617
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/175919
Fix https://github.com/elastic/kibana/issues/176007
Bump `@elastic/elasticsearch` from `8.9.1-canary.1` to `8.12.2`.
## Notable changes
### `IngestPipeline._meta`
I was forced to introduce a lot of new `@ts-expect-error` because the
`_meta` property was introduced to `IngestPipeline` as mandatory instead
of optional (which feels like a type error to me)
**8.9**
```ts
export interface IngestPipeline {
description?: string
on_failure?: IngestProcessorContainer[]
processors?: IngestProcessorContainer[]
version?: VersionNumber
}
```
**8.12**
```ts
export interface IngestPipeline {
description?: string;
on_failure?: IngestProcessorContainer[];
processors?: IngestProcessorContainer[];
version?: VersionNumber;
_meta: Metadata; // <= not defined as optional...
}
```
I opened
https://github.com/elastic/elasticsearch-specification/issues/2434 in
the specification repo to address the problem, but it likely won't be
done for any `8.12.x` versions of the client.
Resolves https://github.com/elastic/kibana/issues/175941
## Summary
Adds a new field, `number_of_delayed_alerts`, to the event log for a
rule run.
It's a count for all the delayed alerts, I opted to go this route
instead of counting the number of times each alert was delayed. Pls let
me know if you would like to go another way or would like to add any
other metrics :)
### To verify
-Go to Dev Tools
- Create a rule with the alert delay
```
POST kbn:/api/alerting/rule
{
"params": {
"searchType": "esQuery",
"timeWindowSize": 5,
"timeWindowUnit": "m",
"threshold": [
-1
],
"thresholdComparator": ">",
"size": 100,
"esQuery": """{
"query":{
"match_all" : {}
}
}""",
"aggType": "count",
"groupBy": "all",
"termSize": 5,
"excludeHitsFromPreviousRun": false,
"sourceFields": [],
"index": [
".kibana-event-log*"
],
"timeField": "@timestamp"
},
"consumer": "stackAlerts",
"schedule": {
"interval": "1m"
},
"tags": [],
"name": "test",
"rule_type_id": ".es-query",
"actions": [
{
"group": "query matched",
"id": "${ACTION_ID}",
"params": {
"level": "info",
"message": """Elasticsearch query rule '{{rule.name}}' is active:
- Value: {{context.value}}
- Conditions Met: {{context.conditions}} over {{rule.params.timeWindowSize}}{{rule.params.timeWindowUnit}}
- Timestamp: {{context.date}}
- Link: {{context.link}}"""
},
"frequency": {
"notify_when": "onActionGroupChange",
"throttle": null,
"summary": false
}
}
],
"alert_delay": {
"active": 3
}
}
```
- Let the rule run and then run the following to look at the event log
- Verify that there is a new field `number_of_delayed_alerts` and that
the counts what you would would expect for a rule running with the
alert_delay
## Summary
Fixes#171409
This fixes weird behavior when attempting to filter more than 1000 rule
execution logs.
The execution log aggregator had two problems:
- It had a max bucket limit of 1000, while the KPI agg had a max bucket
limit of 10000, leading to inconsistent results
- For pagination, it reported the total number of logs by using a
cardinality aggregator, which wasn't subject to any bucket limit at all
The endpoint responds with a `total` (the cardinality) and an array of
`data` (a paginated slice of the aggregated logs). The way the data
table UI works is that it takes the `total` value, caps it at 1000, and
then generates that many blank rows to fill with whatever's in the
`data` array.
So as seen in the issue, we could easily run into a situation where:
1. User enters a filter query that last appeared more than 1000 logs ago
2. The cardinality agg accurately reports the number of logs that should
be fetched, and generates enough blank rows for these logs
3. The actual execution log agg hits the 1000 bucket limit, and returns
an empty `data` array
This PR fixes this by using a bucket sum aggregation to determine the
data table's `total` instead of a cardinality aggregation.
It also ups the bucket limit from 1000 to 10000, to match the bucket
limit from the summary KPI endpoint. This prevents a situation where:
1. User enters a filter query that last appeared in <1000 logs, but more
than 1000 logs ago
2. Summary KPI widget, with a bucket limit of 10000, accurately displays
a count of the <1000 logs this query matches
3. The data table is empty because the execution log bucket limit tops
out at 1000
### 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>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
Resolves: #158679
This PR removes the stack version from the EventLog index and datastream
names.
As we already use `kibana-event-log-*` as indexPattern,
`kibana-event-log-ds` is used as DataStream name to avoid creating a
breaking change.
**Changes:**
| Name | Old | New |
| -------- | ------- | ------- |
| Datastream | `kibana-event-log-<version>` | `kibana-event-log-ds` |
| IndexPattern | `kibana-event-log-*` | `kibana-event-log-*` (No change)
|
| IndexTemplate | `kibana-event-log-<version>-template` |
`kibana-event-log-template` |
Backing indices still have `<date>-000001` suffix but i think this is
expected.
## To verify:
Run Kibana and ES in main with `-E path.data=../local-es-data` to save
the data.
Create a rule and let it run and create some alerts.
See the alerts in the rule details page.
Stop ES and Kibana
Switch to this PR
Run Kibana and ES again with `-E path.data=../local-es-data`
See the all old and new alerts in the rule details page.
The old index created by the main branch should remain, therefore the
both old and the new indices (with and without version) should be
visible in the console.
Addresses https://github.com/elastic/kibana/issues/160411
## Summary
This PR adds functionality for filtering out advanced settings that are
not relevant for serverless.
For context, we need to build an Advanced settings page in serverless
which only contains a set of the existing settings. We will reuse the
section registry (https://github.com/elastic/kibana/pull/163502) from
the original Advanced settings plugin as well as its UI components which
will also be extracted into a separate package. The app will be
registered from inside the `serverless` plugin.
In order to only display the settings that are relevant for serverless,
we need to make some changes to the uiSettings service. The
implementation in this PR leverages the existing `readonly` uiSettings
param and adds the `setAllowlist()` method which is called by the
serverless plugin to set an allowlist of setting keys.
**Testing in serverless:**
1. Set `advanced_settings.enabled: true` to enable the Advanced settings
app in serverless:
5b216c6ea9/config/serverless.yml (L53)
2. Start Es with `yarn es serverless --ssl` and Kibana with `yarn
serverless-{mode} --ssl` in any serverless mode.
3. Navigate to `app/management/kibana/settings`
4. Verify that the app only displays the settings from
`packages/serverless/settings/common/index.ts` (these are the settings,
relevant for all projects in serverless) as well as the settings from
the corresponding project package
`packages/serverless/settings/{mode}_project/index.ts`.
5. Verify that the app is functioning correctly.
**Testing in self-managed:**
1. Start Es with `yarn es snapshot` and Kibana with `yarn start`.
2. Go to Stack Management > Advanced settings
3. Verify that all settings are displayed as usual.
4. Verify that the app is functioning correctly.
If your team is a code owner of any of the serverless project plugins,
please review the corresponding package
`packages/serverless/settings/{search/observanility/security}_project/index.ts`
where you've been added as an owner and test in the serverless solution
accordingly.
<!---
### 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
- [ ] 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Resolves https://github.com/elastic/kibana/issues/163891.
In this PR, I'm making the event log skip converting existing assets to
hidden if it is in a serverless deployment. Given assets that need to be
converted to hidden would exist prior to 8.0, there isn't such a case in
serverless and we do not have the necessary legacy APIs to retrieve
them.
## To verify on Serverless
- Ensure on serverless there are no more warnings as indicated in
https://github.com/elastic/kibana/issues/163891.
## To verify on non-Serverless
1. Create a 7.15 deployment (and persisting the ES data so you can
upgrade later)
2. Create an alerting rule (with short interval, say 10s)
3. Let the alerting rule run a few times so it generates event logs
4. Upgrade ES to 7.17 (it will fail otherwise)
5. Upgrade your deployment to this PR
6. Check the event log index template, indices and alias for 7.15 to
ensure they got converted to hidden
- `curl -XGET
http://elastic:changeme@localhost:9200/_template/.kibana-event-log-7.15.3-template`
- `curl -XGET
http://elastic:changeme@localhost:9200/.kibana-event-log-7.15.3-000001`
- `curl -XGET
http://elastic:changeme@localhost:9200/_alias/.kibana-event-log-7.15.3`
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/164731
## Summary
This removes the check for a legacy index template for the event log for
the current version it wants to create. This was presumably done this
way, to allow for the switch from legacy to component templates.
But it's not really needed, since each stack version creates new index
templates. So, removing the check should be fine.
### 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: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/162886
The default continues to be 90 days for data detetention of event log
documents, and the rollover is now controlled by DLM, as described in
[Data stream lifecycle][].
[Data stream lifecycle]:
https://www.elastic.co/guide/en/elasticsearch/reference/8.9/data-stream-lifecycle.html
## Release note
Fixes the event log data stream to use Data stream lifecycle instead of
Index Lifecycle Management. If you had previously customized the Kibana
event log ILM policy, you should now update the lifecycle of the event
log data stream itself.
https://github.com/elastic/kibana/issues/156061
## Summary
Fixes flaky test by adding ceil(). When it fails the time elapsed is
close to the `MOCK_RETRY_DELAY` of 20 (like 19.7), so rounding up helps
with the flakiness
Resolves https://github.com/elastic/kibana/issues/156443,
https://github.com/elastic/kibana/issues/156445
## Summary
- Updates `AlertsClient` with `create` API that allows rule executors to
report alerts with AAD payload, along with the values for `actionGroup`,
`context` and `state`. This proxies the `LegacyAlertsClient` to create
alerts via the alerts factory but also saves the reported payload
- When the alert doc is bulk written at the end of rule execution, the
AAD payload (if specified) is included in the alert document
- Deprecates the alert factory that is passed into the rule executors,
but this PR does not remove or replace usages of the alert factory
- Expose `AlertsClient` services to the rule executors. Note that this
PR does not migrate any rule type to use this service.
This PR does not opt any rule types into writing the AAD payload or
using the AlertsClient API but updates the AAD functional test to do so.
To test it out with the ES query rule type, use the following commit:
1b1e139f80
## Followup issues
- This PR does not add a recovery API to the FAAD AlertsClient so alerts
reported via the new alerts client currently do not have a way of
specifying recovered payload.
## To Verify
- Verify that rule registry rule types still work as expected
- Verify that non rule-registry rule types still work as expected
- Check out [this
commit](1b1e139f80)
which onboards the ES query rule type onto FAAD. Create an ES query rule
that alerts and then recovers and verify that the alert documents look
as expected. Alternatively, you can modify your own rule type to
register with FAAD and write alerts and verify that the alert documents
look as expected.
### 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
Resolves: #156061
Since all the failed CI results show actual elapsed time as `19` rather
than `20` (expected), the issue seems like an inaccurate time
calculation caused by `Date.now()` method.
Replacing `Date.now()` with the more precise `performance.now()` method
may solve the problem.
## Description
Fix https://github.com/elastic/kibana/issues/104081
This PR move some of the SO types from the `.kibana` index into the
following ones:
- `.kibana_alerting_cases`
- `.kibana_analytics`
- `.kibana_security_solution`
- `.kibana_ingest`
This split/reallocation will occur during the `8.8.0` Kibana upgrade
(*meaning: from any version older than `8.8.0` to any version greater or
equal to `8.8.0`*)
**This PR main changes are:**
- implement the changes required in the SO migration algorithm to
support this reallocation
- update the FTR tools (looking at you esArchiver) to support these new
indices
- update hardcoded references to `.kibana` and usage of the
`core.savedObjects.getKibanaIndex()` to use new APIs to target the
correct index/indices
- update FTR datasets, tests and utility accordingly
## To reviewers
**Overall estimated risk of regressions: low**
But, still, please take the time to review changes in your code. The
parts of the production code that were the most impacted are the
telemetry collectors, as most of them were performing direct requests
against the `.kibana` index, so we had to adapt them. Most other
contributor-owned changes are in FTR tests and datasets.
If you think a type is misplaced (either we missed some types that
should be moved to a specific index, or some types were moved and
shouldn't have been) please tell us, and we'll fix the reallocation
either in this PR or in a follow-up.
## .Kibana split
The following new indices are introduced by this PR, with the following
SO types being moved to it. (any SO type not listed here will be staying
in its current index)
Note: The complete **_type => index_** breakdown is available in [this
spreadsheet](https://docs.google.com/spreadsheets/d/1b_MG_E_aBksZ4Vkd9cVayij1oBpdhvH4XC8NVlChiio/edit#gid=145920788).
#### `.kibana_alerting_cases`
- action
- action_task_params
- alert
- api_key_pending_invalidation
- cases
- cases-comments
- cases-configure
- cases-connector-mappings
- cases-telemetry
- cases-user-actions
- connector_token
- rules-settings
- maintenance-window
#### `.kibana_security_solution`
- csp-rule-template
- endpoint:user-artifact
- endpoint:user-artifact-manifest
- exception-list
- exception-list-agnostic
- osquery-manager-usage-metric
- osquery-pack
- osquery-pack-asset
- osquery-saved-query
- security-rule
- security-solution-signals-migration
- siem-detection-engine-rule-actions
- siem-ui-timeline
- siem-ui-timeline-note
- siem-ui-timeline-pinned-event
#### `.kibana_analytics`
- canvas-element
- canvas-workpad-template
- canvas-workpad
- dashboard
- graph-workspace
- index-pattern
- kql-telemetry
- lens
- lens-ui-telemetry
- map
- search
- search-session
- search-telemetry
- visualization
#### `.kibana_ingest`
- epm-packages
- epm-packages-assets
- fleet-fleet-server-host
- fleet-message-signing-keys
- fleet-preconfiguration-deletion-record
- fleet-proxy
- ingest_manager_settings
- ingest-agent-policies
- ingest-download-sources
- ingest-outputs
- ingest-package-policies
## Tasks / PRs
### Sub-PRs
**Implementation**
- 🟣https://github.com/elastic/kibana/pull/154846
- 🟣https://github.com/elastic/kibana/pull/154892
- 🟣https://github.com/elastic/kibana/pull/154882
- 🟣https://github.com/elastic/kibana/pull/154884
- 🟣https://github.com/elastic/kibana/pull/155155
**Individual index split**
- 🟣https://github.com/elastic/kibana/pull/154897
- 🟣https://github.com/elastic/kibana/pull/155129
- 🟣https://github.com/elastic/kibana/pull/155140
- 🟣https://github.com/elastic/kibana/pull/155130
### Improvements / follow-ups
- 👷🏼 Extract logic into
[runV2Migration](https://github.com/elastic/kibana/pull/154151#discussion_r1158470566)
@gsoldevila
- Make `getCurrentIndexTypesMap` resillient to intermittent failures
https://github.com/elastic/kibana/pull/154151#discussion_r1169289717
- 🚧 Build a more structured
[MigratorSynchronizer](https://github.com/elastic/kibana/pull/154151#discussion_r1158469918)
- 🟣https://github.com/elastic/kibana/pull/155035
- 🟣https://github.com/elastic/kibana/pull/155116
- 🟣https://github.com/elastic/kibana/pull/155366
## Reallocation tweaks
Tweaks to the reallocation can be done after the initial merge, as long
as it's done before the public release of 8.8
- `url` should get back to `.kibana` (see
[comment](https://github.com/elastic/kibana/pull/154888#discussion_r1172317133))
## Release Note
For performance purposes, Kibana is now using more system indices to
store its internal data.
The following system indices will be created when upgrading to `8.8.0`:
- `.kibana_alerting_cases`
- `.kibana_analytics`
- `.kibana_security_solution`
- `.kibana_ingest`
---------
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
resolves https://github.com/elastic/kibana/issues/142874
The alerting framework now generates an alert UUID for every alert it
creates. The UUID will be reused for alerts which continue to be active
on subsequent runs, until the alert recovers. When the same alert (alert
instance id) becomes active again, a new UUID will be generated. These
UUIDs then identify a "span" of events for a single alert.
The rule registry plugin was already adding these UUIDs to it's own
alerts-as-data indices, and that code has now been changed to make use
of the new UUID the alerting framework generates.
- adds property in the rule task state
`alertInstances[alertInstanceId].meta.uuid`; this is where the alert
UUID is persisted across runs
- adds a new `Alert` method getUuid(): string` that can be used by rule
executors to obtain the UUID of the alert they just retrieved from the
factory; the rule registry uses this to get the UUID generated by the
alerting framework
- for the event log, adds the property `kibana.alert.uuid` to
`*-instance` event log events; this is the same field the rule registry
writes into the alerts-as-data indices
- various changes to tests to accommodate new UUID data / methods
- migrates the UUID previous stored with lifecycle alerts in the alert
state, via the rule registry *INTO* the new `meta.uuid` field in the
existing alert state.
Resolves https://github.com/elastic/kibana/issues/143984
## Summary
This PR persists an execution source field to the action event log
`execute` document which indicates the source of the action. Currently,
we have 3 sources of action execution:
* `http_request` - these are executions triggered from the `_execute`
route in the actions API. This is used by the test connector
functionality in the UI but could also be used directly via curl
command. We do not differentiate between the two.
* `notification` - these are executions triggered by the notifications
service. currently, this only occurs when a case is assigned to a user.
* `saved_object` - these are executions triggered by another saved
object, like the `alert` saved object. Cases also triggers action
execution in `x-pack/plugins/cases/server/client/cases/push.ts`. The
source will be saved as the type of the saved object that triggered the
action
After persisting the source, we also updated the connector exec log to
show the source in a new column (hidden by default).
<img width="1710" alt="Screenshot 2023-03-01 at 4 12 35 PM"
src="https://user-images.githubusercontent.com/13104637/222266192-2877ad2b-0309-408e-ad44-ec37ef597afb.png">
## To Verify
1. Create a connector and run it via the Test Connector tab
2. Create a rule that will fire an action using the connector and let it
run
3. Create a case an assign it to a user (other than yourself)
4. Go to the connector exec log view, add the "Source" column and see
that it is populated. You can also inspect the event log docs for
`provider: "actions"` and see that `kibana.action.execution.source` is
populated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/149824
## Summary
Added a filter to filter out logs that have an action set to
`execute-action` in the `alert_summary` route on the rules details
page.
Updated how we log summary alerts by removing the `alertId` and `group`
fields. I added a new summary field to `kibana.alerting` that includes
the counts for new, ongoing, and recovered alerts.
### 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 rule that has Alert Summary and let the rule run.
- Click on the rule to navigate to the rule details page and look at the
`Alerts` tab. Verify that the summary alert is not listed in the table.
**This is a screen shot of the table in the issue:**
We want to verify that the last row is no longer there.
<img width="1728" alt="Screen Shot 2023-02-01 at 3 02 21 PM"
src="https://user-images.githubusercontent.com/109488926/216150854-590e084d-3519-4785-8375-00a7455c319f.png">
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <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
Closes#144732
Adds functional tests for:
- Global logs api with `namespace`
- Global logs kpi with `namespace`
- Error log api with `namespace`
- Showing/hiding the logs switch based on space existence and user
permissions
Also:
- Fixes the query backend for `getActionErrorLogWithAuth` so that it
actually successfully filters down to just a single specified alert `id`
instead of returning all action error logs from everything. Writing a
test for this functionality revealed that it was broken.
### 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
* 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
* Add all_namespaces prop to global logs api
* Display space column and disable link on inactive spaces
* Add ability to link across spaces
* Fix allNamespace query on default space
* Fix KPI and link space switch to permissions
* Open alternate space rules in new tab
* Fix Jest 11
* Fix Jest 1
* Fix Jest 4 and 10
* Fix i18n
* Move space column visibility out of data grid
* Adding new field to the event log
* Fixing tests
* Fixing additional tests
* Fixing types
* Adding runtime fields
* Fixing tests and global event log
* Fixing jest tests
* Update x-pack/plugins/alerting/server/lib/get_execution_log_aggregation.ts
Co-authored-by: Ying Mao <ying.mao@elastic.co>
* Removing action executor
* Removing runtime fields
* Cleaning up some of the changes
* Using variable instead of string
* Adding back unknown
* Adding back status color
* Fixing failing test
* Adding new test
Co-authored-by: Ying Mao <ying.mao@elastic.co>
* Add initial logs tab, permissions checks still broken
* Filter global event logs by permissions
* Finalize table in logs list tab
* Create new function without wildcard id
* Fix error flyout
* Fix rule_id test
* Add test for getGlobalExecutionLogWithAuth
* Fix typechecks
* Fix jest types
* Fix types and tests
* Fix aggregation test
* Fix aggregation test
* Fix mocks in jest test
* Fix localstorage test
* Add rule.id to OutcomeAndMessage agg
* Move authfilter to query, move ruleid agg to outcomeandmessage
* Memoize rule name onclick
* Add new route for global execution logs
* Remove * from getruleexecutionlog route
* Fix types and jest
* Fix types
* Fix jest
* Fix nits
* Add cluster client adapter unti tests
* Add unit test for event log client
* Update get execution log aggregation test
* Remove sort options and hide option from Rule column
* Add functional test for global execution logs
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
**Epics:** https://github.com/elastic/kibana/issues/124947, https://github.com/elastic/kibana/issues/118324
**Fixes:** https://github.com/elastic/kibana/issues/131352
## Summary
Console logs written by rule executors can now be "routed" to the Event Log in addition to the console. A new table UI for viewing plain rule execution logs allows the user to look at all status changes, errors, warnings, info and debug messages on the Rule Details page.
<img width="1502" alt="Screenshot 2022-07-20 at 15 31 54" src="https://user-images.githubusercontent.com/7359339/179995075-24440224-daf9-4e73-bc62-b6ce211052b3.png">
**This feature is hidden under a feature flag and disabled by default** -- it might not be production-ready yet. We will need to work on product and UX/UI design in the subsequent development cycles to make it ready for release. Until then, we can start using it in development: it should make it easier to troubleshoot issues with rule execution. Add this flag to your Kibana config to enable this feature:
```yaml
xpack.securitySolution.enableExperimental: ['extendedRuleExecutionLoggingEnabled']
```
If the flag is enabled:
- Rules will start writing console logs to Event Log as events of a new type `message`, in addition to the existing `status-change` and `execution-metrics` events.
- Rule Details page will show a new tab called `Execution events`. This tab will contain a table with plain execution logs.
- In Stack Management, you will find two new Kibana Advanced Settings for controlling this extended logging.
As for the new Kibana Advanced Settings, by default:
- Extended logging is enabled.
- The minimum console log level to be written to Event Log is `error`. This only affects the new `message` events.
<img width="774" alt="Screenshot 2022-07-20 at 15 41 29" src="https://user-images.githubusercontent.com/7359339/179997070-d86dfc6b-3862-49ff-879d-ecc30bc128d7.png">
## Implementation details
**Important change**: refactored the folder structure as our first step to **domain-driven architecture** and **splitting the Detection Engine into subdomains**.
- Extracted most of the code related to Rule Execution Log and Rule Monitoring in general into a subdomain called `rule_monitoring`. This subdomain now lives in three folders:
- `security_solution/common/detection_engine/rule_monitoring`
- `security_solution/public/detection_engine/rule_monitoring`
- `security_solution/server/lib/detection_engine/rule_monitoring`
- Tried to create a developer-friendly and clear folder structure within the subdomain.
Other changes:
- Changed all rule executors to write console logs via an instance of `IRuleExecutionLogForExecutors` instead of the console `Logger`.
- `IRuleExecutionLogForExecutors` is passed to rule executors and downstream functions they call.
- `Logger` is not passed anymore.
- `buildRuleMessage` and `buildRuleMessageFactory` are deleted.
- Added support for writing console logs to Event Log.
- Added a new rule execution event type `message` for writing console logs to Event Log.
- Every rule execution event now has a `log.level` and `event.severity`.
- Improved the format of console logs written by rules.
- Created a child logger for console logs of rule executors: `plugins.securitySolution.ruleExecution`.
- Added rule static “signature” ID (`rule.rule_id`) as a correlation id to the logs.
- Cleaned up the formatting of console logs.
- Fixed `ExtMeta` to use interfaces instead of type intersection due to a found [bug](https://github.com/microsoft/TypeScript/issues/47935) in TypeScript that affected this type.
- Made changes in the domain model.
- Renamed the `AggregateRuleExecutionEvent` into the `RuleExecutionResult`.
- The new plain event is called `RuleExecutionEvent`.
- Finalized the API endpoint for fetching plain execution logs.
- Built a Rule Execution Events Table UI for showing and filtering plain execution logs.
- Did some refactoring to extract reusable components/hooks to make development of tables easier in the future.
## Execution events table UI
For context, this is how the existing `Execution logs` table looks like when the flag is off (notice the renaming to `Execution results`:
<img width="1506" alt="Screenshot 2022-07-20 at 15 29 04" src="https://user-images.githubusercontent.com/7359339/179994450-45121035-ebb0-4e6f-83c0-9cbbbbd0b598.png">
This is the new `Execution events` table when the flag is on:
<img width="1502" alt="Screenshot 2022-07-20 at 15 31 54" src="https://user-images.githubusercontent.com/7359339/179995075-24440224-daf9-4e73-bc62-b6ce211052b3.png">
Showing only trace and debug events:
<img width="1505" alt="Screenshot 2022-07-20 at 15 33 48" src="https://user-images.githubusercontent.com/7359339/179995484-d97ff7e3-2756-42db-802f-41f11bd37507.png">
Showing only status changes:
<img width="1507" alt="Screenshot 2022-07-20 at 15 35 04" src="https://user-images.githubusercontent.com/7359339/179995804-ca6808b7-3b47-411b-a74e-d141b3fd74e0.png">
Showing only warning and error `message`s:
<img width="1508" alt="Screenshot 2022-07-20 at 15 37 11" src="https://user-images.githubusercontent.com/7359339/179996258-c154b95d-642d-45a6-b19a-7185cd71f295.png">
Expanded rows showing details of the corresponding events:
<img width="1452" alt="Screenshot 2022-07-20 at 15 39 16" src="https://user-images.githubusercontent.com/7359339/179996771-3954ceea-24e9-4760-9103-2daf6cb7b528.png">
<img width="1449" alt="Screenshot 2022-07-20 at 15 39 56" src="https://user-images.githubusercontent.com/7359339/179996805-c866674d-09a1-42ec-b954-58c6829ef19b.png">
## Console logs
Example:
```
[2022-02-23T17:05:09.901+03:00][DEBUG][plugins.securitySolution.ruleExecution] [+] Starting Signal Rule execution [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:09.907+03:00][DEBUG][plugins.securitySolution.ruleExecution] interval: 5m [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:09.908+03:00][INFO ][plugins.securitySolution.ruleExecution] Changing rule status to "running" [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:10.595+03:00][WARN ][plugins.securitySolution.ruleExecution] This rule is attempting to query data from Elasticsearch indices listed in the "Index pattern" section of the rule definition, however no index matching: ["logs-endpoint.alerts-*"] was found. This warning will continue to appear until a matching index is created or this rule is de-activated. If you have recently enrolled agents enabled with Endpoint Security through Fleet, this warning should stop once an alert is sent from an agent. [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:10.595+03:00][WARN ][plugins.securitySolution.ruleExecution] Changing rule status to "partial failure" [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.630+03:00][DEBUG][plugins.securitySolution.ruleExecution] sortIds: undefined [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.634+03:00][DEBUG][plugins.securitySolution.ruleExecution] totalHits: 0 [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.634+03:00][DEBUG][plugins.securitySolution.ruleExecution] searchResult.hit.hits.length: 0 [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.635+03:00][DEBUG][plugins.securitySolution.ruleExecution] totalHits was 0, exiting early [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.636+03:00][DEBUG][plugins.securitySolution.ruleExecution] [+] completed bulk index of 0 [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.636+03:00][DEBUG][plugins.securitySolution.ruleExecution] [+] Signal Rule execution completed. [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.638+03:00][DEBUG][plugins.securitySolution.ruleExecution] [+] Finished indexing 0 signals into .alerts-security.alerts [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
[2022-02-23T17:05:11.639+03:00][DEBUG][plugins.securitySolution.ruleExecution] [+] Finished indexing 0 signals searched between date ranges [
{
"to": "2022-02-23T14:05:09.775Z",
"from": "2022-02-23T13:55:09.775Z",
"maxSignals": 10000
}
] [siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]
```
Note that:
- The logger name is now `plugins.securitySolution.ruleExecution`, which allows to turn on _only_ rule execution logs in the config (could be useful when debugging).
- Every log message has a suffix with correlation ids: `[siem.queryRule][Endpoint Security][rule id 825b2fab-8b3e-11ec-a4a0-cf820453283c][rule uuid 9a1a2dae-0b5f-4c3d-8305-a268d404c306][exec id ebb7f713-b216-4c90-a456-6c1a6815a065][space default]`
### 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)
- [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials
- [x] `x-pack/plugins/security_solution/server/lib/detection_engine/rule_monitoring/logic/rule_execution_log/README.md`
- [x] Various JSDoc comments
- [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
- [ ] 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))
- [x] 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)
### 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)
