Merge branch 'master' into feature/lens/intervals-suggestions

elastic · Oct 13, 2020 · 73ead33 · 73ead33
2 parents 6f1448a + 6eeab00
commit 73ead33
Show file tree

Hide file tree

Showing 210 changed files with 17,588 additions and 11,258 deletions.
diff --git a/docs/developer/best-practices/typescript.asciidoc b/docs/developer/best-practices/typescript.asciidoc
@@ -19,15 +19,16 @@ More details are available in the https://www.typescriptlang.org/docs/handbook/p
 ==== Caveats
 This architecture imposes several limitations to which we must comply:
 
-- Projects cannot have circular dependencies. Even though the Kibana platform doesn't support circular dependencies between Kibana plugins, TypeScript (and ES6 modules) does allow circular imports between files. So in theory, you may face a problem when migrating to the TS project references and you will have to resolve this circular dependency.
+- Projects cannot have circular dependencies. Even though the Kibana platform doesn't support circular dependencies between Kibana plugins, TypeScript (and ES6 modules) does allow circular imports between files. So in theory, you may face a problem when migrating to the TS project references and you will have to resolve this circular dependency. https://github.com/elastic/kibana/issues/78162 is going to provide a tool to find such problem places.
 - A project must emit its type declaration. It's not always possible to generate a type declaration if the compiler cannot infer a type. There are two basic cases:
 
 1. Your plugin exports a type inferring an internal type declared in Kibana codebase. In this case, you'll have to either export an internal type or to declare an exported type explicitly.
 2. Your plugin exports something inferring a type from a 3rd party library that doesn't export this type. To fix the problem, you have to declare the exported type manually.
 
 [discrete]
 ==== Prerequisites
-Since `tsc` doesn't support circular project references, the migration order does matter. You can migrate your plugin only when all the plugin dependencies already have migrated. It creates a situation where commonly used plugins (such as `data` or `kibana_react`) have to migrate first.
+Since project refs rely on generated `d.ts` files, the migration order does matter. You can migrate your plugin only when all the plugin dependencies already have migrated. It creates a situation where commonly used plugins (such as `data` or `kibana_react`) have to migrate first.
+https://github.com/elastic/kibana/issues/79343 is going to provide a tool for identifying a plugin dependency tree.
 
 [discrete]
 ==== Implementation

diff --git a/...velopment/plugins/data/server/kibana-plugin-plugins-data-server.isearchstart.md b/...velopment/plugins/data/server/kibana-plugin-plugins-data-server.isearchstart.md
@@ -16,6 +16,6 @@ export interface ISearchStart<SearchStrategyRequest extends IKibanaSearchRequest
 |  --- | --- | --- |
 |  [aggs](./kibana-plugin-plugins-data-server.isearchstart.aggs.md) | <code>AggsStart</code> |  |
 |  [getSearchStrategy](./kibana-plugin-plugins-data-server.isearchstart.getsearchstrategy.md) | <code>(name: string) =&gt; ISearchStrategy&lt;SearchStrategyRequest, SearchStrategyResponse&gt;</code> | Get other registered search strategies. For example, if a new strategy needs to use the already-registered ES search strategy, it can use this function to accomplish that. |
-|  [search](./kibana-plugin-plugins-data-server.isearchstart.search.md) | <code>(context: RequestHandlerContext, request: SearchStrategyRequest, options: ISearchOptions) =&gt; Promise&lt;SearchStrategyResponse&gt;</code> |  |
+|  [search](./kibana-plugin-plugins-data-server.isearchstart.search.md) | <code>ISearchStrategy['search']</code> |  |
 |  [searchSource](./kibana-plugin-plugins-data-server.isearchstart.searchsource.md) | <code>{</code><br/><code>        asScoped: (request: KibanaRequest) =&gt; Promise&lt;ISearchStartSearchSource&gt;;</code><br/><code>    }</code> |  |
 
diff --git a/...nt/plugins/data/server/kibana-plugin-plugins-data-server.isearchstart.search.md b/...nt/plugins/data/server/kibana-plugin-plugins-data-server.isearchstart.search.md
@@ -7,5 +7,5 @@
 <b>Signature:</b>
 
 ```typescript
-search: (context: RequestHandlerContext, request: SearchStrategyRequest, options: ISearchOptions) => Promise<SearchStrategyResponse>;
+search: ISearchStrategy['search'];
 ```
diff --git a/...opment/plugins/data/server/kibana-plugin-plugins-data-server.isearchstrategy.md b/...opment/plugins/data/server/kibana-plugin-plugins-data-server.isearchstrategy.md
@@ -17,5 +17,5 @@ export interface ISearchStrategy<SearchStrategyRequest extends IKibanaSearchRequ
 |  Property | Type | Description |
 |  --- | --- | --- |
 |  [cancel](./kibana-plugin-plugins-data-server.isearchstrategy.cancel.md) | <code>(context: RequestHandlerContext, id: string) =&gt; Promise&lt;void&gt;</code> |  |
