- Kibana Guide: other versions:
- What is Kibana?
- What’s new in 8.13
- Kibana concepts
- Quick start
- Set up
- Install Kibana
- Configure Kibana
- Alerting and action settings
- APM settings
- Banners settings
- Cases settings
- Enterprise Search settings
- Fleet settings
- i18n settings
- Logging settings
- Logs settings
- Metrics settings
- Monitoring settings
- Reporting settings
- Search sessions settings
- Secure settings
- Security settings
- Spaces settings
- Task Manager settings
- Telemetry settings
- URL drilldown settings
- Start and stop Kibana
- Access Kibana
- Securing access to Kibana
- Add data
- Upgrade Kibana
- Configure security
- Configure reporting
- Configure logging
- Configure monitoring
- Command line tools
- Production considerations
- Discover
- Dashboard and visualizations
- Canvas
- Maps
- Build a map to compare metrics by country or region
- Track, visualize, and alert on assets in real time
- Map custom regions with reverse geocoding
- Heat map layer
- Tile layer
- Vector layer
- Plot big data
- Search geographic data
- Configure map settings
- Connect to Elastic Maps Service
- Import geospatial data
- Troubleshoot
- Reporting and sharing
- Machine learning
- Graph
- Alerting
- Observability
- APM
- Set up
- Get started
- How-to guides
- Configure APM agents with central config
- Control access to APM data
- Create an alert
- Create custom links
- Filter data
- Find transaction latency and failure correlations
- Identify deployment details for APM agents
- Integrate with machine learning
- Exploring mobile sessions with Discover
- Viewing sessions with Discover
- Observe Lambda functions
- Query your data
- Storage Explorer
- Track deployments with annotations
- Users and privileges
- Settings
- REST API
- Troubleshooting
- Security
- Dev Tools
- Fleet
- Osquery
- Stack Monitoring
- Stack Management
- REST API
- Get features API
- Kibana spaces APIs
- Kibana role management APIs
- User session management APIs
- Saved objects APIs
- Data views API
- Get all data views
- Get data view
- Create data view
- Update data view
- Delete data view
- Swap references preview
- Swap references
- Get default data view
- Set default data view
- Update data view fields metadata
- Get runtime field
- Create runtime field
- Upsert runtime field
- Update runtime field
- Delete runtime field
- Index patterns APIs
- Alerting APIs
- Action and connector APIs
- Cases APIs
- Add comment
- Create case
- Delete cases
- Delete comments
- Find case activity
- Find cases
- Find connectors
- Get alerts
- Get case activity
- Get case
- Get case status
- Get cases by alert
- Get comments
- Get configuration
- Get reporters
- Get tags
- Push case
- Set configuration
- Update cases
- Update comment
- Update configuration
- Import and export dashboard APIs
- Logstash configuration management APIs
- Machine learning APIs
- Osquery manager API
- Short URLs APIs
- Get Task Manager health
- Upgrade assistant APIs
- Synthetics APIs
- Uptime APIs
- Kibana plugins
- Troubleshooting
- Accessibility
- Release notes
- Kibana 8.13.4
- Kibana 8.13.3
- Kibana 8.13.2
- Kibana 8.13.1
- Kibana 8.13.0
- Kibana 8.12.2
- Kibana 8.12.1
- Kibana 8.12.0
- Kibana 8.11.4
- Kibana 8.11.3
- Kibana 8.11.2
- Kibana 8.11.1
- Kibana 8.11.0
- Kibana 8.10.4
- Kibana 8.10.3
- Kibana 8.10.2
- Kibana 8.10.1
- Kibana 8.10.0
- Kibana 8.9.2
- Kibana 8.9.1
- Kibana 8.9.0
- Kibana 8.8.2
- Kibana 8.8.1
- Kibana 8.8.0
- Kibana 8.7.1
- Kibana 8.7.0
- Kibana 8.6.1
- Kibana 8.6.0
- Kibana 8.5.2
- Kibana 8.5.1
- Kibana 8.5.0
- Kibana 8.4.3
- Kibana 8.4.2
- Kibana 8.4.1
- Kibana 8.4.0
- Kibana 8.3.3
- Kibana 8.3.2
- Kibana 8.3.1
- Kibana 8.3.0
- Kibana 8.2.3
- Kibana 8.2.2
- Kibana 8.2.1
- Kibana 8.2.0
- Kibana 8.1.3
- Kibana 8.1.2
- Kibana 8.1.1
- Kibana 8.1.0
- Kibana 8.0.0
- Kibana 8.0.0-rc2
- Kibana 8.0.0-rc1
- Kibana 8.0.0-beta1
- Kibana 8.0.0-alpha2
- Kibana 8.0.0-alpha1
- Developer guide
Configuration service
editConfiguration service
editKibana provides ConfigService
for plugin developers that want to support
adjustable runtime behavior for their plugins.
Plugins can only read their own configuration values, it is not possible to access the configuration values from Kibana Core or other plugins directly.
The Configuration service is only available server side.
// in Legacy platform const basePath = config.get('server.basePath'); // in Kibana Platform 'basePath' belongs to the http service const basePath = core.http.basePath.get(request);
To have access to your plugin config, you should:
-
Declare plugin-specific
configPath
(will fallback to pluginid
if not specified) in your plugin definition. -
Export schema validation for the config from plugin’s main file. Schema is
mandatory. If a plugin reads from the config without schema declaration,
ConfigService
will throw an error.
my_plugin/server/index.ts
import { schema, TypeOf } from '@kbn/config-schema'; export const plugin = … export const config = { schema: schema.object(…), }; export type MyPluginConfigType = TypeOf<typeof config.schema>;
-
Read config value exposed via
PluginInitializerContext
:
my_plugin/server/plugin.ts
import type { PluginInitializerContext } from '@kbn/core/server'; export class MyPlugin { constructor(initializerContext: PluginInitializerContext) { this.config$ = initializerContext.config.create<MyPluginConfigType>(); // or if config is optional: this.config$ = initializerContext.config.createIfExists<MyPluginConfigType>(); } ... }
If your plugin also has a client-side part, you can also expose
configuration properties to it using the configuration exposeToBrowser
allow-list property.
my_plugin/server/index.ts
import { schema, TypeOf } from '@kbn/config-schema'; import type { PluginConfigDescriptor } from '@kbn/core/server'; const configSchema = schema.object({ secret: schema.string({ defaultValue: 'Only on server' }), uiProp: schema.string({ defaultValue: 'Accessible from client' }), }); type ConfigType = TypeOf<typeof configSchema>; export const config: PluginConfigDescriptor<ConfigType> = { exposeToBrowser: { uiProp: true, }, schema: configSchema, };
Configuration containing only the exposed properties will be then
available on the client-side using the plugin’s initializerContext
:
my_plugin/public/index.ts
interface ClientConfigType { uiProp: string; } export class MyPlugin implements Plugin<PluginSetup, PluginStart> { constructor(private readonly initializerContext: PluginInitializerContext) {} public async setup(core: CoreSetup, deps: {}) { const config = this.initializerContext.config.get<ClientConfigType>(); }
All plugins are considered enabled by default. If you want to disable
your plugin, you could declare the enabled
flag in the plugin
config. This is a special Kibana Platform key. Kibana reads its
value and won’t create a plugin instance if enabled: false
.
export const config = { schema: schema.object({ enabled: schema.boolean({ defaultValue: false }) }), };
Handle plugin configuration deprecations
editIf your plugin has deprecated configuration keys, you can describe them using
the deprecations
config descriptor field.
Deprecations are managed on a per-plugin basis, meaning you don’t need to specify
the whole property path, but use the relative path from your plugin’s
configuration root.
my_plugin/server/index.ts
import { schema, TypeOf } from '@kbn/config-schema'; import type { PluginConfigDescriptor } from '@kbn/core/server'; const configSchema = schema.object({ newProperty: schema.string({ defaultValue: 'Some string' }), }); type ConfigType = TypeOf<typeof configSchema>; export const config: PluginConfigDescriptor<ConfigType> = { schema: configSchema, deprecations: ({ rename, unused }) => [ rename('oldProperty', 'newProperty'), unused('someUnusedProperty'), ], };
In some cases, accessing the whole configuration for deprecations is
necessary. For these edge cases, renameFromRoot
and unusedFromRoot
are also accessible when declaring deprecations.
my_plugin/server/index.ts
export const config: PluginConfigDescriptor<ConfigType> = { schema: configSchema, deprecations: ({ renameFromRoot, unusedFromRoot }) => [ renameFromRoot('oldplugin.property', 'myplugin.property'), unusedFromRoot('oldplugin.deprecated'), ], };
Validating your configuration based on context references
editSome features require special configuration when running in different modes (dev/prod/dist, or even serverless). For purpose, core injects the following references in the validation’s context:
Context Reference | Potential values | Description |
---|---|---|
|
|
Is Kibana running in Dev mode? |
|
|
Is Kibana running in Production mode (running from binary)? |
|
|
Is Kibana running from a distributable build (not running from source)? |
|
|
Is Kibana running in Serverless offering? |
|
|
The current version of Kibana |
|
|
The build number |
|
|
The current branch running |
|
|
The build SHA (typically refers to the last commit’s SHA) |
|
|
The ISO 8601 date of the build |
To use any of the references listed above in a config validation schema, they can be accessed via schema.contextRef('{CONTEXT_REFERENCE}')
:
export const config = { schema: schema.object({ // Enabled by default in Dev mode enabled: schema.boolean({ defaultValue: schema.contextRef('dev') }), // Setting only allowed in the Serverless offering plansForWorldPeace: schema.conditional( schema.contextRef('serverless'), true, schema.string({ defaultValue: 'Free hugs' }), schema.never() ), }), };
For Serverless vs. Traditional configuration, you are encouraged to use the offeringBasedSchema
helper:
import { schema, offeringBasedSchema } from '@kbn/config-schema' export const config = { schema: schema.object({ // Enabled by default in Dev mode enabled: schema.boolean({ defaultValue: schema.contextRef('dev') }), // Setting only allowed in the Serverless offering plansForWorldPeace: offeringBasedSchema({ serverless: schema.string({ defaultValue: 'Free hugs' }), }), }), };
On this page