# Backport
This will backport the following commits from `main` to `8.8`:
- [Update APM links
(#156460)](https://github.com/elastic/kibana/pull/156460)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Brandon
Morelli","email":"brandon.morelli@elastic.co"},"sourceCommit":{"committedDate":"2023-05-03T01:42:18Z","message":"Update
APM links (#156460)\n\nThis PR updates three APM links. For the failing
links
in\r\nhttps://github.com/elastic/apm-server/pull/10560.","sha":"72c5d5286a651d8c4a3f7b9268a142270c7c3310","branchLabelMapping":{"^v8.9.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v8.8.0","v8.9.0"],"number":156460,"url":"https://github.com/elastic/kibana/pull/156460","mergeCommit":{"message":"Update
APM links (#156460)\n\nThis PR updates three APM links. For the failing
links
in\r\nhttps://github.com/elastic/apm-server/pull/10560.","sha":"72c5d5286a651d8c4a3f7b9268a142270c7c3310"}},"sourceBranch":"main","suggestedTargetBranches":["8.8"],"targetPullRequestStates":[{"branch":"8.8","label":"v8.8.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.9.0","labelRegex":"^v8.9.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/156460","number":156460,"mergeCommit":{"message":"Update
APM links (#156460)\n\nThis PR updates three APM links. For the failing
links
in\r\nhttps://github.com/elastic/apm-server/pull/10560.","sha":"72c5d5286a651d8c4a3f7b9268a142270c7c3310"}}]}]
BACKPORT-->
Co-authored-by: Brandon Morelli <brandon.morelli@elastic.co>
Closes#154733
Creates a new plugin for logs onboarding with wizard to organize steps
into discrete views.
#### TODO:
- [x] rename plugin to observability_onboarding
- [x] configure: UI and server plugin
- [x] enable/disable new plugin
- [x] remove the link to it from Observability nav
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Yngrid Coello <yngrid.coello@elastic.co>
Co-authored-by: Yngrid Coello <yngrdyn@gmail.com>
Resolves https://github.com/elastic/kibana/issues/135035.
In this PR, I'm removing the deprecated attribute
`alerting_framework_heath` from the alerting framework health API.
## To verify
1. Start Kibana.
2. Call `/api/alerting/_health`.
3. Notice `alerting_framework_heath` is no longer part of the HTTP API
response.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
Resolves https://github.com/elastic/kibana/issues/151457.
In this PR, I'm deprecating ephemeral tasks and their related settings.
The following settings have been deprecated with proper warning
messages:
- `xpack.task_manager.ephemeral_tasks.enabled`
- `xpack.task_manager.ephemeral_tasks.request_capacity`
- `xpack.alerting.maxEphemeralActionsPerAlert`
## To verify
1. Set the following in your `kibana.yml`
```
xpack.task_manager.ephemeral_tasks.enabled: true
xpack.task_manager.ephemeral_tasks.request_capacity: 10
xpack.alerting.maxEphemeralActionsPerAlert: 10
```
2. Start up Kibana
3. Notice the deprecation warnings about these settings appear in the
logs
4. Remove settings from step 1
## Sample warning logs
```
[2023-04-18T09:45:36.731-04:00][WARN ][config.deprecation] Configuring "xpack.alerting.maxEphemeralActionsPerAlert" is deprecated and will be removed in a future version. Remove this setting to increase action execution resiliency.
[2023-04-18T09:45:36.732-04:00][WARN ][config.deprecation] Configuring "xpack.task_manager.ephemeral_tasks.enabled" is deprecated and will be removed in a future version. Remove this setting to increase task execution resiliency.
[2023-04-18T09:45:36.732-04:00][WARN ][config.deprecation] Configuring "xpack.task_manager.ephemeral_tasks.request_capacity" is deprecated and will be removed in a future version. Remove this setting to increase task execution resiliency.
```
### Release notes
The following settings have been deprecated. Remove them to increase
task execution resiliency.
- `xpack.task_manager.ephemeral_tasks.enabled`
- `xpack.task_manager.ephemeral_tasks.request_capacity`
- `xpack.alerting.maxEphemeralActionsPerAlert`
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
Removes the warning about the email allowlist in Elastic Cloud from the docs.
It is not necessary anymore to allowlist individual email addresses in Elastic Cloud. The connector can now be used immediately without any additional config.
Instead I added a link to the list of limitations for the Elastic Cloud connector (rate-limit etc.)
resolves https://github.com/elastic/kibana/issues/135402
Allows deployments to not have the default footer added to alerting
emails via the new `xpack.actions.enableFooterInEmail` config setting.
The default value is `true`, which renders the footer. Setting the
value to `false` will cause no footer to be rendered.
Also changes the footer separator from `--` to `---`, which renders
nicer in HTML, as a `<hr>` element.
This PR adds the new configuration settings to the docs. The
configurations were added in this PR:
https://github.com/elastic/kibana/pull/154013
---------
Co-authored-by: lcawl <lcawley@elastic.co>
This PR fixes the 3rd party external plugin development workflow by
introducing a dev step for plugins that allows for development usages of
those with Kibana.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
The Android agent officially supports central configuration as of
version 0.4.0. This PR links from the central configuration
documentation to the Android agent config reference. Closes
https://github.com/elastic/observability-docs/issues/2812. cc
@LikeTheSalad
resolves https://github.com/elastic/kibana/issues/142874
The alerting framework now generates an alert UUID for every alert it
creates. The UUID will be reused for alerts which continue to be active
on subsequent runs, until the alert recovers. When the same alert (alert
instance id) becomes active again, a new UUID will be generated. These
UUIDs then identify a "span" of events for a single alert.
The rule registry plugin was already adding these UUIDs to it's own
alerts-as-data indices, and that code has now been changed to make use
of the new UUID the alerting framework generates.
- adds property in the rule task state
`alertInstances[alertInstanceId].meta.uuid`; this is where the alert
UUID is persisted across runs
- adds a new `Alert` method getUuid(): string` that can be used by rule
executors to obtain the UUID of the alert they just retrieved from the
factory; the rule registry uses this to get the UUID generated by the
alerting framework
- for the event log, adds the property `kibana.alert.uuid` to
`*-instance` event log events; this is the same field the rule registry
writes into the alerts-as-data indices
- various changes to tests to accommodate new UUID data / methods
- migrates the UUID previous stored with lifecycle alerts in the alert
state, via the rule registry *INTO* the new `meta.uuid` field in the
existing alert state.
## Summary
Replace the deprecated Jenkins specifics in the interpreting CI failures
section for something Buildkite specific.
Please bear with me, I'm not much familiar with the implementations but
found the current documentation to be obsoleted.
## Summary
Add Elastic Agent as another way to collect monitoring data.
This work is tracked by
https://github.com/elastic/observability-docs/issues/2602.
There will be additional PRs to address changes required to monitoring
docs for other stack components. TBH, it pains me a bit to see how many
places users need to go to find info about stack monitoring, but fixing
that problem is not in scope for these updates unfortunately. :-/
Please respond to questions addressed to reviewers.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
### To Do before merging
- [x] Remove questions to reviewers.
---------
Co-authored-by: Kevin Lacabane <klacabane@gmail.com>
## Summary
This plugin will contain the asset inventory and topology API in Kibana,
giving Kibana projects access to inventory and topology data via an HTTP
and/or JS API on the server and client.
[Currently proposed API
docs](https://github.com/elastic/o11y-topology-playground/tree/main/docs/api)
will be moved to this repo as well, contained inside this plugin folder,
as a part of this PR.
## Enabling the plugin
This plugin is entirely in "technical preview" and because of this, must
be specifically enabled via config for it to do anything besides being
run by the core plugin framework. To enable the server API layer, as
well as the index template management, put the following line in your
kibana.yml file:
```yml
xpack.assetManager.alphaEnabled: true
```
## Running the API integration tests
Run the functional test server with the asset manager config in place:
```shell
$ node scripts/functional_tests_server --config x-pack/test/api_integration/apis/asset_manager/config.ts
```
Then run the functional test runner with the same config, to target just
these tests:
```shell
$ node scripts/functional_test_runner --config=x-pack/test/api_integration/apis/asset_manager/config.
ts
```
_Note:_ The config file added in this folder enables the tech preview
plugin ([see file
here](https://github.com/elastic/kibana/pull/152456/files#diff-bc00de6c34c9bc131cfbdf3570c487fe9ee947e9a88a84c59d6b139b79d7708eR20)).
### Running the integration tests for verifying that the plugin is
"disabled" by default
There is a small set of tests that confirm that the endpoints return 404
and there is no index template installed if the config value is not set
in the kibana.yml file. To run this suite, use the following config:
```shell
$ node scripts/functional_tests_server --config x-pack/test/api_integration/apis/asset_manager/config_when_disabled.ts
$ node scripts/functional_test_runner --config=x-pack/test/api_integration/apis/asset_manager/config_when_disabled.
ts
```
## Testing this PR with sample data
There are some sample data mechanisms in place inside this PR to allow
us to build out the endpoints.
### View sample docs
```http
GET /api/asset-manager/assets/sample
```
This will return a list of the assets that are included if you elect to
write assets. This is a good endpoint to use to find EAN (Elastic Asset
Name) values that you may want to exclude from writing for a given time
period, to simulate assets appearing/disappearing over time.
### Write sample docs
```http
POST /api/asset-manager/assets/sample
{
"baseDateTime": "2023-02-28T12:00:00.000Z",
"excludeEans": ["k8s.cluster:cluster-002"]
}
```
This posts all of the sample asset documents to Elasticsearch using the
`baseDateTime` value as the timestamp. Any valid string or number that
is accepted by `new Date()` should work for `baseDateTime`.
The `excludeEans` value is an array of EAN ("Elastic Asset Name") values
that you don't want to write on this particular run. This way you can
have assets appear (exclude them in the past, don't exclude them during
a later run) or disappear (vice versa) and see how that shows up in
other endpoints.
**Note:** *Remember that when you curl a Kibana server API with a POST
request, you must include a `kbn-xsrf` header with any string value you
want.*
### Get asset docs from ES
```http
GET /api/asset-manager/assets?type=k8s.cluster&from=now-10m
```
This is the primary "real" endpoint available right now. It should
retrieve a list of assets based on the type/from/to/ean filter values
you specify. Once you load the sample data, this endpoint should return
results.
## Debug logging
There are some extra debug logs for ES queries that are running in the
code in this PR. To print those logs to the Kibana server console, run
Kibana using `DEBUG_LOGGER=true`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes#149338
## Summary
Sets refresh parameter to false in session create, update, and
invalidate. Previously refresh was set to 'wait_for' (or 'true' in the
case of invalidating by query).
### Tests
Several unit tests and functional tests have been updated to reflect the
change in test snapshots and to manually refresh the session index in
order to complete testing. The bulk of the test changes reside in the
[concurrent session limit
suite](66a43be28c/x-pack/test/security_api_integration/tests/session_concurrent_limit/global_limit.ts).
Flaky Test Runner for relevant test suites:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/1984
### Documentation
Adds a note to the session-management ascii doc to document a known
limitation of enforcing the concurrent sessions limit...
```
NOTE: Due to the rate at which session information is refreshed, there might be a few seconds where the concurrent session limit is not enforced.
This is something to consider for use cases where it is common to create multiple sessions simultaneously.
```
---------
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
## Summary
Updating the Debugging Kibana documentation:
1. Adding Python as additional pre-requisite technology
2. Replacing apm.dev.js configuration with updated kibana.dev.yml
approach
Similar to recent discussion in issue #79490, I've found that the
`apm.dev.js` approach is no longer working.
### Checklist
Delete any items that are not applicable to this PR.
- [X]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
### Risk Matrix
N/A
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Fixes https://github.com/elastic/kibana/issues/152495
<img width="500" alt="Screen Shot 2023-03-06 at 12 46 41 PM"
src="https://user-images.githubusercontent.com/373691/223216940-0b41a775-cbf4-424d-ab89-6c1a3b8a4c14.png">
Running Kibana in an offline environment without setting
`map.includeElasticMapsService: false` is an anti-pattern and leads to
lens and maps visualizations delaying initialization while waiting for
EMS connection. This PR ensures there is proper console notification.
Better messaging should point users to the correct resolution of setting
`map.includeElasticMapsService: false`.
The PR does not resolve the timeout issue. Not going to resolve the
timeout issue since running in an offline environment without setting
`map.includeElasticMapsService: false` is not supported.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
