Skip to content

Commit

Permalink
Merge branch '7.x' into backport/7.x/pr-90600
Browse files Browse the repository at this point in the history
  • Loading branch information
kibanamachine authored Feb 23, 2021
2 parents 0cf4914 + f328034 commit c121999
Show file tree
Hide file tree
Showing 547 changed files with 20,219 additions and 7,452 deletions.
34 changes: 17 additions & 17 deletions dev_docs/kibana_platform_plugin_intro.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,25 +7,25 @@ date: 2021-01-06
tags: ['kibana','onboarding', 'dev', 'architecture']
---

From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way
From an end user perspective, Kibana is a tool for interacting with Elasticsearch, providing an easy way
to visualize and analyze data.

From a developer perspective, Kibana is a platform that provides a set of tools to build not only the UI you see in Kibana today, but
a wide variety of applications that can be used to explore, visualize, and act upon data in Elasticsearch. The platform provides developers the ability
to build applications, or inject extra functionality into
a wide variety of applications that can be used to explore, visualize, and act upon data in Elasticsearch. The platform provides developers the ability
to build applications, or inject extra functionality into
already existing applications. Did you know that almost everything you see in the
Kibana UI is built inside a plugin? If you removed all plugins from Kibana, you'd be left with an empty navigation menu, and a set of
developer tools. The Kibana platform is a blank canvas, just waiting for a developer to come along and create something!

![Kibana personas](assets/kibana_platform_plugin_end_user.png)

## Platform services

Plugins have access to three kinds of public services:

- Platform services provided by `core` (<DocLink id="kibPlatformIntro" section="core-services" text="Core services"/>)
- Platform services provided by plugins (<DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>)
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").
- Shared services provided by plugins, that are only relevant for only a few, specific plugins (e.g. "presentation utils").

The first two items are what make up "Platform services".

Expand All @@ -37,9 +37,9 @@ clear, and we haven't done a great job of sticking to it. For example, notificat
Today it looks something like this.

![Core vs platform plugins vs plugins](assets/platform_plugins_core.png)

<DocAccordion buttonContent="A bit of history">
When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental
When the Kibana platform and plugin infrastructure was built, we thought of two types of code: core services, and other plugin services. We planned to keep the most stable and fundamental
code needed to build plugins inside core.

In reality, we ended up with many platform-like services living outside of core, with no (short term) intention of moving them. We highly encourage plugin developers to use
Expand All @@ -54,7 +54,7 @@ In reality, our plugin model ended up being used like micro-services. Plugins ar
they desire, without the need to build a plugin.

Another side effect of having many small plugins is that common code often ends up extracted into another plugin. Use case specific utilities are exported,
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
that are not meant to be used in a general manner. This makes our definition of "platform code" a bit trickier to define. We'd like to say "The platform is made up of
every publically exposed service", but in today's world, that wouldn't be a very accurate picture.

We recognize the need to better clarify the relationship between core functionality, platform-like plugin functionality, and functionality exposed by other plugins.
Expand All @@ -69,19 +69,19 @@ We will continue to focus on adding clarity around these types of services and w
### Core services

Sometimes referred to just as Core, Core services provide the most basic and fundamental tools neccessary for building a plugin, like creating saved objects,
routing, application registration, and notifications. The Core platform is not a plugin itself, although
routing, application registration, notifications and <DocLink id="kibCoreLogging" text="logging"/>. The Core platform is not a plugin itself, although
there are some plugins that provide platform functionality. We call these <DocLink id="kibPlatformIntro" section="platform-plugins" text="Platform plugins"/>.

### Platform plugins

Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
Plugins that provide fundamental services and functionality to extend and customize Kibana, for example, the
<DocLink id="kibDataPlugin" text="data"/> plugin. There is no official way to tell if a plugin is a platform plugin or not.
Platform plugins are _usually_ plugins that are managed by the Platform Group, but we are starting to see some exceptions.

## Plugins

Plugins are code that is written to extend and customize Kibana. Plugin's don't have to be part of the Kibana repo, though the Kibana
repo does contain many plugins! Plugins add customizations by
Plugins are code that is written to extend and customize Kibana. Plugin's don't have to be part of the Kibana repo, though the Kibana
repo does contain many plugins! Plugins add customizations by
using <DocLink id="kibPlatformIntro" section="extension-points" text="extension points"/> provided by <DocLink id="kibPlatformIntro" section="platform-services" text="platform services"/>.
Sometimes people confuse the term "plugin" and "application". While often there is a 1:1 relationship between a plugin and an application, it is not always the case.
A plugin may register many applications, or none.
Expand All @@ -97,7 +97,7 @@ adding it to core's application <DocLink id="kibPlatformIntro" section="registry

### Public plugin API

A plugin's public API consists of everything exported from a plugin's <DocLink id="kibPlatformIntro" section="plugin-lifecycle" text="start or setup lifecycle methods"/>,
A plugin's public API consists of everything exported from a plugin's <DocLink id="kibPlatformIntro" section="plugin-lifecycle" text="start or setup lifecycle methods"/>,
as well as from the top level `index.ts` files that exist in the three "scope" folders:

