Merge branch 'main' into issue_118866_observability

.github/CODEOWNERS

@@ -177,6 +177,8 @@
 /x-pack/test/functional/services/ml/  @elastic/ml-ui
 /x-pack/test/functional_basic/apps/ml/ @elastic/ml-ui
 /x-pack/test/functional_with_es_ssl/apps/ml/ @elastic/ml-ui
+/x-pack/test/alerting_api_integration/spaces_only/tests/alerting/ml_rule_types/ @elastic/ml-ui
+/x-pack/test/alerting_api_integration/spaces_only/tests/alerting/transform_rule_types/ @elastic/ml-ui
 
 # ML team owns and maintains the transform plugin despite it living in the Data management section.
 /x-pack/plugins/transform/  @elastic/ml-ui

NOTICE.txt

@@ -295,7 +295,7 @@ MIT License http://www.opensource.org/licenses/mit-license
 ---
 This product includes code that is adapted from mapbox-gl-js, which is
 available under a "BSD-3-Clause" license.
-https://github.com/mapbox/mapbox-gl-js/blob/master/src/util/image.js
+https://github.com/mapbox/mapbox-gl-js/blob/v1.13.2/src/util/image.js
 
 Copyright (c) 2016, Mapbox
 

docs/developer/getting-started/debugging.asciidoc

@@ -130,71 +130,3 @@ Once you're finished, you can stop Kibana normally, then stop the {es} and APM s
 ----
 ./scripts/compose.py stop
 ----
-
-=== Using {kib} server logs
-{kib} Logs is a great way to see what's going on in your application and to debug performance issues. Navigating through a large number of generated logs can be overwhelming, and following are some techniques that you can use to optimize the process.
-
-Start by defining a problem area that you are interested in. For example, you might be interested in seeing how a particular {kib} Plugin is performing, so no need to gather logs for all of {kib}. Or you might want to focus on a particular feature, such as requests from the {kib} server to the {es} server.
-Depending on your needs, you can configure {kib} to generate logs for a specific feature.
-[source,yml]
-----
-logging:
-  appenders:
-    file:
-      type: file
-      fileName: ./kibana.log
-      layout:
-        type: json
-
-### gather all the Kibana logs into a file
-logging.root:
-    appenders: [file]
-    level: all
-
-### or gather a subset of the logs
-logging.loggers:
-  ### responses to an HTTP request
-  - name: http.server.response
-    level: debug
-    appenders: [file]
-  ### result of a query to the Elasticsearch server
-  - name: elasticsearch.query
-    level: debug
-    appenders: [file]
-  ### logs generated by my plugin
-  - name: plugins.myPlugin
-    level: debug
-    appenders: [file]
-----
-WARNING: Kibana's `file` appender is configured to produce logs in https://www.elastic.co/guide/en/ecs/master/ecs-reference.html[ECS JSON] format. It's the only format that includes the meta information necessary for https://www.elastic.co/guide/en/apm/agent/nodejs/current/log-correlation.html[log correlation] out-of-the-box.
-
-The next step is to define what https://www.elastic.co/observability[observability tools] are available. 
-For a better experience, set up an https://www.elastic.co/guide/en/apm/get-started/current/observability-integrations.html[Observability integration] provided by Elastic to debug your application with the <<debugging-logs-apm-ui, APM UI.>>
-To debug something quickly without setting up additional tooling, you can work with <<plain-kibana-logs, the plain {kib} logs.>>
-
-[[debugging-logs-apm-ui]]
-==== APM UI
-*Prerequisites* {kib} logs are configured to be in https://www.elastic.co/guide/en/ecs/master/ecs-reference.html[ECS JSON] format to include tracing identifiers.
-
-To debug {kib} with the APM UI, you must set up the APM infrastructure. You can find instructions for the setup process
-https://www.elastic.co/guide/en/apm/get-started/current/observability-integrations.html[on the Observability integrations page].
-
-Once you set up the APM infrastructure, you can enable the APM agent and put {kib} under load to collect APM events. To analyze the collected metrics and logs, use the APM UI as demonstrated https://www.elastic.co/guide/en/kibana/master/transactions.html#transaction-trace-sample[in the docs].
-
-[[plain-kibana-logs]]
-==== Plain {kib} logs
-*Prerequisites* {kib} logs are configured to be in https://www.elastic.co/guide/en/ecs/master/ecs-reference.html[ECS JSON] format to include tracing identifiers.
-
-Open {kib} Logs and search for an operation you are interested in.
-For example, suppose you want to investigate the response times for queries to the `/api/telemetry/v2/clusters/_stats` {kib} endpoint.
-Open Kibana Logs and search for the HTTP server response for the endpoint. It looks similar to the following (some fields are omitted for brevity).
-[source,json]
-----
-{
-  "message":"POST /api/telemetry/v2/clusters/_stats 200 1014ms - 43.2KB",
-  "log":{"level":"DEBUG","logger":"http.server.response"},
-  "trace":{"id":"9b99131a6f66587971ef085ef97dfd07"},
-  "transaction":{"id":"d0c5bbf14f5febca"}
-}
-----
-You are interested in the https://www.elastic.co/guide/en/ecs/current/ecs-tracing.html#field-trace-id[trace.id] field, which is a unique identifier of a trace. The `trace.id` provides a way to group multiple events, like transactions, which belong together. You can search for `"trace":{"id":"9b99131a6f66587971ef085ef97dfd07"}` to get all the logs that belong to the same trace. This enables you to see how many {es} requests were triggered during the `9b99131a6f66587971ef085ef97dfd07` trace, what they looked like, what {es} endpoints were hit, and so on.

