* [Alerts][Docs] Extended README.md and the user docs with the licensing information.
* Apply suggestions from code review
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
* fixed due to comments
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
* Cleanup alerts README.md to remove duplication from docs
* fixed due to comments
* fixed due to comments
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/49392
Adds the top-level mustache variable `kibanaBaseUrl` for action parameter
mustache templates. The value comes from Kibana config, which, if not set
will result in this variable having the value `undefined` which will be rendered
as an empty string.
* Add support for custom alert ids
* UUID v4 also supported
* Change ESO custom id error message
* Update api integration test
* Use errors.createBadRequestError
resolves https://github.com/elastic/kibana/issues/88367
Prior to this PR, the KQL node_builder code was using recursion to generate
"and" & "or" expressions. Eg, `and(foo1=bar1, foo2=bar2, foo3=bar3)` would
be generated as if was specified as `and(foo1=bar1, and(foo2=bar2, foo3=bar3))`.
Calls to the builder with long lists of expressions would generate nested JSON
as deep as the lists are long. This is problematic, as Elasticsearch is
changing the default limit on nested bools to 20 levels, and alerting already
generates nested bools greater than that limit.
See: https://github.com/elastic/elasticsearch/issues/55303
This PR changes the generated shape of above, so that all the nodes are at the
same level, instead of the previous "recursive" treatment.
* Adding es query alert type to server with commented out executor
* Adding skeleton es query alert to client with JSON editor. Pulled out index popoover into component for reuse between index threshold and es query alert types
* Implementing alert executor that performs query and matches condition against doc count
* Added tests for server side alert type
* Updated alert executor to de-duplicate matches and create instance for every document if threshold is not defined
* Moving more index popover code out of index threshold and es query expression components
* Ability to remove threshold condition from es query alert
* Validation tests
* Adding ability to test out query. Need to add error handling and it looks ugly
* Fixing bug with creating alert with threshold and i18n
* wip
* Fixing tests
* Simplifying executor logic to only handle threshold and store hits in action context
* Adding functional test for es query alert
* Types
* Adding functional test for query testing
* Fixing unit test
* Adding link to ES docs. Cleaning up logger statements
* Adding docs
* Updating docs based on feedback
* PR fixes
* Using ES client typings
* Fixing unit test
* Fixing copy based on comments
* Fixing copy based on comments
* Fixing bug in index select popover
* Fixing unit tests
* Making track_total_hits configurable
* Fixing functional test
* PR fixes
* Added unit test
* Removing unused import
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [Alerts][Actions][Telemetry] Fix mappings for Kibana actions and alert types telemetry.
* fixed count_active_by_type for actions
* fixed tests
* Fixed due to comments.
* Fixed due to comments.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
The alerts plugin was importing `JsonObject` from the infra plugin. The infra plugin imported `JsonObject`, `JsonValue`, and `JsonArray` from kibanaUtils and then re-exported them.
Remove the re-export from the infra plugin and instead always import these types from kibanaUtils.
* Added alerting API to get all active instances
* modofied event log findEventsBySavedObject to support bulk ids, renamed to findEventsBySavedObjectIds
* fixed faling typechecks
* fixed crash on zpd/api/event_log/alert/84c00970-5130-11eb-9fa7/_find for non existing id
* fixed faling typechecks
* fixed faling typechecks
* fixed due to comments
* fixed due to comments
* fixed failing test
* fixed due to comments
* Monitor ids
* import fix
* solve circular dep
* eslint
* mock circular dep
* max retries test
* mock circular dep
* test
* jest <(-:C
* jestttttt
* [data.search] Move search method inside session service and add tests
* merge
* Move background session service to data_enhanced plugin
* Better logs
Save IDs only in monitoring loop
* Fix types
* Space aware session service
* ts
* initial
* initial
* Fix session service saving
* merge fix
* stable stringify
* INMEM_MAX_SESSIONS
* INMEM_MAX_SESSIONS
* use the status API
* Move task scheduling behind a feature flag
* Update x-pack/plugins/data_enhanced/server/search/session/session_service.ts
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
* Add unit tests
* Update x-pack/plugins/data_enhanced/server/search/session/session_service.ts
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
* Use setTimeout to schedule monitoring steps
* Update request_utils.ts
* settimeout
* tiny cleanup
* Core review + use client.asyncSearch.status
* update ts
* fix unit test
* code review fixes
* Save individual search errors on SO
* Don't re-fetch completed or errored searches
* Rename Background Sessions to Search Sessions (with a send to background action)
* doc
* doc
* jest fun
* rename rfc
* translations
* merge fix
* merge fix
* code review
* update so name in features
* Move deleteTaskIfItExists to task manager
* task_manager to ts project
* Move deleteTaskIfItExists to public contract
* mock
* use task store
* ts
* code review
* code review + jest
* Alerting code review
Co-authored-by: Lukas Olson <olson.lukas@gmail.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
Co-authored-by: restrry <restrry@gmail.com>
* Replaced single invalidateApiKey request with the bulk
* fixed failing test
* Extended invalidate method to support multiple invalidation. Updated fleets plugin usage of this API.
* fixed due to comments
This PR tightens the typing on the Alerting framework's `AlertType` and its deeper typing around `AlertServices ` and `AlertExecutorOptions`.
This ensures the following:
1. It's now impossible<sup>✴</sup> to schedule actions on any ActionGroup other than the groups specified on the AlertType (including the Recovery group)
2. It's now impossible<sup>✴</sup> to schedule actions with incorrect `InstanceState` or `InstanceContext`
✴ Unless they bypass the Typescript typing, which is an explicit choice to bypass type safety
This PR encourages type safe usage of the Alerting framework by replacing the current default Params/State/InstanceState/InstanceContext types (which are `AlertTypeParams`/`AlertTypeState`/etc.) with `never`.
This means that code can continue to omit the specific types for these fields, as long as they aren't referenced.
Once an alert developer wishes to actually reference the parameters (or state/context), then they have to specify the type.
This PR also changed the typing of the `AlertTypeParams` and `AlertTypeState` from `Record<string, any>` to `Record<string, unknown>`, to ensure that where these catch-all types are used they will at least enforce `unknown` rather than `any`.
This change broke some usage in both @elastic/kibana-alerting-services plugins, but also other plugins in the Stack/Solutions. I tried to fix these where I could, but some of these require new types and refactoring in other teams' code, which I decided is best done by the team who own and maintain that code - I've added explicit `TODO` comments in all of these places, describing the required fix.
This PR also introduced a Generics based typing for the `Alert` type so that the `params` field can be typed as something other than `AlertTypeParams`.
* Initial work
* Change messaging from copy
* Fix jest tests for email connector
* Fix jest tests for alerts plugin
* Update copy
* Use server.publicBaseUrl
* Fix jest tests
* Update tests
* Cleanup jest test
* Code cleanup
* Improve email parameter names for kibana footer url
* Cleanup
* Add test for kibana footer link
* Fix type check
* Fix jest test
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [Alerts][License] Define minimum license required for each alert type (#84997)
* Define minimum license required for each alert type
* fixed typechecks
* fixed tests
* fixed tests
* fixed due to comments
* fixed due to comments
* removed file
* removed casting to LicenseType
* [Alerts][License] Add license checks to alerts HTTP APIs and execution (#85223)
* [Alerts][License] Add license checks to alerts HTTP APIs and execution
* fixed typechecks
* resolved conflicts
* resolved conflicts
* added router tests
* fixed typechecks
* added license check support for alert task running
* fixed typechecks
* added integration tests
* fixed due to comments
* fixed due to comments
* fixed tests
* fixed typechecks
* [Alerting UI][License] Disable alert types in UI when the license doesn't support it. (#85496)
* [Alerting UI][License] Disable alert types in UI when the license doesn't support it.
* fixed typechecks
* added licensing for alert list and details page
* fixed multy select menu
* fixed due to comments
* fixed due to comments
* fixed due to comments
* fixed typechecks
* fixed license error message
* fixed license error message
* fixed typechecks
* fixed license error message
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/79371
resolves https://github.com/elastic/kibana/issues/62928
In this PR, we allow action types to determine how to escape the
variables used in their parameters, when rendered as mustache
templates. Prior to this, action parameters were recursively
rendered as mustache templates using the default mustache
templating, by the alerts library. The default mustache
templating used html escaping.
Action types opt-in to the new capability via a new optional
method in the action type, `renderParameterTemplates()`. If not
provided, the previous recursive rendering is done, but now with
no escaping at all.
For #62928, changed the mustache template rendering to be
replaced with the error message, if an error occurred,
so at least you can now see that an error occurred. Useful
to diagnose problems with invalid mustache templates.
* plugged Task Manager lifecycle into status reactively
* fixed tests
* Revert "fixed tests"
This reverts commit e9f2cd05bd.
* made action group fields optional
* revert deletion
* again
* extracted action type for mto its own component
* extracted more sections of the action form to their own components
* updated icon
* added docs
* fixed always firing alert
* fixed export of components
* fixed react warning
* Adding flag for notifying on state change
* Updating logic in task runner
* Starting to update tests
* Adding tests
* Fixing types check
* Tests and types
* Tests
* Tests
* Tests
* Tests
* Tests
* Renaming field to a more descriptive name. Adding migrations
* Renaming field to a more descriptive name. Adding migrations
* Fixing tests
* Type check and tests
* Moving schedule and notify interval to bottom of flyout. Implementing dropdown from mockup in new component
* Changing boolean flag to enum type and updating in triggers_actions_ui
* Changing boolean flag to enum type and updating in alerts plugin
* Fixing types check
* Fixing monitoring jest tests
* Changing last references to old variable names
* Moving form inputs back to the top
* Renaming to alert_notify_when
* Updating functional tests
* Adding new functional test for notifyWhen onActionGroupChange
* Updating wording
* Incorporating action subgroups into logic
* PR fixes
* Updating functional test
* Fixing types check
* Changing default throttle interval to hour
* Fixing types check
Co-authored-by: Gidi Meir Morris <github@gidi.io>
This PR introduces a new concept of an _Action Subgroup_ (naming is open for discussion) which can be used by an Alert Type when scheduling actions.
An Action Subgroup can be dynamically specified, unlike Action Groups which have to be specified on the AlertType definition.
When scheduling actions, and AlertType can specify an _Action Subgroup_ along side the scheduled _Action Group_, which denotes that the alert instance falls into some kind of narrower grouping in the action group.
* Adding disabled action groups to action type definition
* Adding tests
* Adding tests
* renamed Resolved to Recovered
* fixed missing import
* fixed buggy default message behaviour
* added missing test
* fixed typing
* fixed resolved in tests
* allows alert types to specify their own custom recovery group name
* removed unnecesery field on always fires
* allows alert types to specify their own custom recovery group
* fixed mock alert types throughout unit tests
* fixed typing issues
* reduce repetition of mock data
* fixed alert type list test
* support legacy event log alert recovery syntax
* added doc
* removed unneeded change in jira
* correct callback name in siem
* renamed resolved to recovered
* fixed mistaken rename
* Moving to alert plugin
* Updating tests
* elvated default params to alert concern instead of actions concern
* made default params optional
* Adding test
* Moving where default action params are retrieved
* Revert "Moving where default action params are retrieved"
This reverts commit 76e7608229.
* Moving where default action params are retrieved
* Cleanup
* Fixing test
* PR fixes
Co-authored-by: Gidi Meir Morris <github@gidi.io>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
In this PR we introduce a new `recoveryActionGroup` field on AlertTypes which allows an implementor to specify a custom action group which the framework will use when an alert instance goes from _active_ to _inactive_.
By default all alert types will use the existing `RecoveryActionGroup`, but when `recoveryActionGroup` is specified, this group is used instead.
This is applied across the UI, event log and underlying object model, rather than just being a label change.
To support this we also introduced the `alertActionGroupName` message variable which is the human readable version of existing `alertActionGroup` variable.
Reapplies the #84123 PR:
This PR changes the default term from “Resolved” to “Recovered”, as it fits most use cases and we feel users are most likely to understand its meaning across domains.
