Merge branch 'master' into fix-delete-bug

api_docs/data.json

@@ -27594,4 +27594,4 @@
       }
     ]
   }
-}
+}

api_docs/data_search.json

@@ -19470,4 +19470,4 @@
       }
     ]
   }
-}
+}

api_docs/expressions.json

@@ -33883,4 +33883,4 @@
       }
     ]
   }
-}
+}

docs/apm/correlations.asciidoc

@@ -3,16 +3,16 @@
 === Find latency and error correlations
 
 **Correlations** surface attributes of your data that are potentially correlated with high-latency or erroneous transactions.
-Surfaced attributes are user-defined, meaning that they are completely customizable to your APM data.
+By default, a number of attributes commonly known to cause performance issues, like version,
+infrastructure, and location, are included, but all are completely customizable to your APM data.
 Find something interesting? A quick click of a button will auto-query your data as you work to resolve the underlying issue.
 
 For example, a site reliability engineer, who is responsible for keeping production systems up and running,
 notices an increase in latency in certain transactions.
 Analyzing metadata or tags that exist in high-latency transactions but not in lower-latency transactions
 can potentially point towards the root cause.
 They may find that a particular piece of hardware, like a host or pod, has failed, increasing latency.
-Or, perhaps a set of users, based on IP address or region, is physically too far away from the nearest
-data center, increasing latency.
+Or, perhaps set of users, based on IP address or region, is facing increased latency due to local data center issues.
 
 [discrete]
 [[view-correlations]]
@@ -27,8 +27,8 @@ Queries within the APM app apply to the correlations shown in the correlations f
 
 If a correlated field seems noteworthy, use the **Filter** quick links:
 
-* `+` creates a new query in the APM app for transactions containing the selected value.
-* `-` creates a new query in the APM app for transactions without the selected value.
+* `+` creates a new query in the APM app for filtering transactions containing the selected value.
+* `-` creates a new query in the APM app to filter out transactions containing the selected value.
 
 [discrete]
 [[correlations-latency]]
@@ -37,8 +37,9 @@ If a correlated field seems noteworthy, use the **Filter** quick links:
 Correlations help you discover which fields are contributing to increased service latency.
 
 A latency distribution chart visualizes the overall latency of the selected service's transactions.
-Correlated attributes are sorted by _Impact_–a visual representation of the score for the underlying
-aggregation that powers correlations.
+Correlated attributes are sorted by _Impact_–a visual representation of the
+{ref}/search-aggregations-bucket-significantterms-aggregation.html[significant terms aggregation]
+score that powers correlations.
 Attributes with a high impact, or attributes present in a large percentage of slow transactions,
 may contribute to increased latency.
 
@@ -51,19 +52,25 @@ exists primarily in higher-latency transactions between 3.7 and 8.7 seconds.
 [role="screenshot"]
 image::apm/images/correlations-hover.png[Correlations hover effect]
 
-Selecting the `+` filter creates a new query in the APM app for transactions with
+Select the `+` filter to create a new query in the APM app for transactions with
 `user_agent.name: HeadlessChrome`. With the "noise" now filtered out,
 you can begin viewing sample traces to continue your investigation.
 
+As you sift through high-latency transactions, you'll likely notice other interesting attributes.
+Return to the correlations fly-out and select *Customize fields* to search on these new attributes.
+You may need to do this a few times–each time filtering out more and more noise and bringing you
+closer to a diagnosis.
+
 [discrete]
 [[correlations-error-rate]]
 ==== Find error rate correlations
 
 Correlations help you discover which fields are contributing to failed transactions.
 
 The Error rate over time chart visualizes the change in error rate over the selected time frame.
-Correlated attributes are sorted by _Impact_–a visual representation of the score for the underlying
-aggregation that powers correlations.
+Correlated attributes are sorted by _Impact_–a visual representation of the
+{ref}/search-aggregations-bucket-significantterms-aggregation.html[significant terms aggregation]
+score that powers correlations.
 Attributes with a high impact, or attributes present in a large percentage of failed transactions,
 may contribute to increased error rates.
 