- common/index.ts
Expand All @@ -113,18 +113,18 @@ Core, and plugins, expose different features at different parts of their lifecyc
specifically-named functions on the service definition.

Kibana has three lifecycles: setup, start, and stop. Each plugin’s setup function is called sequentially while Kibana is setting up
on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
on the server or when it is being loaded in the browser. The start functions are called sequentially after setup has been completed for all plugins.
The stop functions are called sequentially while Kibana is gracefully shutting down the server or when the browser tab or window is being closed.

The table below explains how each lifecycle relates to the state of Kibana.

| lifecycle | purpose | server | browser |
| ---------- | ------ | ------- | ----- |
| setup | perform "registration" work to setup environment for runtime |configure REST API endpoint, register saved object types, etc. | configure application routes in SPA, register custom UI elements in extension points, etc. |
| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.|
| start | bootstrap runtime logic | respond to an incoming request, request Elasticsearch server, etc. | start polling Kibana server, update DOM tree in response to user interactions, etc.|
| stop | cleanup runtime | dispose of active handles before the server shutdown. | store session data in the LocalStorage when the user navigates away from Kibana, etc. |

Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types
Different service interfaces can and will be passed to setup, start, and stop because certain functionality makes sense in the context of a running plugin while other types
of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.

## Extension points
Expand All @@ -141,4 +141,4 @@ plugins to customize the Kibana experience. Examples of extension points are:

## Follow up material

Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />
Learn how to build your own plugin by following <DocLink id="kibDevTutorialBuildAPlugin" />
42 changes: 42 additions & 0 deletions docs/api/alerts.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
[[alerts-api]]
== Alerts APIs

The following APIs are available for managing {kib} alerts.

* <<alerts-api-create, Create alert API>> to create an alert

* <<alerts-api-update, Update alert API>> to update the attributes for existing alerts

* <<alerts-api-get, Get object API>> to retrieve a single alert by ID

* <<alerts-api-delete, Delete alert API>> to permanently remove an alert

* <<alerts-api-find, Find alerts API>> to retrieve a paginated set of alerts by condition

* <<alerts-api-list, List all alert types API>> to retrieve a list of all alert types

* <<alerts-api-enable, Enable alert API>> to enable a single alert by ID

* <<alerts-api-disable, Disable alert API>> to disable a single alert by ID

* <<alerts-api-mute, Mute alert instance API>> to mute alert instances for a single alert by ID

* <<alerts-api-unmute, Unmute alert instance API>> to unmute alert instances for a single alert by ID

* <<alerts-api-unmute-all, Unmute all alert instances API>> to unmute all alert instances for a single alert by ID

* <<alerts-api-health, Get framework health API>> to retrieve the health of the alerts framework

include::alerts/create.asciidoc[]
include::alerts/update.asciidoc[]
include::alerts/get.asciidoc[]
include::alerts/delete.asciidoc[]
include::alerts/find.asciidoc[]
include::alerts/list.asciidoc[]
include::alerts/enable.asciidoc[]
include::alerts/disable.asciidoc[]
include::alerts/mute_all.asciidoc[]
include::alerts/mute.asciidoc[]
include::alerts/unmute_all.asciidoc[]
include::alerts/unmute.asciidoc[]
include::alerts/health.asciidoc[]
189 changes: 189 additions & 0 deletions docs/api/alerts/create.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,189 @@
[[alerts-api-create]]
=== Create alert API
++++
<titleabbrev>Create alert</titleabbrev>
++++

Create {kib} alerts.

[[alerts-api-create-request]]
==== Request

`POST <kibana host>:<port>/api/alerts/alert`

[[alerts-api-create-request-body]]
==== Request body

`name`::
(Required, string) A name to reference and search.

`tags`::
(Optional, string array) A list of keywords to reference and search.

`alertTypeId`::
(Required, string) The ID of the alert type that you want to call when the alert is scheduled to run.

`schedule`::
(Required, object) The schedule specifying when this alert should be run, using one of the available schedule formats specified under
+
._Schedule Formats_.
[%collapsible%open]
=====
A schedule is structured such that the key specifies the format you wish to use and its value specifies the schedule.
We currently support the _Interval format_ which specifies the interval in seconds, minutes, hours or days at which the alert should execute.
Example: `{ interval: "10s" }`, `{ interval: "5m" }`, `{ interval: "1h" }`, `{ interval: "1d" }`.
There are plans to support multiple other schedule formats in the near future.
=====

`throttle`::
(Optional, string) How often this alert should fire the same actions. This will prevent the alert from sending out the same notification over and over. For example, if an alert with a `schedule` of 1 minute stays in a triggered state for 90 minutes, setting a `throttle` of `10m` or `1h` will prevent it from sending 90 notifications during this period.

`notifyWhen`::
(Required, string) The condition for throttling the notification: `onActionGroupChange`, `onActiveAlert`, or `onThrottleInterval`.

