Actions & alerting getting started user guides #39093

mikecote · 2019-06-17T16:58:59Z

In this PR, we're adding the initial documentation to allow solution teams to get started at validating the alerting framework that is developed so far.

elasticmachine · 2019-06-17T16:59:03Z

Pinging @elastic/kibana-stack-services

pmuellr

This is great!

I made a number of comments, but they're mostly about the design of the APIs, not the doc :-)

x-pack/plugins/actions/README.md

pmuellr · 2019-06-18T17:03:02Z

x-pack/plugins/actions/README.md

+|---|---|---|
+|id|Unique identifier for the action type.|string|
+|name|A user friendly name for the action type.|string|
+|unencryptedAttributes|A list of opt-out attributes that don't need to be encrypted, these attributes won't need to be re-entered on import / export when the feature becomes available.|array of strings|


had some chit-chat about maybe indicating unencrypted config attributes (this is really just config, and not params, right?) could be specified instead via joi.meta({unencrypted: true}) or such (or possibly the reverse - specify which config attrs are encrypted). Seems more readable and writable. We'd need to use joi.describe() to get these

x-pack/plugins/actions/README.md

pmuellr · 2019-06-18T17:11:11Z

x-pack/plugins/actions/README.md

+|id|The id of the action you want to fire.|string|
+|params|The `params` value to give the action type executor|object|
+|namespace|The namespace the action exists within|string|
+|basePath|The request's basePath value, usually `request.getBasePath()`|string|


Is basePath supposed to provide some audit/log-ish kind of value? Like, "this alert was associated with an http request here: x/y/z". Otherwise not sure what it's for.

It's a temporary thing until we do the security phase of alerting. Currently when we're detached from a request, we need to capture that value for the saved objects client to know what space it relates to, we've discussed decomposing it into just the namespace but figured it wasn't worth the effort for now.

pmuellr · 2019-06-18T17:22:31Z

x-pack/plugins/alerting/README.md

+|services.callCluster|Use this to do elasticsearch queries on the cluster Kibana connects to. NOTE: This currently authenticates as the Kibana internal user, this will change in a future PR.|
+|services.savedObjectsClient|Use this to manipulate saved objects. NOTE: This currently only works when security is disabled. A future PR will add support for enabled security using Elasticsearch API tokens.|
+|services.log|Use this to create server logs. (This is the same function as server.log)|
+|scheduledRunAt|The date and time the alert type was supposed to be called.|


We had talked about some more elaborate "meta" state on previous scheduled runs - time of last successful run, number of errors since last successful run, etc. Seems like at least previousScheduleRunAt and probably scheduledRunAt should be properties on some kind of "meta" object which is passed in.

Speaking of "meta" info about alerts, I wonder if this should include error information about running the actions. Wonder if there's enough info in the alert to provide interesting user-facing info on things like "we ran this alert but this action failed" kinda thing. I guess eventually, when we start adding audit/log info to ES on the alerts as they are "executed"? Seems right, so ... can defer, but just wondering ...

yeah I think that will come with the history / audit log phase where we could leverage that for meta functionality and such.

In regards to meta you're thinking wrapping those two into a meta object instead of being provided flat?

ya, that was the suggestion, sorry: move scheduledRunAt and previousScheduledRunAt into some new top-level property, maybe scheduleState.

pmuellr · 2019-06-18T17:38:21Z

x-pack/plugins/alerting/README.md

