## 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
Adds reference documentation about the Obs AI Assistant connector
(requested in #181282)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.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>
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>
Closes https://github.com/elastic/kibana/issues/176069
## Summary
This adds the logic to register a new Saved Object type to store custom
dashboards for Asset Details and adds endpoints to fetch and save custom
dashboards.
Changes highlights:
* Renamed the `enableInfrastructureHostsCustomDashboards` to
`enableInfrastructureAssetCustomDashboards` to make it more generic and
support additional asset types in the future
* Added a new Saved Object type
* Moved initialization of all Infra endpoints to plugin's `start`. This
one one of the points on [the BE tech debt
ticket](https://github.com/elastic/kibana/issues/175975). Having
endpoint initialization in `start` makes it more convenient to access
start dependencies which almost all endpoints require.
* Added `savedObjectClient` and `uiSettingsClient` to the custom request
context (also one of the ideas for endpoints improvement). Right now
infra endpoints use custom `libs` object with all dependencies required
for routes, the idea is to rely on the request context instead because
it automatically available for every route handler and by default
includes some useful things like scoped service clients.
* Added a wrapper `handleRouteErrors` to avoid error handling
duplication which we now have in a few routes. In the future we could do
something similar right within `registerRoutes` framework function, but
this would require a bit of refactoring.
## Hot to Test
1. Toggle the UI setting off in Advanced Settings
2. Go to the Dev Tools and try the endpoints, both should respond with
403
```
GET kbn:api/infra/custom-dashboards/host
POST kbn:api/infra/custom-dashboards
{
"assetType": "host",
"dashboardIdList": ["0", "1"]
}
```
3. Toggle the UI setting on
4. Try the endpoints again, now they should work as expected
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/89340
Implements a third option, `system`, for the `theme:darkMode`
uiSettings, which will follow the system's theme preference (light/dark)
when Kibana loads.
82078697-8bf5-41df-add1-4ecfed6e1dea
**Note: system theme refresh still requires the user to reload Kibana -
please see the next section for the reasons if you're interested**
## How theming works in Kibana, again?
This is an excellent question, thanks for asking. And the answer is,
"well, it's complicated".
We have multiples sources of "themed" styles in Kibana, ordered from
"best" to "worse":
#### 1. the EUI/JSS Theming
It was initially implemented in
https://github.com/elastic/kibana/pull/117368. All react applications
and react mountpoints are supposed to be wrapped by a
`KibanaThemeProvider` that bridges core's `theme$` values to the
`EuiProvider`.
477505a2dd/packages/core/theme/core-theme-browser-internal/src/core_theme_provider.tsx (L11)
This one was already dynamic and just works perfectly. If
`core.theme.theme$` changes, the new values is received by the theme
provider, which automatically changes the styles accordingly, creating
this sexy "it just works" effect:
f3e61ca7-f3ed-4c37-aa46-76ee68c1a628
If everything theme-related was using this approach, dynamic theme
reload would have been possible. However, Kibana has a lot of legacy, so
as you can imagine, it wasn't that easy.
So, **don't get false hopes** (as I did when I tried it...) from this
video. Dynamic theme swap **could not** be implemented in this PR. And
the reasons are just below.
#### 2. Per-theme css files
6443b57164/packages/core/rendering/core-rendering-server-internal/src/render_utils.ts (L40-L54)
We have a bunch of dark/light variations of some css files that are
computed in the rendering service, server-side, to be injected into the
page template.
Of course, this doesn't play well with dynamic theming, given the UI
then doesn't know which css should be swapped, and which one should be
added instead.
However, porting the responsibilities of which theme css files to load
to the browser was achievable, and done in this PR. core's browser-side
`theme` provider now receives the list of theme files for both light and
dark theme (via the injected metadata), and inject them in the document
(instead of having them pre-injected in the page template by the
rendering service server-side).
So this one wasn't a blocker for dynamic theme reload.
#### 3. Plugin styles
This is where the problems start.
Plugins can ship their own styles too, by importing them from components
or from their entrypoint.
E.g this component
f1dc1e1869/src/plugins/controls/public/control_group/component/control_group_component.tsx (L9)
importing this file:
bafb23580b/src/plugins/controls/public/control_group/control_group.scss (L107-L110)
Which relies on a theme variable, `$euiFormBackgroundColor`
So how does it works under the hood? How is that
`$euiFormBackgroundColor` variable interpolated? Using which theme?
Well, technically, how the styles are effectively loaded differs
slightly between dev and production (different webpack loaders/config),
but in both cases, it depends on the `__kbnThemeTag__` variable that is
injected to the global scope by the `bootstrap.js` script.
This `__kbnThemeTag__` tag (apparently) **can** be modified after page
load. However it doesn't magically reload everything, so styles already
loaded for one theme will not reload. If a component and its imported
styles were already compiled / injected, then they won't reload
As a short video is better than 3 blocks of text, just see:
3087ffd6-80d8-42bf-ab17-691ec408ea6f
That was the first blocker for supporting "dynamic" reloads of the
system theme.
#### 4. Static inline styles
Last but not least, we have some static style injected in the template,
that also depend on the current theme.
6443b57164/packages/core/rendering/core-rendering-server-internal/src/views/styles.tsx (L52-L54)
Of course this plays very badly with dynamic theming. And worth noting,
those styles are used by the "Loading Elastic" screen, where Core (and
therefore Core's theming service) isn't loaded yet, which made the
things even more complicated.
This was the second blocker for supporting "dynamic" reloads of the
system theme.
#### 5. `euiThemeVars`
Actually TIL (not that I was asking for it)
We're exposing the EUI theme variable via the `euiThemeVars` of the
`@kbn/ui-theme` package:
E.g.
c7e785383a/src/plugins/chart_expressions/expression_metric/public/components/metric_vis.tsx (L41)c7e785383a/src/plugins/chart_expressions/expression_metric/public/components/metric_vis.tsx (L50)
So I did my best, and made it that this export was a proxy, and that
Core's theme service was dynamically swapping the target of the proxy
depending on the system's theme...
b0a0017811/packages/kbn-ui-theme/src/theme.ts (L30-L42)
Unfortunately it doesn't fully work for dynamic system theme switch,
given modules/code can keep references of the property directly (e.g.
the snippet a few lines on top), and there's nothing to dynamically
reload components when the proxy changes.
So yet another blocker for dynamic theme switch.
## Release Notes
Add a new option, `system`, to the `theme:darkMode` Kibana advanced
setting, that can be used to have Kibana's theme follow the system's
(light or dark)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This change allows the Universal Profiling agent to send error frames,
which will give us more accurate values for CO2 emission and $ costs.
The reason is that unwinding errors resulting in 0-length stacktraces
happen quite often. These are not sent to the backend currently, so the
related CPU activity doesn't go into the calculations. This can make up
showing 10% less CPU / CO2 / costs in the UI.
Adding artificial error frames in case of unwinding errors guarantees
that stacktraces always have a length of > 0.
Once we settled on how error frames can be displayed in a user-friendly
way, this code can be removed.
---------
Co-authored-by: Joel Höner <joel@elastic.co>
Co-authored-by: Caue Marcondes <caue.marcondes@elastic.co>
~This PR still needs work (tests, mainly), so keeping it in draft for
now, but feel free to take it for a spin.~
Implements Bedrock support, specifically for the Claude models.
Architecturally, this introduces LLM adapters: one for OpenAI (which is
what we already have), and one for Bedrock/Claude. The Bedrock/Claude
adapter does the following things:
- parses data from a SerDe (an AWS concept IIUC) stream using
`@smithy/eventstream-serde-node`.
- Converts function requests and results into XML and back (to some
extent)
- some slight changes to existing functionality to achieve _some_ kind
of baseline performance with Bedrock + Claude.
Generally, GPT seems better at implicit tasks. Claude needs explicit
tasks, otherwise it will take things too literally. For instance, I had
to use a function for generating a title because Claude was too eager to
add explanations. For the `classify_esql` function, I had to add extra
instructions to stop it from requesting information that is not there.
It is prone to generating invalid XML.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/173154
Adds a UI setting to control Infra+Profiling integration from Kibana's
Advanced Settings as well as from the Infra Settings screen.
Note that the plugin config feature flag is still there because I
realized we need it to disable Profiling integration in serverless.
2a5ace9d-9e18-49a4-be95-c722f24072a7
### How to test
* Make sure profiling is enabled in `kibana.dev.yml`
```
xpack.profiling.enabled: true
```
* Start kibana in traditional mode, go to Infra Settings
* Make sure there is the new toggle for Profiling integration and it's
on
* Go to one of your host's details and make sure you see the profiling
tab
* Toggle the Profiling integration setting off and check that the tap in
host details is not visible
* Start kibana in serverless mode
* Make sure there is no new setting neither in Infra Settings nor in
Advanced Settings
* Make sure Profiling tab is not visible in host details
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
