## Summary
Follow up to #210579. Close#193683.
This PR removes the deprecated `visualization:useLegacyTimeAxis`
advanced setting and all related code. This setting was previously used
to enable legacy time axis behavior for charts in Lens, Discover,
Visualize and TSVB, but has been deprecated and is no longer needed. All
usage of the setting was already removed in #210579, this PR just cleans
up the advanced setting itself.
## Changes
- Removed the `visualization:useLegacyTimeAxis` UI setting registration
from the charts plugin
- Removed `LEGACY_TIME_AXIS` constant export from charts common module
- Cleaned up related TypeScript configuration dependencies
- Removed telemetry schema entries for the deprecated setting
- Removed translation strings for the deprecated setting
- Adds a saved object migration to remove the setting (see [advanced
settings
migrations](https://docs.elastic.dev/kibana-dev-docs/tutorials/advanced-settings#registering-migrations))
### Identify risks
- Identified that a saved object migration needs to be added for the
removal of the setting. See this
[PR](https://github.com/elastic/kibana/pull/157699) for reference.
- Advanced settings [can be
overridden](https://www.elastic.co/docs/extend/kibana/ui-settings-service#uisettings-overrides)
in `kibana.yml`. If the setting is present in `kibana.yml` and we remove
support for it, if verification of the file was too strict, it would
fail to start Kibana. I verified that Kibana still starts when support
for the advanced setting was removed but it's still present in
`kibana.yml`.
## Release note
Removal of the deprecated `visualization:useLegacyTimeAxis` advanced
setting.
## Summary
This PR applies **lossless compression** to all SVG and JPG/PNG assets
across Kibana using:
- [`svgo`](https://github.com/svg/svgo) — for optimizing SVGs
- [`image-optimize`](https://www.npmjs.com/package/image-optimize) — for
JPG/PNG compression
‼️**Please scroll to ''Unknown metric groups" accordion to see what's
the gain for your code.**
<img width="542" alt="Screenshot 2025-06-18 at 13 24 20"
src="https://github.com/user-attachments/assets/191afb28-44fc-4551-9026-756a8385c66a"
/>
The goal is to reduce asset size and improve load performance without
compromising visual quality.
This PR achieves a **23 MB** reduction in asset size across all images
bundled in Kibana’s running code—meaning these compressed images
directly impact what ships in Kibana.
Some assets get bundled into chunks due to our bundling strategy but
might not actually be requested at runtime.
Additionally, I ran the same optimization script on the docs assets as a
harmless extra step, but those savings aren’t included in the 23 MB
total.
---
## Why
While working on Emotion rewrites, I noticed some SVGs seemed
unnecessarily heavy. That led to a broader investigation into our image
assets, and it turns out we’re not consistently optimizing them during
development or build.
---
## Notes
- Visual fidelity of optimized assets has been manually verified — no
visible differences
- The optimization is **lossless**, meaning no quality degradation
- Some assets (like large background images) could benefit further from
**lossy compression**
---
## Follow-ups / Ideas
1. **Automate compression in the dev/build pipeline**
- e.g. add `svgo` as a pre-commit or CI step for SVGs
2. **Improve CI reporting**
- Currently, bundle size diffs for images are hidden under "Unknown
metric groups" in the GitHub CI comment. We may want to make these more
visible.
-
3. **Audit large assets manually** — apply lossy compression where
appropriate
4. **Avoid redundant image loading**
- e.g. background images on the login page are loaded again on the space
selector page since they’re bundled twice. I’m working on a separate PR
to address that.
## Snippets I used to apply the compression
```
# Find SVG files
find . -type f -iname "*.svg" \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > svg-files.txt
# Compress SVGs
while IFS= read -r file; do
svgo "$file"
done < svg-files.txt
```
This snippet has been used for png and jpg, but the example below is for
png:
```
# Find PNG files
find . -type f -iname "*.png \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > png-files.txt
# Compress PNGs
while IFS= read -r file; do
image-optimize -f jpg "$file"
done < png-files.txt
```
## Release Notes
Kibana logging's pattern layout, used by default for the console
appender, will now use a new default pattern layout
`[%date][%level][%logger] %message %error`. This will include the error
name and stack trace if these were included in the log entry. To opt out
of this behavior users can omit the `%error` placeholder from their log
pattern config in kibana.yml e.g.:
```
logging:
appenders:
console:
type: console
layout:
type: pattern
pattern: "[%date][%level][%logger] %message"
```
## Summary
Previously, when we pass the error in meta, the information related to
stacktrace and error message was not available in console. This PR
changed the default pattern to also include error information if it is
provided in meta (similar to the way that the logging happens when error
is directly passed to logger.error).
New pattern: (added `%error` at the end)
```
[%date][%level][%logger] %message %error
```
Here you can see the difference:
Logger:
```
server.logger.error(
`Unable to create Synthetics monitor ${monitorWithNamespace[ConfigKey.NAME]}`,
{ error: e }
);
```
#### Before
#### After
### Alternative
We could also change the MetaConversion and include this information,
but we might have additional meta information which I am not sure if it
is OK to be logged by default. Let me know if you prefer changing
MetaConversion instead of adding a new error conversion.
<details>
<summary>Code changes for MetaConversion</summary>
```
function isError(x: any): x is Error {
return x instanceof Error;
}
export const MetaConversion: Conversion = {
pattern: /%meta/g,
convert(record: LogRecord) {
if (!record.meta) {
return '';
}
const { error, ...rest } = record.meta;
const metaString = Object.keys(rest).length !== 0 ? JSON.stringify(rest) : '';
let errorString = '';
if (isError(record.meta?.error)) {
errorString = record.meta?.error.stack || '';
}
return [metaString, errorString].filter(Boolean).join(' ');
},
};
```
</details>
Here is how adjusting meta will look like in this case:
## Summary
Part of #218501
This PR removes the advanced setting
`observability:enableInfrastructureAssetCustomDashboards` but keeps the
saved object, to be removed in a [follow-up
issue](https://github.com/elastic/kibana/issues/220340).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates some remaining obsolete variables and mentions of
ESS/Elasticsearch Service that should now refer to Elastic Cloud Hosted.
Note: There are still a few valid references to the Elasticsearch
service, not to be mixed with the cloud offering bearing the same name.
Fixes image paths to work with docs-assembler.
Notes for the reviewer:
* I was not able to get images in reference, extend, or release-notes to
work using the `:::{image}` syntax because it seems to resolve
differently than the Markdown `![]()` syntax. We should address this in
docs-builder, but in order to get images working as soon as possible,
I've used Markdown syntax and left us a `TO DO` in a code comment to add
back the `screenshot` class where applicable.
* Can you please add the appropriate labels needed for backporting?
Related to https://github.com/elastic/docs-content/pull/914
Removes reliance on temporary redirects in the docs-content repo.
@florent-leborgne can you help me with backport labels? I always get
mixed up across repos.
This PR resolves [Link color in banner shown in blue and not the defined
color](https://github.com/elastic/kibana/issues/206266) issue.
Now there is a new option added that applies custom color specifically
for links, and can be fully customized.
- Updated documentation
- in Cloud
- advanced-settings
- configuration
- Added to plugins
- kibana_usage
- telemetry
- Implemented new 'linkColor' property for the banners
- Updated functional tests
Migrate docs from AsciiDoc to Markdown. The preview can be built after
#212557 is merged.
@florent-leborgne please tag reviewers, add the appropriate label(s),
and take this out of draft when you're ready.
Note: More files are deleted than added here because the content from
some files was moved to
[elastic/docs-content](https://github.com/elastic/docs-content).
**What has moved to
[elastic/docs-content](https://github.com/elastic/docs-content)?**
Public-facing narrative and conceptual docs have moved. Most can now be
found under the following directories in the new docs:
- explore-analyze: Discover, Dashboards, Visualizations, Reporting,
Alerting, dev tools...
- deploy-manage: Stack management (Spaces, user management, remote
clusters...)
- troubleshooting: .... troubleshooting pages
**What is staying in the Kibana repo?**
- Reference content (= anything that is or could be auto-generated):
Settings, syntax references
- Release notes
- Developer guide
---------
Co-authored-by: Florent Le Borgne <florent.leborgne@elastic.co>