@@ -76,16 +83,41 @@ existed in 100% of failed transactions between 6:00 and 10:30.
 [role="screenshot"]
 image::apm/images/error-rate-hover.png[Correlations errors hover effect]
 
-Selecting the `+` filter creates a new query in the APM app for transactions with
+Select the `+` filter to create a new query in the APM app for transactions with
 `url.original: http://localhost:3100...`. With the "noise" now filtered out,
 you can begin viewing sample traces to continue your investigation.
 
+As you sift through erroneous transactions, you'll likely notice other interesting attributes.
+Return to the correlations fly-out and select *Customize fields* to search on these new attributes.
+You may need to do this a few times–each time filtering out more and more noise and bringing you
+closer to a diagnosis.
+
 [discrete]
-[[correlations-custom-fields]]
+[[correlations-customize-fields]]
 ====  Customize fields
 
 Correlations are only as good as the data they're searching for.
-By default, a handful of potentially useful fields are selected, like `lables`, `service.version`, and `host.ip`.
-You can remove and add fields to this list under the **Customize fields** dropdown.
+By default, a handful of attributes commonly known to cause performance issues are included.
+During the course of an investigation however, you may to need to add and remove fields from
+this list multiple times as you narrow in on a diagnosis.
+
+Add and remove fields under the **Customize fields** dropdown.
+The following fields are selected by default.
+To keep the default list manageable, only the first six matching fields with wildcards are used.
+
+**Frontend (RUM) agent:**
+
+* `labels.*`
+* `user.*`
+* `user_agent.name`
+* `user_agent.os.name`
+* `url.original`
+
+**Backend agents:**
+
+* `labels.*`
+* `host.ip`
+* `service.node.name`
+* `service.version`
 
 TIP: Want to start over? Select **reset** to clear your customizations.

docs/apm/troubleshooting.asciidoc

@@ -20,7 +20,7 @@ don't forget to check our other troubleshooting guides or discussion forum:
 * {apm-php-ref}/troubleshooting.html[PHP agent troubleshooting]
 * {apm-py-ref}/troubleshooting.html[Python agent troubleshooting]
 * {apm-ruby-ref}/debugging.html[Ruby agent troubleshooting]
