mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 17:59:23 -04:00
42bf33f146
# Backport This will backport the following commits from `main` to `8.6`: - [Reduce startup time by skipping update mappings step when possible (#145604)](https://github.com/elastic/kibana/pull/145604) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Gerard Soldevila","email":"gerard.soldevila@elastic.co"},"sourceCommit":{"committedDate":"2022-11-28T14:34:58Z","message":"Reduce startup time by skipping update mappings step when possible (#145604)\n\nThe goal of this PR is to reduce the startup times of Kibana server by\r\nimproving the migration logic.\r\n\r\nFixes https://github.com/elastic/kibana/issues/145743\r\nRelated https://github.com/elastic/kibana/issues/144035)\r\n\r\nThe migration logic is run systematically at startup, whether the\r\ncustomers are upgrading or not.\r\nHistorically, these steps have been very quick, but we recently found\r\nout about some customers that have more than **one million** Saved\r\nObjects stored, making the overall startup process slow, even when there\r\nare no migrations to perform.\r\n\r\nThis PR specifically targets the case where there are no migrations to\r\nperform, aka a Kibana node is started against an ES cluster that is\r\nalready up to date wrt stack version and list of plugins.\r\n\r\nIn this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step\r\nof the migration logic, which internally runs the\r\n`updateAndPickupMappings` method, which turns out to be expensive if the\r\nsystem indices contain lots of SO.\r\n\r\n\r\nI locally tested the following scenarios too:\r\n\r\n- **Fresh install.** The step is not even run, as the `.kibana` index\r\ndid not exist ✅\r\n- **Stack version + list of plugins up to date.** Simply restarting\r\nKibana after the fresh install. The step is run and leads to `DONE`, as\r\nthe md5 hashes match those stored in `.kibana._mapping._meta` ✅\r\n- **Faking re-enabling an old plugin.** I manually removed one of the\r\nMD5 hashes from the stored .kibana._mapping._meta through `curl`, and\r\nthen restarted Kibana. The step is run and leads to\r\n`UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅\r\n- **Faking updating a plugin.** Same as the previous one, but altering\r\nan existing md5 stored in the metas. ✅\r\n\r\nAnd that is the curl command used to tamper with the stored _meta:\r\n```bash\r\ncurl -X PUT \"kibana:changeme@localhost:9200/.kibana/_mapping?pretty\" -H 'Content-Type: application/json' -d'\r\n{\r\n \"_meta\": {\r\n \"migrationMappingPropertyHashes\": {\r\n \"references\": \"7997cf5a56cc02bdc9c93361bde732b0\",\r\n }\r\n }\r\n}\r\n'\r\n```","sha":"b1e18a0414ed99456706119d15173b687c6e7366","branchLabelMapping":{"^v8.7.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","enhancement","release_note:skip","Feature:Migrations","backport:prev-minor","v8.7.0"],"number":145604,"url":"https://github.com/elastic/kibana/pull/145604","mergeCommit":{"message":"Reduce startup time by skipping update mappings step when possible (#145604)\n\nThe goal of this PR is to reduce the startup times of Kibana server by\r\nimproving the migration logic.\r\n\r\nFixes https://github.com/elastic/kibana/issues/145743\r\nRelated https://github.com/elastic/kibana/issues/144035)\r\n\r\nThe migration logic is run systematically at startup, whether the\r\ncustomers are upgrading or not.\r\nHistorically, these steps have been very quick, but we recently found\r\nout about some customers that have more than **one million** Saved\r\nObjects stored, making the overall startup process slow, even when there\r\nare no migrations to perform.\r\n\r\nThis PR specifically targets the case where there are no migrations to\r\nperform, aka a Kibana node is started against an ES cluster that is\r\nalready up to date wrt stack version and list of plugins.\r\n\r\nIn this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step\r\nof the migration logic, which internally runs the\r\n`updateAndPickupMappings` method, which turns out to be expensive if the\r\nsystem indices contain lots of SO.\r\n\r\n\r\nI locally tested the following scenarios too:\r\n\r\n- **Fresh install.** The step is not even run, as the `.kibana` index\r\ndid not exist ✅\r\n- **Stack version + list of plugins up to date.** Simply restarting\r\nKibana after the fresh install. The step is run and leads to `DONE`, as\r\nthe md5 hashes match those stored in `.kibana._mapping._meta` ✅\r\n- **Faking re-enabling an old plugin.** I manually removed one of the\r\nMD5 hashes from the stored .kibana._mapping._meta through `curl`, and\r\nthen restarted Kibana. The step is run and leads to\r\n`UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅\r\n- **Faking updating a plugin.** Same as the previous one, but altering\r\nan existing md5 stored in the metas. ✅\r\n\r\nAnd that is the curl command used to tamper with the stored _meta:\r\n```bash\r\ncurl -X PUT \"kibana:changeme@localhost:9200/.kibana/_mapping?pretty\" -H 'Content-Type: application/json' -d'\r\n{\r\n \"_meta\": {\r\n \"migrationMappingPropertyHashes\": {\r\n \"references\": \"7997cf5a56cc02bdc9c93361bde732b0\",\r\n }\r\n }\r\n}\r\n'\r\n```","sha":"b1e18a0414ed99456706119d15173b687c6e7366"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.7.0","labelRegex":"^v8.7.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/145604","number":145604,"mergeCommit":{"message":"Reduce startup time by skipping update mappings step when possible (#145604)\n\nThe goal of this PR is to reduce the startup times of Kibana server by\r\nimproving the migration logic.\r\n\r\nFixes https://github.com/elastic/kibana/issues/145743\r\nRelated https://github.com/elastic/kibana/issues/144035)\r\n\r\nThe migration logic is run systematically at startup, whether the\r\ncustomers are upgrading or not.\r\nHistorically, these steps have been very quick, but we recently found\r\nout about some customers that have more than **one million** Saved\r\nObjects stored, making the overall startup process slow, even when there\r\nare no migrations to perform.\r\n\r\nThis PR specifically targets the case where there are no migrations to\r\nperform, aka a Kibana node is started against an ES cluster that is\r\nalready up to date wrt stack version and list of plugins.\r\n\r\nIn this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step\r\nof the migration logic, which internally runs the\r\n`updateAndPickupMappings` method, which turns out to be expensive if the\r\nsystem indices contain lots of SO.\r\n\r\n\r\nI locally tested the following scenarios too:\r\n\r\n- **Fresh install.** The step is not even run, as the `.kibana` index\r\ndid not exist ✅\r\n- **Stack version + list of plugins up to date.** Simply restarting\r\nKibana after the fresh install. The step is run and leads to `DONE`, as\r\nthe md5 hashes match those stored in `.kibana._mapping._meta` ✅\r\n- **Faking re-enabling an old plugin.** I manually removed one of the\r\nMD5 hashes from the stored .kibana._mapping._meta through `curl`, and\r\nthen restarted Kibana. The step is run and leads to\r\n`UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅\r\n- **Faking updating a plugin.** Same as the previous one, but altering\r\nan existing md5 stored in the metas. ✅\r\n\r\nAnd that is the curl command used to tamper with the stored _meta:\r\n```bash\r\ncurl -X PUT \"kibana:changeme@localhost:9200/.kibana/_mapping?pretty\" -H 'Content-Type: application/json' -d'\r\n{\r\n \"_meta\": {\r\n \"migrationMappingPropertyHashes\": {\r\n \"references\": \"7997cf5a56cc02bdc9c93361bde732b0\",\r\n }\r\n }\r\n}\r\n'\r\n```","sha":"b1e18a0414ed99456706119d15173b687c6e7366"}}]}] BACKPORT--> |
||
|---|---|---|
| .. | ||
| analytics | ||
| content-management | ||
| core | ||
| home | ||
| kbn-ace | ||
| kbn-alerts | ||
| kbn-ambient-storybook-types | ||
| kbn-ambient-ui-types | ||
| kbn-analytics | ||
| kbn-apm-config-loader | ||
| kbn-apm-synthtrace | ||
| kbn-apm-utils | ||
| kbn-axe-config | ||
| kbn-babel-plugin-synthetic-packages | ||
| kbn-babel-preset | ||
| kbn-bazel-packages | ||
| kbn-bazel-runner | ||
| kbn-cases-components | ||
| kbn-chart-icons | ||
| kbn-ci-stats-core | ||
| kbn-ci-stats-performance-metrics | ||
| kbn-ci-stats-reporter | ||
| kbn-cli-dev-mode | ||
| kbn-coloring | ||
| kbn-config | ||
| kbn-config-mocks | ||
| kbn-config-schema | ||
| kbn-crypto | ||
| kbn-crypto-browser | ||
| kbn-datemath | ||
| kbn-dev-cli-errors | ||
| kbn-dev-cli-runner | ||
| kbn-dev-proc-runner | ||
| kbn-dev-utils | ||
| kbn-doc-links | ||
| kbn-docs-utils | ||
| kbn-ebt-tools | ||
| kbn-es | ||
| kbn-es-archiver | ||
| kbn-es-errors | ||
| kbn-es-query | ||
| kbn-es-types | ||
| kbn-eslint-config | ||
| kbn-eslint-plugin-disable | ||
| kbn-eslint-plugin-eslint | ||
| kbn-eslint-plugin-imports | ||
| kbn-expect | ||
| kbn-failed-test-reporter-cli | ||
| kbn-field-types | ||
| kbn-find-used-node-modules | ||
| kbn-flot-charts | ||
| kbn-ftr-common-functional-services | ||
| kbn-ftr-screenshot-filename | ||
| kbn-generate | ||
| kbn-get-repo-files | ||
| kbn-guided-onboarding | ||
| kbn-handlebars | ||
| kbn-hapi-mocks | ||
| kbn-health-gateway-server | ||
| kbn-i18n | ||
| kbn-i18n-react | ||
| kbn-import-resolver | ||
| kbn-interpreter | ||
| kbn-io-ts-utils | ||
| kbn-jest-serializers | ||
| kbn-journeys | ||
| kbn-kibana-manifest-schema | ||
| kbn-language-documentation-popover | ||
| kbn-logging | ||
| kbn-logging-mocks | ||
| kbn-managed-vscode-config | ||
| kbn-managed-vscode-config-cli | ||
| kbn-mapbox-gl | ||
| kbn-monaco | ||
| kbn-optimizer | ||
| kbn-optimizer-webpack-helpers | ||
| kbn-osquery-io-ts-types | ||
| kbn-performance-testing-dataset-extractor | ||
| kbn-plugin-discovery | ||
| kbn-plugin-generator | ||
| kbn-plugin-helpers | ||
| kbn-react-field | ||
| kbn-repo-source-classifier | ||
| kbn-repo-source-classifier-cli | ||
| kbn-rule-data-utils | ||
| kbn-safer-lodash-set | ||
| kbn-securitysolution-autocomplete | ||
| kbn-securitysolution-es-utils | ||
| kbn-securitysolution-exception-list-components | ||
| kbn-securitysolution-hook-utils | ||
| kbn-securitysolution-io-ts-alerting-types | ||
| kbn-securitysolution-io-ts-list-types | ||
| kbn-securitysolution-io-ts-types | ||
| kbn-securitysolution-io-ts-utils | ||
| kbn-securitysolution-list-api | ||
| kbn-securitysolution-list-constants | ||
| kbn-securitysolution-list-hooks | ||
| kbn-securitysolution-list-utils | ||
| kbn-securitysolution-rules | ||
| kbn-securitysolution-t-grid | ||
| kbn-securitysolution-utils | ||
| kbn-server-http-tools | ||
| kbn-server-route-repository | ||
| kbn-shared-svg | ||
| kbn-shared-ux-utility | ||
| kbn-some-dev-log | ||
| kbn-sort-package-json | ||
| kbn-spec-to-console | ||
| kbn-std | ||
| kbn-stdio-dev-helpers | ||
| kbn-storybook | ||
| kbn-synthetic-package-map | ||
| kbn-telemetry-tools | ||
| kbn-test | ||
| kbn-test-jest-helpers | ||
| kbn-test-subj-selector | ||
| kbn-timelion-grammar | ||
| kbn-tinymath | ||
| kbn-tooling-log | ||
| kbn-type-summarizer | ||
| kbn-type-summarizer-cli | ||
| kbn-type-summarizer-core | ||
| kbn-typed-react-router-config | ||
| kbn-ui-framework | ||
| kbn-ui-shared-deps-npm | ||
| kbn-ui-shared-deps-src | ||
| kbn-ui-theme | ||
| kbn-user-profile-components | ||
| kbn-utility-types | ||
| kbn-utility-types-jest | ||
| kbn-utils | ||
| kbn-yarn-lock-validator | ||
| shared-ux | ||
| BUILD.bazel | ||
| README.md | ||
Kibana-related packages
This folder contains packages that are intended for use in Kibana and Kibana plugins.
tl;dr:
- Don't publish to npm registry
- Always use the
@kbnnamespace - Always set
"private": trueinpackage.json
Using these packages
We no longer publish these packages to the npm registry. Now, instead of specifying a version when including these packages, we rely on yarn workspaces, which sets up a symlink to the package.
For example if you want to use the @kbn/i18n package in Kibana itself, you
can specify the dependency like this:
"@kbn/i18n": "1.0.0"
However, if you want to use this from a Kibana plugin, you need to use a link:
dependency and account for the relative location of the Kibana repo, so it would
instead be:
"@kbn/i18n": "link:../../kibana/packages/kbn-i18n"
Creating a new package
Create a new sub-folder. The name of the folder should mirror the name in the
package's package.json. E.g. if the name is @kbn/i18n the folder name
should be kbn-i18n.
All new packages should use the @kbn namespace, and should be marked with
"private": true.
Unit tests for a package
Currently there is only one tool being used in order to test packages which is Jest. Below we will explain how it should be done.
Jest
A package should follow the pattern of having .test.js files as siblings of the source code files, and these run by Jest.
A package using the .test.js naming convention will have those tests automatically picked up by Jest and run by the unit test runner, currently mapped to the Kibana test script in the root package.json.
yarn testruns all unit tests.yarn jestruns all Jest tests in Kibana.
In order for the plugin or package to use Jest, a jest.config.js file must be present in it's root. However, there are safeguards for this in CI should a test file be added without a corresponding config file.
Each package can also specify its own test script in the package's package.json, for cases where you'd prefer to run the tests from the local package directory.