45df5fdf42
* Mark incoming plugin members as readonly
These cannot and should not be modifiable.
* Use env var instead of EnvironmentMode
* There doesn't appear to be an EnvMode in the new platform
* We're only using envMode to check whether we're in production
* We're already using process.env.NODE_ENV elsewhere
We can revisit this, but for now I'm simplifying things under this
assumption.
* Pass our setup context to the compose function
We're going to retrieve our router instance from this, for now.
* Remove unused static files route
I spent a few minutes trying to do this in the new platform, only to
realize that this was cargo culted from another plugin's structure and
never used.
* WIP: convert main GraphQL endpoints to New Platform
Splits the existing dual-method route into separate GET/POST
routes, while converting it to the NP routing syntax
TODO:
* Full route schema declarations
* Address context being moved off of the response object and into its
own object; callWithRequest is currently broken for this reason.
* Remove unnecesary Request type
While the defaultIndex patterns can be retrieved on the request itself,
that requires this special case of our FrameworkRequest.
In my smoke testing, the incoming `indices` argument was never different from
the one present on the request payload. Xavier had mentioned that these
might be redundant and a relic of some quick prototyping, so I'm going
to simplify this logic and delete that type under this assumption.
* Retrieve Elasticsearch client from RequestHandlerContext
In order to minimize the amount of noise on this refactor, I'm adding
the RequestHandlerContext to the existing FrameworkRequest object that
we already pass around.
This also removes some adapter methods that were cribbed from infra but
have since become unused. There are likely more.
* Use uiSettings client from RequestHandlerContext
Pulls from the new platform instead of from request.server.
* Remove unused properties from RequestFacade
One of these was obviated by the refactor to NP routing; the other may
never have been necessary.
* Remove unused interface
This is a relic that is no longer used in the codebase.
* Make error response code dynamic
* Handle GraphQL errors
Refactors to use new platform's responses instead of Boom.
Unless we intentionally do not want isGraphQLError error headers, I saw no
reason for the latter two branches of this method (and merged them).
* Fix graphiQL route
We needed to loosen the restriction on our main POST graphQL route, as
the requests coming from graphiQL do not match our normal format.
* Clean up logging
* Remove unused var injection functionality
I could not find a case where we were using these vars within the siem
app.
* Fix typo on config fetching
* Migrate to NP IndexPatterns service
* Removes unused extra parameter on callWithRequest
* I think this was a relic from the infra code
* Clean up typings of callWithRequest
* GenericParams is, ironically, not generic enough to handle all ES
client calls. Instead we type it as Record<string, any> but ensure
that our function adheres to the APICaller interface.
* Use savedObjects client in request context
These resolvers already receive a request containing the NP context, so
we can retrieve our client directly from that, now.
* Rename dependencies -> plugins to match kibana.json
* Remove unnecessary type annotation
The type of callCluster is already checked due to being passed to the
IndexPatternsFetcher constructor.
* Add siem plugin to new platform
For now this just generates a config observable with some defaults;
everything still lives in the legacy plugin.
* WIP: flattening out plugin initialization
Rather than pass our legacy API around everywhere, let's be explicit
about who needs what, and start flattening things out so that we can
move the legacy-independent stuff over.
* Pass our plugin context to initServerWithKibana
We can get the NP equivalent of `pkg.version` from
context.env.packageInfo.version, so let's do that and remove a usage of
config().
* Simplify siem configuration
As far as I can tell, the only siem config that we're using is
`xpack.siem.enabled`. The `query` was a holdover from infra, and if
we're using the `sources` queries at all, it's only with the default
values. Since our config is not typed, trying to add `sources` config
only results in runtime errors.
This removes the KibanaConfigurationAdapter entirely, and instead passes
what is effectively { sources: {} } to the SourcesConfigurationAdapter.
* Run all legacy-free setup through our plugin
Once this is vetted, we should be able to move the entire tree under the
plugin into the new platform plugin. We can inline the compose and
init_server calls into the plugin once things are vetted and stable; for
now leaving them there cuts down on the diff.
* Temporarily ignore our unused config declaration
* Fix detection engine route tests
While we're passing a properly bound route function in the app, the
tests' interfaces needed to be updated. Adds a helper method for
retrieving a bound route function from a Server object.
* Add some rudimentary schema validation to our graphQL endpoints
* Remove defunct server.config fn
The last remaining usage of this config was removed in #51985.
* Group our dev endpoints together
The graphiQL endpoint is the only thing that currently uses the GET
endpoint; everything else that talks to graphQL uses POST. For that
reason, I'm putting them in the same scope (along with annotating here)
to make that a bit clearer.
* Determine environment from plugin context
The kibana platform did and does provide this interface to check with
environment we're running in.
* Migrate xpack_main to NP features service
* Fix some issues missed in the previous merge
DE added some dependencies on both the server and request objects. Most
have NP equivalents and can be converted, but for now let's just add
them back to the Facades and convert in another PR.
Also changes one function to pull plugins from the server object, rather
than the server object living on the request (as this is how similar
functions are structured right now).
* Fix type resulting from bad merge resolution
* Fix type error due to incorrect usage of Hapi.Request
Pull elasticsearch service off our legacy server object, rather than
indirectly off the request object. Still legacy, but it's one less step
for later.
|
||
|---|---|---|
| .ci | ||
| .github | ||
| bin | ||
| common/graphql | ||
| config | ||
| data | ||
| docs | ||
| licenses | ||
| packages | ||
| rfcs | ||
| 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.