## Summary This adds utilities and two strategies for merging using the [fields API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-fields.html) and the `_source` document during signal generation. This gives us the ability to support `constant_keyword`, field alias value support, some runtime fields support, and `copy_to` support. Previously we did not copy any of these values and only generated signals based on the `_source` record values. This changes the behavior to allow us to copy some of the mentioned values above. The folder of `source_fields_merging` contains a `strategy` folder and a `utils` folder which contains both the strategies and the utilities for this implementation. The two strategies are `merge_all_fields_with_source` and `merge_missing_fields_with_source`. The defaulted choice for this PR is we use `merge_missing_fields_with_source` and not the `merge_all_fields_with_source`. The reasoning is that this is much lower risk and lower behavior changes to the signals detection engine. The main driving force behind this PR is that ECS has introduced `constant_keyword` and that field has the possibility of only showing up in the fields section of a document and not `_source` when index authors do not push the `constant_keyword` into the `_source` section. The secondary driving forces behind this behavioral change is that some users have been expecting their runtime fields, `copy_to` fields, and field alias values of their indexes to be copied into the signals index. Both strategies of `merge_missing_fields_with_source` and `merge_all_fields_with_source` are considered Best Effort meaning that both strategies will not always merge as expected when they encounter ambiguous use cases as outlined in the `README.md` text at the top of `source_fields_merging` in detail. The default used strategy of `merge_missing_fields_with_source` which has the simplest behavior will work in most common use cases. This is simply if the `_source` document is missing a value that is present in the `fields`, and the `fields` value is a primitive concrete value such as a `string` or `number` or `boolean` and the `_source` document does not contain an existing object or ambiguous array, then the value will be merged into `_source` and a new reference is returned. If you call the strategy twice it should be idempotent meaning that the second call will detect a value is now present in `_source` and not re-merge a second time. * 301 unit tests were added * Extensive README.md docs are added * e2e tests are updated to test scenarios and ambiguity and conflicts from previously to support this effort. * Other e2e tests were updated * One bug with EQL and fields was found with a workaround implemented. See https://github.com/elastic/elasticsearch/issues/74582 * SearchTypes adjusted to use recursive TypeScript types * Changed deprecated for `@deprecated` in a few spots * Removed some `ts-expect-error` in favor of `??` in a few areas * Added a new handling of epoch strings and tests to `detection_engine/signals/utils.ts` since fields returns `epoch_millis` as a string instead of as a number. * Uses lodash safer set to reduce changes of prototype pollution ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### Risk Matrix | Risk | Probability | Severity | Mitigation/Notes | |---------------------------|-------------|----------|-------------------------| | Prototype pollution | Low | High | Used lodash safer set | | Users which have existing rules that work, upgrade and now we do not generate signals due to bad merging of fields and _source | Mid | High | We use the safer strategy method, `merge_missing_fields_with_source `, that is lighter weight to start with. We might add a follow up PR which enables a key in Kibana to turn off merging of fields with source. We added extensive unit tests and e2e tests. However, unexpected unknowns and behaviors from runtime fields and fields API such as geo-points looking like nested fields or `epoch_milliseconds` being a string value or runtime fields allowing invalid values were uncovered and tests and utilities around that have been added which makes this PR risky | | Found a bug with using fields and EQL which caused EQL rules to not run. | Low | High | Implemented workaround for tests to pass and created an Elastic ticket and communicated the bug to EQL developers. | |
||
---|---|---|
.buildkite | ||
.ci | ||
.github | ||
api_docs | ||
config | ||
dev_docs | ||
docs | ||
examples | ||
licenses | ||
packages | ||
plugins | ||
rfcs | ||
scripts | ||
src | ||
tasks/config | ||
test | ||
typings | ||
utilities | ||
vars | ||
x-pack | ||
.backportrc.json | ||
.bazelignore | ||
.bazeliskversion | ||
.bazelrc | ||
.bazelrc.common | ||
.bazelversion | ||
.browserslistrc | ||
.editorconfig | ||
.eslintignore | ||
.eslintrc.js | ||
.fossa.yml | ||
.gitattributes | ||
.gitignore | ||
.i18nrc.json | ||
.node-version | ||
.npmrc | ||
.nvmrc | ||
.prettierignore | ||
.prettierrc | ||
.stylelintignore | ||
.stylelintrc | ||
.telemetryrc.json | ||
.yarnrc | ||
api-documenter.json | ||
BUILD.bazel | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
FAQ.md | ||
github_checks_reporter.json | ||
Gruntfile.js | ||
Jenkinsfile | ||
jest.config.integration.js | ||
jest.config.js | ||
kibana.d.ts | ||
LICENSE.txt | ||
NOTICE.txt | ||
package.json | ||
preinstall_check.js | ||
README.md | ||
renovate.json5 | ||
RISK_MATRIX.mdx | ||
SECURITY.md | ||
STYLEGUIDE.mdx | ||
tsconfig.base.json | ||
tsconfig.browser.json | ||
tsconfig.json | ||
tsconfig.refs.json | ||
tsconfig.types.json | ||
TYPESCRIPT.md | ||
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.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.