mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
Your window into the Elastic Stack
657c0aa8b4
## 📓 Summary Closes https://github.com/elastic/observability-dev/issues/4490 We need to introduce a tier concept in Kibana to offer tiered versions of our Observability solution. Some time ago, the security team did something similar to introduce tiered product lines, and this work lays the foundation for a Kibana shared solution that can work with product tiers. This PoC introduces a new core `PricingService` to manage feature availability based on subscription tiers in serverless deployments. The implementation enables: - Tier-aware feature registration. - Dynamic configuration loading based on `serverless.<project-type>.<tier>.yml` files. - Client/server APIs for feature checks based on available tier (`isFeatureAvailable()`) - Backwards compatibility with existing project types (Search, Observability, Security, Chat) ## 🚶 Architecture walkthrough ### Configuration To have a mechanism that allows for performing changes at the configuration level, the `PricingService` loads and validates a strict configuration of product tiers. The available configuration is defined as follows: ```yml # serverless.oblt.yml (default config) pricing.tiers.enabled: true pricing.tiers.products: - name: observability tier: complete # serverless.oblt.complete.yml xpack.infra.enabled: true xpack.slo.enabled: true xpack.features.overrides: // Etc... # serverless.oblt.essentials.yml xpack.infra.enabled: false xpack.slo.enabled: false // Etc... # Optionally, security solution could set their product tiers from their configuration files, as they are already supported by the core pricing service # serverless.security.yml pricing.tiers.enabled: true pricing.tiers.products: - name: security tier: complete - name: endpoint tier: complete - name: cloud tier: complete ``` The Control Plane team will update how the kibana-controller inject the configuration in the `kibana.yml` file to reflect the values set during the project creation. It will also auto-load any optional `serverless.<project-type>.<tier>.yml` matching the config definition when tiers are enabled. The configuration is strictly validated against typed products. It might be very opinionated to store this validation in a core package, but it ensures strong typing across the codebase to register product features and ensure a fast-failing check in case the product tiers do not exist. ### Pricing service As far as the configuration-based approach is great to disable whole plugins and override configs, it doesn't cover all the scenarios where a specific tier wants to limit minor parts of a plugin feature (e.g., for o11y limited onboarding, we cannot disable the whole plugin). To cover these cases, the `PricingService` exposes a mechanism to register features associated with specific tiers. This is unbound from the `KibanaFeatureRegistry` mechanism, and we could consider extending its behaviour in the future as needed. Once product features are registered, the core start contract exposes a simple client to detect when a feature is available. <img width="1453" alt="Screenshot 2025-05-23 at 12 35 11" src="https://github.com/user-attachments/assets/05267c00-afe0-49c6-b518-b1ce8f4a0546" /> ## ✏️ Usage To launch Kibana with a specific product tier (e.g. observability `essentials`, mostly limiting to logs features), update the `pricing.tiers.products` in the serverless project configuration file: ```yml # serverless.oblt.yml pricing.tiers.enabled: true pricing.tiers.products: - name: observability tier: essentials ``` The above will run a Kibana serverless project in this specific tier and will load the configuration defined in `serverless.oblt.essentials.yml`, which currently disables a couple of plugins. Given this context, let's take a limited o11y onboarding when the subscription tier is `essentials`: ```ts // x-pack/solutions/observability/plugins/observability_onboarding/server/plugin.ts export class ObservabilityOnboardingPlugin { public setup(core: CoreSetup) { // ... // Register a feature available only on the complete tier core.pricing.registerProductFeatures([ { id: 'observability-complete-onboarding', products: [{ name: 'observability', tier: 'complete' }], }, ]); // ... } } // x-pack/solutions/observability/plugins/observability_onboarding/public/application/onboarding_flow_form/onboarding_flow_form.tsx const { core } = useKibana(); const isCompleteOnboardingAvailable = core.pricing.tiers.isFeatureAvailable('observability-complete-onboarding'); if (isCompleteOnboardingAvailable) { return <CompleteOnboarding />; } else { return <EssentialsOnboarding />; } ``` The results of the above changes will look as follows once Kibana is running: | Complete tier | Essentials tier | |--------|--------| | <img width="2998" alt="Screenshot 2025-05-23 at 13 51 14" src="https://github.com/user-attachments/assets/bcf7c791-4623-42e4-91ce-0622d981e7e7" /> | <img width="2996" alt="Screenshot 2025-05-23 at 13 53 36" src="https://github.com/user-attachments/assets/429c82eb-761c-4aa1-b13d-81ac95301e60" /> | The tiers client is also available server-side through the `getStartServices()` function, such that ad-hoc activity/registrations can be performed. ## 👣 Next Steps - [x] Implement pending core tests - [x] Document API usage in README --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .buildkite | ||
| .devcontainer | ||
| .github | ||
| api_docs | ||
| config | ||
| dev_docs | ||
| docs | ||
| examples | ||
| kbn_pm | ||
| legacy_rfcs | ||
| licenses | ||
| oas_docs | ||
| packages | ||
| plugins | ||
| scripts | ||
| src | ||
| typings | ||
| x-pack | ||
| .backportrc.json | ||
| .bazelignore | ||
| .bazeliskversion | ||
| .bazelrc | ||
| .bazelrc.common | ||
| .bazelversion | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| .puppeteerrc | ||
| .stylelintignore | ||
| .stylelintrc | ||
| .telemetryrc.json | ||
| .yarnrc | ||
| BUILD.bazel | ||
| catalog-info.yaml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| fleet_packages.json | ||
| github_checks_reporter.json | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json | ||
| RISK_MATRIX.mdx | ||
| run_fleet_setup_parallel.sh | ||
| SECURITY.md | ||
| sonar-project.properties | ||
| STYLEGUIDE.mdx | ||
| tsconfig.base.json | ||
| tsconfig.browser.json | ||
| tsconfig.browser_bazel.json | ||
| tsconfig.json | ||
| TYPESCRIPT.md | ||
| updatecli-compose.yaml | ||
| versions.json | ||
| WORKSPACE.bazel | ||
| yarn.lock | ||
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
| Situation | Example Kibana version | Example ES version | Outcome |
|---|---|---|---|
| Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
| ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
| ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
| ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
| ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
| ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
| ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.