* 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.
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.
* 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;
};
}
```
During development of https://github.com/elastic/kibana/pull/75553,
some issues came up with the optimistic concurrency control (OCC) we
were using internally within the alertsClient, via the `version`
option/property of the saved object. The referenced PR updates new
fields in the alert from the taskManager task after the alertType
executor runs. In some alertsClient methods, OCC is used to update
the alert which are requested via user requests. And so in some
cases, version conflict errors were coming up when the alert was
updated by task manager, in the middle of one of these methods. Note:
the SIEM function test cases stress test this REALLY well.
In this PR, we wrap all the methods using OCC with a function that
will retry them, a short number of times, with a short delay in
between. If the original method STILL has a conflict error, it
will get thrown after the retry limit. In practice, this eliminated
the version conflict calls that were occurring with the SIEM tests,
once we started updating the saved object in the executor.
For cases where we know only attributes not contributing to AAD are
being updated, a new function is provided that does a partial update
on just those attributes, making partial updates for those attributes
a bit safer. That will be also used by PR #75553.
The PagerDuty Action currently defaults to a dedupKey that's shared between all action executions of the same connector.
To ensure we don't group unrelated executions together this PR avoids setting a default, which means each execution will result in its own incident in PD.
As part of this change we've also made the `dedupKey` a required field whenever a `resolve` or `acknowledge` event_action is chosen. This ensure we don't try to resolve without a dedupKey, which would result in an error in PD.
A migration has been introduced to migrate existing alerts which might not have a `dedupKey` configured.
