Create the Investigate plugin (naming TBD). Part of
https://github.com/elastic/kibana/pull/183293, splitting up the work in
several PRs.
The investigate plugin is mostly a registry to allow plugins to register
their widgets without creating dependency issues.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updates the [advanced settings
docs](https://www.elastic.co/guide/en/kibana/master/advanced-options.html)
to include the `observability:enableLegacyUptimeApp` option for enabling
the Uptime Kibana app by default (in conjunction with the Observability
doc updates in https://github.com/elastic/observability-docs/pull/3890)
The list of options (under Observability, at least) don't seem to be
alphabetical, so I've put this in where seems to be a good place, but
feel free to move it somewhere else if more appropriate.
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/3331
Given the needs described in the linked issue about having a centralized
and async way to consume field metadata across Kibana, this work focuses
on providing server/client services to consume field metadata on demand
from static ECS definition and integration manifests, with the chance to
extend further the possible resolution sources.
3b2d9027-5c29-4081-ab17-1b43618c62a7
## 💡 Reviewers hints
This PR got quite long as it involves and touches different parts of the
codebase, so I'll break down the interesting parts for an easier review.
More details, code examples and mechanics description can be found in
the README file for the plugin.
### `@kbn/fields-metadata-plugin`
To avoid bundling and consuming the whole ECS static definition
client-side, a new plugin `@kbn/fields-metadata-plugin` is created to
expose the server/client services which enable retrieving only the
fields needed on a use-case basis.
### FieldsMetadataService server side
A `FieldsMetadataService` is instantiated on the plugin setup/start
server lifecycle, exposing a client to consume the fields and setup
tools for registering external dependencies.
The start contract exposes a `FieldsMetadataClient` instance. With this,
any application in Kibana can query for some fields using the available
methods, currently:
- `FieldsMetadataClient.prototype.getByName()`: retrieves a single
`FieldMetadata` instance.
- `FieldsMetadataClient.prototype.find()`: retrieves a record of
matching `FieldMetadata` instances.
`FieldsMetadataClient` is instantiated with the source repositories
dependencies. They act as encapsulated sources which are responsible for
fetching fields from their related source. Currently, there are 2 field
repository sources used in the resolution step, but we can use this
concept to extend the resolution step in future with more sources (LLM,
OTel, ...).
The currently used sources are:
- `EcsFieldsRepository`: allows fetching static ECS field metadata.
- `IntegrationFieldsRepository`: allows fetching fields from an
integration package from EPR, where the fields metadata are stored. To
correctly consume these fields, the `fleet` plugin must be enabled,
otherwise, the service won't be able to access the registered fields
extractor implemented with the fleet services.
As this service performs a more expensive retrieval process than the
`EcsFieldsRepository` constant complexity access, a caching layer is
applied to the retrieved results from the external source to minimize
latency.
### Fields metadata API
To expose this service to the client, a first API endpoint is created to
find field metadata and filter the results to minimize the served
payload.
- `GET /internal/fields_metadata/find` supports some initial query
parameters to narrow the fields' search.
### FieldsMetadataService client side
As we have a server-side `FieldsMetadataService`, we need a client
counterpart to consume the exposed API safely and go through the
validation steps.
The client `FieldsMetadataService` works similarly to the server-side
one, exposing a client which is returned by the public start contract of
the plugin, allowing any other to directly use fields metadata
client-side.
This client would work well with existing state management solutions, as
it's not decoupled from any library.
### useFieldsMetadata
For simpler use cases where we need a quick and easy way to consume
fields metadata client-side, the plugin start contract also exposes a
`useFieldsMetadata` react custom hook, which is pre-created accessing
the FieldsMetadataService client described above. It is important to
retrieve the hook from the start contract of this plugin, as it already
gets all the required dependencies injected minimizing the effort on the
consumer side.
The `UnifiedDocViewer` plugin changes exemplify how we can use this hook
to access and filter fields' metadata quickly.
### `registerIntegrationFieldsExtractor` (@elastic/fleet)
Getting fields from an integration dataset is more complex than
accessing a static dictionary of ECS fields, and to achieve that we need
access to the PackageService implemented by the fleet team.
To get access to the package, maintain a proper separation of concerns
and avoid a direct dependency on the fleet plugin, some actions were
taken:
- the `PackageService.prototype.getPackageFieldsMetadata()` method is
implemented to keep the knowledge about retrieving package details on
this service instead of mixing it on parallel services.
- a fleet `registerIntegrationFieldsExtractor` service is created and
used during the fleet plugin setup to register a callback that accesses
the service as an internal user and retrieves the fields by the given
parameters.
- the fields metadata plugin returns a
`registerIntegrationFieldsExtractor` function from its server setup so
that we can use it to register the above-mentioned callback that
retrieves fields from an integration.
This inverts the dependency between `fields_metadata` and `fleet`
plugins so that the `fields_metadata` plugin keeps zero dependencies on
external apps.
## Adoption
We currently have places where the `@elastic/ecs` package is directly
accessed and where we might be able to refactor the codebase to consume
this service.
**[EcsFlat usages in
Kibana](https://github.com/search?q=repo%3Aelastic%2Fkibana%20EcsFlat&type=code)**
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds reference documentation about the Obs AI Assistant connector
(requested in #181282)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds `Task Manager is unhealthy - Reason: setting HealthStatus.Error
because of expired hot timestamps` to docs for resolution discussion
searchability.
### Checklist
### For maintainers
👋🏽 howdy, team! AFAICT `Task Manager is unhealthy - Reason: setting
HealthStatus.Error because of expired hot timestamps` is a newer Kibana
(Task Manager) error which generally correlates not necessarily to sheer
resource usage (cpu/heap) but workers/intervals vs load/drift. So adding
to [docs where we're already discussing
that](https://www.elastic.co/guide/en/kibana/master/task-manager-troubleshooting.html#task-manager-kibana-log)
so users+Support can search-find the appropriate conversation. Recent
high severity examples : 01607184 , 01607982 .
Relates to https://github.com/elastic/kibana/issues/183406.
## 📝 Summary
This PR creates a new plugin `data_quality` in order to register dataset
quality as a Stack management page under data section. For now there is
no reference to this new page in the sideNav in stateful or serverless.
In order to navigate to this new page you can use the url
`/app/management/data/data_quality`
Changes included in this PR:
- New plugin created
- Plugin registered in stack management, data section
- Dataset quality plugin is instantiated and the state is in sync with
URL
- Removed references to dataset quality in Logs explorer
## 🎥 Demo
501c9c47-4a1b-4f91-9be6-d022a821e88e
## 🙅🏼 Missing
- Dataset quality locator
- There are still references to logs explorer (table and flyout) that
will be handled in a follow up PR.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added solution property for the space.
- Forbidden in serverless.
- To facilitate iterative development made the property as optional in
stateful offering until all of the workstreams are complete.
### How to test API changes
```
# Should create space
POST kbn:/api/spaces/space
{
"name": "space without solution",
"id": "my-space-solution-1",
"description": "a description",
"color": "#5c5959",
"disabledFeatures": []
}
# Should fail with 400
POST kbn:/api/spaces/space
{
"name": "space with solution",
"id": "my-space-solution-2",
"description": "a description",
"color": "#5c5959",
"solution": "some_solution",
"disabledFeatures": []
}
# Should fail with 400
POST kbn:/api/spaces/space
{
"name": "space with solution",
"id": "my-space-solution-2",
"description": "a description",
"color": "#5c5959",
"solution": null,
"disabledFeatures": []
}
# Should create space
POST kbn:/api/spaces/space
{
"name": "space with solution",
"id": "my-space-solution-2",
"description": "a description",
"color": "#5c5959",
"solution": "search",
"disabledFeatures": []
}
# Should get 'my-space-solution-1' space without solution field
GET kbn:/api/spaces/space/my-space-solution-1
# Should get 'my-space-solution-2' space with solution field
GET kbn:/api/spaces/space/my-space-solution-2
# Should fail to update with 400
PUT kbn:/api/spaces/space/my-space-solution-1
{
"id": "my-space-solution-1",
"name": "my-space-solution-1 name",
"solution": "some_solution"
}
# Should fail to update with 400
PUT kbn:/api/spaces/space/my-space-solution-1
{
"id": "my-space-solution-1",
"name": "my-space-solution-1 name",
"solution": null
}
# Should update 'my-space-solution-1'
PUT kbn:/api/spaces/space/my-space-solution-1
{
"id": "my-space-solution-1",
"name": "my-space-solution-1 name",
"solution": "security"
}
# Should get 'my-space-solution-1' space wit solution field set to 'security'
GET kbn:/api/spaces/space/my-space-solution-1
# Should return list where
# 1. 'my-space-solution-1' has solution 'security'
# 2. 'my-space-solution-2' has solution 'search'
# 3. Other spaces don't have solution field present
GET kbn:/api/spaces/space
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed ([Security and Spaces
config](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6076),
[Spaces only
config](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6075))
### For maintainers
- [x] 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/183559__
## Release note
Added optional solution property for Space in a stateful offering.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161608
* [X] Depends on https://github.com/elastic/elasticsearch/pull/97765
* [x] Depends on https://github.com/elastic/elasticsearch/pull/107581
* [x] Add create a new report job and check the details of the templated
data stream.
* [x] Run Discover tests in Flaky Test Runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5999
## Release Note
Reporting internal storage has been changed from using regular indices
to a data stream configuration for a more efficient sharding strategy.
This change is not expected to have any impact to users.
## Screenshots
### Upgrade test (manual process)
Using a report generated before this change, and a report generated
after "upgrading":
Even though the two reports are in different types storage, they are
still managed by the same policy:
Looking at the details of the policy shows how the different types of
storage are used:
### Log lines
Initial startup in clean environment
```
[2024-05-13T13:22:49.138-07:00][INFO ][plugins.reporting.store] Creating ILM policy for reporting data stream: kibana-reporting
[2024-05-13T13:22:53.337-07:00][INFO ][plugins.reporting.store] Linking ILM policy to reporting data stream: .kibana-reporting, component template: kibana-reporting@custom
```
Kibana restart with ES running continuously
```
[2024-05-13T13:24:32.733-07:00][DEBUG][plugins.reporting.store] Found ILM policy kibana-reporting; skipping creation.
[2024-05-13T13:24:32.733-07:00][INFO ][plugins.reporting.store] Linking ILM policy to reporting data stream: .kibana-reporting, component template: kibana-reporting@custom
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
~~See
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/5302
(internal link)~~
Paired with @ThomThomson to expand Embeddable documentation with
"Guiding principles" and "Best practices"
PR also moves overview to src/plugins/embeddables/README.md. Then, this
markdown is displayed in the embeddable example application as well.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
## Summary
Adds a new `xpack.security.audit.ignore_filters.users` configuration
setting. This behaves similar to the existing
`xpack.security.audit.ignore_filters.spaces` configuration setting, in
that it will filter out audit events for any of the specified users.
Resolves#183136
This PR also adds documentation for the existing
`xpack.security.audit.ignore_filters.spaces` setting, as it was
previously missing.
## Testing
1) Configure audit logging, ignoring one or more users of your choosing:
```yml
# kibana.yml
xpack.security.audit:
enabled: true
appender:
type: rolling-file
fileName: ./audit.log
layout:
type: json
ignore_filters:
- users: ["elastic"]
```
2) Start Kibana and ES with a `trial` license.
3) Login as an ignored user
4) Notice the user activity is not present in the audit logs.
5) Login as a non-ignored user
6) Notice the user activity is present in the audit logs.
## Release note:
Audit logs can be filtered by username via the
`xpack.security.audit.ignore_filters.users` configuration setting.
Having the same thing in multiple places is confusing and hard to
maintain. Embeddable documentation is exposed via developer examples.
This PR removes embeddable documentation in README and dev-docs and
points those locations to the single location for embeddable
documenation.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This adds support a password protected keystore. The UX should match
other stack products.
Closes https://github.com/elastic/kibana/issues/21756.
```
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore create --password
A Kibana keystore already exists. Overwrite? [y/N] y
Enter new password for the kibana keystore (empty for no password): ********
Created Kibana keystore in /tmp/kibana-8.15.0-SNAPSHOT/config/kibana.keystore
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore add elasticsearch.username
Enter password for the kibana keystore: ********
Enter value for elasticsearch.username: *************
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore add elasticsearch.password
Enter password for the kibana keystore: ********
Enter value for elasticsearch.password: ********
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana
...
Enter password for the kibana keystore: ********
[2024-04-30T09:47:03.560-05:00][INFO ][root] Kibana is starting
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore has-passwd
Keystore is password-protected
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore show elasticsearch.username
Enter password for the kibana keystore: ********
kibana_system
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore remove elasticsearch.username
Enter password for the kibana keystore: ********
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore show elasticsearch.username
Enter password for the kibana keystore: ********
ERROR: Kibana keystore doesn't have requested key.
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore passwd
Enter password for the kibana keystore: ********
Enter new password for the kibana keystore (empty for no password):
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore has-passwd
Error: Keystore is not password protected
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana
...
[2024-04-30T09:49:03.220-05:00][INFO ][root] Kibana is starting
```
## Password input
Environment variable usage is not consistent across stack products. I
implemented `KBN_KEYSTORE_PASSWORD_FILE` and `KBN_KEYSTORE_PASSWORD` to
be used to avoid prompts. @elastic/kibana-security do you have any
thoughts?
- `LOGSTASH_KEYSTORE_PASS` -
https://www.elastic.co/guide/en/logstash/current/keystore.html#keystore-password
- `KEYSTORE_PASSWORD` -
https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#docker-keystore-bind-mount
- `ES_KEYSTORE_PASSPHRASE_FILE` -
https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html#rpm-running-systemd
- Beats discussion, unresolved:
https://github.com/elastic/beats/issues/5737
## Release note
Adds password support to the Kibana keystore.
## 📓 Summary
Closes#181528Closes#181976
**N.B.** This work was initially reviewed on a separate PR at
https://github.com/tonyghiani/kibana/pull/1.
This implementation aims to have a stateful layer that allows the
management of dependencies between Discover and other plugins, reducing
the need for a direct dependency.
Although the initial thought was to have a plugin to register features
for Discover, there might be other cases in future where we need to
prevent cyclic dependencies.
With this in mind, I created the plugin as a more generic solution to
hold stateful logic as a communication layer for Discover <-> Plugins.
## Discover Shared
Based on some recurring naming in the Kibana codebase, `discover_shared`
felt like the right place for owning these dependencies and exposing
Discover functionalities to the external world.
It is initially pretty simple and only exposes a registry for the
Discover features, but might be a good place to implement other upcoming
concepts related to Discover.
Also, this plugin should ideally never depend on other solution plugins
and keep its dependencies to a bare minimum of packages and core/data
services.
```mermaid
flowchart TD
A(Discover) -- Get --> E[DiscoverShared]
B(Logs Explorer) -- Set --> E[DiscoverShared]
C(Security) -- Set --> E[DiscoverShared]
D(Any app) -- Set --> E[DiscoverShared]
```
## DiscoverFeaturesService
This service initializes and exposes a strictly typed registry to allow
consumer apps to register additional features and Discover and retrieve
them.
The **README** file explains a real use case of when we'd need to use it
and how to do that step-by-step.
Although it introduces a more nested folder structure, I decided to
implement the service as a client-service and expose it through the
plugin lifecycle methods to provide the necessary flexibility we might
need:
- We don't know yet if any of the features we register will be done on
the setup/start steps, so having the registry available in both places
opens the door to any case we face.
- The service is client-only on purpose. My opinion is that if we ever
need to register features such as server services or anything else, it
should be scoped to a similar service dedicated for the server lifecycle
and its environment.
It should never be possible to register the ObsAIAssistant
presentational component from the server, as it should not be permitted
to register a server service in the client registry.
A server DiscoverFeaturesService is not required yet for any feature, so
I left it out to avoid overcomplicating the implementation.
## FeaturesRegistry
To have a strictly typed utility that suggests the available features on
a registry and adheres to a base contract, the registry exposed on the
DiscoverFeaturesService is an instance of the `FeaturesRegistry` class,
which implements the registration/retrieval logic such that:
- If a feature is already registered, is not possible to override it and
an error is thrown to notify the user of the collision.
- In case we need to react to registry changes, is possible to subscribe
to the registry or obtain it as an observable for more complex
scenarios.
The FeaturesRegistry already takes care of the required logic for the
registry, so that `DiscoverFeaturesService`is left with the
responsibility of instantiating/exposing an instance and provide the set
of allowed features.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
## Summary
Renames the setting from discover:enableESQL to enableESQL and moves it
to the General Section
<img width="985" alt="image"
src="ebafe7cd-4695-413c-a0e3-90e3574139e5">
We checked the telemetry and a very small percentage of users have
switched off this setting. It was also on tech preview so we decided in
favor of this change as more and more applications are using this
setting to hide ESQL from their applications.
<img width="850" alt="image"
src="404f2494-8a17-4a9d-943a-d9d72b324bc0">
### Release note
We renamed the advanced setting which hides the ES|QL from the UI from
`discover:enableESQL` to `enableESQL`. You have to switch it off again
if you want to disable ES|QL features from your kibana applications.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/100854
### Release note
The Kibana configuration file now supports assigning default value for
environment variables, using the `${VAR_ENV:defaultValue}` syntax.
Create an empty assets data access plugin so we can start registering
the services(APIs) that will be used to fetch assets type documents.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Update levels ordering
## Summary
The documentation is currently reporting a misleading information
https://www.elastic.co/guide/en/kibana/current/logging-configuration.html#log-level:
<img width="546" alt="image"
src="573f82c5-51f8-4e32-a85d-6895cc1b2041">
indeed the "maximum" should be off and the "minimum" should be all,
because:
>A log record will be logged by the logger if its level **(ed: its
refers to log)** is higher than or equal to the level of its logger.
Otherwise, the log record is ignored.
There is no value smaller than all that will result in all types of logs
being outputted.
### Checklist
Delete any items that are not applicable to this PR.
### 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)
---------
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
closes https://github.com/elastic/kibana/issues/178719
A new ES API has been created to support linking APM from the Profiling
UI. It's called `topN/functions`. The new API allows grouping fields. So
we first fetch functions grouping by `service.name` and when the user
opens the APM Transactions we make another request grouping by
`transaction.name`.
A new Advanced setting was created to toggle the old API on (fetch
functions from Stacktraces API): It's turned off by default.
<img width="1235" alt="Screenshot 2024-04-12 at 10 39 36"
src="ee6e7731-2f44-43ca-9793-23ba87e22e6e">
When there are services on the selected function:
*If we cannot find the transaction, we show `N/A`.
<img width="933" alt="Screenshot 2024-04-12 at 10 16 34"
src="2c5dbf60-3a47-4f4c-a46d-8a0984e0e482">
When there are **no** services on the selected function:
*hide the APM transactions section
<img width="921" alt="Screenshot 2024-04-12 at 10 59 14"
src="3fc4c5b1-da62-47c8-97a8-8bcbd1ae1b75">
--
Performance boost:
The new API is faster than the Stacktraces API, especially because
there's no logic on the Kibana side.
Stacktraces API:
<img width="1210" alt="Screenshot 2024-04-12 at 10 50 26"
src="158d73d1-ed91-4652-97c1-c7c3328d5e3d">
TopN/Functions API:
<img width="1195" alt="Screenshot 2024-04-12 at 10 51 20"
src="2de4ef46-eb8a-4557-b7b8-a1c2fed6fd8a">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
