mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 17:59:23 -04:00
Your window into the Elastic Stack
cd8fe02ed0
* Add shims for new platform structure Defines both our Plugin class and the factory function. * Simplify server init code path We were doing some work with server, then dropping into another function to further mutate it. I'm moving this all to the same level (initServerWithKibana) to make decoupling from Hapi simpler to follow. * Remove unnecessary casting Server has newPlatform on it, now. * Remove unused arguments These had their usage removed in #36662 but their signature remained. Since we're trying to pin down the existing interface with hapi, this is just noise that should be deleted. * Remove unneeded destructuring This was only needed for a type assertion, originally. * Document current interface with hapi via ServerFacade This is everything we're using from hapi's server right now. The next step is moving what we can to the new platform, and abstracting the rest behind a facade layer. * Include NP plugin in initialization path * Instantiates plugin and passes NP modules * We're just passing the LoggerFactory from the init context, for now. * Whitelist functionality from Server, pass through as ServerFacade * This will verify our facade at runtime in addition to typechecking * Uses Pick and Partial to use existing types while shimming properties as we go * Remove redundant logging mechanism We were logger in two different ways, but we can move to the NP version now that it's ready. * Bind server's route function context This was causing a test failure and needed to be bound similarly to the register function. Slight rename of variables as well. * Type Hapi.Request usage via RequestFacade This is everything we're currently using from Hapi.Request; as we move things away we can update this interface and let TS tell us what's broken. Remove any typing of our request payloads These _can_ have fields like `variables` and `operationName` from graphQL, or they might not. In the majority of cases the payload was typed as any, and to cut down on churn and because I have no confidence in typing each individual request, we're going to make that the default. * Inline our GraphQL Hapi plugin A la uptime, this effectively just moves the call to server.route() into the function itself, rather than registering a Hapi plugin that ultimately does the same. * Remove register from our list of Hapi dependencies This was only used to register our GraphQL plugin(s), which are now inlined and use `route`. * Invoke existing init path from plugin's setup This isn't the final format as we're eventually doing away with __legacy entirely, but this makes our plugin 'live' and is a step in the right direction. * Remove usage of Pick in favor of a type assertion The onus here should be on the shim invocation, not the plugin itself. * Pass existing NP modules into our plugin Another step toward the proper plugin signature. We're needlessly destructuring coreContext just to get the logger and pass it right back in. The other logger usage will be removed momentarily when we change the signature of `initServerWithKibana`. Also adds core and plugins to our setup method, which are currently unused. * Remove dependence on newPlatform property in Server We now get these through NP's initializerContext, so we do that in the plugin now instead. The extra parameters are gross but temporary (initServerWithKibana will eventually go away), and it's much better to shrink the size of ServerFacade. * Remove unused mocking fn/logging/tests These are relics from the initial graphQL implementation and are no longer used. * Move log statement into plugin Makes more sense to decorate the init invocation than to log 'start' from outside and 'end' from inside. * Fix shape of our InitializerContext While PluginInitializerContext type has the env property, the newPlatform object on the Server has it in a different shape. * Ensure our request payloads are typed Rather than the free-for-all of `any`, let's instead type our payload as unknown and actually name the request types whose payloads are being reached into. A type assertion in the resolver for these requests is the secret sauce here. |
||
|---|---|---|
| .ci | ||
| .github | ||
| bin | ||
| common/graphql | ||
| config | ||
| data | ||
| docs | ||
| licenses | ||
| packages | ||
| rfcs/text | ||
| scripts | ||
| src | ||
| style_guides | ||
| tasks | ||
| test | ||
| typings | ||
| utilities | ||
| vars | ||
| webpackShims | ||
| x-pack | ||
| .backportrc.json | ||
| .browserslistrc | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .i18nrc.json | ||
| .node-version | ||
| .nvmrc | ||
| .prettierrc | ||
| .sass-lint.yml | ||
| .yarnrc | ||
| CONTRIBUTING.md | ||
| FAQ.md | ||
| github_checks_reporter.json | ||
| Gruntfile.js | ||
| Jenkinsfile | ||
| kibana.d.ts | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| package.json | ||
| preinstall_check.js | ||
| README.md | ||
| renovate.json5 | ||
| STYLEGUIDE.md | ||
| tsconfig.browser.json | ||
| tsconfig.json | ||
| tsconfig.types.json | ||
| TYPESCRIPT.md | ||
| 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.md.
- Learn more about our UI code with UI_SYSTEMS.md.
- 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. | 5.1.2 | 5.1.2 | 💚 OK |
| ES patch number is newer. | 5.1.2 | 5.1.5 | ⚠️ Logged warning |
| ES minor number is newer. | 5.1.2 | 5.5.0 | ⚠️ Logged warning |
| ES major number is newer. | 5.1.2 | 6.0.0 | 🚫 Fatal error |
| ES patch number is older. | 5.1.2 | 5.1.0 | ⚠️ Logged warning |
| ES minor number is older. | 5.1.2 | 5.0.0 | 🚫 Fatal error |
| ES major number is older. | 5.1.2 | 4.0.0 | 🚫 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.