* [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.
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.
This PR adds two components to aid in creating a uniform UI for specifying the conditions for Action Groups:
1. `AlertConditions`: A component that generates a container which renders custom component for each Action Group which has had its _conditions_ specified.
2. `AlertConditionsGroup`: A component that provides a unified container for the Action Group with its name and a button for resetting its condition.
This can be used by any Alert Type to easily create the UI for adding action groups with whichever UI is specific to their component.
* Adding alert.updatedAt field that only updates on user edit
* Updating unit tests
* Functional tests
* Updating alert attributes excluded from AAD
* Fixing test
* PR comments
* Unskipping tests and updating es archiver data
* Removing circular dependency between spaces and security
* Apply suggestions from code review
Co-authored-by: Constance <constancecchen@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
* Tests refactor
- Reorganize top level describes into 3 space-based blocks into based on spaces:
- space disabled
- spaces plugin unavailable
- space enabled (most previous tests go under this new block) with new beforeEach
- wrote new tests for uncovered lines 58, 66-69
* Review1: address PR feedback
* changing fake requests for alerts/actions
* Fixing tests
* fixing more tests
* Additional testing and refactoring
* Apply suggestions from code review
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
* Review 2: Address feedback
* Make ESLint happy again
Co-authored-by: Constance <constancecchen@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Constance Chen <constance.chen.3@gmail.com>
resolves: https://github.com/elastic/kibana/issues/67389
Adds new variables to the existing set of variables that can be used in mustache templates to be used in action parameters when creating alerts.
- `alertActionGroup` - the action group associated with the alert scheduling actions
- `date` - the current date, in ISO format
* Adding alert.updatedAt field that only updates on user edit
* Updating unit tests
* Functional tests
* Updating alert attributes excluded from AAD
* Fixing test
* PR comments
* Used SO for saving the API key IDs that should be deleted and create a configuration option where can set an execution interval for a TM task which will get the data from this SO and remove marked for delete keys.
* removed invalidateApiKey from AlertsClient
* Fixed type checks
* Fixed jest tests
* Removed test code
* Changed SO name
* fixed type cheks
* Moved invalidate logic out of alerts client
* fixed type check
* Added functional tests
* Fixed due to comments
* added configurable delay for invalidation task
* added interval to the task response
* Fixed jest tests
* Fixed due to comments
* Fixed task
* fixed paging
* Fixed date filter
* Fixed jest tests
* fixed due to comments
* fixed due to comments
* Fixed e2e test
* Fixed e2e test
* Fixed due to comments. Changed api key invalidation task to use SavedObjectClient
* Use encryptedSavedObjectClient
* set back flaky test comment
* Added ability to fire actions when an alert instance is resolved
* Fixed due to comments
* Fixed merge issue
* Fixed tests and added skip for muted resolve
* added test for muted alert
* Fixed due to comments
* Fixed registry error message
* Fixed jest test
resolves https://github.com/elastic/kibana/issues/79785
Until now, the execution status was available in the the event
log document for the execute action. In this PR we add it.
The event log is extended to add the following fields:
- `kibana.alerting.status` - from executionStatus.status
- `event.reason` - from executionStatus.error.reason
The date from the executionStatus and start date in the event
log will be set to the same value.
Previously, errors encountered while trying to execute an
alert executor, eg decrypting the alert, would not end up
with an event doc generated. Now they will.
In addition, there were a few places where events that could
have had the action group in them did not, and one where the
instance id was undefined - those were fixed up.
* Implemented Alerting health status pusher by using task manager and status pooler for Kibana status plugins 'kibanahost/api/status'
* Exposed health task registration to alerts plugin
* Fixed type error
* Extended health API endpoint with info about decryption failures, added correct health task implementation
* adjusted query
* Tested locally and got it working as expected, fixed tests and type check
* Added unit tests
* Changed AlertExecutionStatusErrorReasons to be enum
* Uppercase the enum
* Replaced string values to enum
* Fixed types
* Extended AlertsClient with getHealth method
* added return type to healthStatus$
* Added configurable health check interval and timestamps
* Extended update core status interval to 5mins
* Fixed failing tests
* Registered alerts config
* Fixed date for ok health state
* fixed jest test
* fixed task state
* Fixed due to comments, moved getHealth to a plugin level
* fixed type checks
* Added sorting to the latest Ok state last update
* adjusted error queries
* Fixed jest tests
* removed unused
* fixed type check
* Adding action group id to event log. Showing action group as part of status in alert details view
* Simplifying getting action group id
* Cleanup
* Adding unit tests
* Updating functional tests
* Updating test
* Fix types check
* Updating test
* PR fixes
* PR fixes
* wip
* wip
* Adding aggregation option to find function and using those results in UI
* Requesting aggregations from client instead of hard-coding in route
* alert_api test
* i18n fix
* Adding functional test
* Adding unit test for filters
* Splitting into two API endpoints
* Fixing test
* Fixing test
* Adding comment
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* spiked intervals in alerts
* ensure scheduled tasks dont get wiped
* Fixed type checks and unit tests
* Added simple test, which only covers successful case when edit happened right after task was complete previous execution
* fixed jest
* fallback to existing task schedule when possible
* added missing test
* Added support for day and hour schedule interval values
* added docs for new schedule run result
* fixed doc
* added UnrecoverableError support for task runners nad pluged it into alerting where needed
* typo
Co-authored-by: Yuliia Naumenko <yuliia.naumenko@elastic.com>
This PR addresses a list of legacy code debt the plugin has incurred over the past year due to extensive changes in its internals and the adoption of the Kibana Platform.
It includes:
1. The `TaskManager` class has been split into several independent components: `TaskTypeDictionary`, `TaskPollingLifecycle`, `TaskScheduling`, `Middleware`. This has made it easier to understand the roles of the different parts and makes it easier to plug them into the observability work.
2. The exposed `mocks` have been corrected to correctly express the Kibana Platform api
3. The lifecycle has been corrected to remove the need for intermediary streames/promises which we're needed when we first introduced the `setup`/`start` lifecycle to support legacy.
4. The Logger mocks have been replaced with the platform's `coreMocks` implementation
5. The integration tests now test the plugin's actual public api (instead of the internals).
6. The Legacy Elasticsearch client has been replaced with the typed client in response to the deprecation notice.
7. Typing has been narrowed to prevent the `type` field from conflicting with the key in the `TaskDictionary`. This could have caused the displayed `type` on a task to differ from the `type` used in the Dictionary itself (this broke a test during refactoring and could have caused a bug in production code if left).
* Initial work
* Fix type check and jest failures
* Add unit tests
* No need to notifyUsage from alert execution handler
* Fix ESLint
* Log action usage from alerts
* Add integration tests
* Fix jest test
* Skip feature usage of basic action types
* Fix types
* Fix ESLint issue
* Clarify comment
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/51099
This formalizes the concept of "alert status", in terms of it's execution, with
some new fields in the alert saved object and types used with the alert client
and http APIs.
These fields are read-only from the client point-of-view; they are provided in
the alert structures, but are only updated by the alerting framework itself.
The values will be updated after each run of the alert type executor.
The data is added to the alert as the `executionStatus` field, with the
following shape:
```ts
interface AlertExecutionStatus {
status: 'ok' | 'active' | 'error' | 'pending' | 'unknown';
lastExecutionDate: Date;
error?: {
reason: 'read' | 'decrypt' | 'execute' | 'unknown';
message: string;
};
}
```
