Merge branch 'master' into xy-plugin-new-palette

Author: kibanamachine

.github/CODEOWNERS

@@ -236,6 +236,7 @@ x-pack/plugins/telemetry_collection_xpack/schema/xpack_plugins.json @elastic/kib
 # Security
 /src/core/server/csp/  @elastic/kibana-security @elastic/kibana-core
 /src/plugins/security_oss/ @elastic/kibana-security
+/src/plugins/spaces_oss/ @elastic/kibana-security
 /test/security_functional/ @elastic/kibana-security
 /x-pack/plugins/spaces/  @elastic/kibana-security
 /x-pack/plugins/encrypted_saved_objects/  @elastic/kibana-security

docs/apm/images/all-instances.png

@@ -2,4 +2,107 @@
 [[service-overview]]
 === Service overview
 
-Selecting a <<services,*service*>> brings you to the *Service overview*.
+Selecting a <<services,*service*>> brings you to the *Service overview*.
+The *Service overview* contains a wide variety of charts and tables that provide
+visibility into how a service performs across your infrastructure.
+
+[discrete]
+[[service-latency]]
+=== Latency
+
+Response times for the service. You can filter the *Latency* chart to display the average,
+95th, or 99th percentile latency times for the service.
+
+[role="screenshot"]
+image::apm/images/latency.png[Service latency]
+
+[discrete]
+[[service-traffic-transactions]]
+=== Traffic and transactions
+
+The *Traffic* chart visualizes the average number of transactions per minute for the selected service.
+
+The *Transactions* table displays a list of _transaction groups_ for the
+selected service and includes the latency, traffic, error rate, and the impact for each transaction.
+Transactions that share the same name are grouped, and only one entry is displayed for each group.
+
+By default, transaction groups are sorted by _Impact_ to show the most used and slowest endpoints in your
+service. If there is a particular endpoint you are interested in, click *View transactions* to view a
+list of similar transactions on the <<transactions, transactions overview>> page.
+
+[role="screenshot"]
+image::apm/images/traffic-transactions.png[Traffic and transactions]
+
+[discrete]
+[[service-error-rates]]
+=== Error rate and errors
+
+The *Error rate* chart displays the average error rates relating to the service, within a specific time range.
+
+The *Errors* table provides a high-level view of each error message when it first and last occurred,
+along with the total number of occurrences. This makes it very easy to quickly see which errors affect
+your services and take actions to rectify them. To do so, click *View errors*.
+
+[role="screenshot"]
+image::apm/images/error-rate.png[Error rate and errors]
+
+[discrete]
+[[service-span-duration]]
+=== Span types average duration and dependencies
+
+The *Average duration by span type* chart visualizes each span type's average duration and helps you determine
+which spans could be slowing down transactions. The "app" label displayed under the
+chart indicates that something was happening within the application. This could signal that the
+agent does not have auto-instrumentation for whatever was happening during that time or that the time was spent in the
+application code and not in database or external requests.
+
+The *Dependencies* table displays a list of downstream services or external connections relevant
+to the service at the selected time range. The table displays latency, traffic, error rate, and the impact of
+each dependency. By default, dependencies are sorted by _Impact_ to show the most used and the slowest dependency.
+If there is a particular dependency you are interested in, click *View service map* to view the related
+<<service-maps, service map>>.
+
+[role="screenshot"]
+image::apm/images/spans-dependencies.png[Span type duration and dependencies]
+
+[discrete]
+[[service-instances]]
+=== All instances
+
+The *All instances* table displays a list of all the available service instances within the selected time range.
+Depending on how the service runs, the instance could be a host or a container. The table displays latency, traffic,
+errors, CPU usage, and memory usage for each instance. By default, instances are sorted by _Traffic_.
+
+[role="screenshot"]
+image::apm/images/all-instances.png[All instances]
+
+[discrete]
+[[service-metadata]]
+=== Service metadata
+
+To view metadata relating to the service agent, and if relevant, the container and cloud provider,
+click on each icon located at the top of the page beside the service name.
+
+[role="screenshot"]
+image::apm/images/metadata-icons.png[Service metadata]
+
+*Service information*
+
+* Service version
+* Runtime name and version
+* Framework name
+* Agent name and version
+
+*Container information*
+
+* Operating system
+* Containerized - Yes or no.
+* Total number of instances
+* Orchestration
+
+*Cloud provider information*
+
+* Cloud provider
+* Availability zones
+* Machine types
+* Project ID

docs/apm/images/error-rate.png

@@ -24,6 +24,7 @@ Like in the Transaction duration graph, you can zoom in on anomalies to further
 
 *Error rate*::
 Visualize the total number of transactions with errors divided by the total number of transactions.
+The error rate value is based on the `event.outcome` field and is the relative number of failed transactions.
 Any unexpected increases, decreases, or irregular patterns can be investigated further
 with the <<errors,errors overview>>.
 

docs/apm/images/latency.png

@@ -9,7 +9,7 @@ Theses files must be updated when upgrading Node.js:
 
   - {kib-repo}blob/{branch}/.ci/Dockerfile[`.ci/Dockerfile`] - The version is specified in the `NODE_VERSION` constant.
     This is used to pull the relevant image from https://hub.docker.com/_/node[Docker Hub].
-    Note that Docker Hub can take 24+ hours to be updated with the new images after a new release of Node.js, so if you're upgrading Node.js in Kibana _just_ after the official Node.js release, you have to check if the new images are present on Docker Hub.
+    Note that Docker Hub can take 24+ hours to be updated with the new images after a new release of Node.js, so if you're upgrading Node.js in Kibana just after the official Node.js release, you have to check if the new images are present on Docker Hub.
     If they are not, and the update is urgent, you can skip this file and update it later once Docker Hub has been updated.
   - {kib-repo}blob/{branch}/.node-version[`.node-version`]
   - {kib-repo}blob/{branch}/.nvmrc[`.nvmrc`]
@@ -29,7 +29,7 @@ Hence, upgrades to either Node.js 14 or Node.js 10 shold be done as separate PRs
 
 ==== Node.js patch upgrades
 
-Typically, you want to backport Node.js *patch* upgrades to all supported release branches that run the same _major_ Node.js version:
+Typically, you want to backport Node.js *patch* upgrades to all supported release branches that run the same *major* Node.js version:
 
   - If upgrading Node.js 14, and the current release is 7.11.1, the main PR should target `master` and be backported to `7.x` and `7.11`.
   - If upgrading Node.js 10, the main PR should target `6.8` only.