## Summary Updates the `TGrid` to use `EuiDataGrid` [schemas](https://eui.elastic.co/#/tabular-content/data-grid-schemas-and-popovers/) as suggested by @snide in the following issue: <https://github.com/elastic/kibana/issues/108894> ## Desk testing 1) In the `Security Solution`, navigate to `Security > Rules` and enable multiple detection rules that have different `Risk Score`s **Expected result** - The Detection Engine generates alerts (when the rule's criteria is met) that have different risk scores 2) Navigate to the `Security > Alerts` page **Expected results** As shown in the screenshot below: - The alerts table is sorted by `@timestamp` in descending (Z-A) order, "newest first" - The `@timestamp` field in every row is newer than, or the same time as the row below it - The alerts table shows a non-zero count of alerts, e.g. `20,600 alerts` ![alerts-table-at-page-load](https://user-images.githubusercontent.com/4459398/130700525-343d51af-7a3a-475c-b3b4-b429bc212adf.png) _Above: At page load, the alerts table is sorted by `@timestamp` in descending (Z-A) order, "newest first"_ 3) Observe the count of alerts shown in the header of the alerts table, e.g. `20,600 alerts`, and then change the global date picker in the KQL bar from `Today` to `Last 1 year` **Expected results** - The golbal date picker now reads `Last 1 year` - The count of the alerts displayed in the alerts table has increased, e.g. from `20,600 alerts` to `118,709 alerts` - The `@timestamp` field in every row is (still) newer than, or the same time as the row below it 4) Click on the `@timestamp` column, and choose `Sort A-Z` from the popover, to change the sorting to ascending, "oldest first", as shown in the screenshot below: ![click-sort-ascending](https://user-images.githubusercontent.com/4459398/130701250-3f229644-2a78-409e-80ff-f88588562190.png) _Above: Click `Sort A-Z` to sort ascending, "oldest first"_ **Expected results** As shown in the screenshot below: - The alerts table is sorted by `@timestamp` in ascending (A-Z) order, "oldest first" - The `@timestamp` field in every row is older than, or the same time as the row below it - `@timestamp` is older than the previously shown value, e.g. `Aug 3` instead of `Aug 24` ![timestamp-ascending-oldest-first](https://user-images.githubusercontent.com/4459398/130702221-cc8cf84f-c044-4574-8a93-b9d35c14c890.png) _Above: The alerts table is now sorted by `@timestamp` in ascending (A-Z) order, "oldest first"_ 5) Click on the `Risk Score` column, and choose `Sort A-Z` from the popover, to add `Risk Score` as a secondary sort in descending (Z-A) "highest first" order, as shown in the screenshot below: ![sort-risk-score](https://user-images.githubusercontent.com/4459398/130702599-e4c0d74a-8775-435b-a263-5b6b278f6dfd.png) _Above: Click `Sort A-Z` to add `Risk Score` as a secondary sort in descending (Z-A) "highest first" order_ **Expected results** - The alerts table re-fetches data - The alerts table shows `2 fields sorted` 6) Hover over the alerts table and click the `Inspect` magnifiing glass icon **Expected result** - The `Inspect` modal appaers, as shown in the screenshot below: ![inspect](https://user-images.githubusercontent.com/4459398/130702849-1189f32e-eb03-4d9d-b248-6c6f0b5665fa.png) _Above: the `Inspect` modal_ 7) Click the `Request` tab, and scroll to the `sort` section of the request **Expected result** Per the JSON shown below: - The request is sorted first by `@timestamp` in ascending (A-Z) order, "oldest first" - The request is sorted second by `signal.rule.risk_score` descending (Z-A) "highest first" order ```json "sort": [ { "@timestamp": { "order": "asc", "unmapped_type": "date" } }, { "signal.rule.risk_score": { "order": "desc", "unmapped_type": "number" } } ], ``` 8) Click `Close` to close the `Inspect` modal 9) Click `2 fields sorted` to display the sort popover 10) Use the drag handles to, via drag-and-drop, update the sorting such that `Risk Score` is sorted **before** `@timestamp`, as shown in the screenshot below: ![sort-by-risk-score-first](https://user-images.githubusercontent.com/4459398/130704159-523effa2-21ef-4599-a939-964fc523f9ec.png) _Above: Use the drag handles to, via drag-and-drop, update the sorting such that `Risk Score` is sorted **before** `@timestamp`_ **Expected results** As shown in the screenshot below: - The table is updated to be sorted first by the higest risk score, e.g. previously `47`, now `73` - The alerts table is sorted second by `@timestamp` in ascending (A-Z) order, "oldest first", and *may* have changed, e.g. from `Aug 3` to `Aug 12`, depending on the sample data in your environment ![highest-risk-score](https://user-images.githubusercontent.com/4459398/130704878-163a2427-fc7a-4755-9adc-a06b0d7b8e43.png) _Above: The alerts table is now sorted first by highest risk score_ 11) Once again, hover over the alerts table and click the `Inspect` magnifiing glass icon 12) Once again, click the `Request` tab, and scroll to the `sort` section of the request **Expected result** Per the JSON shown below: - The request is sorted first by `signal.rule.risk_score` in descending (Z-A) "highest first" order - The request is sorted second by `@timestamp` in ascending (A-Z) order, "oldest first" ```json "sort": [ { "signal.rule.risk_score": { "order": "desc", "unmapped_type": "number" } }, { "@timestamp": { "order": "asc", "unmapped_type": "date" } } ], ``` Co-authored-by: Andrew Goldstein <andrew-goldstein@users.noreply.github.com> |
||
---|---|---|
.buildkite | ||
.ci | ||
.github/ISSUE_TEMPLATE | ||
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 | ||
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 | ||
STYLEGUIDE.mdx | ||
tsconfig.base.json | ||
tsconfig.bazel.json | ||
tsconfig.browser.json | ||
tsconfig.browser_bazel.json | ||
tsconfig.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.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. | 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.