-|  [search](./kibana-plugin-plugins-data-server.isearchstrategy.search.md) | <code>(context: RequestHandlerContext, request: SearchStrategyRequest, options?: ISearchOptions) =&gt; Promise&lt;SearchStrategyResponse&gt;</code> |  |
+|  [search](./kibana-plugin-plugins-data-server.isearchstrategy.search.md) | <code>(request: SearchStrategyRequest, options: ISearchOptions, context: RequestHandlerContext) =&gt; Observable&lt;SearchStrategyResponse&gt;</code> |  |
 
diff --git a/...plugins/data/server/kibana-plugin-plugins-data-server.isearchstrategy.search.md b/...plugins/data/server/kibana-plugin-plugins-data-server.isearchstrategy.search.md
@@ -7,5 +7,5 @@
 <b>Signature:</b>
 
 ```typescript
-search: (context: RequestHandlerContext, request: SearchStrategyRequest, options?: ISearchOptions) => Promise<SearchStrategyResponse>;
+search: (request: SearchStrategyRequest, options: ISearchOptions, context: RequestHandlerContext) => Observable<SearchStrategyResponse>;
 ```
diff --git a/...ssions/public/kibana-plugin-plugins-expressions-public.expressionrendererror.md b/...ssions/public/kibana-plugin-plugins-expressions-public.expressionrendererror.md
@@ -14,5 +14,6 @@ export interface ExpressionRenderError extends Error
 
 |  Property | Type | Description |
 |  --- | --- | --- |
+|  [original](./kibana-plugin-plugins-expressions-public.expressionrendererror.original.md) | <code>Error</code> |  |
 |  [type](./kibana-plugin-plugins-expressions-public.expressionrendererror.type.md) | <code>string</code> |  |
 
diff --git a/...blic/kibana-plugin-plugins-expressions-public.expressionrendererror.original.md b/...blic/kibana-plugin-plugins-expressions-public.expressionrendererror.original.md
@@ -0,0 +1,11 @@
+<!-- Do not edit this file. It is automatically generated by API Documenter. -->
+
+[Home](./index.md) &gt; [kibana-plugin-plugins-expressions-public](./kibana-plugin-plugins-expressions-public.md) &gt; [ExpressionRenderError](./kibana-plugin-plugins-expressions-public.expressionrendererror.md) &gt; [original](./kibana-plugin-plugins-expressions-public.expressionrendererror.original.md)
+
+## ExpressionRenderError.original property
+
+<b>Signature:</b>
+
+```typescript
+original?: Error;
+```
diff --git a/...public/kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.md b/...public/kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.md
@@ -20,5 +20,5 @@ export interface ReactExpressionRendererProps extends IExpressionLoaderParams
 |  [onEvent](./kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.onevent.md) | <code>(event: ExpressionRendererEvent) =&gt; void</code> |  |
 |  [padding](./kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.padding.md) | <code>'xs' &#124; 's' &#124; 'm' &#124; 'l' &#124; 'xl'</code> |  |
 |  [reload$](./kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.reload_.md) | <code>Observable&lt;unknown&gt;</code> | An observable which can be used to re-run the expression without destroying the component |