docs/developer/plugin-list.asciidoc

@@ -540,6 +540,11 @@ Elastic.
 |Add tagging capability to saved objects
 
 
+|{kib-repo}blob/{branch}/x-pack/plugins/screenshotting/README.md[screenshotting]
+|This plugin provides functionality to take screenshots of the Kibana pages.
+It uses Chromium and Puppeteer underneath to run the browser in headless mode.
+
+
 |{kib-repo}blob/{branch}/x-pack/plugins/searchprofiler/README.md[searchprofiler]
 |The search profiler consumes the Profile API
 by sending a search API with profile: true enabled in the request body. The response contains

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

@@ -88,6 +88,7 @@ readonly links: {
             readonly usersAccess: string;
         };
         readonly workplaceSearch: {
+            readonly apiKeys: string;
             readonly box: string;
             readonly confluenceCloud: string;
             readonly confluenceServer: string;
@@ -289,7 +290,14 @@ readonly links: {
         }>;
         readonly watcher: Record<string, string>;
         readonly ccs: Record<string, string>;
-        readonly plugins: Record<string, string>;
+        readonly plugins: {
+            azureRepo: string;
+            gcsRepo: string;
+            hdfsRepo: string;
+            s3Repo: string;
+            snapshotRestoreRepos: string;
+            mapperSize: string;
+        };
         readonly snapshotRestore: Record<string, string>;
         readonly ingest: Record<string, string>;
         readonly fleet: Readonly<{

docs/osquery/osquery.asciidoc

@@ -288,13 +288,21 @@ This is useful for teams who need in-depth and detailed control.
 
 [float]
 === Customize Osquery configuration
-By default, all Osquery Manager integrations share the same osquery configuration. However, you can customize how Osquery is configured by editing the Osquery Manager integration for each agent policy
+experimental[] By default, all Osquery Manager integrations share the same osquery configuration. However, you can customize how Osquery is configured by editing the Osquery Manager integration for each agent policy
 you want to adjust. The custom configuration is then applied to all agents in the policy. 
 This powerful feature allows you to configure
 https://osquery.readthedocs.io/en/stable/deployment/file-integrity-monitoring[File Integrity Monitoring], https://osquery.readthedocs.io/en/stable/deployment/process-auditing[Process auditing], 
 and https://osquery.readthedocs.io/en/stable/deployment/configuration/#configuration-specification[others].
 
-IMPORTANT: Take caution when editing this configuration. The changes you make are distributed to all agents in the policy.
+[IMPORTANT]
+=========================
+
+* Take caution when editing this configuration. The changes you make are distributed to all agents in the policy.
+
+* Take caution when editing `packs` using the Advanced *Osquery config* field. 
+Any changes you make to `packs` from this field are not reflected in the UI on the Osquery *Packs* page in {kib}, however, these changes are deployed to agents in the policy. 
+While this allows you to use advanced Osquery functionality like pack discovery queries, you do lose the ability to manage packs defined this way from the Osquery *Packs* page.
+=========================
 
 . From the {kib} main menu, click *Fleet*, then the *Agent policies* tab.
 
@@ -315,6 +323,16 @@ IMPORTANT: Take caution when editing this configuration. The changes you make ar
 * (Optional) To load a full configuration file, drag and drop an Osquery `.conf` file into the area at the bottom of the page.
 
 . Click *Save integration* to apply the custom configuration to all agents in the policy.
++
+As an example, the following configuration disables two tables.
++
+```ts
+{
+   "options":{
+      "disable_tables":"curl,process_envs"
+   }
+}
+```
 
 [float]
 === Upgrade Osquery versions

docs/settings/apm-settings.asciidoc

@@ -101,8 +101,8 @@ Changing these settings may disable features of the APM App.
 | `xpack.apm.indices.sourcemap` {ess-icon}
   | Matcher for all source map indices. Defaults to `apm-*`.
 
-| `xpack.apm.autocreateApmIndexPattern` {ess-icon}
-  | Set to `false` to disable the automatic creation of the APM index pattern when the APM app is opened. Defaults to `true`.
+| `xpack.apm.autoCreateApmDataView` {ess-icon}
+  | Set to `false` to disable the automatic creation of the APM data view when the APM app is opened. Defaults to `true`.
 |===
 
-// end::general-apm-settings[]
+// end::general-apm-settings[]

docs/settings/fleet-settings.asciidoc

@@ -87,6 +87,7 @@ Optional properties are:
   `data_output_id`:: ID of the output to send data (Need to be identical to `monitoring_output_id`)
   `monitoring_output_id`:: ID of the output to send monitoring data. (Need to be identical to `data_output_id`)
   `package_policies`:: List of integration policies to add to this policy.
+    `id`::: Unique ID of the integration policy. The ID may be a number or string.
     `name`::: (required) Name of the integration policy.
     `package`::: (required) Integration that this policy configures
       `name`:::: Name of the integration associated with this policy.
@@ -128,6 +129,7 @@ xpack.fleet.agentPolicies:
       - package:
           name: system
         name: System Integration
+        id: preconfigured-system
         inputs:
           - type: system/metrics
             enabled: true

docs/settings/monitoring-settings.asciidoc

@@ -72,6 +72,9 @@ For more information, see
 | `monitoring.ui.elasticsearch.ssl`
   | Shares the same configuration as <<elasticsearch-ssl-cert-key, `elasticsearch.ssl`>>. These settings configure encrypted communication between {kib} and the monitoring cluster.
 
+| `monitoring.cluster_alerts.allowedSpaces` {ess-icon}
+  | Specifies the spaces where cluster Stack Monitoring alerts can be created. You must specify all spaces where you want to generate alerts, including the default space. Defaults to `[ "default" ]`.
+
 |===
 
 [float]

docs/settings/spaces-settings.asciidoc

@@ -12,11 +12,3 @@ The maximum number of spaces that you can use with the {kib} instance. Some {kib
 return all spaces using a single `_search` from {es}, so you must
 configure this setting lower than the `index.max_result_window` in {es}.
 The default is `1000`.
-
-`monitoring.cluster_alerts.allowedSpaces` {ess-icon}:: 
-Specifies the spaces where cluster alerts are automatically generated. 
-You must specify all spaces where you want to generate alerts, including the default space. 
-When the default space is unspecified, {kib} is unable to generate an alert for the default space.
-{es} clusters that run on {es} services are all containers. To send monitoring data 
-from your self-managed {es} installation to {es} services, set to `false`. 
-The default is `true`.

docs/settings/url-drilldown-settings.asciidoc

@@ -6,16 +6,13 @@
 
 Configure the URL drilldown settings in your `kibana.yml` configuration file.
 
-[cols="2*<"]
-|===
-| [[external-URL-policy]] `externalUrl.policy`
- | Configures the external URL policies. URL drilldowns respect the global *External URL* service, which you can use to deny or allow external URLs.
+[[external-URL-policy]] `externalUrl.policy`::
+Configures the external URL policies. URL drilldowns respect the global *External URL* service, which you can use to deny or allow external URLs.
 By default all external URLs are allowed.
-|===
-
-For example, to allow external URLs only to the `example.com` domain with the `https` scheme, except for the `danger.example.com` sub-domain,
++
+For example, to allow only external URLs to the `example.com` domain with the `https` scheme, except for the `danger.example.com` sub-domain,
 which is denied even when `https` scheme is used:
-
++
 ["source","yml"]
 -----------
 externalUrl.policy:
@@ -25,4 +22,3 @@ externalUrl.policy:
     host: example.com
     protocol: https
 -----------
-