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
* [ResponseOps] Add kibana.alert.time_range field to Alert-As-Data mappings and populate it
* Fixing snapshots to match new reality
* Removing the lte (end of range) for active alerts.
* Fixing expected resutls for mapping test
* fixing tests
* updating readme
* Fixing field name in README
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
* [packages] add kibana.jsonc files
* auto-migrate to kibana.jsonc
* support interactive pkg id selection too
* remove old codeowners entry
* skip codeowners generation when .github/CODEOWNERS doesn't exist
* fall back to format validation if user is offline
* update question style
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* refact(NA): apply root_input_dir=src to each already created pkg
* refact(NA): update package generator
* fix(NA): correctly use rootDir
* fix(NA): use root input dir on latest introduced pkgs for jsts_transpiler macro
* chore(NA): merge with main
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [type-summarizer] reimplement for broader support
* Enable sourceMaps in all packages
* include naming collision in summarizePackage test
* fix readmes
* remove unnecessary transient dependency
* remove code that was commented out
* remove outdated todo comment
* ensure errors triggered by untyped-exports are ligible
* remove unused import
* break out snippet generation from AstIndexer
* refactor several massive files into smaller pieces and add more inline docs
* fix typos
* update jest snapshots
* add sections to readme that points people to the useful parts of the source code along with a high-level overview of how the type-summarizer works
* remove --dump flag, it doesn't work
* use decName instead of calling names.get a second time
* include `export` as invalid name
* Replace schemas derived from FieldMaps with versioned alert schema
* Import fixes and comment
* Another import fix
* Separate read and write schemas
* Separate read and write schemas for common alert fields
* fix import
* Update ALERT_RULE_PARAMETERS type
* Fix getField type
* Fix more types
* Remove unneeded index signature from PersistenceAlertServiceResult
* Fix types and tests
* Update comment describing new schema process
* Update Ancestor800 type
* Add modified PR description as initial README
* Remove duplication in CommonAlertFields definition
* Add explicit undefined value for rule in mock
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Add exceptions to threshold timeline
* Tests and error handling
* Fix unit tests
* Add alias for exceptions filter
* Fix tests
* Type fixes
Co-authored-by: Marshall Main <marshall.main@elastic.co>
* chore(NA): splits types from code on @kbn/rule-data-utils
* chore(NA): remove old style imports for this pkg
* chore(NA): eslint fix
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Remove kibana.alert.rule.risk_score and severity
* Fix tests related to risk_score and severity
* Make translation a template
* Can't use expression in template literal
* Remove commented line added by bad merge
* Fix linting
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* add kibana.alert.rule.parameters as a flattened type
* temp
* rule_data_formatter
* fix bug in search strategy with flattend field type where prefix was wrong (kibana.alert.rule.parameters was ignored)
* fix inventory rule data formatters
* remove console log
* hack that prepends kibana.alerts.rule.parameters in the nested subfields
* import ALERT_RULE_PARAMETERS from kbn rule data utils
* remove console log
* format custom metric link
* remove ALERT_PARAMS from technical field names
* fix bug in timelines plugin to use dotField instead of prependField & fix failing tests
* remove console log and unused variable
* delete kibana.alert.rule.params from the mapping
* flatten kibana.alert.rule.parameters and add some unit tests
* fix rule_data_formatter
* handle scenario of having multiple items in an array (multiple conditions setup in the rule)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Add flattend parameters object and populate it in Security Solution
* Fix severity, risk_score, bugs, tests
* Add ALERT_RULE_PARAMETERS to package
* Skip tightly coupled test
* fix more tests
* Remove unused import
* Fix threat matching API test
* Continue overriding kibana.alert.rule.risk_score and severity for now
* Add ignore_above to ALERT_RULE_PARAMETERS
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Switches RuleDetails to query alerts by ruleId instead of SO id
* Increases integrity of test outputs
* Cleans up duplicate RuleRegistry functions
* Removes support for rule.id for alerts filter and updates exceptions to use new filter
* [kbn/rule-data-utils] add submodules and require public use them
* fix lint errors
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Initial commit
* Properly handle signal history
* Fix#95258 - cardinality sort bug
* Init threshold rule
* Create working threshold rule
* Fix threshold signal generation
* Fix tests
* Update mappings
* ALERT_TYPE_ID => RULE_TYPE_ID
* Add tests
* Fix types
* Adds RAC rule type migration
* Fix threshold tests (remove outputIndex)
* Add threshold rule type to ruleTypeMappings
* Add kbn-securitysolution-rules package for sharing with alerting framework
* Fix type errors
* Fix find_rules tests
* First round of test fixes
* Fix issues from merge conflicts
* Use ruleDataClient getReader() for reading
* Fixes to 'generating_signals' tests
* Remove more refs to legacy schema
* Linting
* Quick type fix
* Bug fixes
* Add saved query rule type
* Linting
* Fix types
* Signal generation tests
* Test updates
* Update some more refs
* build_alert tests
* Cleanup
* Ref updates
* Revert "Ref updates"
This reverts commit 4d1473d6b0.
* Update status field
* Test fixes
* Another test
* Got a little too aggressive with search/replace
* let's see where we're at
* Fix
* Test fixes
* cleanup
* Fix cases API integration test config, flaky DE tests
* Move flattenWithPrefix to package / skip signal migration tests
* Fix unit tests
* Use new schema for bulk rule creation
* event: { kind } => event.kind
* Fix signal migration API tests
* Fix ml integration test
* Fix threat match integration tests
* Fix ML rule type tests and add correct producer to all rule types
* Update threat match API integration test
* Remove dupe properties
* Type fix
* Fix ML producer in functional test
* Fix generating_signals tests
* Remove usage of RuleDataClient-based execution log client
* Don't check output index version if rule registry enabled
* Fix bulk duplicate rule
* Fix duplicate rule test
* Fix readPrivileges and timestamp check logic
* Fixes for eql and exceptions tests... disable open_close_signals
* Type fixes / keyword test fixes
* Additional test fixes
* Unit test fixes + signal -> kibana.alert
* Test fixes for exceptions
* Fix read_resolve_rules test
* Various test fixes with marshallmain
* Sort search results
* Fix create_rules tests
* Disable writer cache for integration tests
* Disable writer cache for cases integration tests
* Fix types in rule_data_plugin_service
* Fix ordering in exceptions tests
* Remove rule_registry.enabled flag
* Fix signals migration tests
* Don't check signals index before creation
* Fix cypress config
* Fix type error
* create_migrations tests
* Skip flaky test
* Helpful comment
* Fixes from merge conflicts
* Pretend that signals index exists
* Fix type errors
* Skip flaky tests
* Fix threat matching test
* Clean up
* Reverting default ruleRegistry experimental flag (breaks unit tests)
* Reenable rule registry experimental feature by default
* Execute DE rule migration in 8.0
Co-authored-by: Marshall Main <marshall.main@elastic.co>
* bump to a pre-8.0 version
* export KibanaClient from /lib sub-folder
* workaround the problem of the absence of estypes
* update es client usage in pacakges
* export estypes from another path
* import errors from root
* import errors from root 2
* update transport import
* update import path for /api/types
* update import path for /api/types
* import errors from top export
* use TransportResult instead if ApiResponse
* fix errors in client_config
* fix src/core/server/saved_objects/migrationsv2/actions/integration_tests/actions.test.ts
* use KibanaClient in mock. we dont export the original Client
* fix client mocks
* fix errors on SO
* fix remaining core errors
* update estype import path
* fix errors in data plugin
* fix data_views
* fix es_ui_shared
* fix errors in interactive_setup
* fix errors in ./test folder
* add @elastic/transport to the runtime deps
* fix errors in packages
* fix erros in src/core
* fix errors in test/
* fix an error in actions plugin
* woraround and fix errors in APM plugin
* fix errors in canvas
* fix errors in event_log
* fix errors in fleet
* fix errors in ILM
* fix errors in infra
* fix errors in ingest_pipeline
* fix errors in lens
* fix errors in license_management
* fix errors in licensing
* fix errors in logstash
* fix errors in ml
* fix errors in monitoring
* fix errors in observability
* fix errors in rule_registry
* fix errors in reporting
* fix errors in rule_registry
* fix errors in security
* fix errors in security_solution
* fix errors in snapshot_restore
* fix errors in transform
* fix errors in UA
* fix errors in uptime
* fix errors in x-pack/test
* fix eslint errors
* fix new errors
* use default HTTP Connection. Undici does not support agent config options keepAlive and maxSockets
* create does not accept require_alias option
* update deps
* use transport types exported from ES client package
* fix ErrorCause | string errors
* do not use enum
* fix errors in data plugin
* update x-pack code
* fix transport
* fix apm search request
* do not crash on reporting
* fix kbn-test build
* mute reporting error to start
* fix ftr build
* another attempt
* update import path
* address or mute new errors
* REMOVE me. pin transport version temporarily.
* remove deep imports from transport package
* fix jest crash
* fix product check tests
* remove unnecessary ts-expect-error
* fix a few failed unit tests
* bump to canary 24
* remove unnecessary ts-expect-error
* remove dependency on transport
* fix types in tests
* mute errors in xpack tests
* product check doesn;t spam in logs anymore
* filterPath --> filter_path
* ignoreUnavailable --> ignore_unavailable
* ignoreUnavailable --> ignore_unavailable
* trackScores --> track_scores
* trackTotalHits --> track_total_hits
* fix es-arcives
* fix data plugin crashes
* fix watcher test utils
* rollback unnecessary changes
* fix another problem in es-archiver
* fix scroll. for whatever reason scroll fails when request scroll_id in body
* add meta: true in kbn-securitysolution-es-utils
* bump client to canary 25
* fix errors in accordance with the es client spec
* update securityscolution-es-utils
* unify scroll api in reporting and fix tests
* fix unit tests in watcher
* refactor APM to abort request with AbortController API
* fix missing es client calls in tests
* fix missing meta in detection engine FTR tests
* fix another bunch of errors in js tests
* fix wrong coercion
* remove test-grep pattern
* fix apm unit test
* rename terminateAfter to terminate_after in infra plugin
* rename terminateAfter to terminate_after in uptime plugin
* rename terminateAfter to terminate_after in apm plugin
* fix security roles FTR tests
* fix reference
* fix post_privilidges test
* fix post_privilidges
* bump client to 26
* add meta for index_management test helpers
* remove ts-expect-error caused by bad type in reason
* bump client to 27
* REMOVE me. workaround until fixed in the es client
* fix incorrect type casting
* swtich from camelCase params
* use `HttpConnection` for FTR-related clients
* bump client to 29
* Revert "REMOVE me. workaround until fixed in the es client"
This reverts commit c038850c09.
* fix new util
* revert repository changes
* do not crash if cannot store event_loop data
* fix new estypes imports
* fix more types
* fix security test types and add ts-ignore for custom ES client
* fix more estypes imports
* yet more ts violations
* line by line fixing is hard
* adapt `evaluateAlert` from infra as it's also used from FTR tests
* use convertToKibanaClient in FTR test instead of meta:true in plugin code
* migrate from deprecated API in fleet
* fix intergration tests
* fix fleet tests
* fix another fleet test
* fix more tests
* let's call it a day
* Removes custom header check on 404 responses, includes es client ProductNotSupportedError in EsUnavailableError conditional (#116029)
* Removes custom header check on 404 responses, includes es client ProductNotSupportedError in EsUnavailableError conditional
* Updates proxy response integration test
* disable APM until compatible with client v8
* skip async_search FTR test
* use kbnClient in integration tests
* bump version to 29
* bump to 30
* have configureClient return a KibanaClient instead of Client, remove resolved violations.
* bump to 31
* bump to 31
* Revert "bump to 31"
This reverts commit 5ac713e640.
* trigger stop to unusubscribe
* update generated docs
* remove obsolete test
* put "as" back
* cleanup
* skip test
* remove new type errors in apm package
* remove ErrorCause casting
* update a comment
* bump version to 32
* remove unnecessary ts-expect-error in apm code
* update comments
* update to client v33
* remove outdated type definition
* bump to 34 without params mutation
* unskip the test that should not fail anymore
* remove unnecessary ts-expect-error comments
* update to v35. body can be string
* move `sort` to body and use body friendly syntax
* fix a failing test. maps register the same SO that has been already registered by home
Co-authored-by: pgayvallet <pierre.gayvallet@gmail.com>
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
