profile
viewpoint
Patrick Mueller pmuellr Elastic, ex-NodeSource, ex-IBM Apex, NC https://muellerware.org

phonegap/phonegap-plugins 3264

(DEPRECATED) Plugins for use with PhoneGap.

pmuellr/AnyViewer 11

a programmable desktop file viewer built on Electron

ctoestreich/CoffeeScriptAntTasks 10

ant tasks for CoffeeScript

pmuellr/bluemix-cron 7

A sample application for bluemix that runs cron tasks.

pmuellr/bluemix-private-packages 5

example of a Bluemix node app using a private repo

moar-things/moar-profiler 2

v8 cpu profiler with moar

pmuellr/android-sdk-epubs 2

Generate ePub files from Android SDK docs

pmuellr/bluemix-hello-iojs 2

Hello World sample for Bluemix using io.js

push eventpmuellr/kibana

Felix Stürmer

commit sha 807803c2dc10e9ffad3ccdedfd5a818bd5b1fc3e

[Metrics UI] Fix mistake in container ip field name (#66198) This corrects an apparent mistake in the inventory's container.ip_address field name.

view details

Quynh Nguyen

commit sha f24785f33bc716385ad8b5fd12ed35fab7411eb6

[ML] Search should have a categorical option for job type (#65770) * [ML] Add categorical filters to ist of df analytics jobs * [ML] Removed unused ANALYSIS_CONFIG_TYPE * [ML] Change getJobTypeBadge to implicit return Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Spencer

commit sha fd66d474e59798f6311fcb2c8f20e6c9a905babc

download cypress from ci-proxy-cache (#66141) Co-authored-by: spalger <spalger@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Shahzad

commit sha 75ea9eaad44854b98f5a39cadf463f5f6d77edd6

[Uptime] Fix document title according to page (#65665)

view details

Nathan Reese

commit sha 7b0d445b5188e7593282d3717f53feef15c7616f

[Maps] convert AddLayerPanel to TS (#65685) * [Maps] convert AddLayerPanel to TS * remove ImportFile component * ts-lint clean up * simply FlyoutBody * remove unneeded ts-ignores Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Mikhail Shustov

commit sha 3667647aa24510c10422ec9c1e33c1baa6549380

Do not register SO in the legacy platform (#66203) * move maps SO registration to KP * move timelion SO registration to KP * register server SO in KP Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

spalger

commit sha 78aa89b8180e3f7621995e70170aa958a277b604

skip flaky suite (#62866)

view details

Frank Hassanabad

commit sha ac4f5d55e1ca3d871fdb2e793ce05c7b5bb710b2

[SIEM][Detection Engine] Removes legacy ElasticSearch from end to end tests ## Summary Removes the legacy ElasticSearch nodejs client from end to end tests in favor of the non-legacy newer Elastic Search client which is recommended by Kibana core and the company to migrate away from and stop using. This PR accomplishes that goal by removing the `getService('legacyES')` when getting the service from the end to end tests and instead gets the service through `getService('es')` ### Checklist - [x] [Unit or functional tests](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#cross-browser-compatibility) were updated or added to match the most common scenarios

view details

spalger

commit sha c9523243f22b01c946060044e600a7a92d541406

skip flaky suite (#65567)

view details

Nick Peihl

commit sha 86017800a8538770b1c027229b799a9a0baede35

Update ems landing page url (#66244) Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Quynh Nguyen

commit sha 7da7080fbc886cd6d0a758689ce093df4744b19a

[ML] Fix anomaly dot plotted in wrong location in Single Metric Viewer (#66071) * [ML] Fix anomaly dot plotted in wrong location in SMV * [ML] Validate if record's actual exists before setting it as chartPoint data * [ML] Add logic for chartPoint in case record dne to use the cause's actual Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Josh Dover

commit sha fd4074f2cd6fa528ac17acb735d7636c2d2523be

Remove slapshot contract tests (#66277)

view details

Yuliia Naumenko

commit sha 5ed5fda8320f9b966645cf9e888c77822315b5f5

Allow registered alert types to be non-editable (#65606) * Allow registered alert types to be non-editable * Fixed isUiEditEnabled values * Fixed due to comments * fixed failing tests * Enable alert type selection per alert consumer, only 'alerting' consumer can display other consumers alert types, but in case if it isEditable * fixed tests * Removed consumer property from the client side alert type registry and added server side property producer which purpose is to manage a feature logic * fixed type check * Fixed tests and type checks * Removed error message for non registered plugins * Fixed failing tests * Fixed due to comments * fixed test * - * revert logic for requiresAppContext * Added close toast after saving alert

view details

Melissa Alvarez

commit sha 840ae20656f2a523e0b9b7a4ef434d4704598aaa

[ML] API integration tests for GET data frame analytics endpoints (#66136) * wip: create analytics api integration dir * add get analytics tests * update types and naming * update api test types

view details

Josh Dover

commit sha 3a59a64690b0bfda060d436d952a3a4ce5e7246c

[skip-ci] Fix links to Core API docs (#66274)

view details

Caroline Horn

commit sha 0fbbc788525fa0abc6b21ff40082c41b6528f0c6

[Spaces] SASS modularization (#65921) * Removing Spaces legacy styles import in favor of direct plugin import * Modularizing the `/management` components * Further modularization within copy_saved_objects_to_space * Add styling section to CONTRIBUTING * SASS lint and snaps * Adding link to EUI SASS

view details

nnamdifrankie

commit sha e4c68f1a7aca5d5628b557638dfc8344a88a5e36

[Endpoint]EMT-339: add new policy response schema (#66264) [Endpoint]EMT-339: add new policy response schema

view details

Paul Tavares

commit sha ad39997ae4c883cba23a0cd08509503f2b67b826

[Ingest] Add additional attributes to the Datasources Saved Object (#66127) * add additional properties to ingest-datasources SO * Adjusted Types and test generators * Added datasources migrations to SO * Add `user` object to calls to datasource.create()

view details

Spencer

commit sha e419ab90a3559f75763ab7bb4dfc7d1dd6ecc1e1

[uptime/usage-collector] add missing await (#66079)

view details

Nathan Reese

commit sha 1a43feb7b674b1b1a0cc12825e7c8f4fb810246b

[Maps] convert map_selectors to TS (#65905) * [Maps] convert map_selectors to TS * fix paths * one more path fix

view details

push time in 14 hours

push eventpmuellr/kibana

Marta Bondyra

commit sha 0d571ae129fde6d3baa7bd590cecb18aced2b648

[Lens] fix empty state for pie (#66206)

view details

Alison Goryachev

commit sha 42028502bf6cc05431748fb533552847d8f93942

[Snapshot Restore] Fix error when deleting snapshots behind reverse proxy (#66147)

view details

Nicolas Chaulet

commit sha 41fbd0f753cbdcb777d74d0f4d49f7173d97be5d

[Ingest] Support root level yaml variables in agent stream template (#66120)

view details

Justin Kambic

commit sha 66e1d32db659a067f35502f5ebcaf0a976edf651

Left-align certs column in monitor list. (#66045) Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Yulia Čech

commit sha fffe641e4a0e967a417e2ce021accbf2314f048b

[IM] Changes index mapping api response to plural form (#66012) * changes index mapping api response to plural form * changes tab title to "Mappings" in Index Management detail panel * updates index management jest snapshots for "Mappings" title

view details

Stacey Gammon

commit sha 6537b15d949ce913b323496ceb4f2cf5d1b487ae

add section on why to prefer async over sync accessor (#66284)

view details

Cauê Marcondes

commit sha ff1d1298138ec9730819b27a21749d77ebaf2142

Fixing jest when running it with --watchAll (#66384)

view details

Alejandro Fernández Haro

commit sha 9ab73efd186ff3dd5f7f7ee41d90a1ace0dd917c

Remove Newsfeed leftovers from the Legacy codebase (#66084)

view details

Dima Arnautov

commit sha 69d4199feb8a9f9ed65f974fe18641c9070fbdff

[ML] Fix vertical overflow on Single Metric Viewer page (#66413) * [ML] fix page overflow * [ML] fix tooltip overflow

view details

Dima Arnautov

commit sha d0b9840041d7566ff87e7dbd43511dfd7bce5a1d

[ML] API integration tests for job validation (#66265) * [ML] TS refactoring * [ML] fix page overflow * [ML] tests * [ML] fix typing issues and unit tests * [ML] remove string conversion * [ML] indexOf checks * [ML] fix tooltip overflow * [ML] fix i18n * [ML] fix unit tests * [ML] use MlJobAggregation * [ML] use enums * Revert "[ML] fix tooltip overflow" This reverts commit 103c36bc * Revert "[ML] fix page overflow" This reverts commit 3c869228

view details

Michail Yasonik

commit sha 7707cbde2174561f759333598631860ef6cadcfc

Fixes Recently Viewed links allowing them to close the nav when clicked (#66280)

view details

Michael Olorunnisola

commit sha cba2a6590169e801b956a1957a68b96a6d0ae7d8

Panning resize fix (#65924) * prevent animation when target is same as initial * fixed resolver resize trigger * explicitly set animation to undefined * updated tests for resize reference * make resize ref test a bit more explicit

view details

spalger

commit sha d9eae98524601cbb338c9f9e57875a25fbf9f601

skip flaky suite (#65949)

view details

Pierre Gayvallet

commit sha 2117ef1df2cbfdb71e710a383ddfc742146c5154

use individual route for each KP app (#65977) * use individual route for each KP app * cleanup

view details

spalger

commit sha 5f9c4704ac511f31674a14ca8f5471ba42e9b984

skip flaky suite (#65010)

view details

Chris Cowan

commit sha 9ab0ad16efc6244cb63489493dc0acede60d41d5

[Metrics UI] Fix validation for threshold values (#66281) * [Metrics UI] Fix validation for threshold values * removing unused dependency * cleaning up a bit * Fixing validation to set error message per threshold Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Chris Cowan

commit sha 2b4760525594359f0bab938b7ce542886c548e9f

[Metrics UI] Fixing chart label for ungrouped alerts (#66444)

view details

spalger

commit sha 6695b184f5c7453c66bf2d8ad51ea708049d04e7

skip flaky suite (#65948)

view details

Michail Yasonik

commit sha 77676adabaf5982f995647682cd7cb1f02224ecf

Adds max-height to recently viewed links (#66297)

view details

Jen Huang

commit sha 053150489a8f8c9f48aaaf29edf8899183f9d53d

[Ingest Manager] Remove Data sources link from integration details page (#66447) * Remove data sources tab * Localize menu links

view details

push time in 14 hours

issue commentelastic/kibana

Alert params and action config will merge sub attributes on update if not explicitly nulled

There's also a 6th option, which is likely the most work, adding support for non-partial updates to saved-objects.

Pretty sure you can already do overwrites w/saved objects - you just can't with ESO's, I believe because of the non-custom-key constraint. So I thought this was the same as option 1).

It's been a while since I looked into this though, I may be remembering wrong.

mikecote

comment created time in 18 hours

issue commentelastic/kibana

Ability to alert when there's been no data for x amount of time

The "no data for certain period of time" portion seems to be a common use case. They can always set it to 0 to fire actions immediately.

More knobs and dials! :-) The existing throttle should work fine with this alerting, but can't handle "ignoring" the condition if it was only for a short time frame - you'd always have the alert fire, at least once. Same with debounce - but presumably debounce would fire later than w/ a throttle.

Throttle / debounce don't feel right to me, a separate "no-data for XXX duration" does kinda feel right, just adds more complexity all around.

mikecote

comment created time in 19 hours

issue commentelastic/kibana

Ability to alert when there's been no data for x amount of time

Ya, my thinking was that if we have a "status" of no-data, then we should also allow a customer to set an alert when the alert is in that status.

I think the original thinking was that this would be at the alert level, and not instance alert level. For alerts that do some kind of query and get instance ids from the data in the query, alert level seems like it makes sense. Would certainly make sense for index threshold. There may be some alerts in the future that have instance id's which are more "fixed", or not determined by the query, and are more well-known in advance. An no-data at the alert instance level might make sense there.

Right now, we don't have a way for an alert executor to inform the framework about a no-data condition at the alert level. Seems like we'd have to add a new function to the services we pass into the executor:

https://github.com/elastic/kibana/blob/c9c37f77e6ad66a6a35b747436c7e9945aeff76a/x-pack/plugins/alerting/server/types.ts#L46-L48

Presumably, if that function was called, no other actions should be scheduled for that turn, before or after the function is called.

mikecote

comment created time in 19 hours

issue commentelastic/kibana

Alert flyout chart to be a bar chart?

Wondering if there are any other thoughts on how to create the bars. Naively, we could consider creating a bar at every interval. I think we show 30 intervals worth of time right now, so that would be 30 bars. We could change that to less or more intervals (I would guess less, like 20, might be more pleasing).

mikecote

comment created time in 19 hours

issue commentelastic/kibana

Alert params and action config will merge sub attributes on update if not explicitly nulled

  1. Change update to create w/ overwrite: true

I didn't realize this would break OCC, I didn't think it would. I thought all we really needed was ESO to support the overwrite option, which ended up requiring support for pre-defined IDs.

  1. Stringify the params and config in Elasticsearch

We are doing this somewhere else, aren't we? Or maybe we used to, but not anymore? This will make the "ability to search through alert/action params" even harder, but it's still not clear to me that we need ES search through the params. Or a precise one anyway - how well would a text search work through those? Maybe that would work good enough?

  1. Custom code to nullify sub attributes

This seems unpossible, since we don't really know the shapes of the params. Currently, we only require an object with a validate() function to be passed in, which is perfect for a config-schema object, but we don't require config-schema. Even if we had config-schema, not clear that we can enumerate the shape of the object from it. I think it probably only gets problematic for 2nd level objects - top level properties we could diff vs what's in ES, but if one of those properties is itself an object, is null in ES, and not null in the update, we don't have anything to compare to from the ES version.

  1. Change object structure to array

I think this would need to be surfaced all the way through our APIs, so breaks everything today :-). We'd need to come up with special per-alert-type migrations to convert existing alerts.

  1. Have clear documentation that optional properties must have default values

Yeah, if we do nothing else, adding more doc with big lettering is something we should do. Probably specifying that you can never use schema.maybe() for folks using config-schema.

Maybe there's a way to validate this programatically.

Not sure how introspective config-schema is, but this might work if we can analyze a schema. Alternatively, if there isn't enough introspection available for this, I wonder if we could add some new functionality to config-schema that would either check for undefined-able properties, or maybe an option on object that would disallow undefined-able properties.

mikecote

comment created time in 20 hours

Pull request review commentelastic/kibana

Changed actions API endpoints urls to follow Kibana STYLEGUIDE

 Table of Contents     - [Example](#example)   - [RESTful API](#restful-api)     - [`POST /api/action`: Create action](#post-apiaction-create-action)-    - [`DELETE /api/action/{id}`: Delete action](#delete-apiactionid-delete-action)-    - [`GET /api/action/_getAll`: Get all actions](#get-apiactiongetall-get-all-actions)-    - [`GET /api/action/{id}`: Get action](#get-apiactionid-get-action)-    - [`GET /api/action/types`: List action types](#get-apiactiontypes-list-action-types)-    - [`PUT /api/action/{id}`: Update action](#put-apiactionid-update-action)-    - [`POST /api/action/{id}/_execute`: Execute action](#post-apiactionidexecute-execute-action)+    - [`DELETE /api/actions/{id}`: Delete action](#delete-apiactionid-delete-action)+    - [`GET /api/actions`: Get all actions](#get-apiactiongetall-get-all-actions)+    - [`GET /api/actions/{id}`: Get action](#get-apiactionid-get-action)+    - [`GET /api/actions/list_action_types`: List action types](#get-apiactiontypes-list-action-types)

And what about CRUD operations for the event log - are we planning to expose the routes for this?

Realizing that in terms of http routes, there is only Read (Query) for event log :-)

And I think the event log query shape is likely to change. We'll probably want to be able to send a list of SO's by type/id ; and we will probably want to filter some documents. But TBD, and I don't think it should block getting alerting and action routes fixed up. So let's ignore the event log for now ...

YulNaumenko

comment created time in 6 days

push eventpmuellr/kbn-sample-plugins

Patrick Mueller

commit sha 77b19c7b6c26b49858c718313727c45050559969

add the el_constipation plugin

view details

push time in 6 days

pull request commentelastic/kibana

[Alerting] Hides the `action` and `action_task_params` SavedObjects types

I'm seeing the following after creating an index threshold alert with a server log action:

server    log   [11:11:26.245] [error][plugins][taskManager][taskManager] \
  Task actions:.server-log "558cef40-9b75-11ea-ab1d-417e80d785fc" failed: \ 
  Error: Saved object [action/fb3f2ab4-8862-46d7-a5d0-88fe948ddcd7] not found

<details> <summary>repro commands</summary>

export ACTION_ID=`kbn-action create .server-log 'server-log' '{}' '{}' | jq -r '.id'`

kbn-alert create .index-threshold 'es-apm-sys-sim threshold' 1s \
  '{
    index:               "es-apm-sys-sim", 
    timeField:           "@timestamp", 
    aggType:             "avg", 
    aggField:            "system.cpu.total.norm.pct",
    groupBy:             "top",
    termSize:            100,
    termField:           "host.name.keyword",
    timeWindowSize:      5, 
    timeWindowUnit:      "s", 
    thresholdComparator: ">", 
    threshold:           [0.8]
  }' \
  "[{ group: 'threshold met', id: '$ACTION_ID', params: {message: '{{context.message}}'}}]"

and assumes you're running es-apm-sys-sim 1 4 - https://github.com/pmuellr/es-apm-sys-sim#install </details>

gmmorris

comment created time in 6 days

Pull request review commentelastic/kibana

Changed actions API endpoints urls to follow Kibana STYLEGUIDE

 Table of Contents     - [Example](#example)   - [RESTful API](#restful-api)     - [`POST /api/action`: Create action](#post-apiaction-create-action)-    - [`DELETE /api/action/{id}`: Delete action](#delete-apiactionid-delete-action)-    - [`GET /api/action/_getAll`: Get all actions](#get-apiactiongetall-get-all-actions)-    - [`GET /api/action/{id}`: Get action](#get-apiactionid-get-action)-    - [`GET /api/action/types`: List action types](#get-apiactiontypes-list-action-types)-    - [`PUT /api/action/{id}`: Update action](#put-apiactionid-update-action)-    - [`POST /api/action/{id}/_execute`: Execute action](#post-apiactionidexecute-execute-action)+    - [`DELETE /api/actions/{id}`: Delete action](#delete-apiactionid-delete-action)+    - [`GET /api/actions`: Get all actions](#get-apiactiongetall-get-all-actions)+    - [`GET /api/actions/{id}`: Get action](#get-apiactionid-get-action)+    - [`GET /api/actions/list_action_types`: List action types](#get-apiactiontypes-list-action-types)

This still has a problem - if a customer creates a preconfigured action with id list_action_types.

I think we need to create a new path element - say action (but of course, that's not great), that we'd use for all the {id} CRUD operations. Here's some URIs that I think will work (current ones from PR on left, suggestions on the right):

POST   /api/actions                     -> POST   /api/actions/action
GET    /api/actions/{id}                -> GET    /api/actions/action/{id}
PUT    /api/actions/{id}                -> PUT    /api/actions/action/{id}
DELETE /api/actions/{id}                -> DELETE /api/actions/action/{id}
POST   /api/actions/{id}/_execute       -> POST   /api/actions/action/{id}/_execute
GET    /api/actions                     -> GET    /api/actions
GET    /api/actions/list_action_types   -> GET    /api/actions/list_action_types

If we end up having "preconfigured alerts", we may end up with the same (or very similar) problem. I wonder if we should look at all the URLs for alerts, actions, event log, (task manager?), and see if there is some common pattern we can apply to all of them.

YulNaumenko

comment created time in 6 days

Pull request review commentelastic/kibana

[Alerting] Hides the `action` and `action_task_params` SavedObjects types

 export class ActionsPlugin implements Plugin<Promise<PluginSetupContract>, Plugi       preconfiguredActions,     } = this; -    const encryptedSavedObjectsClient = plugins.encryptedSavedObjects.getClient();+    const encryptedSavedObjectsClient = plugins.encryptedSavedObjects.getClient({+      includedHiddenTypes,+    });+    const getScopedSavedObjectsClient = (request: KibanaRequest) =>

I believe this SO client is the one that we pass to action executor functions - do we want to specifically include the hidden types here? I'm not sure if this client is also used by the framework (ie, not just in the action executor), in which case it would, or we'd need separate ones.

gmmorris

comment created time in 6 days

issue commentelastic/kibana

Plz provide an example on how to use Index connector in alerting

hmmm ... the :Alerting label came back, after it was removed 2 days ago by Gidi ... with no comment about how it was added - must be some automated thing?

rasroh

comment created time in 7 days

issue commentelastic/kibana

UI ability to assign alert actions per action group

The Alert, No data and Resolved would be built-in groups, whereas Warning would be defined by the Alert type.

Only No data and Resolved are "built-in" groups. I assumed Alert was a defined group by the alert type, like Warning and Minor.

Or maybe I'm misunderstanding what the group Alert means ...

mikecote

comment created time in 7 days

Pull request review commentelastic/kibana

[Saved Objects] adds support for including hidden types in saved objects client

 export class AlertsClient {     alertId: string;     alertInstanceId: string;   }) {-    const { attributes, version } = await this.savedObjectsClient.get('alert', alertId);+    const { attributes, version } = await this.savedObjectsClient.get<Alert>('alert', alertId);

+1 :-)

gmmorris

comment created time in 8 days

push eventelastic/kibana

Patrick Mueller

commit sha 477ed19a4638dcc73c0ed8d36a1f6923e90d5ad3

[Alerting] fix labels and links in PagerDuty action ui and docs (#64032) (#66895) resolves #63222, resolves #63768, resolves #63223 ui changes: - adds an "(optional)" label after the API URL label - changes help link to go to alerting docs and not watcher docs - changes the label "Routing key" to "Integration key" to match other docs - changes the order of the severity options to match other docs doc changes: - changes the reference of "Routing key" to "Integration key" to match other docs - makes clearer that the API URL is optional

view details

push time in 8 days

PR merged elastic/kibana

[7.7] [Alerting] fix labels and links in PagerDuty action ui and docs (#64032) backport

Backports the following commits to 7.7:

  • [Alerting] fix labels and links in PagerDuty action ui and docs (#64032)
+14 -14

1 comment

2 changed files

pmuellr

pr closed time in 8 days

create barnchpmuellr/kbn-plugin-graph

branch : master

created branch time in 8 days

created repositorypmuellr/kbn-plugin-graph

generate elasticsearch documents describing kibana plugins

created time in 8 days

create barnchpmuellr/kibana

branch : backport/7.7/pr-64032

created branch time in 9 days

PR opened elastic/kibana

[7.7] [Alerting] fix labels and links in PagerDuty action ui and docs (#64032)

Backports the following commits to 7.7:

  • [Alerting] fix labels and links in PagerDuty action ui and docs (#64032)
+14 -14

0 comment

2 changed files

pr created time in 9 days

issue commentelastic/kibana

[Alerting] unexpected action type causes null dereference

Probably worth noting that this problem was observed during development, where a dev worked on one branch that had a new action type and created one, then switched to a branch that did not have the code for the new action type, but used the same ES instance. So, it's certainly something that can happen during normal development cycles as well.

pmuellr

comment created time in 12 days

issue openedelastic/kibana

[Alerting] unexpected action type causes null dereference

Repro:

  • run Kibana, create a new connector, any type
  • stop Kibana
  • comment out the registration of the action type of that connector here
  • restart Kibana
  • navigate to the connectors tab of the alerting management page

You'll see the following error in the browser console:

Uncaught TypeError: Cannot read property 'enabled' of undefined
    at render (actions_connectors_list.tsx:160)
    at EuiBasicTable.renderItemFieldDataCell (basic_table.js:923)
    at basic_table.js:780
    at Array.forEach (<anonymous>)
    at EuiBasicTable.renderItemRow (basic_table.js:774)
    at basic_table.js:713
    at Array.map (<anonymous>)
    at EuiBasicTable.renderTableBody (basic_table.js:710)
    at EuiBasicTable.renderTable (basic_table.js:464)
    at EuiBasicTable.render 

The problem seems to be here, as actionTypesIndex[item.actionTypeId] is null: https://github.com/elastic/kibana/blob/725472714933014677584d71ad76e855abda5fff/x-pack/plugins/triggers_actions_ui/public/application/sections/actions_connectors_list/components/actions_connectors_list.tsx#L158-L167

Even though the repro is contrived, this would model a situation where - for some reason - version X of Kibana had an action type that version >X did not have. Since action types can be registered by plugins, a non-contrived scenario would be that a plugin which registers an action type is enabled and a connector for that action type is created, then later that plugin is not enabled so the action type won't exist.

created time in 12 days

issue commentelastic/kibana

[Alerting] [Discuss] Modifying alert params within the executor as a migration tool

I've seen a few notes about future directions of saved object migrations, we should be sure we're aligned with that. This sort of migrate-when-needed is an interesting approach.

Also potentially relevant: https://github.com/elastic/kibana/issues/50213 - I think migrate-when-needed would imply we can't have mappings for alert params. But presumably if we did have mappings for alert params, then we'd be doing standard SO migrations at that point (in terms of when and how they happened).

Zacqary

comment created time in 12 days

issue commentelastic/kibana

UI ability to assign alert actions per action group

Depending on what statuses/conditions are added in the trigger section, if the user checks "Run actions when resolved", a dropdown will provide options for 'Resolved', 'Alerting -> Warning', or 'Major --> Minor'.

Technically, these are "action groups" - [alert, warning], [major, minor], where resolved may end up being a "free" action group you get (and maybe "no data") (eg, [alert, warning, resolved, no-data]. Of course, that's a terrible phrase; status is not a great one either maybe, as we want to have an alert-level thing called "status" which would indicate no-data, error, actively firing kind of info.

I'm not sure a toggle for "Run actions when resolved" makes sense as a toggle, if it's just another action group.

I'm assuming that 'Warning --> Resolved' or 'Alerting --> Resolved' are the same as simply 'Resolved'. Is this correct?

That was my understanding. There is only "resolved", we won't have "minor->resolved" and "major->resolved" as separate things. I think technically, we could, but not sure we need it, and it makes things more complicated, so I'd say at best we defer that (and open a new issue if we think we need that).

If an alert goes from Warning to Alert, will it simply run the actions that are associated with 'Alert'? Or do we also need to provide transitional actions here as well?

Likewise, my understanding is that we won't have transitional actions like that, so you'd only see the 'Alert' actions run in that case. And as before, we could, but it's just more stuff, so worthy of a new issue (probably one issue for this and the previous note ^^^).

mikecote

comment created time in 13 days

issue commentelastic/kibana

Using Saved Searches as input for creating Threshold Alerts

for Kibana Alerting, see: https://github.com/elastic/kibana/issues/61314

elasticmachine

comment created time in 13 days

issue commentelastic/kibana

[Watcher UI] Clone Watch

Kibana Alerting does not currently have a "copy" function in the UI, but it does seem like it would be fairly easy to implement. Could probably make a complete copy of the alert, but change the name by adding a suffix (Copy) to it or something.

elasticmachine

comment created time in 13 days

issue commentelastic/kibana

Filtering with alert creation

We'll also need to know the boolean operators at play here. We could go with ANDing all the filters, but beyond that, and perhaps an "OR all the filters", any combination of AND or OR may require grouping semantics within the filters (x AND (y OR z))

arisonl

comment created time in 13 days

issue commentelastic/kibana

Add organization structure to watcher

FWIW, Kibana Alerting exposes tags on the top-level alert objects, and you can filter them in the search bar of the alerts list. Seems like it's worked out well, but we'll see ...

It would be interesting to think about a view of the alert lists that had groupings based on the tags, I guess a depth=2 tree, one branch for every unique tag, an alert could be listed under multiple tags, the tag lists are collapsible.

Rukas

comment created time in 13 days

issue commentelastic/kibana

Filtering with alert creation

see also: https://github.com/elastic/kibana/issues/33931

arisonl

comment created time in 13 days

issue commentelastic/kibana

Trying to edit the action part to a trigger.

Given the name of the context variables, this seems like it must be related to Watcher vs Kibana Alerting.

wxyvk

comment created time in 13 days

issue commentelastic/kibana

User-specified maximum number of action triggers

The existing alerting throttle is not sufficient here? I'm not completely understanding why it doesn't, could the use case explain why it doesn't?

arisonl

comment created time in 13 days

issue commentelastic/kibana

Ability to bulk assign actions to alerts

So the customer has N existing alerts and they'd like to add a Slack action to each one. Adding actions is conceptually simple, if we assume they get added to the existing list of actions, which is probably fine. I'm assuming this is something a customer would do from a UI - I think doing this programmatically with the alertClient should be possible today.

The other more complicated bits. Actions are actually added to action groups, so presumably the action group would need to be specified on the bulk-action-add, which then implies that you can probably only do it for alerts of the same alertType. That might be fine.

What about updating/deleting them later? Bulk action update/delete?

I wonder if it makes sense to think about "reusable actions lists". First class objects (with a Saved Object) that is just a list of actions like you'd add to an alert. But you could then reference that object when creating an alert, and we'd run those actions. It's an additional level of richness, I worry about the complication it implies.

arisonl

comment created time in 13 days

issue commentelastic/kibana

Filtering with alert creation

Perhaps Top-N / Group by already handles the Per Alert use case, the filtering is definitely high value.

Yes, I believe the top-n grouping we already support handles the per-alert use case, and there's an issue open to allow multiple "nested" groupings - https://github.com/elastic/kibana/issues/66052

Seems like we need a new array of "filter" specs here. You'd pick a term, and a value, do we need a comparator there? In Stephen's example, it would be "log.level" "=" "ERROR". Do all the other comparators for the threshold value apply? Or maybe a subset, like = and !=. One difference is the threshold value is always numeric, would the filter values always be strings?

arisonl

comment created time in 13 days

issue commentelastic/kibana

Schedule-based muting of alerts

Is there another solution that's doing anything calendar-related like this? I'm thinking there is, but not sure which one.

I wonder if this will be simpler with cron support? Can these schedules be specified easily as cron expressions (guessing not, but worth poking at a bit more?)

I think there's an implication that you'd be setting a schedule on multiple alerts, and perhaps these scheduled mutes should be searchable/sortable for UI purposes.

Could there be multiple mute schedules for an alert? Can a single mute schedule include multiple date ranges?

Do we need support at the instance level, or is at the alert level good enough?

I wonder if we can fit this into the current schedule property? Eg, as a peer of interval, named muted? https://github.com/elastic/kibana/blob/e2c471b9e501db9d15b9c739a0f3fe3095619ee1/x-pack/plugins/alerting/server/saved_objects/mappings.json#L21-L27

arisonl

comment created time in 13 days

issue commentelastic/kibana

Nested grouping-over

This presumably for the built-in index threshold? I don't think there's anything alert-generic about this request, but not entirely sure. And if the question is about an existing alert besides the index threshold alert, we'll want an issue for that alert as well (eg, an observability-provided alert).

I think the implication is that we can have multiple top-N groups in the search spec that gets built, where we have a single one today. It seems like it should be a limited grouping (using the same sort of top-N limit), to keep the ES query less expensive (in the worst case).

This will likely be a usefulness blocker: https://github.com/elastic/kibana/issues/64268 - the instanceIds for an alert with N groups will be something like group1-group2-...-groupN, so we'll want human-readable versions of those for the UI.

We'll have to think about how to represent the group data in the context here - I guess it will need to be an array of groups, where we have a single group today.

arisonl

comment created time in 13 days

pull request commentelastic/kibana

[Alerting] refactor action whitelisting functions

I'm not in love with the name runtimeValidate either. I considered using config in it somewhere, as the extra parameter we send is (whitelisting utiltities) is all config based, but ... who knows, we may have some other "dynamic" thing later we want in here, that isn't config based.

executionValidate isn't quite right either, as we do call this when creating/updating actions as well as executing them.

The way these properties are paralleled looks a bit off to me, but I think it makes for a pretty nice story in the end, for action implementors. Basically, the validate properties can be config-schema objects, and the runtimeValidateproperties are functions that take the TS type of the config-schema as a parameter. So, there's no real need to add a top-level validate() function on your schema (as we used to), since the body of that can go in runtimeValidate(). The odd thing about the schema-config validate() is that even though you are getting a "validated" object which should match the TS type, it can't be declared that way because it creates a circular reference, eg https://github.com/elastic/kibana/blob/7707cbde2174561f759333598631860ef6cadcfc/x-pack/plugins/actions/server/builtin_action_types/email.ts#L98-L100

We can't remove params and config from validate and only have them in runtimeValidate, because we need validate to do the basic structure checking. runtimeValidate assumes it's parameter is an already validated object.

I tried a few things to see if we could keep one structure (instead of having two), and somehow provide an augmentation of a schema-config object as a parameter instead of schema-config itself, and then know we can do special processing on it (the runtimeValidate processing). I may take another go at that, but I kept having to resort to instanceof sniffing, which never makes me very happy.

I was also considering adding new schema for the whitelisting support - you'd do something like schema.whitelistedURL() instead of schema.string() and a whitelisting validation somewhere else. Not sure how that would work tho - somehow the validation for that property would need access to the whitelisting utilities, based off the current config. And it would be mucking with the innards of schema-object, which sounds like it could be fragile.

pmuellr

comment created time in 14 days

issue commentelastic/kibana

Make alert params and action config searchable

I'm worried about any solution that introduces new mappings for alertType-specific data, due to all the challenges pointed out ^^^.

It's not completely clear that we need an ES solution here; from the SIEM issue https://github.com/elastic/kibana/issues/50222:

Either that or a plain API (even if slower like a table scan) to abstract us away so we can natively to the actions/alerting objects would make it to where we don't have write our own hand rolled solutions.

I read "table scan" as "do as much of a query as you can with ES, then do the remaining filtering/mapping/aggs on the results in JS". That will work if the number of alerts is "reasonable", which I don't know if it is.

I think we should also find out if having an "internal tags" via https://github.com/elastic/kibana/issues/58417 would be good enough for now. This would presumably be a parallel of the current tags structure, but not editable (or probably viewable) in the UI, only programmatically. Not nearly the same as ES fields, but may be useful enough for common needs.

There was also mention of scripted fields in the discussion above, but I'm not sure how we might use them.

mikecote

comment created time in 14 days

PR opened elastic/kibana

[Alerting] use event log to populate alert details view

resolves https://github.com/elastic/kibana/issues/57446

Checklist

Delete any items that are not applicable to this PR.

For maintainers

+28 -1

0 comment

2 changed files

pr created time in 14 days

create barnchpmuellr/kibana

branch : alerting/details-via-el

created branch time in 14 days

pull request commentelastic/kibana

[Alerting] refactor action whitelisting functions

I have a first pass of the refactoring of the action whitelist validation in commit caeca99c82eed90beb53126c476d93f7fcd96c36 - not finished yet, but the email action has been converted to use new validationService to do the whitelisting, instead of the old way we used to do it. The other actions will also need to be changed, but figured I'd just do that one first, make sure this is headed in the right direction.

I ended up making the config, secrets and params types as generic params on action type, which should help to prevent folks from creating invalid validators/schemas due to the previous untyped access for those. Especially since I've added new runtimeValidate: { config, secrets, params } functions to ActionType, which are purpose-built for whitelisting, or any other validation needs we can provide to action authors in the future.

Why validate.config AND runtimeValidate.config (and secrets, and params)? The validate properties still expect an object which has a validate() function, which config-schema provides. So you can continue to just pass a config-schema Schema object to those. Very simple. The new runtimeValidate properties are a little different in that they expect the typed config/secrets/params object, and are also passed a validationService object, which today just contains some whitelisting utilities. One thing that is pretty nice is that instead of adding a validate option to your top-level schema (if you need one), you can move that to runtimeValidate instead, and get the signature typed. The config-schema validate() function also expects a validated object as a param, but it's impossible to get the typing on that AFAIK because of circular references. That doesn't happen with runtimeValidate.

The generic typing of the config, secrets, and params is opt-in at present, as it defaults to <any, any, any>. If we want to be stricter by changing that to either void or maybe never, I think we'll need to change all the internal code to type internal uses as <any, any, any>. There's little value in doing that, as the types don't have any value for the internal code - it's really just useful for action authors to make sure they've defined their actionTypes correctly. We can look into that later ...

pmuellr

comment created time in 15 days

PR opened elastic/kibana

[Alerting] refactor action whitelisting functions

resolves https://github.com/elastic/kibana/issues/64659

In this PR, the action whitelisting utilities have been refactored to allow them to (eventually) be used in plugins other than the actions plugin. Prior to this, actions required deeper integration with the internal of the actions plugin.

This also adds some generic typing to the actionType config, secrets, and params properties, since they are now referred to in multiple places within the actionType.

For maintainers

+308 -238

0 comment

19 changed files

pr created time in 15 days

create barnchpmuellr/kibana

branch : alerting/validators-whitelist-2

created branch time in 15 days

Pull request review commentelastic/kibana

[Alerting] Adds lazy loading to AlertType and Flyout components

 export { AlertsContextProvider } from './application/context/alerts_context'; export { ActionsConnectorsContextProvider } from './application/context/actions_connectors_context'; export { AlertAdd } from './application/sections/alert_form'; export { ActionForm } from './application/sections/action_connector_form';-export { AlertAction, Alert, AlertTypeModel, ActionType } from './types';+export {+  AlertAction,+  Alert,+  AlertTypeModel,+  AlertTypeParamsExpressionProps,

AlertTypeParamsExpressionProps doesn't seem to be referenced in this module. I assume you would have gotten a lint error on this

gmmorris

comment created time in 15 days

issue commentelastic/kibana

[Alerting][Discuss] allow alerts to create default action parameters

My current thinking on this is to allow alerts (and eventually other objects) to provide a "action parameter provider" object ... somehow. Probably an object passed when scheduling actions, but ... not sure.

The basic idea is that the action parameter provider would look something like this:

interface ActionParameterProvider {
   getParameter(name: string, type: string): any;
}

The email action would call this object twice:

    message = paramProvider.getParameter('message', 'markdown')
    subject = paramProvider.getParameter('title', 'markdown')

The slack action would call this object once:

    message = paramProvider.getParameter('message', 'slack')

We'd have a list of "common parameter values" like message and title, and the action would be responsible for asking for the correct name for the parameter it was getting a value for.

Likewise, we'd have a set of "formats" like 'markdown', 'slack', which alerts could use for very specific formatting requirements.

It seems like this sort of interface would work, I worry about when we actually call it, to ensure the alert can provide the appropriate data - and I think that would be when it schedules actions.

Alternatively, instead of deal with callbacks, we could have an alert create the appropriate formatted objects for all formats ahead of time, before scheduling the actions. We could also have figure out all the types that would be needed, based on actions to be executed, and pass those formats to the alert, so it would know what formats it should generate data for.

Lastly, we'll need a way to allow customers to specify they want to use these default parameters, instead of customizing them, themselves. We'd probably like customers to use the defaults when available, so at a UI level we might not even provide an action parameter form, unless the user specified they wanted to "customize the action parameters" (for actions whose parameters can all be provided as defaults).

At an API level, we could probably get away with allowing null/undefined as the value, indicating that the alert default should be used, as I think currently these sorts of parameters do not allow null/undefined values.

pmuellr

comment created time in 16 days

issue openedelastic/kibana

[Alerting][Discuss] allow alerts to create default action parameters

Currently, when creating an alert and adding actions to it, a customer will have to fill in all the action parameters manually. We've tried making this a little easier with the index threshold alert, by having that alert create two context variables message and title, which can be used as the message and subject for an email action, and message for a slack action. The user can then enter {{context.message}} for the message body in the action form, or click on the menu item for it in the context variables associated with the field.

It would be nicer to make this even easier. Why require the customer to do anything, if they want to use a default message provided by the alert?

Some additional considerations:

  • if we want the message to have formatting specific to the action, then somehow the message will have to know what formatting type the action takes - for email, the message should be in markdown, and for slack, the message should be in slack-flavored-markdown.

  • some action parameters like documents in the index action aren't strings, but JSON-able objects; is that just another "format type" like markdown/slack?

  • at some point, we'll probably want to have message itself be a set of messages - eg, you want to create a GH issue with one action, then send an email in a second action. The email should include a link to the GH issue created. Presumably the GH action will be able to create a formatted piece of text that can be added to the action body, presumably after the main message body for the alert. We've also talked about having "fixed" message snippets at the beginning and/or end of the messages - eg, allow for some kind of legal prefix message for compliance requirements, allow a suffix message that includes a link to the alert details page, etc. I don't think anything with this necessarily impacts having alerts create default action parameters, but would be good to keep in mind while developing this.

created time in 16 days

issue commentelastic/kibana

Alert instances view to display data from event log instead of current instances

I'd be happy to pair with someone on this; I'm very familiar with the event log :-)

mikecote

comment created time in 16 days

push eventpmuellr/kibana

Patrick Mueller

commit sha 0d5f453b9af6ea223b11ca20d7166fc2dd8d3439

[Alerting] explicitly pass config utils to action validators resolves https://github.com/elastic/kibana/issues/64659 Previously, for action validators that needed to perform whitelisting checks, they would need to curry in the config utilties providing the whitelisting functions, into their validators. This is unwieldy - the config utilities should be passed explicitly in.

view details

push time in 18 days

create barnchpmuellr/kibana

branch : alerting/validators-whitelist

created branch time in 18 days

issue commentelastic/kibana

Make alert params and action config searchable

Also see this issue: Request for alerting internal tags structure. The gist is to add a new "tags" property to alerts, but would be separate from the existing tags property, which is used by customers. Let's call this new tags property internalTags. It's meant to be used by alert implementors to add their own tags, for whatever purpose they want, without conflicting with the tags customers use or having the customers see them in the UI.

Would having this be good enough to solve the requirements? I think it depends on how/what you want to search on.

I don't really want to go down the path of adding mappings for alertType-specific data, seems like the migration problem would be ... messy. And not sure what the other options are.

mikecote

comment created time in 19 days

Pull request review commentelastic/kibana

Allow registered alert types to be non-editable

 describe('alert_form', () => {       return { errors: {} };     },     alertParamsExpression: () => <Fragment />,+    isEditable: true,+    consumer: 'alerting',

I didn't notice tests that had a consumer that wasn't 'alerting', though maybe I missed it, or it's essentially done elsewhere (in app-specific tests). If there isn't already a test like that, I think we should add one.

YulNaumenko

comment created time in 19 days

Pull request review commentelastic/kibana

Allow registered alert types to be non-editable

 export interface AlertTypeModel {   iconClass: string;   validate: (alertParams: any) => ValidationResult;   alertParamsExpression: React.FunctionComponent<any>;+  isEditable: boolean;+  consumer: string;

The problem with having this in the alertType, is that we already have a "consumer" in the alert itself, on the back-end, I think we may have some confusion using the same name for different things:

https://github.com/elastic/kibana/blob/3a6c1ceeddfb51efed5cff163599ab17bcf78701/x-pack/plugins/alerting/common/alert.ts#L22-L29

They are very similar concepts though. I wonder if we should call this uiConsumer or something?

Also, wondering if this should actually be a new property on the back-end alertType. I don't think it's needed there, but wondering if it makes more sense to put as many alertType properties like this in one place. Probably doesn't matter, since I don't know what we'd use it for in the alertType in the back-end.

YulNaumenko

comment created time in 19 days

Pull request review commentelastic/kibana

Allow registered alert types to be non-editable

 describe('alert_form', () => {     actionParamsFields: null,   }; +  const alertTypeNonEditable = {+    id: 'non-edit-alert-type',+    iconClass: 'test',+    name: 'non edit alert',+    validate: (): ValidationResult => {+      return { errors: {} };+    },+    alertParamsExpression: () => <Fragment />,+    isEditable: false,

this is a good test, as it's a not-expected case. I'd expect that any alertType with consumer alerting would be a built-in alertType, and this should be editable. So I'd expect that you can't ever create the alert, nor could you edit it even if it somehow did get created (eg, via curl). Basically, an alertType that can never be used, except via API. Maybe that's kinda interesting!?!? In any case, nice to have a test for it.

YulNaumenko

comment created time in 19 days

PR merged elastic/kibana

[7.8] [Alerting] changes preconfigured actions config from array to object (#65397) backport

Backports the following commits to 7.8:

  • [Alerting] changes preconfigured actions config from array to object (#65397)
+121 -76

1 comment

8 changed files

pmuellr

pr closed time in 19 days

push eventelastic/kibana

Patrick Mueller

commit sha 667406a268f8f659cc0f55d51bcee6fca39d720c

[Alerting] changes preconfigured actions config from array to object (#65397) (#65759) resolves https://github.com/elastic/kibana/issues/63171 Previously, preconfigured actions were specified as an array of action properties. This ended up being problematic when using the kibana keystore for secrets, as you'd have to reference specific actions via index. This changes preconfigured actions to be specified as an object, where the property key is the id, and the body is the remainder of the action properties. As access to preconfigured actions has leaked across the code base, it's probably time to consider changing the internal representation from an array to a Map, to provide easier access by action id. For a future PR. # Conflicts: # docs/user/alerting/action-types/email.asciidoc # docs/user/alerting/action-types/index.asciidoc # docs/user/alerting/action-types/pagerduty.asciidoc # docs/user/alerting/action-types/server-log.asciidoc # docs/user/alerting/action-types/slack.asciidoc # docs/user/alerting/action-types/webhook.asciidoc # docs/user/alerting/pre-configured-connectors.asciidoc

view details

push time in 19 days

push eventelastic/kibana

Patrick Mueller

commit sha ddb3e6d2aba9c0ed8c4ea3acd52340e11e9604ed

[Alerting] changes preconfigured actions config from array to object (#65397) (#65756) resolves https://github.com/elastic/kibana/issues/63171 Previously, preconfigured actions were specified as an array of action properties. This ended up being problematic when using the kibana keystore for secrets, as you'd have to reference specific actions via index. This changes preconfigured actions to be specified as an object, where the property key is the id, and the body is the remainder of the action properties. As access to preconfigured actions has leaked across the code base, it's probably time to consider changing the internal representation from an array to a Map, to provide easier access by action id. For a future PR.

view details

push time in 19 days

PR merged elastic/kibana

[7.x] [Alerting] changes preconfigured actions config from array to object (#65397) backport

Backports the following commits to 7.x:

  • [Alerting] changes preconfigured actions config from array to object (#65397)
+166 -121

1 comment

14 changed files

pmuellr

pr closed time in 19 days

create barnchpmuellr/kibana

branch : backport/7.8/pr-65397

created branch time in 20 days

create barnchpmuellr/kibana

branch : backport/7.x/pr-65397

created branch time in 20 days

PR opened elastic/kibana

[7.x] [Alerting] changes preconfigured actions config from array to object (#65397)

Backports the following commits to 7.x:

  • [Alerting] changes preconfigured actions config from array to object (#65397)
+166 -121

0 comment

14 changed files

pr created time in 20 days

push eventelastic/kibana

Patrick Mueller

commit sha 39427f5ed3362bd4eee4a3414c3a84160aa317a8

[Alerting] changes preconfigured actions config from array to object (#65397) resolves https://github.com/elastic/kibana/issues/63171 Previously, preconfigured actions were specified as an array of action properties. This ended up being problematic when using the kibana keystore for secrets, as you'd have to reference specific actions via index. This changes preconfigured actions to be specified as an object, where the property key is the id, and the body is the remainder of the action properties. As access to preconfigured actions has leaked across the code base, it's probably time to consider changing the internal representation from an array to a Map, to provide easier access by action id. For a future PR.

view details

push time in 20 days

PR merged elastic/kibana

[Alerting] changes preconfigured actions config from array to object Feature:Alerting Team:Alerting Services release_note:skip v7.8.0 v7.9.0 v8.0.0

resolves https://github.com/elastic/kibana/issues/63171

Previously, preconfigured actions were specified as an array of action properties. This ended up being problematic when using the kibana keystore for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's probably time to consider changing the internal representation from an array to a Map, to provide easier access by action id. For a future PR.

Checklist

Delete any items that are not applicable to this PR.

For maintainers

+166 -121

3 comments

14 changed files

pmuellr

pr closed time in 20 days

issue closedelastic/kibana

Pre-configured connectors not easy to configure in kibana.yml

The xpack.actions.preconfigured kibana.yml configuration currently accepts an array of objects but doesn't make it easy to configure in YML. Using for example a collection, it would be more natural to configure like the following example:

xpack.actions.preconfigured:
  - foo:
    name: Foo
    actionTypeId: .server-log
    config:
      param1: test

closed time in 20 days

mikecote

pull request commentelastic/kibana

[Alerting] changes preconfigured actions config from array to object

docs updated in commit https://github.com/elastic/kibana/pull/65397/commits/7134f4f70ba9562e4f750e22f32abe7ace3e9930

pmuellr

comment created time in 20 days

push eventpmuellr/kibana

Patrick Mueller

commit sha 7134f4f70ba9562e4f750e22f32abe7ace3e9930

update docs

view details

push time in 20 days

issue commentelastic/kibana

Creating an alert with multiple indices and selecting a time field

I struggle with these field pickers - mainly with the index action. For testing, I often want to create a new index via the action, which works, but then I can't provide a time field, since the index doesn't exist and so there are no fields to pick. So, ideally, I'd like a editable combo box listing "existing fields", but also allow me to enter a new one myself.

In that vein, I'm not sure listing fields as a union across all indices is wrong. But could certainly be confusing. In this case with the index threshold, documents in an index that doesn't have the time field would be ignored. Which definitely seems wrong, or at least worth warning the user about.

Also, I'd guess my issues with dealing with non-existent indices isn't a problem a customer is going to see. So more weight on providing the intersection of the fields vs union.

Presumably this also applies to the field picker for the aggregation fn's (avg, max, etc) and the "top-n" aggregation field. The top-n one may be interesting, if the agg ended up returning a bucket for "null" entries for the field - not sure if it does or not. But the aggregation fn's are like the timestamp - if an index didn't have that field, I think all the docs in the index would be ignored.

We'll have to look into the API we're using to get this info - perhaps there's an option to get the intersection vs the union, if that's what's happening ...

mdefazio

comment created time in 20 days

push eventpmuellr/kibana

Nicolas Chaulet

commit sha f5d6466f89b1bdd5b112bb368635924b131ef2b6

[Fleet] Fix display of local_metadata (#65260)

view details

Dmitry Lemeshko

commit sha ce06d37ce0c072504c6ef5cd3f12bf82c63fc685

[test/functional] page objects cleanup (#64891) * move point series functions to POs * remove unused monitoring_page Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Nicolas Chaulet

commit sha 9a0b7dde516a058bf2be2d1743f6cf1aafbaca90

[Fleet] Redirect user to fleet setup in enrollment flyout (#65265)

view details

Søren Louv-Jansen

commit sha e02350cdc7d3e6071b262bc73ba2a3a6187fd96b

[APM] Update path to APM app after move to NP (#65034)

view details

Tyler Smalley

commit sha f26292e0a2c589909ba09ecfee61d33f76f14bae

Revert "[SIEM] Adds 'Configure connector' Cypress test (#64807)" (#65297) This reverts commit 5c2fb4ce386ccba823d6b2b7e834ff9443c180e2.

view details

Tyler Smalley

commit sha df1874756fb403ae2343330f80564411d9460679

Disallows commonjs in new platform public (#65218) Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>

view details

Pierre Gayvallet

commit sha 4330865a6ca67e9e9802b3833307e680091c0621

Hide chrome until an app is mounting or mounted to avoid FOC on chromeless apps (#65036) * hidden chrome until an application is mounted * emits currentAppId$ before executing mount handler * address comments

view details

Chris Cowan

commit sha 0b202dc5dd236d6cc581a1c75b90e311ea4175a0

[Metrics UI] Add 99th and 95th percentiles to Metric Explorer (#64699) * [Metrics UI] Add 99th and 95th percentiles to Metric Exploer Aggregations * Removing unused dependency; fixing types

view details

Shahzad

commit sha db914a8986c88e1c10ed3a2811e281e96354fa30

[Uptime] Move status filter to monitor list (#65049)

view details

Marco Vettorello

commit sha 49289785570b176333908f247cbcc977f3364941

update elastic/charts to 19.2.0 (#65279)

view details

dependabot[bot]

commit sha 23282a2f372243530c51935819dfaa8b67240981

Bump jquery from 3.4.1 to 3.5.0 (#64884)

view details

Aleh Zasypkin

commit sha af8f9fa05f0fb3c773d3f27d2269b4c635c849c9

Change default icon for the `Log in with Elasticsearch` login selector button. (#65282)

view details

Dario Gieselaar

commit sha 399eed77bb591bbb5fce9799dc4798fd29561f64

[APM] Annotations API (#64796)

view details

Mikhail Shustov

commit sha 52a232f40b61dbe24c722c4154e9702ee5bef486

load react component lazily to reduce entry bundle (#65267) * load react component lazily to reduce entry bundle * address comments

view details

Brian Seeders

commit sha 283b61b1d8a64d7c6fcf8a380f28643aa6d462a0

Increase verify es job timeout to 2.5 hours (#65313)

view details

Chris Cowan

commit sha 7d5aa80976cf8d55d570a042877b5479eae799dc

[Metrics UI] Migrating Docker network fields (#65133)

view details

Shahzad

commit sha c2422c9fce05886e268460eab3b34cc1ea7cf9cd

[Uptime] Remove legacy uptime from path labeler (#65054)

view details

Lisa Cawley

commit sha 415d33b756d7ad280c3ae054c9caa734bbbe27f3

[ML] Edits create anomaly job intro text (#64607) * Edits create anomaly job intro text * [DOCS] More edits * [DOCS] Removes obsolete translations * [DOCS] Addresses feedback * [DOCS] Update create job breadcrumb Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Nathan Reese

commit sha 891e27eb1f654889ad02703003e7b6e0ff3116e1

[Maps] observability real user monitoring solution layer (#64949) * [Maps] observability real user monitoring solution layer * make stateful component * rename RUM to observability * layer select * metrics select * display select * clean up * create cholopleth map layer descriptor * get styling working * fix unique count agg * create geo grid source * render as heatmap * clusters * tslint errors * last tslint fix * only show card when APM index exists * layer label * clean up * fix getLayerWizards * add parans * review feedback * add cluster labels * use green to red ramp * tslint fix Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

view details

Tim Sullivan

commit sha 76d8ffe0cd218a44c96ca7e96fe5f1d8c462d63a

[Reporting] Convert test code to Typescript (#65155) * convert tests to typescript * comment note * add type for api integration test * fix import

view details

push time in 20 days

push eventpmuellr/kibana

Patrick Mueller

commit sha d6353cae8f1198fa187aaec36270cae63fef0a09

add comments to validation

view details

push time in 21 days

push eventpmuellr/kibana

Patrick Mueller

commit sha a70b270573584cd7db77b187feaf26b950d3606f

add dubious test for preconfigured action __proto__

view details

push time in 21 days

issue commentelastic/kibana

Ability to select a slack channel or person at execution time

So the alert will have an "address" (email to: / slack channel/user) available it can provide in the context that gets passed to actions? Or would those "addresses" be available somewhere else?

I'm wondering if the case integrations might have some interesting data like that, which could be passed as context to action parameters.

mikecote

comment created time in 21 days

push eventpmuellr/kibana

Patrick Mueller

commit sha a0cb334df55da761a929b1185c16ddcd8f8329cf

fix function tests

view details

push time in 21 days

PR opened elastic/kibana

[Alerting] changes preconfigured actions config from array to object

resolves https://github.com/elastic/kibana/issues/63171

Previously, preconfigured actions were specified as an array of action properties. This ended up being problematic when using the kibana keystore for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's probably time to consider changing the internal representation from an array to a Map, to provide easier access by action id. For a future PR.

Checklist

Delete any items that are not applicable to this PR.

For maintainers

+44 -37

0 comment

4 changed files

pr created time in 21 days

create barnchpmuellr/kibana

branch : alerting/preconfigured-by-id

created branch time in 21 days

IssuesEvent

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 A message indicates that this is a preconfigured connector.  [role="screenshot"] image::images/pre-configured-connectors-view-screen.png[Pre-configured connector view details]++If preconfigured connector belong to the preconfigured action type, it is disabled for the details preview.

I don't think it matters if the connector is a preconfigured action type. All preconfigured connectors have their details preview disabled. So I think this can be shorted to:

The connector details preview is disabled for preconfigured connectors.

YulNaumenko

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 A message indicates that this is a preconfigured connector.  [role="screenshot"] image::images/pre-configured-connectors-view-screen.png[Pre-configured connector view details]++If preconfigured connector belong to the preconfigured action type, it is disabled for the details preview.++[role="screenshot"]+image::images/pre-configured-action-type-managing.png[Connectors managing tab with pre-cofigured]+++[float]+[[managing-pre-configured-action-types]]+=== Managing preconfigured action types++Clicking *Create connector* shows the list of available action types.+Preconfigured action types are not included because you can't create a connector with a preconfigured action type.

I believe the action types aren't included in the list if they are disabled via config, so I think this can be simplified:

Disabled action types are not included.

YulNaumenko

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 [role="xpack"]-[[pre-configured-connectors]]+[[pre-configured-action-types-and-connectors]] -== Preconfigured connectors+== Preconfigured action types and connectors -You can preconfigure an action connector to have all the information it needs prior to startup+You can preconfigure an action type or just a connector to have all the information it needs prior to startup by adding it to the `kibana.yml` file.-Sensitive configuration information, such as credentials, can use the {kib} keystore.  Preconfigured connectors offer the following capabilities: -- Require no setup. Configuration and credentials needed to execute an-action are predefined, including the connector name and ID.+- Requires no setup. Configuration and credentials needed to execute an+action are predefined, including the connectors name and ID.

s/connectors/connector's/

YulNaumenko

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 [role="xpack"]-[[pre-configured-connectors]]+[[pre-configured-action-types-and-connectors]] -== Preconfigured connectors+== Preconfigured action types and connectors -You can preconfigure an action connector to have all the information it needs prior to startup+You can preconfigure an action type or just a connector to have all the information it needs prior to startup by adding it to the `kibana.yml` file.-Sensitive configuration information, such as credentials, can use the {kib} keystore.  Preconfigured connectors offer the following capabilities: -- Require no setup. Configuration and credentials needed to execute an-action are predefined, including the connector name and ID.+- Requires no setup. Configuration and credentials needed to execute an+action are predefined, including the connectors name and ID. - Appear in all spaces because they are not saved objects. - Cannot be edited or deleted. +Sensitive configuration information, such as credentials, can use the <<creating-keystore, {kib} keystore>>.++A preconfigured action types has only preconfigured connectors. But preconfigured connectors could belong to the preconfigured action type or to the regular action type as well.+ [float] [[preconfigured-connector-example]]-=== Example of a preconfigured connector+=== Creating a preconfigured connector -The following example shows a valid configuration 2 out-of-the box connector.+The following example shows a valid configuration 2 out-of-the box connectors: <<slack-action-type, Slack>> and <<webhook-action-type, Webhook>>.

change "2" to "of two" or "of 2"

YulNaumenko

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 see https://www.elastic.co/subscriptions[the subscription page]. === Preconfigured connectors and action types  You can create connectors for actions in <<managing-alerts-and-actions, Alerts and Actions>> or via the action API.-For out-of-the-box and standardized connectors, you can <<pre-configured-connectors, preconfigure connectors>>-before {kib} starts.--Action type with only preconfigured connectors could be specified as a <<pre-configured-action-types, preconfigured action type>>.+For out-of-the-box and standardized connectors, you can <<preconfigured-connector-example, preconfigure connectors>>

The last part of the sentence, starting with "or define action type ..." feels ... complex. I think we can just remove it, and keep the original text:

For out-of-the-box and standardized connectors, you can <<preconfigured-connector-example, preconfigure connectors>> before {kib} starts.

YulNaumenko

comment created time in 22 days

issue commentelastic/kibana

Pre-configured connectors not easy to configure in kibana.yml

Re-opening this, as we found that the structure for these doesn't work great when you want to configure the keys in the kibana keystore; you have to reference the secrets with the index they are in the array, like so:

node src/cli_keystore add xpack.actions.preconfigured[4].secrets.password

(note, customers would use bin/kibana-keystore, but that doesn't work in dev envs, you need to use node src/cli_keystore instead)

Going to look to see how changing the structure so it's an object with action ids as they keys works out. That should allow you to do something like the following, where mySlack is the id of a pre-configured slack action:

node src/cli_keystore add xpack.actions.preconfigured.mySlack.secrets.password
mikecote

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 action are predefined, including the connector name and ID. [[preconfigured-connector-example]] === Example of a preconfigured connector -The following example shows a valid configuration 2 out-of-the box connector.+The following example shows a valid configuration 2 out-of-the box connectors: <<slack-action-type, Slack>> and <<webhook-action-type, Webhook>>.+You can find all details about available action types configuration <<action-types, here>>

Needs a period . at the end.

YulNaumenko

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 Username::  username for 'login' type authentication. Password::  password for 'login' type authentication.  [float]+[[Preconfigured-email-configuration]]+==== Preconfigured action type properties: ++[source,text]+--+ id: 'my-email'+ name: preconfigured-email-action-type+ actionTypeId: .email+ config:+   sender: testsender@test.com+   host: validhostname+   port: 8080+   secure: false+ secrets:+   user: testuser+   password: passwordkeystorevalue+--++`config:` define action type specific to the configuration. Index `config:` consists from the next sub properties:

The second sentence ("Index config: consists from the next sub properties:") is repeated for each of the action types, and doesn't feel like it flows correctly to me. I'd suggest. "The config object contains the following properties:"

YulNaumenko

comment created time in 22 days

Pull request review commentelastic/kibana

Extended alerting documentation with information about using Kibana keystore and action types for preconfigured connectors

 Username::  username for 'login' type authentication. Password::  password for 'login' type authentication.  [float]+[[Preconfigured-email-configuration]]+==== Preconfigured action type properties: ++[source,text]+--+ id: 'my-email'+ name: preconfigured-email-action-type+ actionTypeId: .email+ config:+   sender: testsender@test.com

The config property is from, not sender.

YulNaumenko

comment created time in 22 days

pull request commentelastic/kibana

[7.x] [Alerting] Alert Details and Alert List design improvements (#64839)

jenkins retest this please

andreadelrio

comment created time in 22 days

push eventandreadelrio/kibana

Patrick Mueller

commit sha ed9f2c490aefbf68ecfb20c0924e6197632a25ec

fix more function tests

view details

push time in 22 days

push eventandreadelrio/kibana

Patrick Mueller

commit sha 0ba71ecdb6b545bdb0110c3dae8de68260e86368

fix function tests

view details

push time in 22 days

push eventelastic/kibana

Patrick Mueller

commit sha 29658bd908dc0aed344a3b1524db245936050be7

[Alerting] only show trial upgrade when running with basic license (#64865) (#65138) resolves https://github.com/elastic/kibana/issues/64245 Prior to this PR, the "Upgrade your license" banner in the connectors list was displayed for gold licenses because the Service Now action requires platinum, and the check only looked for any actions disabled by license. Rather than display a different message for gold users, this PR changes the banner display logic to check for any actions disabled by license that also have a minimum required license of gold. That means gold+ users won't see the message, even for actions with a minimum required license of platinum+. Another perk of the gold license! This will continue to display the banner for basic users, but will no longer display it for gold users. It also continues to not display it for trial, platinum and enterprise users.

view details

push time in 22 days

PR merged elastic/kibana

[7.x] [Alerting] only show trial upgrade when running with basic license (#64865) backport

Backports the following commits to 7.x:

  • [Alerting] only show trial upgrade when running with basic license (#64865)
+108 -10

1 comment

3 changed files

pmuellr

pr closed time in 22 days

issue closedelastic/kibana

[Alerting] allow action variables for email subject

I noticed the email subject field for the email action does not have the action fields context menu associated with it. Would be nice if it did, as we have a context variable with the index threshold alert purpose-built for it - title.

closed time in 23 days

pmuellr

issue commentelastic/kibana

[Alerting] allow action variables for email subject

Since reported, this has been fixed in some other PR:

image

pmuellr

comment created time in 23 days

create barnchpmuellr/kibana

branch : backport/7.x/pr-64865

created branch time in 23 days

PR opened elastic/kibana

[7.x] [Alerting] only show trial upgrade when running with basic license (#64865)

Backports the following commits to 7.x:

  • [Alerting] only show trial upgrade when running with basic license (#64865)
+108 -10

0 comment

3 changed files

pr created time in 23 days

push eventelastic/kibana

Patrick Mueller

commit sha 47887544198f9c35ca625d60094e115cc554f0a6

[Alerting] only show trial upgrade when running with basic license (#64865) resolves https://github.com/elastic/kibana/issues/64245 Prior to this PR, the "Upgrade your license" banner in the connectors list was displayed for gold licenses because the Service Now action requires platinum, and the check only looked for any actions disabled by license. Rather than display a different message for gold users, this PR changes the banner display logic to check for any actions disabled by license that also have a minimum required license of gold. That means gold+ users won't see the message, even for actions with a minimum required license of platinum+. Another perk of the gold license! This will continue to display the banner for basic users, but will no longer display it for gold users. It also continues to not display it for trial, platinum and enterprise users.

view details

push time in 23 days

PR merged elastic/kibana

[Alerting] only show trial upgrade when running with basic license Feature:Alerting Team:Alerting Services release_note:skip v7.8.0 v8.0.0

resolves https://github.com/elastic/kibana/issues/64245

Prior to this PR, the "Upgrade your license" banner in the connectors list was displayed for gold licenses because the Service Now action requires platinum, and the check only looked for any actions disabled by license.

Rather than display a different message for gold users, this PR changes the banner display logic to check for any actions disabled by license that also have a minimum required license of gold. That means gold+ users won't see the message, even for actions with a minimum required license of platinum+. Another perk of the gold license!

This will continue to display the banner for basic users, but will no longer display it for gold users. It also continues to not display it for trial, platinum and enterprise users.

Summary

Summarize your PR. If it involves visual changes include a screenshot or gif.

Checklist

+108 -10

4 comments

3 changed files

pmuellr

pr closed time in 23 days

issue closedelastic/kibana

Upgrade your license to access all connectors gets displayed when user is on gold license

Kibana version: 7.7.0 BC8

Elasticsearch version: 7.7.0 BC8

Server OS version: centos7_rpm

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: Clicking on create connectors displays "Upgrade your license to access all connectors" message even when user is on gold license.

Screen Shot 2020-04-22 at 4 30 04 PM

closed time in 23 days

bhavyarm

pull request commentelastic/kibana

[Alerting] fix labels and links in PagerDuty action ui and docs

I merged this to master and 7.x for 7.8 - I was originally planning on waiting till the 7.7.0 tag was created to merge to 7.7 for the 7.7.1 release, but it hasn't been created yet.

pmuellr

comment created time in 23 days

push eventelastic/kibana

Patrick Mueller

commit sha 71c14c6d307feae22dcba8fee5d450932e71716e

[Alerting] fix labels and links in PagerDuty action ui and docs (#64032) (#65075) resolves #63222, resolves #63768, resolves #63223 ui changes: - adds an "(optional)" label after the API URL label - changes help link to go to alerting docs and not watcher docs - changes the label "Routing key" to "Integration key" to match other docs - changes the order of the severity options to match other docs doc changes: - changes the reference of "Routing key" to "Integration key" to match other docs - makes clearer that the API URL is optional

view details

push time in 23 days

PR merged elastic/kibana

[7.x] [Alerting] fix labels and links in PagerDuty action ui and docs (#64032) backport

Backports the following commits to 7.x:

  • [Alerting] fix labels and links in PagerDuty action ui and docs (#64032)
+14 -14

1 comment

2 changed files

pmuellr

pr closed time in 23 days

Pull request review commentelastic/kibana

Added support for docLinks plugin in Connectors forms and missing save capabilities for modal dialog

 const PagerDutyActionConnectorFields: React.FunctionComponent<ActionConnectorFie         fullWidth         helpText={           <EuiLink-            href="https://www.elastic.co/guide/en/elasticsearch/reference/current/actions-pagerduty.html#configuring-pagerduty"+            href={`${docLinks.ELASTIC_WEBSITE_URL}/guide/en/elasticsearch/reference/${docLinks.DOC_LINK_VERSION}/actions-pagerduty.html#configuring-pagerduty`}

The link here was recently changed to point to Kibana instead of ES, here's what's currently in master:

https://github.com/elastic/kibana/blob/3ba268d8a59a02c2d9aec123f2a701b2ba3e3f83/x-pack/plugins/triggers_actions_ui/public/application/components/builtin_action_types/pagerduty.tsx#L141-L144

We should use that link, with the docLinks properties as appropriate.

YulNaumenko

comment created time in 23 days

more