-|  [renderError](./kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.rendererror.md) | <code>(error?: string &#124; null) =&gt; React.ReactElement &#124; React.ReactElement[]</code> |  |
+|  [renderError](./kibana-plugin-plugins-expressions-public.reactexpressionrendererprops.rendererror.md) | <code>(message?: string &#124; null, error?: ExpressionRenderError &#124; null) =&gt; React.ReactElement &#124; React.ReactElement[]</code> |  |
 
diff --git a/...a-plugin-plugins-expressions-public.reactexpressionrendererprops.rendererror.md b/...a-plugin-plugins-expressions-public.reactexpressionrendererprops.rendererror.md
@@ -7,5 +7,5 @@
 <b>Signature:</b>
 
 ```typescript
-renderError?: (error?: string | null) => React.ReactElement | React.ReactElement[];
+renderError?: (message?: string | null, error?: ExpressionRenderError | null) => React.ReactElement | React.ReactElement[];
 ```
diff --git a/docs/infrastructure/images/infra-sysmon.png b/docs/infrastructure/images/infra-sysmon.png
diff --git a/docs/infrastructure/index.asciidoc b/docs/infrastructure/index.asciidoc
diff --git a/docs/logs/images/logs-console.png b/docs/logs/images/logs-console.png
diff --git a/docs/logs/index.asciidoc b/docs/logs/index.asciidoc
diff --git a/docs/management/alerting/alert-management.asciidoc b/docs/management/alerting/alert-management.asciidoc
@@ -4,7 +4,7 @@
 
 beta[]
 
-The *Alerts* tab provides a cross-app view of alerting. Different {kib} apps like <<xpack-infra, Metrics>>, <<xpack-apm, APM>>, <<xpack-uptime, Uptime>>, and <<xpack-siem, SIEM>> can offer their own alerts, and the *Alerts* tab provides a central place to:
+The *Alerts* tab provides a cross-app view of alerting. Different {kib} apps like <<metrics-app,Metrics>>, <<xpack-apm,APM>>, <<uptime-app,Uptime>>, and <<xpack-siem,SIEM>> can offer their own alerts, and the *Alerts* tab provides a central place to:
 
 * <<create-edit-alerts, Create and edit>> alerts
 * <<controlling-alerts, Control alerts>> including enabling/disabling, muting/unmuting, and deleting
@@ -39,7 +39,7 @@ image::images/alerts-filter-by-action-type.png[Filtering the alert list by type
 [[create-edit-alerts]]
 ==== Creating and editing alerts
 
-Many alerts must be created within the context of a {kib} app like <<xpack-infra, Metrics>>, <<xpack-apm, APM>>, or <<xpack-uptime, Uptime>>, but others are generic. Generic alert types can be created in the *Alerts* management UI by clicking the *Create* button. This will launch a flyout that guides you through selecting an alert type and configuring it's properties. Refer to <<alert-types>> for details on what types of alerts are available and how to configure them.
+Many alerts must be created within the context of a {kib} app like <<metrics-app, Metrics>>, <<xpack-apm, APM>>, or <<uptime-app, Uptime>>, but others are generic. Generic alert types can be created in the *Alerts* management UI by clicking the *Create* button. This will launch a flyout that guides you through selecting an alert type and configuring it's properties. Refer to <<alert-types>> for details on what types of alerts are available and how to configure them.
 
 After an alert is created, you can re-open the flyout and change an alerts properties by clicking the *Edit* button shown on each row of the alert listing.
 

diff --git a/docs/management/ingest-pipelines/images/ingest-pipeline-processor.png b/docs/management/ingest-pipelines/images/ingest-pipeline-processor.png
diff --git a/docs/management/ingest-pipelines/ingest-pipelines.asciidoc b/docs/management/ingest-pipelines/ingest-pipelines.asciidoc
@@ -62,11 +62,40 @@ You also want to know where the request is coming from.
 
 . In *Ingest Node Pipelines*, click *Create a pipeline*.
 . Provide a name and description for the pipeline.
-. Define the processors:
+. Add a grok processor to parse the log message:
+
+.. Click *Add a processor* and select the *Grok* processor type.
+.. Set the field input to `message` and enter the following grok pattern:
 +
 [source,js]
 ----------------------------------
-[
+%{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:verb} %{DATA:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response:int} (?:-|%{NUMBER:bytes:int}) %{QS:referrer} %{QS:agent}
+----------------------------------
++
+.. Click *Update* to save the processor.
+
+. Add processors to map the date, IP, and user agent fields.
+
+.. Map the appropriate field to each processor type:
++
+--
+* **Date**: `timestamp`
+* **GeoIP**: `clientip`
+* **User agent**: `agent`
+
+For the **Date** processor, you also need to specify the date format you want to use: `dd/MMM/YYYY:HH:mm:ss Z`.
+--
+Your form should look similar to this:
++
+[role="screenshot"]
+image:management/ingest-pipelines/images/ingest-pipeline-processor.png["Processors for Ingest Node Pipelines"]
++
+Alternatively, you can click the **Import processors** link and define the processors as JSON:
++
+[source,js]
+----------------------------------
+{
+  "processors": [
     {
       "grok": {
         "field": "message",
@@ -90,19 +119,16 @@ You also want to know where the request is coming from.
       }
     }
   ]
+}
 ----------------------------------
 +
-This code defines four {ref}/ingest-processors.html[processors] that run sequentially:
+The four {ref}/ingest-processors.html[processors] will run sequentially:
 {ref}/grok-processor.html[grok], {ref}/date-processor.html[date],
-{ref}/geoip-processor.html[geoip], and {ref}/user-agent-processor.html[user_agent].
-Your form should look similar to this:
-+
-[role="screenshot"]
-image:management/ingest-pipelines/images/ingest-pipeline-processor.png["Processors for Ingest Node Pipelines"]
+{ref}/geoip-processor.html[geoip], and {ref}/user-agent-processor.html[user_agent]. You can reorder processors using the arrow icon next to each processor. 
 
-. To verify that the pipeline gives the expected outcome, click *Test pipeline*.
+. To test the pipeline to verify that it produces the expected results, click *Add documents*.
 
-. In the *Document* tab, provide the following sample document for testing:
+. In the *Documents* tab, provide a sample document for testing:
 +
 [source,js]
 ----------------------------------

diff --git a/docs/observability/images/apm-app.png b/docs/observability/images/apm-app.png
diff --git a/docs/observability/images/logs-app.png b/docs/observability/images/logs-app.png
diff --git a/docs/observability/images/metrics-app.png b/docs/observability/images/metrics-app.png
diff --git a/docs/observability/images/uptime-app.png b/docs/observability/images/uptime-app.png
diff --git a/docs/observability/index.asciidoc b/docs/observability/index.asciidoc
@@ -13,12 +13,69 @@ With *Observability*, you have:
 * *View in app* options to drill down and analyze data in the Logs, Metrics, Uptime, and APM apps.
 * An alerts chart to keep you informed of any issues that you may need to resolve quickly.
 
+{kib} provides step-by-step instructions to help you add and configure your data
+sources. The {observability-guide}/index.html[Observability Guide] is a good source for more detailed information
+and instructions.
+
 [role="screenshot"]
 image::observability/images/observability-overview.png[Observability Overview in {kib}]
 
 [float]
-== Get started
+[[logs-app]]
+== Logs
 
-{kib} provides step-by-step instructions to help you add and configure your data
-sources. The {observability-guide}/index.html[Observability Guide] is a good source for more detailed information
-and instructions.
+The {logs-app} in {kib} enables you to search, filter, and tail all your logs
+ingested into {es}. Instead of having to log into different servers, change
+directories, and tail individual files, all your logs are available in the {logs-app}.
+
+There is live streaming of logs, filtering using auto-complete, and a logs histogram
+for quick navigation. You can also use machine learning to detect specific log
+anomalies automatically and categorize log messages to quickly identify patterns in your
+log events.
+
+To get started with the {logs-app}, see {observability-guide}/ingest-logs.html[Ingest logs].
+
+[role="screenshot"]
+image::observability/images/logs-app.png[Logs app in {kib}]
+
+[float]
+[[metrics-app]]
+== Metrics
+
+The {metrics-app} in {kib} enables you to visualize infrastructure metrics
+to help diagnose problematic spikes, identify high resource utilization,
+automatically discover and track pods, and unify your metrics 
+with logs and APM data in {es}. 
+
+To get started with the {metrics-app}, see {observability-guide}/ingest-metrics.html[Ingest metrics].
+
+[role="screenshot"]
+image::observability/images/metrics-app.png[Metrics app in {kib}]
+
+[float]
+[[uptime-app]]
+== Uptime
+
+The {uptime-app} in {kib} enables you to monitor the availability and response times
+of applications and services in real time, and detect problems before they affect users.
+You can monitor the status of network endpoints via HTTP/S, TCP, and ICMP, explore
+endpoint status over time, drill down into specific monitors, and view a high-level
+snapshot of your environment at any point in time.
+
+To get started with the {uptime-app}, see {observability-guide}/ingest-uptime.html[Ingest uptime data].
+
+[role="screenshot"]
+image::observability/images/uptime-app.png[Uptime app in {kib}]
+
+[float]
+[[apm-app]]
+== APM
+
+The APM app in {kib} enables you to monitors software services and applications in real time,
+collect unhandled errors and exceptions, and automatically pick up basic host-level metrics
+and agent specific metrics.
+
+To get started with the APM app, see <<apm-ui,Set up the APM app>>.
+
+[role="screenshot"]
+image::observability/images/apm-app.png[APM app in {kib}]
diff --git a/docs/uptime/images/uptime-overview.png b/docs/uptime/images/uptime-overview.png
diff --git a/docs/uptime/index.asciidoc b/docs/uptime/index.asciidoc
diff --git a/docs/user/alerting/alert-types.asciidoc b/docs/user/alerting/alert-types.asciidoc
@@ -2,7 +2,7 @@
 [[alert-types]]
 == Alert types
 
-{kib} supplies alerts types in two ways: some are built into {kib}, while domain-specific alert types are registered by {kib} apps such as <<xpack-apm,*APM*>>, <<xpack-infra,*Metrics*>>, and <<xpack-uptime,*Uptime*>>.
+{kib} supplies alerts types in two ways: some are built into {kib}, while domain-specific alert types are registered by {kib} apps such as <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, and <<uptime-app,*Uptime*>>.
 
 This section covers built-in alert types. For domain-specific alert types, refer to the documentation for that app.