-* {apm-rum-ref/troubleshooting.html[RUM troubleshooting]
+* {apm-rum-ref}/troubleshooting.html[RUM troubleshooting]
 * https://discuss.elastic.co/c/apm[APM discussion forum].
 
 [discrete]

docs/developer/telemetry.asciidoc

@@ -6,6 +6,7 @@ To help us provide a good developer experience, we track some straightforward me
 The operations we current report timing data for:
 
 * Total execution time of `yarn kbn bootstrap`
+* Total execution time of `@kbn/optimizer` runs as well as the following metadata about the runs: The number of bundles created, the number of bundles which were cached, usage of `--watch`, `--dist`, `--workers` and `--no-cache` flags, and the count of themes being built.
 
 Along with the execution time of each execution, we ship the following information about your machine to the service:
 

docs/development/core/public/kibana-plugin-core-public.doclinksstart.links.md

@@ -99,7 +99,6 @@ readonly links: {
             readonly luceneExpressions: string;
         };
         readonly indexPatterns: {
-            readonly loadingData: string;
             readonly introduction: string;
         };
         readonly addData: string;

docs/development/core/server/kibana-plugin-core-server.md

@@ -300,7 +300,7 @@ The plugin integrates with the core system via lifecycle events: `setup`<!-- -->
 |  [SavedObjectAttributeSingle](./kibana-plugin-core-server.savedobjectattributesingle.md) | Don't use this type, it's simply a helper type for [SavedObjectAttribute](./kibana-plugin-core-server.savedobjectattribute.md) |
 |  [SavedObjectMigrationFn](./kibana-plugin-core-server.savedobjectmigrationfn.md) | A migration function for a [saved object type](./kibana-plugin-core-server.savedobjectstype.md) used to migrate it to a given version |
 |  [SavedObjectSanitizedDoc](./kibana-plugin-core-server.savedobjectsanitizeddoc.md) | Describes Saved Object documents that have passed through the migration framework and are guaranteed to have a <code>references</code> root property. |
-|  [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistance and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
+|  [SavedObjectsClientContract](./kibana-plugin-core-server.savedobjectsclientcontract.md) | Saved Objects is Kibana's data persisentence mechanism allowing plugins to use Elasticsearch for storing plugin state.<!-- -->\#\# SavedObjectsClient errors<!-- -->Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:<!-- -->1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)<!-- -->Type 1 errors are inevitable, but since all expected/handle-able errors should be Type 2 the <code>isXYZError()</code> helpers exposed at <code>SavedObjectsErrorHelpers</code> should be used to understand and manage error responses from the <code>SavedObjectsClient</code>.<!-- -->Type 2 errors are decorated versions of the source error, so if the elasticsearch client threw an error it will be decorated based on its type. That means that rather than looking for <code>error.body.error.type</code> or doing substring checks on <code>error.body.error.reason</code>, just use the helpers to understand the meaning of the error:<!-- -->\`\`\`<!-- -->js if (SavedObjectsErrorHelpers.isNotFoundError(error)) { // handle 404 }<!-- -->if (SavedObjectsErrorHelpers.isNotAuthorizedError(error)) { // 401 handling should be automatic, but in case you wanted to know }<!-- -->// always rethrow the error unless you handle it throw error; \`\`\`<!-- -->\#\#\# 404s from missing index<!-- -->From the perspective of application code and APIs the SavedObjectsClient is a black box that persists objects. One of the internal details that users have no control over is that we use an elasticsearch index for persistance and that index might be missing.<!-- -->At the time of writing we are in the process of transitioning away from the operating assumption that the SavedObjects index is always available. Part of this transition is handling errors resulting from an index missing. These used to trigger a 500 error in most cases, and in others cause 404s with different error messages.<!-- -->From my (Spencer) perspective, a 404 from the SavedObjectsApi is a 404; The object the request/call was targeting could not be found. This is why \#14141 takes special care to ensure that 404 errors are generic and don't distinguish between index missing or document missing.<!-- -->See [SavedObjectsClient](./kibana-plugin-core-server.savedobjectsclient.md) See [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md) |
 |  [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md) | Describes the factory used to create instances of the Saved Objects Client. |
 |  [SavedObjectsClientFactoryProvider](./kibana-plugin-core-server.savedobjectsclientfactoryprovider.md) | Provider to invoke to retrieve a [SavedObjectsClientFactory](./kibana-plugin-core-server.savedobjectsclientfactory.md)<!-- -->. |
 |  [SavedObjectsClientWrapperFactory](./kibana-plugin-core-server.savedobjectsclientwrapperfactory.md) | Describes the factory used to create instances of Saved Objects Client Wrappers. |

docs/development/core/server/kibana-plugin-core-server.savedobjectsclientcontract.md

@@ -8,7 +8,7 @@ Saved Objects is Kibana's data persisentence mechanism allowing plugins to use E
 
 \#\# SavedObjectsClient errors
 
-Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to application code. Ideally, all errors will be either:
+Since the SavedObjectsClient has its hands in everything we are a little paranoid about the way we present errors back to to application code. Ideally, all errors will be either:
 
 1. Caused by bad implementation (ie. undefined is not a function) and as such unpredictable 2. An error that has been classified and decorated appropriately by the decorators in [SavedObjectsErrorHelpers](./kibana-plugin-core-server.savedobjectserrorhelpers.md)