`enabled`::
(Optional, boolean) Indicates if you want to run the alert on an interval basis after it is created.

`consumer`::
(Required, string) The name of the application that owns the alert. This name has to match the Kibana Feature name, as that dictates the required RBAC privileges.

`params`::
(Required, object) The parameters to pass to the alert type executor `params` value. This will also validate against the alert type params validator, if defined.

`actions`::
(Optional, object array) An array of the following action objects.
+
.Properties of the action objects:
[%collapsible%open]
=====
`group`:::
(Required, string) Grouping actions is recommended for escalations for different types of alert instances. If you don't need this, set this value to `default`.
`id`:::
(Required, string) The ID of the action saved object to execute.
`actionTypeId`:::
(Required, string) The ID of the <<action-types,action type>>.
`params`:::
(Required, object) The map to the `params` that the <<action-types,action type>> will receive. ` params` are handled as Mustache templates and passed a default set of context.
=====


[[alerts-api-create-request-codes]]
==== Response code

`200`::
Indicates a successful call.

[[alerts-api-create-example]]
==== Example

[source,sh]
--------------------------------------------------
$ curl -X POST api/alerts/alert -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d '
{
"params":{
"aggType":"avg",
"termSize":6,
"thresholdComparator":">",
"timeWindowSize":5,
"timeWindowUnit":"m",
"groupBy":"top",
"threshold":[
1000
],
"index":[
".test-index"
],
"timeField":"@timestamp",
"aggField":"sheet.version",
"termField":"name.keyword"
},
"consumer":"alerts",
"alertTypeId":".index-threshold",
"schedule":{
"interval":"1m"
},
"actions":[
{
"id":"dceeb5d0-6b41-11eb-802b-85b0c1bc8ba2",
"actionTypeId":".server-log",
"group":"threshold met",
"params":{
"level":"info",
"message":"alert '{{alertName}}' is active for group '{{context.group}}':\n\n- Value: {{context.value}}\n- Conditions Met: {{context.conditions}} over {{params.timeWindowSize}}{{params.timeWindowUnit}}\n- Timestamp: {{context.date}}"
}
}
],
"tags":[
"cpu"
],
"notifyWhen":"onActionGroupChange",
"name":"my alert"
}'
--------------------------------------------------
// KIBANA

The API returns the following:

[source,sh]
--------------------------------------------------
{
"id": "41893910-6bca-11eb-9e0d-85d233e3ee35",
"notifyWhen": "onActionGroupChange",
"params": {
"aggType": "avg",
"termSize": 6,
"thresholdComparator": ">",
"timeWindowSize": 5,
"timeWindowUnit": "m",
"groupBy": "top",
"threshold": [
1000
],
"index": [
".kibana"
],
"timeField": "@timestamp",
"aggField": "sheet.version",
"termField": "name.keyword"
},
"consumer": "alerts",
"alertTypeId": ".index-threshold",
"schedule": {
"interval": "1m"
},
"actions": [
{
"actionTypeId": ".server-log",
"group": "threshold met",
"params": {
"level": "info",
"message": "alert {{alertName}} is active for group {{context.group}}:\n\n- Value: {{context.value}}\n- Conditions Met: {{context.conditions}} over {{params.timeWindowSize}}{{params.timeWindowUnit}}\n- Timestamp: {{context.date}}"
},
"id": "dceeb5d0-6b41-11eb-802b-85b0c1bc8ba2"
}
],
"tags": [
"cpu"
],
"name": "my alert",
"enabled": true,
"throttle": null,
"apiKeyOwner": "elastic",
"createdBy": "elastic",
"updatedBy": "elastic",
"muteAll": false,
"mutedInstanceIds": [],
"updatedAt": "2021-02-10T18:03:19.961Z",
"createdAt": "2021-02-10T18:03:19.961Z",
"scheduledTaskId": "425b0800-6bca-11eb-9e0d-85d233e3ee35",
"executionStatus": {
"lastExecutionDate": "2021-02-10T18:03:19.966Z",
"status": "pending"
}
}
--------------------------------------------------
36 changes: 36 additions & 0 deletions docs/api/alerts/delete.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
[[alerts-api-delete]]
=== Delete alert API
++++
<titleabbrev>Delete alert</titleabbrev>
++++

Permanently remove an alert.

WARNING: Once you delete an alert, you cannot recover it.

[[alerts-api-delete-request]]
==== Request

`DELETE <kibana host>:<port>/api/alerts/alert/<id>`

[[alerts-api-delete-path-params]]
==== Path parameters

`id`::
(Required, string) The ID of the alert that you want to remove.

[[alerts-api-delete-response-codes]]
==== Response code

`200`::
Indicates a successful call.

==== Example

Delete an alert with ID:

[source,sh]
--------------------------------------------------
$ curl -X DELETE api/alerts/alert/41893910-6bca-11eb-9e0d-85d233e3ee35
--------------------------------------------------
// KIBANA
Loading

0 comments on commit c121999

Please sign in to comment.