+      });
+
+    // Returning updated alert type level state
+    return {


brain fart: I wonder how well this will work in practice. I think I find that for functions that might be pretty complicated to implement (eg, an alert executor heh), it can get complicated to coordinate all the returns. Something we could "enhance" later with an API that let you explicitly set the state or something, perhaps. I think I'm thinking of how AWS lambda has morphed over the years from kind of a return-centric thing to explicit API, for responses.

I'm open for suggestions, this one here is the global state at the alert level regardless if an instance is created or not. We'll see if its used by the team.

pmuellr · 2019-06-18T17:43:37Z

x-pack/plugins/alerting/README.md

+|resetFire()|Reverts a `.fire(...)` call and makes the instance no longer fire.|
+|getState()|Get the current state of the alert instance.|
+|getMeta()|Get the internal set meta attributes for the alert instance.|
+|fire(actionGroup, context)|Called to fire actions.|


Can I call fire() multiple times? Does resetFire() take options to remove a specific fire() that was previously called? Allowing fire() to be called multiple times seems like one answer to the "how do we do 'aggregated' actions on alerts" - the answer is that it's up to the alert. If an alert wants to support either or both, it could provide it's own toggle switches to deal with that, then either do a single fire() or multiple or ... both.

By design it can only be called once, we could enhance to throw an error if it does. In the scenario to do different actions, they would create different alert instances and fire each of them.

pmuellr · 2019-06-18T17:45:26Z

x-pack/plugins/alerting/README.md

+|shouldFire()|Function returns `true` or `false` whether the alert instance should fire or not. This value turns to true when `.fire(...)` is called.|
+|getFireOptions()|Function returns an object of `actionGroup`, `context` and `state` to use for firing the actions.|
+|resetFire()|Reverts a `.fire(...)` call and makes the instance no longer fire.|
+|getState()|Get the current state of the alert instance.|


If state and meta are things that alert creators might make use of, needs more description. Or maybe it's a placeholder for future stuff we know we'll need but don't know the shape of yet?

Yeah I'll try to rethink this one, its hard to explain what it will contain since the developer is in control of that. But I can mark where the values will come from / be set from.

pmuellr · 2019-06-18T18:02:16Z

x-pack/plugins/alerting/README.md

+
+```
+alertInstanceFactory('server_1')
+  .replaceState({


I'm really curious about this .replaceState() now! How is related to the state that is returned by the alert executor, which is labelled updated alert type level state in an example above. Perhaps this answers my question above re: having an explicit api to set state instead of via the return value. But ... I'm thinking it's probably something different. If different, I think we need a different name, or will need a simple "prefix" name for these "alert state" vss "alert type state" etc.

Yeah this is different state than the updated alert type level state. One is global and one is specific to an alert instance. I'm open for new names. Just have to avoid confusion when you have two alerts for the same type, there's no cross state for that scenario.

pmuellr · 2019-06-18T18:06:34Z

x-pack/plugins/alerting/README.md

+
+Below is an example of an alert that takes advantage of templating:
+
+```


It would probably be good to have both a simple example like this one, as well as a more complicated one that shows how you might deal with multiple objects to "action".

pmuellr · 2019-06-18T18:19:58Z

x-pack/plugins/alerting/README.md

+|Property|Description|Type|
+|---|---|---|
+|alertTypeId|The id value of the alert type you want to call when the alert is scheduled to execute.|string|
+|interval|The interval in milliseconds the alert should execute.|number|


thinking into the near future, we'll want some crontab like thing here. Here's how watcher does this: https://www.elastic.co/guide/en/elastic-stack-overview/7.1/trigger-schedule.html

I propose we eventually follow that, we can do just interval for now, unitless, and should probably be seconds and not millseconds.

That just means moving interval under a new top-level schedule attribute. We can then roll out the other schedule types as needed.

…rting/README-files

mikecote · 2019-06-19T11:48:00Z

Jenkins, test this

bmcconaghy

I was able with a little bit of fiddling to get a full custom alert + custom action thing going locally following this guide. I've called out the confusions and issues I ran into.

x-pack/plugins/actions/README.md

x-pack/plugins/alerting/README.md

bmcconaghy · 2019-06-19T17:04:32Z

x-pack/plugins/alerting/README.md

+        // previous and persisted values
+        ...
+      })
+      .fire('default', {


It's not immediately clear what the default string does here. Reading below I might be able to connect the dots and realize that this is the action group. Also, what if I want to fire multiple action groups? Seems like this wouldn't be supported with the current code.

I will make a change to the docs, in regards to fire multiple action groups, by design, you would have to duplicate the action for each group you would like it to fire for. Ex if you want email on warning and severe action groups, you would have to pass two objects to actions on the create alert API. In the future we could make group an array within the actions array passed into the create alert API.

Seems fairly painful to have to recreate actions. I can easily imagine a scenario where I want a less important alert firing slack messages, but if the alert severity grows into a more important scenario, send an email (contrived example). But I'd still want the slack messages fired.

Don't have any thoughts on making it easier tho, ATM. Have thoughts on making it harder, so I'll keep those to myself for now :-)

bmcconaghy · 2019-06-19T17:05:59Z

x-pack/plugins/alerting/README.md

+
+Below is an example of an alert that takes advantage of templating:
+
+```


x-pack/plugins/alerting/README.md

bmcconaghy · 2019-06-19T17:24:08Z

x-pack/plugins/alerting/README.md

+  ...
+  actions: [
+    {
+      "group": "default",


so thinking about this more: group names are configured on alert instances, but the alert type code itself needs to know names for when it fires. Don't see how this will work in practice unless we only have predefined names that you can use.

Yes I think when we come up with throttling we'll make the alert type the source of truth for these groups and define a priority or something so we know when to stop throttling when alert status gets worse.

x-pack/plugins/actions/README.md

x-pack/plugins/alerting/README.md

Co-Authored-By: gchaps <[email protected]>

mikecote · 2019-06-20T00:28:33Z

Thank you so much for the feedback @gchaps! All the changes have been applied as suggested. They all made sense.

peterschretlen · 2019-06-20T14:34:34Z

x-pack/plugins/actions/README.md

+  namespace: undefined, // The namespace the action exists within
+  basePath: undefined, // Usually `request.getBasePath();` or `undefined`
+});
+```


Reading through this document I have a good understanding of the different pieces like action types, CRUD for actions, and firing. But an example that shows the full usage from creation of an action to the action being completed might help answer some questions. For example: after I create an action and fire it, how do I get its status - how do I know it worked? Do I get that through task manager, do I poll the action to get a status?

For example: after I create an action and fire it, how do I get its status - how do I know it worked? Do I get that through task manager, do I poll the action to get a status?

TBD; seems like we'll have some kind of history &| audit log of actions run, so you'd need to poll that. We'll need to have the action fire return some kind of id for the action fire status, that would eventually show up in the history &| audit log.

Another question related to action lifecycle, once an action has been fired and executed, should I delete it or keep it for history? Are there any consequences to not deleting them, do they get cleaned up periodically?

do they get cleaned up periodically?

I just did a test regarding this, if a task isn't re-scheduled, it gets removed from the task manager. The task manager periodically cleans up expired tasks.

I just had a conversation with @bmcconaghy about this. We're going to add a REST API to fire actions (PR coming soon). We will change the behaviour of this manual function and make it hold off until the execution is complete. This function will then be able to throw errors, if any occur, during the execution.

elasticmachine · 2019-06-20T15:02:08Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request

peterschretlen · 2019-06-20T15:54:03Z

x-pack/plugins/alerting/README.md

+
+|Property|Description|Type|
+|---|---|---|
+|id|The id of the alert you're trying to get.|string|


Some information on what gets returned would be useful - I think we're just returning the alert configuration (i.e. what is in the saved object). Some people might be expecting instance data like alert state being returned here (say I want to get my alert and show its state in UI). But sounds like we'd need to get that via the alertInstanceFactory since it is part of the instance.

Yeah, I can see that. We can add new APIs or modify them as we build the alerting app to display valuable information. We may have to move things around or develop something new to make the data accessible.

x-pack/plugins/alerting/README.md

peterschretlen

Looks good I left a few comments!

bmcconaghy

LGTM. We'll have to be extra careful to keep these in sync with the implementations.

…rting/README-files

elasticmachine · 2019-06-20T20:09:38Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request

elasticmachine · 2019-06-20T21:24:50Z

💔 Build Failed

continuous-integration/kibana-ci/pull-request

@ts-ignore

* Create actions plugin (elastic#35679) * Basic alerting plugin with actions * Remove relative imports * Code cleanup * Split service into 3 parts, change connector structure * Ability to disable plugin, ability to get actions * Add slack connector * Add email connector * Ability to validate params and connector options * Remove connectorOptionsSecrets for now * Fix plugin config validation * Add tests for slack connector * Default connectors register on plugin init, console renamed to log, slack to message_slack * Add remaining API endpoints for action CRUD * Add list connectors API * Change actions CRUD APIs to be closer with saved objects structure * WIP * Fix broken tests * Add encrypted attribute support * Add params and connectorOptions for email * WIP * Remove action's ability to have custom ids * Remove ts-ignore * Fix broken test * Remove default connectors from this branch * Fix API integration tests to use fixture connector * Rename connector terminology to action type * Rename actionTypeOptions to actionTypeConfig * Code cleanup * Fix broken tests * Rename alerting plugin to actions * Some code cleanup and add API unit tests * Change signature of action type service execute function * Add some plugin api integration tests * Fix type check failure * Code cleanup * Create an actions client instead of an action service * Apply Bill's PR feedback * Fix broken test * Find function to have destructured params * Add tests to ensure encrypted attributes are not returned * Fix broken test * Add tests for validation * Ensure actions can be updated without re-passing the config * Remove dead code * Test cleanup * Fix eslint issue * Apply Peter's PR feedback * Code cleanup and fix broken tests * Apply Brandon's PR feedback * Add namespace support * Fix broken test * Pass services to action executors (elastic#37194) * Pass services to action executors * Fix tests * Apply PR feedback * Apply PR feedback pt2 * Cleanup actions plugin (elastic#37250) * Cleanup actions, move code from alerting plugin PR * Rename service terminology to registry * Use static encryption key for encrypted attributes plugin inside of tests * Empty data after create test is done running * Fix type checks * Fix inconsistent naming * add server log action for alerting (elastic#37530) adds the first "builtin" alertType for performing a `server.log()` * Create alerting plugin (elastic#37043) * WIP * Rename fire function and remove @ts-ignore in all places * Change naming in alerting service * Remove alert instance class for now, support interval configuration * Cleanup TS * Split alerting between registry and client * Use saved object alongside task manager instance * Add remaining alerting APIs * Change create structure * Rename some variables, change actionGroups structure * Use handlebars for templating strings at fire time * Fix params given to alert type execute function * Use alert instance class * Alert instances support meta attributes * Move alert instances deserialization * Change interval to be ms * Rename actions es archive * Fix tests to use encrypted esArchive for action record * Add create alert test to demo end to end flow * Fix type check issue * Alerts to use references to action objects * Only update task manager tasks after saved objects are fully updated * Use scope in task manager * Fix type check * Use task manager to execute actions * Convert ids into references and back * Apply PR feedback * Fix broken test * Fix some bugs * Fix test errors * Alert interval to be previous runAt + interval instead of now + interval * Add range support * Remove extra line * Cleanup * Add alert_instance.test.ts * Add alert_type_registry.test.ts * Move tests around * Create generic task manager mock * Add note about saved objects client mock * Create alert_type_registry.mock.ts * Add alerts_client.test.ts * Add create_alert_instance_factory.test.ts * Add create_fire_handler.test.ts * WIP * Fix get_create_task_runner_function.test.ts and make test pass * Make get_create_task_runner_function.test.ts 100% coverage * Add unit tests for routes * Move files around * Created transform_action_params.ts * Add get_next_run_at.ts * Add comment explaining why we copy nextRunAt * Re-use state within alert instance * Finalize code coverage in unit tests * Create base api integration tests * Add a test that ensures end to end functionality of an alert * Fix ui capabilities test * Fix broken plugin api integration test * Fix jest tests with new saved objects client * Fix broken integration tests * Change api integration test fixture to make more sense, add functions for future tests * Move alerts integration testing into own file, prep to add more tests * Add tests to ensure failed task instances get retried * Add get_create_task_runner_function.test.ts for actions, create encrypted saved objects mock * Add action validation tests * Ensure action type validation occurs on update * Test 400 on unregistered alert types * Ensure alertTypeId can't be updated * Add validation test for alert create / update * Fix broken checks / tests * Skip failing test for now * Cleanup jest tests * Ensure action objects can be updated while keeping encrypted attributes readable * Remove partial update sopport, remove ability to change actionTypeId, require config * Ensure actionTypeConfig is validated on create and update * Add alertTypeParams validation support * Fix failing tests * Ensure alert cleanup errors don't replace the original error * Pass callCluster as a service to alerts and actions * Only pass log to alerts client * Pass savedObjectsClient as a service to alerting and actions * Fix failing tests * Remove range support, provide when current and previous task got scheduled * Ensure Joi validation happens before every execute * Remove skipped tests, to be done in future PR * Apply self feedback pt1 * Apply self feedback pt2 * Fix broken tests * Apply PR feedback * PR feedback pt1 * Apply security team PR feedback * PR feedback pt1 * PR feedback pt2 * PR feedback pt3 * Fix broken tests * Fix callCluster to have signature * Revert f11a6ae * PR feedback pt4 * Remove __jest__ folders * PR feedback pt5 * Fix Joi from leaking secrets * Fire instance actions in parallel instead of series * Fix failing jest tests * Accept core api changes * Fix saved objects client mock * PR feedback pt1 * Fix eslint issues * Throw error when alert instance already fired (elastic#39251) * Throw error when alert instance already fired * shouldFire doesn't need its own boolean value * Actions & alerting getting started user guides (elastic#39093) * Initial user guides * Cleanup * Typos, example changes * Switch to tables, use ordered list for usage * Start docs around alert instances and templating * Documentation changes * Some adjustments * Apply PR feedback * Apply suggestions from code review Co-Authored-By: gchaps <[email protected]> * PR feedback pt2 * Provide better examples for alert types * Apply PR feedback * Update README locations

@ts-ignore

* Create actions plugin (elastic#35679) * Basic alerting plugin with actions * Remove relative imports * Code cleanup * Split service into 3 parts, change connector structure * Ability to disable plugin, ability to get actions * Add slack connector * Add email connector * Ability to validate params and connector options * Remove connectorOptionsSecrets for now * Fix plugin config validation * Add tests for slack connector * Default connectors register on plugin init, console renamed to log, slack to message_slack * Add remaining API endpoints for action CRUD * Add list connectors API * Change actions CRUD APIs to be closer with saved objects structure * WIP * Fix broken tests * Add encrypted attribute support * Add params and connectorOptions for email * WIP * Remove action's ability to have custom ids * Remove ts-ignore * Fix broken test * Remove default connectors from this branch * Fix API integration tests to use fixture connector * Rename connector terminology to action type * Rename actionTypeOptions to actionTypeConfig * Code cleanup * Fix broken tests * Rename alerting plugin to actions * Some code cleanup and add API unit tests * Change signature of action type service execute function * Add some plugin api integration tests * Fix type check failure * Code cleanup * Create an actions client instead of an action service * Apply Bill's PR feedback * Fix broken test * Find function to have destructured params * Add tests to ensure encrypted attributes are not returned * Fix broken test * Add tests for validation * Ensure actions can be updated without re-passing the config * Remove dead code * Test cleanup * Fix eslint issue * Apply Peter's PR feedback * Code cleanup and fix broken tests * Apply Brandon's PR feedback * Add namespace support * Fix broken test * Pass services to action executors (elastic#37194) * Pass services to action executors * Fix tests * Apply PR feedback * Apply PR feedback pt2 * Cleanup actions plugin (elastic#37250) * Cleanup actions, move code from alerting plugin PR * Rename service terminology to registry * Use static encryption key for encrypted attributes plugin inside of tests * Empty data after create test is done running * Fix type checks * Fix inconsistent naming * add server log action for alerting (elastic#37530) adds the first "builtin" alertType for performing a `server.log()` * Create alerting plugin (elastic#37043) * WIP * Rename fire function and remove @ts-ignore in all places * Change naming in alerting service * Remove alert instance class for now, support interval configuration * Cleanup TS * Split alerting between registry and client * Use saved object alongside task manager instance * Add remaining alerting APIs * Change create structure * Rename some variables, change actionGroups structure * Use handlebars for templating strings at fire time * Fix params given to alert type execute function * Use alert instance class * Alert instances support meta attributes * Move alert instances deserialization * Change interval to be ms * Rename actions es archive * Fix tests to use encrypted esArchive for action record * Add create alert test to demo end to end flow * Fix type check issue * Alerts to use references to action objects * Only update task manager tasks after saved objects are fully updated * Use scope in task manager * Fix type check * Use task manager to execute actions * Convert ids into references and back * Apply PR feedback * Fix broken test * Fix some bugs * Fix test errors * Alert interval to be previous runAt + interval instead of now + interval * Add range support * Remove extra line * Cleanup * Add alert_instance.test.ts * Add alert_type_registry.test.ts * Move tests around * Create generic task manager mock * Add note about saved objects client mock * Create alert_type_registry.mock.ts * Add alerts_client.test.ts * Add create_alert_instance_factory.test.ts * Add create_fire_handler.test.ts * WIP * Fix get_create_task_runner_function.test.ts and make test pass * Make get_create_task_runner_function.test.ts 100% coverage * Add unit tests for routes * Move files around * Created transform_action_params.ts * Add get_next_run_at.ts * Add comment explaining why we copy nextRunAt * Re-use state within alert instance * Finalize code coverage in unit tests * Create base api integration tests * Add a test that ensures end to end functionality of an alert * Fix ui capabilities test * Fix broken plugin api integration test * Fix jest tests with new saved objects client * Fix broken integration tests * Change api integration test fixture to make more sense, add functions for future tests * Move alerts integration testing into own file, prep to add more tests * Add tests to ensure failed task instances get retried * Add get_create_task_runner_function.test.ts for actions, create encrypted saved objects mock * Add action validation tests * Ensure action type validation occurs on update * Test 400 on unregistered alert types * Ensure alertTypeId can't be updated * Add validation test for alert create / update * Fix broken checks / tests * Skip failing test for now * Cleanup jest tests * Ensure action objects can be updated while keeping encrypted attributes readable * Remove partial update sopport, remove ability to change actionTypeId, require config * Ensure actionTypeConfig is validated on create and update * Add alertTypeParams validation support * Fix failing tests * Ensure alert cleanup errors don't replace the original error * Pass callCluster as a service to alerts and actions * Only pass log to alerts client * Pass savedObjectsClient as a service to alerting and actions * Fix failing tests * Remove range support, provide when current and previous task got scheduled * Ensure Joi validation happens before every execute * Remove skipped tests, to be done in future PR * Apply self feedback pt1 * Apply self feedback pt2 * Fix broken tests * Apply PR feedback * PR feedback pt1 * Apply security team PR feedback * PR feedback pt1 * PR feedback pt2 * PR feedback pt3 * Fix broken tests * Fix callCluster to have signature * Revert f11a6ae * PR feedback pt4 * Remove __jest__ folders * PR feedback pt5 * Fix Joi from leaking secrets * Fire instance actions in parallel instead of series * Fix failing jest tests * Accept core api changes * Fix saved objects client mock * PR feedback pt1 * Fix eslint issues * Throw error when alert instance already fired (elastic#39251) * Throw error when alert instance already fired * shouldFire doesn't need its own boolean value * Actions & alerting getting started user guides (elastic#39093) * Initial user guides * Cleanup * Typos, example changes * Switch to tables, use ordered list for usage * Start docs around alert instances and templating * Documentation changes * Some adjustments * Apply PR feedback * Apply suggestions from code review Co-Authored-By: gchaps <[email protected]> * PR feedback pt2 * Provide better examples for alert types * Apply PR feedback * Update README locations

@ts-ignore

* Create actions plugin (#35679) * Basic alerting plugin with actions * Remove relative imports * Code cleanup * Split service into 3 parts, change connector structure * Ability to disable plugin, ability to get actions * Add slack connector * Add email connector * Ability to validate params and connector options * Remove connectorOptionsSecrets for now * Fix plugin config validation * Add tests for slack connector * Default connectors register on plugin init, console renamed to log, slack to message_slack * Add remaining API endpoints for action CRUD * Add list connectors API * Change actions CRUD APIs to be closer with saved objects structure * WIP * Fix broken tests * Add encrypted attribute support * Add params and connectorOptions for email * WIP * Remove action's ability to have custom ids * Remove ts-ignore * Fix broken test * Remove default connectors from this branch * Fix API integration tests to use fixture connector * Rename connector terminology to action type * Rename actionTypeOptions to actionTypeConfig * Code cleanup * Fix broken tests * Rename alerting plugin to actions * Some code cleanup and add API unit tests * Change signature of action type service execute function * Add some plugin api integration tests * Fix type check failure * Code cleanup * Create an actions client instead of an action service * Apply Bill's PR feedback * Fix broken test * Find function to have destructured params * Add tests to ensure encrypted attributes are not returned * Fix broken test * Add tests for validation * Ensure actions can be updated without re-passing the config * Remove dead code * Test cleanup * Fix eslint issue * Apply Peter's PR feedback * Code cleanup and fix broken tests * Apply Brandon's PR feedback * Add namespace support * Fix broken test * Pass services to action executors (#37194) * Pass services to action executors * Fix tests * Apply PR feedback * Apply PR feedback pt2 * Cleanup actions plugin (#37250) * Cleanup actions, move code from alerting plugin PR * Rename service terminology to registry * Use static encryption key for encrypted attributes plugin inside of tests * Empty data after create test is done running * Fix type checks * Fix inconsistent naming * add server log action for alerting (#37530) adds the first "builtin" alertType for performing a `server.log()` * Create alerting plugin (#37043) * WIP * Rename fire function and remove @ts-ignore in all places * Change naming in alerting service * Remove alert instance class for now, support interval configuration * Cleanup TS * Split alerting between registry and client * Use saved object alongside task manager instance * Add remaining alerting APIs * Change create structure * Rename some variables, change actionGroups structure * Use handlebars for templating strings at fire time * Fix params given to alert type execute function * Use alert instance class * Alert instances support meta attributes * Move alert instances deserialization * Change interval to be ms * Rename actions es archive * Fix tests to use encrypted esArchive for action record * Add create alert test to demo end to end flow * Fix type check issue * Alerts to use references to action objects * Only update task manager tasks after saved objects are fully updated * Use scope in task manager * Fix type check * Use task manager to execute actions * Convert ids into references and back * Apply PR feedback * Fix broken test * Fix some bugs * Fix test errors * Alert interval to be previous runAt + interval instead of now + interval * Add range support * Remove extra line * Cleanup * Add alert_instance.test.ts * Add alert_type_registry.test.ts * Move tests around * Create generic task manager mock * Add note about saved objects client mock * Create alert_type_registry.mock.ts * Add alerts_client.test.ts * Add create_alert_instance_factory.test.ts * Add create_fire_handler.test.ts * WIP * Fix get_create_task_runner_function.test.ts and make test pass * Make get_create_task_runner_function.test.ts 100% coverage * Add unit tests for routes * Move files around * Created transform_action_params.ts * Add get_next_run_at.ts * Add comment explaining why we copy nextRunAt * Re-use state within alert instance * Finalize code coverage in unit tests * Create base api integration tests * Add a test that ensures end to end functionality of an alert * Fix ui capabilities test * Fix broken plugin api integration test * Fix jest tests with new saved objects client * Fix broken integration tests * Change api integration test fixture to make more sense, add functions for future tests * Move alerts integration testing into own file, prep to add more tests * Add tests to ensure failed task instances get retried * Add get_create_task_runner_function.test.ts for actions, create encrypted saved objects mock * Add action validation tests * Ensure action type validation occurs on update * Test 400 on unregistered alert types * Ensure alertTypeId can't be updated * Add validation test for alert create / update * Fix broken checks / tests * Skip failing test for now * Cleanup jest tests * Ensure action objects can be updated while keeping encrypted attributes readable * Remove partial update sopport, remove ability to change actionTypeId, require config * Ensure actionTypeConfig is validated on create and update * Add alertTypeParams validation support * Fix failing tests * Ensure alert cleanup errors don't replace the original error * Pass callCluster as a service to alerts and actions * Only pass log to alerts client * Pass savedObjectsClient as a service to alerting and actions * Fix failing tests * Remove range support, provide when current and previous task got scheduled * Ensure Joi validation happens before every execute * Remove skipped tests, to be done in future PR * Apply self feedback pt1 * Apply self feedback pt2 * Fix broken tests * Apply PR feedback * PR feedback pt1 * Apply security team PR feedback * PR feedback pt1 * PR feedback pt2 * PR feedback pt3 * Fix broken tests * Fix callCluster to have signature * Revert f11a6ae * PR feedback pt4 * Remove __jest__ folders * PR feedback pt5 * Fix Joi from leaking secrets * Fire instance actions in parallel instead of series * Fix failing jest tests * Accept core api changes * Fix saved objects client mock * PR feedback pt1 * Fix eslint issues * Throw error when alert instance already fired (#39251) * Throw error when alert instance already fired * shouldFire doesn't need its own boolean value * Actions & alerting getting started user guides (#39093) * Initial user guides * Cleanup * Typos, example changes * Switch to tables, use ordered list for usage * Start docs around alert instances and templating * Documentation changes * Some adjustments * Apply PR feedback * Apply suggestions from code review Co-Authored-By: gchaps <[email protected]> * PR feedback pt2 * Provide better examples for alert types * Apply PR feedback * Update README locations

mikecote added Feature:Alerting release_note:skip Skip the PR/issue when compiling release notes Team:Stack Services labels Jun 17, 2019

mikecote self-assigned this Jun 17, 2019

mikecote added 3 commits June 18, 2019 07:39

Initial user guides

c7eb007

Cleanup

c383049

Typos, example changes

02b078a

mikecote force-pushed the alerting/README-files branch from 569f6f3 to 02b078a Compare June 18, 2019 11:39

mikecote added 2 commits June 18, 2019 08:57

Switch to tables, use ordered list for usage

b0dc723

Start docs around alert instances and templating

e601a2e

pmuellr approved these changes Jun 18, 2019

View reviewed changes

pmuellr reviewed Jun 18, 2019

View reviewed changes

mikecote added 4 commits June 18, 2019 17:23

Documentation changes

9572715

Merge branch 'feature/alerting' of github.com:elastic/kibana into ale…

f874e43

…rting/README-files

Some adjustments

af7b104

Merge branch 'feature/alerting' of github.com:elastic/kibana into ale…

2e013f3

…rting/README-files

mikecote marked this pull request as ready for review June 19, 2019 11:47

mikecote added the review label Jun 19, 2019

This comment has been minimized.

Sign in to view

bmcconaghy reviewed Jun 19, 2019

View reviewed changes

Apply PR feedback

64b246d

This comment has been minimized.

Sign in to view

gchaps reviewed Jun 19, 2019

View reviewed changes

mikecote and others added 2 commits June 19, 2019 20:18

Apply suggestions from code review

5918aa6

Co-Authored-By: gchaps <[email protected]>

PR feedback pt2

7c8af16

This comment has been minimized.

Sign in to view

Provide better examples for alert types

349010c

peterschretlen reviewed Jun 20, 2019

View reviewed changes

x-pack/plugins/alerting/README.md Show resolved Hide resolved

peterschretlen reviewed Jun 20, 2019

View reviewed changes

Apply PR feedback

2f4ae50

bmcconaghy approved these changes Jun 20, 2019

View reviewed changes

Merge branch 'feature/alerting' of github.com:elastic/kibana into ale…

1af13d2

…rting/README-files

Update README locations

a1ce2a2

mikecote merged commit c3ceb4d into elastic:feature/alerting Jun 20, 2019

mikecote mentioned this pull request Jun 24, 2019

Adds a slack action #39221

Merged

mikecote added v7.3.0 v8.0.0 labels Dec 6, 2019

ruflin mentioned this pull request Aug 18, 2020

Add Action / Alert assets elastic/package-spec#28

Closed


		Below is an example of an alert that takes advantage of templating:

		```

Actions & alerting getting started user guides #39093

Actions & alerting getting started user guides #39093

Uh oh!

Conversation

mikecote commented Jun 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elasticmachine commented Jun 17, 2019

Uh oh!

pmuellr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikecote commented Jun 19, 2019

Uh oh!

This comment has been minimized.

bmcconaghy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mikecote commented Jun 17, 2019 •

edited

Loading