Skip to content

Commit e26d877

Browse files
kibanamachinekibanamachine
authored
Merge branch 'master' into fix/payload-bytes
2 parents daae50f + 41b81a1 commit e26d877

712 files changed

Lines changed: 8036 additions & 4750 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.eslintrc.js‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1316,7 +1316,7 @@ module.exports = {
13161316

13171317
{
13181318
files: [
1319-
// platform-team owned code
1319+
// core-team owned code
13201320
'src/core/**',
13211321
'x-pack/plugins/features/**',
13221322
'x-pack/plugins/licensing/**',
@@ -1325,6 +1325,14 @@ module.exports = {
13251325
'packages/kbn-config-schema',
13261326
'src/plugins/status_page/**',
13271327
'src/plugins/saved_objects_management/**',
1328+
'packages/kbn-analytics/**',
1329+
'packages/kbn-telemetry-tools/**',
1330+
'src/plugins/kibana_usage_collection/**',
1331+
'src/plugins/usage_collection/**',
1332+
'src/plugins/telemetry/**',
1333+
'src/plugins/telemetry_collection_manager/**',
1334+
'src/plugins/telemetry_management_section/**',
1335+
'x-pack/plugins/telemetry_collection_xpack/**',
13281336
],
13291337
rules: {
13301338
'@typescript-eslint/prefer-ts-expect-error': 'error',

‎.github/CODEOWNERS‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -240,6 +240,7 @@ x-pack/plugins/telemetry_collection_xpack/schema/ @elastic/kibana-core @elastic/
240240
# Security
241241
/src/core/server/csp/ @elastic/kibana-security @elastic/kibana-core
242242
/src/plugins/security_oss/ @elastic/kibana-security
243+
/src/plugins/spaces_oss/ @elastic/kibana-security
243244
/test/security_functional/ @elastic/kibana-security
244245
/x-pack/plugins/spaces/ @elastic/kibana-security
245246
/x-pack/plugins/encrypted_saved_objects/ @elastic/kibana-security

‎dev_docs/building_blocks.mdx‎

Lines changed: 138 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,138 @@
1+
---
2+
id: kibBuildingBlocks
3+
slug: /kibana-dev-docs/building-blocks
4+
title: Building blocks
5+
summary: Consider these building blocks when developing your plugin.
6+
date: 2021-02-24
7+
tags: ['kibana','onboarding', 'dev', 'architecture']
8+
---
9+
10+
When building a plugin in Kibana, there are a handful of architectural "building blocks" you can use. Some of these building blocks are "higher-level",
11+
and some are "lower-level". High-level building blocks come
12+
with many built-in capabilities, require less maintenance, and evolve new feature sets over time with little to no
13+
impact on consumers. When developers use high-level building blocks, new features are exposed consistently, across all of Kibana, at the same time.
14+
On the downside, they are not as flexible as our low-level building blocks.
15+
16+
Low-level building blocks
17+
provide greater flexibility, but require more code to stitch them together into a meaningful UX. This results in higher maintenance cost for consumers and greater UI/UX variability
18+
across Kibana.
19+
20+
For example, if an application is using <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/> and
21+
<DocLink id="kibBuildingBlocks" section="search-source" text="Search Source"/>,
22+
their application would automatically support runtime fields. If the app is instead using the
23+
lower-level <DocLink id="kibBuildingBlocks" section="search-strategy" text="Search Strategy"/>, additional work would be required.
24+
25+
Armed with this knowledge, you can choose what works best for your use case!
26+
27+
# Application building blocks
28+
29+
## UI components
30+
31+
The following high-level building blocks can be rendered directly into your application UI.
32+
33+
### Query Bar
34+
35+
The <DocLink id="kibDataPlugin" text="Data plugin"/> provides a high-level Query Bar component that comes with support for Lucene, KQL, Saved Queries,
36+
and <DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>.
37+
38+
If you would like to expose the ability to search and filter on Elasticsearch data, the Query Bar provided by the
39+
<DocLink id="kibDataPlugin" text="Data plugin"/>
40+
is your go-to building block.
41+
42+
**Github labels**: `Team:AppServices`, `Feature:QueryBar`
43+
44+
### Dashboard Embeddable
45+
46+
Add a Dashboard Embeddable directly inside your application to provide users with a set of visualizations and graphs that work seamlessly
47+
with the <DocLink id="kibBuildingBlocks" section="query-bar" text="Query Bar"/>. Every feature that is added to a registered
48+
<DocLink id="kibBuildingBlocks" section="embeddables" text="Embeddable"/>
49+
(Lens, Maps, Saved Searches and more) will be available automatically, as well as any
50+
<DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions"/> that are
51+
added to the Embeddable context menu panel (for example, drilldowns, custom panel time ranges, and "share to" features).
52+
53+
The Dashboard Embeddable is one of the highest-level UI components you can add to your application.
54+
55+
**Github labels**: `Team:Presentation`, `Feature:Dashboard`
56+
57+
### Lens Embeddable
58+
59+
Check out the Lens Embeddable if you wish to show users visualizations based on Elasticsearch data without worrying about query building and chart rendering. It's built on top of the
60+
<DocLink id="kibBuildingBlocks" section="expressions" text="Expression language"/>, and integrates with
61+
<DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Patterns"/>
62+
and <DocLink id="kibBuildingBlocks" section="ui-actions--triggers" text="UI Actions"/>. Using the same configuration, it's also possible to link to
63+
a prefilled Lens editor, allowing the user to drill deeper and explore their data.
64+
65+
**Github labels**: `Team:KibanaApp`, `Feature:Lens`
66+
67+
### Map Embeddable
68+
69+
Check out the Map Embeddable if you wish to embed a map in your application.
70+
71+
**Github labels**: `Team:Geo`
72+
73+
## Searching
74+
75+
### Index Patterns
76+
77+
<DocLink id="kibDataPlugin" section="index-patterns-api" text="Index Patterns"/> are a high-level, space-aware abstraction layer that sits
78+
above Data Streams and Elasticsearch indices. Index Patterns provide users the
79+
ability to define and customize the data they wish to search and filter on, on a per-space basis. For example, users can specify a set of indices,
80+
and they can customize the field list with runtime fields, formatting options and custom labels.
81+
82+
Index Patterns are used in many other high-level building blocks so we highly recommend you consider this building block for your search needs.
83+
84+
**Github labels**: `Team:AppServices`, `Feature:Index Patterns`
85+
86+
### Search Source
87+
88+
<DocLink id="kibDataPlugin" section="searchsource" text="Search Source"/> is a high-level search service offered by the
89+
<DocLink id="kibDataPlugin" section="searchsource" text="Data plugin"/>. It requires an
90+
<DocLink id="kibBuildingBlocks" section="index-patterns" text="Index Pattern"/>, and abstracts away the raw ES DSL and search endpoint. Internally
91+
it uses the ES <DocLink id="kibBuildingBlocks" section="search-strategies" text="Search Strategy"/>. Use Search Source if you need to query data
92+
from Elasticsearch, and you aren't already using one of the high-level UI Components that handles this internally.
93+
94+
**Github labels**: `Team:AppServices`, `Feature:Search`
95+
96+
### Search Strategies
97+
98+
Search Strategies are a low-level building block that abstracts away search details, like what REST endpoint is being called. The ES Search Strategy
99+
is a very lightweight abstraction layer that sits just above querying ES with the elasticsearch-js client. Other search stragies are offered for other
100+
languages, like EQL and SQL. These are very low-level building blocks so expect a lot of glue work to make these work with the higher-level abstractions.
101+
102+
**Github labels**: `Team:AppServices`, `Feature:Search`
103+
104+
### Expressions
105+
106+
Expressions are a low-level building block that can be used if you have advanced search needs that requiring piping results into additional functionality, like
107+
joining and manipulating data. Lens and Canvas are built on top of Expressions. Most developers should be able to use
108+
<DocLink id="kibBuildingBlocks" section="lens-embeddable" text="Lens"/> or
109+
<DocLink id="kibBuildingBlocks" section="search-source" text="Search Source"/>, rather than need to access the Expression language directly.
110+
111+
**Github labels**: `Team:AppServices`, `Feature:ExpressionLanguage`
112+
113+
## Saved Objects
114+
115+
<DocLink id="kibDevDocsSavedObjectsIntro" text="Saved Objects" /> should be used if you need to persist application-level information. If you were building a TODO
116+
application, each TODO item would be a `Saved Object`. Saved objects come pre-wired with support for bulk export/import, security features like space sharing and
117+
space isolation, and tags.
118+
119+
**Github labels**: `Team:Core`, `Feature:Saved Objects`
120+
121+
# Integration building blocks
122+
123+
Use the following building blocks to create an inter-connected, cross-application, holistic Kibana experience. These building blocks allow you to expose functionality
124+
that promotes your own application into other applications, as well as help developers of other applications integrate into your app.
125+
126+
## UI Actions & Triggers
127+
128+
Integrate custom actions into other applications by registering UI Actions attached to existing triggers. For example, the Maps
129+
application could register a UI Action called "View in Maps" to appear any time the user clicked a geo field to filter on.
130+
131+
**Github labels**: `Team:AppServices`, `Feature:UIActions`
132+
133+
## Embeddables
134+
135+
Embeddables help you integrate your application with the Dashboard application. Register your custom UI Widget as an Embeddable and users will
136+
be able to add it as a panel on a Dashboard. With a little extra work, it can also be exposed in Canvas workpads.
137+
138+
**Github labels**: `Team:AppServices`, `Feature:Embeddables`

‎docs/developer/plugin-list.asciidoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -224,7 +224,7 @@ which also contains the timelion APIs and backend, look at the vis_type_timelion
224224
|This plugins contains helpers to redirect legacy URLs. It can be used to forward old URLs to their new counterparts.
225225
226226
227-
|{kib-repo}blob/{branch}/src/plugins/usage_collection/README.md[usageCollection]
227+
|{kib-repo}blob/{branch}/src/plugins/usage_collection/README.mdx[usageCollection]
228228
|The Usage Collection Service defines a set of APIs for other plugins to report the usage of their features. At the same time, it provides necessary the APIs for other services (i.e.: telemetry, monitoring, ...) to consume that usage data.
229229
230230

‎docs/settings/alert-action-settings.asciidoc‎

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,8 @@ You can configure the following settings in the `kibana.yml` file.
4040

4141
[cols="2*<"]
4242
|===
43+
| `xpack.actions.enabled`
44+
| Feature toggle that enables Actions in {kib}. Defaults to `true`.
4345

4446
| `xpack.actions.allowedHosts` {ess-icon}
4547
| A list of hostnames that {kib} is allowed to connect to when built-in actions are triggered. It defaults to `[*]`, allowing any host, but keep in mind the potential for SSRF attacks when hosts are not explicitly added to the allowed hosts. An empty list `[]` can be used to block built-in actions from making any external connections. +
@@ -51,6 +53,24 @@ You can configure the following settings in the `kibana.yml` file.
5153
+
5254
Disabled action types will not appear as an option when creating new connectors, but existing connectors and actions of that type will remain in {kib} and will not function.
5355

56+
| `xpack.actions.preconfigured`
57+
| Specifies preconfigured action IDs and configs. Defaults to {}.
58+
59+
| `xpack.actions.proxyUrl` {ess-icon}
60+
| Specifies the proxy URL to use, if using a proxy for actions. By default, no proxy is used.
61+
62+
| `xpack.actions.proxyHeaders` {ess-icon}
63+
| Specifies HTTP headers for the proxy, if using a proxy for actions. Defaults to {}.
64+
65+
a|`xpack.actions.`
66+
`proxyRejectUnauthorizedCertificates` {ess-icon}
67+
| Set to `false` to bypass certificate validation for the proxy, if using a proxy for actions. Defaults to `true`.
68+
69+
| `xpack.actions.rejectUnauthorized` {ess-icon}
70+
| Set to `false` to bypass certificate validation for actions. Defaults to `true`. +
71+
+
72+
As an alternative to setting both `xpack.actions.proxyRejectUnauthorizedCertificates` and `xpack.actions.rejectUnauthorized`, you can point the OS level environment variable `NODE_EXTRA_CA_CERTS` to a file that contains the root CAs needed to trust certificates.
73+
5474
|===
5575

5676
[float]

‎docs/user/alerting/action-types/pre-configured-connectors.asciidoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -95,7 +95,7 @@ This example shows a preconfigured action type with one out-of-the box connector
9595
name: 'Server log #xyz'
9696
```
9797

98-
<1> `enabledActionTypes` excludes the preconfigured action type to prevent creating and deleting connectors.
98+
<1> `enabledActionTypes` prevents the preconfigured action type from creating and deleting connectors. For more details, check <<action-settings, Action settings>>.
9999
<2> `preconfigured` is the setting for defining the list of available connectors for the preconfigured action type.
100100

101101
[[managing-pre-configured-action-types]]

‎docs/user/alerting/alert-types.asciidoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ For domain-specific alerts, refer to the documentation for that app.
2828
* {observability-guide}/create-alerts.html[Observability alerts]
2929
* {security-guide}/prebuilt-rules.html[Security alerts]
3030
* <<geo-alerting, Maps alerts>>
31-
* <<xpack-ml, ML alerts>>
31+
* {ml-docs}/ml-configuring-alerts.html[{ml-cap} alerts]
3232

3333
[NOTE]
3434
==============================================

‎docs/user/alerting/alerting-getting-started.asciidoc‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55

66
--
77

8-
Alerting allows you to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and <<xpack-ml,*ML*>>, can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, actions>> and <<alert-types, alerts>> (known as stack alerts) for you to use.
8+
Alerting allows you to detect complex conditions within different {kib} apps and trigger actions when those conditions are met. Alerting is integrated with {observability-guide}/create-alerts.html[*Observability*], {security-guide}/prebuilt-rules.html[*Security*], <<geo-alerting,*Maps*>> and {ml-docs}/ml-configuring-alerts.html[*{ml-app}*], can be centrally managed from the <<management,*Management*>> UI, and provides a set of built-in <<action-types, actions>> and <<alert-types, alerts>> (known as stack alerts) for you to use.
99

1010
image::images/alerting-overview.png[Alerts and actions UI]
1111

@@ -157,7 +157,7 @@ Pre-packaged *alert types* simplify setup, hide the details complex domain-speci
157157

158158
If you are using an *on-premises* Elastic Stack deployment:
159159

160-
* In the kibana.yml configuration file, add the <<alert-action-settings-kb,`xpack.encryptedSavedObjects.encryptionKey`>> setting.
160+
* In the kibana.yml configuration file, add the <<general-alert-action-settings,`xpack.encryptedSavedObjects.encryptionKey`>> setting.
161161
* For emails to have a footer with a link back to {kib}, set the <<server-publicBaseUrl, `server.publicBaseUrl`>> configuration setting.
162162

163163
If you are using an *on-premises* Elastic Stack deployment with <<using-kibana-with-security, *security*>>:

‎docs/user/alerting/alerting-production-considerations.asciidoc‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2,17 +2,17 @@
22
[[alerting-production-considerations]]
33
== Production considerations
44

5-
{kib} alerting run both alert checks and actions as persistent background tasks managed by the Kibana Task Manager. This has two major benefits:
5+
{kib} alerting runs both alert checks and actions as persistent background tasks managed by the Kibana Task Manager. This has two major benefits:
66

7-
* *Persistence*: all task state and scheduling is stored in {es}, so if {kib} is restarted, alerts and actions will pick up where they left off. Task definitions for alerts and actions are stored in the index specified by `xpack.task_manager.index` (defaults to `.kibana_task_manager`). It is important to have at least 1 replica of this index for production deployments, since if you lose this index all scheduled alerts and actions are also lost.
7+
* *Persistence*: all task state and scheduling is stored in {es}, so if you restart {kib}, alerts and actions will pick up where they left off. Task definitions for alerts and actions are stored in the index specified by <<task-manager-settings, `xpack.task_manager.index`>>. The default is `.kibana_task_manager`. You must have at least one replica of this index for production deployments. If you lose this index, all scheduled alerts and actions are lost.
88
* *Scaling*: multiple {kib} instances can read from and update the same task queue in {es}, allowing the alerting and action load to be distributed across instances. In cases where a {kib} instance no longer has capacity to run alert checks or actions, capacity can be increased by adding additional {kib} instances.
99

1010
[float]
1111
=== Running background alert checks and actions
1212

1313
{kib} background tasks are managed by:
1414

15-
* Polling an {es} task index for overdue tasks at 3 second intervals. This interval can be changed using the `xpack.task_manager.poll_interval` setting.
15+
* Polling an {es} task index for overdue tasks at 3 second intervals. You can change this interval using the <<task-manager-settings, `xpack.task_manager.poll_interval`>> setting.
1616
* Tasks are then claiming them by updating them in the {es} index, using optimistic concurrency control to prevent conflicts. Each {kib} instance can run a maximum of 10 concurrent tasks, so a maximum of 10 tasks are claimed each interval.
1717
* Tasks are run on the {kib} server.
1818
* In the case of alerts which are recurring background checks, upon completion the task is scheduled again according to the <<defining-alerts-general-details, check interval>>.
@@ -32,4 +32,4 @@ For details on the settings that can influence the performance and throughput of
3232
[float]
3333
=== Deployment considerations
3434

35-
{es} and {kib} instances use the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as http://www.ntp.org/[Network Time Protocol].
35+
{es} and {kib} instances use the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as http://www.ntp.org/[Network Time Protocol].

0 commit comments

Comments
 (0)