[pull] main from elastic:main #735
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
## Summary Closes [#198995](#198995) Closes #198996 Part of #193245 This PR contains the changes to migrate `traces` test folder to Deployment-agnostic testing strategy. It also adds support for deployment-agnostic snapshots validation ### How to test - Serverless ``` node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM" ``` It's recommended to be run against [MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki) - Stateful ``` node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM" ``` - [ ] ~(OPTIONAL, only if a test has been unskipped) Run flaky test suite~ - [x] local run for serverless - [x] local run for stateful - [x] MKI run for serverless --------- Co-authored-by: Elastic Machine <[email protected]>
## Summary Let's just disallow space input as index names can't contain spaces anyway. This fixes an a11y issue raised recently. Fix (im clicking space a lot in the vid): https://github.com/user-attachments/assets/bdf3217a-2869-4814-8243-900c348e24fb ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [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 - [x] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Query `[ '*', '*:*' ]` by default when listing indices. Co-authored-by: Elastic Machine <[email protected]>
…efault Settings (#201163) ## Summary This PR solves the issues #195951 and #195942 getting the focus on the first interactive element as suggested which is the _ingest pipelines_ external link after pressing enter using the keyboard navigation either the _Reset_ or _Save_ buttons. With this the screen reader announces the _ingest pipelines_ content after any of those previous events. 
…200922) ## Summary This is part 1 of a 2-3 part PR. This involes the initial implementation of the integration RAG, while part 2 focuses on prompt tuning, and a potential part 3 is the change from local JSON file to EPR client and further tuning of prompts and search result ranking. The change introduces a new feature to the rule migration, enriching the current graph implementation with metadata from available integrations, allowing us to currently choose the correct index patterns needed if a relevant integration is found. Changes in the PR: - Introduction of the `integration data client`, which might later be moved under resource. - Moving` translate_rule` node to its own subgraph, then divided into multiple nodes to support the RAG search step. - The creation and population of the index used to store the integration metadata, together with the `semantic_text` mapping used by the default included ELSER model. - Updates to `elastic_rule` type, to include the integration ID's and index patterns. ## Example finished task: ```json [ { "migration_id": "3d4cae35-eb8d-49fe-960a-2ef17bc026c6", "original_rule": { "id": "f8c325ea-506e-4105-8ccf-da1492e90115", "vendor": "splunk", "title": "Linux Auditd Add User Account Type", "description": "The following analytic detects the suspicious add user account type. This behavior is critical for a SOC to monitor because it may indicate attempts to gain unauthorized access or maintain control over a system. Such actions could be signs of malicious activity. If confirmed, this could lead to serious consequences, including a compromised system, unauthorized access to sensitive data, or even a wider breach affecting the entire network. Detecting and responding to these signs early is essential to prevent potential security incidents.", "query": "sourcetype=\"linux:audit\" type=ADD_USER \n| rename hostname as dest \n| stats count min(_time) as firstTime max(_time) as lastTime by exe pid dest res UID type \n| `security_content_ctime(firstTime)` \n| `security_content_ctime(lastTime)`\n| search *", "query_language": "spl", "mitre_attack_ids": [ "T1136" ] }, "@timestamp": "2024-11-21T11:37:10.548Z", "status": "completed", "created_by": "elastic", "updated_at": "2024-11-21T11:38:01.397Z", "updated_by": "elastic", "comments": [ "## Migration Summary\n\n1. Source selection:\n - The original SPL query used `sourcetype=\"linux:audit\"`. In the ES|QL query, we're using the provided index patterns that include logs related to system audit and auditd.\n\n2. Event type filtering:\n - The SPL query filtered for `type=ADD_USER`. In ES|QL, we use `WHERE event.type == \"ADD_USER\"` to achieve the same filtering.\n\n3. Field renaming:\n - The SPL query renamed `hostname` to `dest`. In ES|QL, we use the `RENAME` command to rename `host.hostname` to `dest`, assuming the ECS field mapping.\n\n4. Statistics calculation:\n - The SPL query used `stats` to calculate count, min(_time), and max(_time). In ES|QL, we use the `STATS` command with `COUNT(*)`, `MIN(@timestamp)`, and `MAX(@timestamp)` to achieve similar results.\n - The grouping fields are adjusted to match ECS field names:\n - `exe` -> `process.executable`\n - `pid` -> `process.pid`\n - `dest` remains the same (after renaming)\n - `res` -> `event.outcome`\n - `UID` -> `user.id`\n - `type` -> `event.type`\n\n5. Time conversion:\n - The SPL query used `security_content_ctime` function for time conversion. In ES|QL, we use the `EVAL` command with `TO_DATETIME` function to convert the `firstTime` and `lastTime` fields to datetime format.\n\n6. Additional notes:\n - The `search *` at the end of the SPL query is not necessary in ES|QL as it doesn't change the result set.\n - The ES|QL query assumes that the `@timestamp` field is used for event timestamps, which is standard in ECS.\n\nThis ES|QL query should provide equivalent functionality to the original Splunk query, adapted for Elastic Security and using ECS field names where appropriate." ], "translation_result": "full", "elastic_rule": { "severity": "low", "query": "FROM logs-system_audit.package-* logs-endpoint.events.api-* logs-endpoint.events.file-* logs-endpoint.events.library-* logs-endpoint.events.network-* logs-endpoint.events.process-* logs-endpoint.events.registry-* logs-endpoint.events.security-* logs-auditd.log-*\n| WHERE event.type == \"ADD_USER\"\n| RENAME host.hostname AS dest\n| STATS count = COUNT(*), firstTime = MIN(@timestamp), lastTime = MAX(@timestamp) BY process.executable, process.pid, dest, event.outcome, user.id, event.type\n| EVAL firstTime = TO_DATETIME(firstTime), lastTime = TO_DATETIME(lastTime)", "description": "The following analytic detects the suspicious add user account type. This behavior is critical for a SOC to monitor because it may indicate attempts to gain unauthorized access or maintain control over a system. Such actions could be signs of malicious activity. If confirmed, this could lead to serious consequences, including a compromised system, unauthorized access to sensitive data, or even a wider breach affecting the entire network. Detecting and responding to these signs early is essential to prevent potential security incidents.", "index_patterns": [ "logs-system_audit.package-*", "logs-endpoint.events.api-*", "logs-endpoint.events.file-*", "logs-endpoint.events.library-*", "logs-endpoint.events.network-*", "logs-endpoint.events.process-*", "logs-endpoint.events.registry-*", "logs-endpoint.events.security-*", "logs-auditd.log-*" ], "query_language": "esql", "title": "Linux Auditd Add User Account Type", "integration_ids": [ "system_audit", "endpoint", "auditd" ] }, "_id": "8eKDTpMBwtRPKDL_CLKW" }, { "migration_id": "3d4cae35-eb8d-49fe-960a-2ef17bc026c6", "original_rule": { "id": "7b87c556-0ca4-47e0-b84c-6cd62a0a3e90", "vendor": "splunk", "title": "Linux Auditd Change File Owner To Root", "description": "The following analytic detects the use of the 'chown' command to change a file owner to 'root' on a Linux system. It leverages Linux Auditd telemetry, specifically monitoring command-line executions and process details. This activity is significant as it may indicate an attempt to escalate privileges by adversaries, malware, or red teamers. If confirmed malicious, this action could allow an attacker to gain root-level access, leading to full control over the compromised host and potential persistence within the environment.", "query": "`linux_auditd` `linux_auditd_normalized_proctitle_process`\r\n| rename host as dest \r\n| where LIKE (process_exec, \"%chown %root%\") \r\n| stats count min(_time) as firstTime max(_time) as lastTime by process_exec proctitle normalized_proctitle_delimiter dest \r\n| `security_content_ctime(firstTime)` \r\n| `security_content_ctime(lastTime)`\r\n| `linux_auditd_change_file_owner_to_root_filter`", "query_language": "spl", "mitre_attack_ids": [ "T1222" ] }, "@timestamp": "2024-11-21T11:37:10.548Z", "status": "completed", "created_by": "elastic", "updated_at": "2024-11-21T11:38:04.527Z", "updated_by": "elastic", "comments": [ "## Migration Summary\n\n1. Source selection:\n - The original SPL query used `linux_auditd` and `linux_auditd_normalized_proctitle_process` macros. In ES|QL, we're using the recommended index patterns for Elastic Endpoint Security events.\n\n2. Field mapping:\n - `host` was renamed to `dest` in the original query. In ECS, we use `host.name`.\n - `process_exec` is mapped to `process.executable` in ECS.\n - `proctitle` and `normalized_proctitle_delimiter` are combined into `process.command_line` in ECS.\n - `_time` is replaced with `@timestamp` in ECS.\n\n3. Filtering:\n - The `LIKE` function is used in ES|QL, which is equivalent to the SPL `LIKE` function.\n - We're checking for \"chown\" in the process executable and \"root\" in the process arguments.\n\n4. Statistics:\n - The `STATS` command in ES|QL is similar to SPL's `stats` command.\n - We use `COUNT(*)`, `MIN(@timestamp)`, and `MAX(@timestamp)` for the count, firstTime, and lastTime respectively.\n - The `BY` clause groups the results by the relevant fields.\n\n5. Sorting:\n - Added a `SORT` command to order the results by count in descending order, which wasn't in the original query but is useful for identifying the most frequent occurrences.\n\n6. Removed:\n - The `security_content_ctime` function calls were removed as they are specific to Splunk. ES|QL uses the native datetime format.\n - The `linux_auditd_change_file_owner_to_root_filter` macro was not included as we don't have an equivalent in ES|QL. If there are specific filters in this macro, they would need to be added explicitly to the query.\n\nThis ES|QL query will detect the use of the 'chown' command to change a file owner to 'root' on a Linux system, using Elastic Endpoint Security events. It groups the results by the process details and host name, providing a count of occurrences and the first and last times the event was observed." ], "translation_result": "full", "elastic_rule": { "severity": "low", "query": "FROM logs-endpoint.events.api-* logs-endpoint.events.file-* logs-endpoint.events.library-* logs-endpoint.events.network-* logs-endpoint.events.process-* logs-endpoint.events.registry-* logs-endpoint.events.security-*\n| WHERE process.executable LIKE \"%chown%\" AND process.args LIKE \"%root%\"\n| STATS count = COUNT(*), firstTime = MIN(@timestamp), lastTime = MAX(@timestamp) BY process.executable, \n process.command_line, \n process.args, \n host.name\n| SORT count DESC", "description": "The following analytic detects the use of the 'chown' command to change a file owner to 'root' on a Linux system. It leverages Linux Auditd telemetry, specifically monitoring command-line executions and process details. This activity is significant as it may indicate an attempt to escalate privileges by adversaries, malware, or red teamers. If confirmed malicious, this action could allow an attacker to gain root-level access, leading to full control over the compromised host and potential persistence within the environment.", "index_patterns": [ "logs-endpoint.events.api-*", "logs-endpoint.events.file-*", "logs-endpoint.events.library-*", "logs-endpoint.events.network-*", "logs-endpoint.events.process-*", "logs-endpoint.events.registry-*", "logs-endpoint.events.security-*" ], "query_language": "esql", "title": "Linux Auditd Change File Owner To Root", "integration_ids": [ "endpoint" ] }, "_id": "8uKDTpMBwtRPKDL_CLKW" } ] ``` ## Testing locally Enable the flag ``` xpack.securitySolution.enableExperimental: ['siemMigrationsEnabled'] ``` Create the rule migration, add relevant macro resources and initiate the task. cURL request examples: <details> <summary>Rules migration `create` POST request</summary> ``` curl --location --request POST 'http://elastic:changeme@localhost:5601/internal/siem_migrations/rules' \ --header 'kbn-xsrf;' \ --header 'x-elastic-internal-origin: security-solution' \ --header 'elastic-api-version: 1' \ --header 'Content-Type: application/json' \ --data '[ { "id": "f8c325ea-506e-4105-8ccf-da1492e90115", "vendor": "splunk", "title": "Linux Auditd Add User Account Type", "description": "The following analytic detects the suspicious add user account type. This behavior is critical for a SOC to monitor because it may indicate attempts to gain unauthorized access or maintain control over a system. Such actions could be signs of malicious activity. If confirmed, this could lead to serious consequences, including a compromised system, unauthorized access to sensitive data, or even a wider breach affecting the entire network. Detecting and responding to these signs early is essential to prevent potential security incidents.", "query": "sourcetype=\"linux:audit\" type=ADD_USER \n| rename hostname as dest \n| stats count min(_time) as firstTime max(_time) as lastTime by exe pid dest res UID type \n| `security_content_ctime(firstTime)` \n| `security_content_ctime(lastTime)`\n| search *", "query_language":"spl", "mitre_attack_ids": [ "T1136" ] }, { "id": "7b87c556-0ca4-47e0-b84c-6cd62a0a3e90", "vendor": "splunk", "title": "Linux Auditd Change File Owner To Root", "description": "The following analytic detects the use of the '\''chown'\'' command to change a file owner to '\''root'\'' on a Linux system. It leverages Linux Auditd telemetry, specifically monitoring command-line executions and process details. This activity is significant as it may indicate an attempt to escalate privileges by adversaries, malware, or red teamers. If confirmed malicious, this action could allow an attacker to gain root-level access, leading to full control over the compromised host and potential persistence within the environment.", "query": "`linux_auditd` `linux_auditd_normalized_proctitle_process`\r\n| rename host as dest \r\n| where LIKE (process_exec, \"%chown %root%\") \r\n| stats count min(_time) as firstTime max(_time) as lastTime by process_exec proctitle normalized_proctitle_delimiter dest \r\n| `security_content_ctime(firstTime)` \r\n| `security_content_ctime(lastTime)`\r\n| `linux_auditd_change_file_owner_to_root_filter`", "query_language": "spl", "mitre_attack_ids": [ "T1222" ] } ]' ``` </details> <details> <summary>Add resources to migration ID</summary> - Assuming the connector `azureOpenAiGPT4o` is already created in the local environment. - Using the {{`migration_id`}} from the first POST request response ``` curl --location --request POST 'http://elastic:changeme@localhost:5601/internal/siem_migrations/rules/{{migration_id}}/respirces' \ --header 'kbn-xsrf;' \ --header 'x-elastic-internal-origin: security-solution' \ --header 'elastic-api-version: 1' \ --header 'Content-Type: application/json' \ --data '[ { "type": "macro", "name": "security_content_ctime", "content": "convert timeformat=\"%Y-%m-%dT%H:%M:%S\" ctime($field$)" }, { "type": "macro", "name": "linux_auditd_add_user_account_type_filter", "content": "search *" }, { "type": "macro", "name": "linux_auditd", "content": "sourcetype=\"linux:audit\"" }, { "type": "macro", "name": "linux_auditd_change_file_owner_to_root_filter", "content": "search *" } ]' ``` </details> <details> <summary>Rules migration `start` task request</summary> - Assuming the connector `azureOpenAiGPT4o` is already created in the local environment. - Using the {{`migration_id`}} from the first POST request response ``` curl --location --request PUT 'http://elastic:changeme@localhost:5601/internal/siem_migrations/rules/{{migration_id}}/start' \ --header 'kbn-xsrf;' \ --header 'x-elastic-internal-origin: security-solution' \ --header 'elastic-api-version: 1' \ --header 'Content-Type: application/json' \ --data '{ "connectorId": "azureOpenAiGPT4o" }' ``` </details>
## Summary [Internal link](elastic/security-team#10820) to the feature details This is a very first version of the SIEM rules migrations UI functionality. The main goal is to setup and agree on a folder structure where the feature gonna live. Tests covering feature will follow in a separate PR (see [internal link](elastic/security-team#11232) for more details). The code follows the structure of prebuilt rules feature https://github.com/elastic/kibana/tree/main/x-pack/plugins/security_solution/public/detection_engine/rule_management_ui/components/rules_table/add_prebuilt_rules_table and hidden behind `siemMigrationsEnabled` feature flag. ### Key UI changes * New "SIEM Rules Migrations." rules management sub-page * Navigation between different "finished" migrations * InMemory table with all the translations within the selected migration * Translation details preview flyout with `Translation` and `Overview` tabs * User cannot modify translations via UI ### Testing locally Enable the flag ``` xpack.securitySolution.enableExperimental: ['siemMigrationsEnabled'] ``` ### Screenshot https://github.com/user-attachments/assets/a5a7e777-c5f8-40b4-be1d-1bd07a2729ac
…201010) Follows #199033 ## Summary This PR further removes logic that uses `xpack.reporting.csv.enablePanelActionDownload`, and removes references of that setting from our documentation. See #199033 for the **release note**. ### Changes 1. `enablePanelActionDownload` exists as an **optional** setting in `packages/kbn-reporting/server/config_schema.ts` 2. The only reference to this setting marks it as unused in `x-pack/plugins/reporting/server/config/index.ts` 3. Removes the detection of the setting from the Upgrade Assistant integration ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations.
…ata view does not exist (#201140) ## Summary Fixes a bug where if the securite default data view does not exist the entity engine would get stuck in 'installing' status. After this fix, the engine is put into 'error' state. The entity engine uses the security default data view by default to generate it's source index pattern. ## Testing 1. Delete the security default data view `security-solution-default` 2. Init the entity store 3. Observe that the entity store is in an error state (the UI should show the error)
## Summary
- create `_search` endpoint to discover entities with esql queries. It
currently reads sources of the provided `type` from
`kibana_entity_definitions` index. Run this query to insert a
definition:
```
POST kibana_entity_definitions/_doc
{
"entity_type": "service",
"index_patterns": ["remote_cluster:logs-*"],
"metadata_fields": [],
"identity_fields": ["service.name"],
"filters": [],
"timestamp_field": "@timestamp"
}
```
By default `_search` will look at data in the last 5m. The lookup period
can be overriden by providing `start`/`end` parameters in ISO format. It
also accepts a `limit` to specify the number of entities returned which
defaults to 10
```
POST kbn:/internal/entities/v2/_search
{
"type": "service",
"start": "2024-11-19T20:40:00.000Z",
"end": "2024-11-19T20:50:00.000Z",
"limit": 20
}
```
- create `_search/preview` endpoint to preview output of entity sources
without persisting them
- create UI to preview results of an entity definition at
`/app/entity_manager`. The application is living in its own plugin at
`observability_solution/entity_manager_app`
---------
Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Milton Hultgren <[email protected]>
## Summary Use proper tooltip EUI elem, before you could not navigate on those elements with keyboard `TAB` key as we were just rendering icon image on the side of label. Now it's possible to reach each (?) with keyboard navigation and it's possible to read the tooltip with screenreader. See: https://github.com/user-attachments/assets/4b50a70c-d153-432f-9093-70ba6dffa9d9 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [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 - [x] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [x] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [x] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ...
… kibana-visualizations (#201152) This PR migrates test suites that use `renderHook` from the library `@testing-library/react-hooks` to adopt the equivalent and replacement of `renderHook` from the export that is now available from `@testing-library/react`. This work is required for the planned migration to react18. ## Context In this PR, usages of `waitForNextUpdate` that previously could have been destructured from `renderHook` are now been replaced with `waitFor` exported from `@testing-library/react`, furthermore `waitFor` that would also have been destructured from the same renderHook result is now been replaced with `waitFor` from the export of `@testing-library/react`. ***Why is `waitFor` a sufficient enough replacement for `waitForNextUpdate`, and better for testing values subject to async computations?*** WaitFor will retry the provided callback if an error is returned, till the configured timeout elapses. By default the retry interval is `50ms` with a timeout value of `1000ms` that effectively translates to at least 20 retries for assertions placed within waitFor. See https://testing-library.com/docs/dom-testing-library/api-async/#waitfor for more information. This however means that for person's writing tests, said person has to be explicit about expectations that describe the internal state of the hook being tested. This implies checking for instance when a react query hook is being rendered, there's an assertion that said hook isn't loading anymore. In this PR you'd notice that this pattern has been adopted, with most existing assertions following an invocation of `waitForNextUpdate` being placed within a `waitFor` invocation. In some cases the replacement is simply a `waitFor(() => new Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for point out exactly why this works), where this suffices the assertions that follow aren't placed within a waitFor so this PR doesn't get larger than it needs to be. It's also worth pointing out this PR might also contain changes to test and application code to improve said existing test. ### What to do next? 1. Review the changes in this PR. 2. If you think the changes are correct, approve the PR. ## Any questions? If you have any questions or need help with this PR, please leave comments in this PR.
## Summary
Removed `security` property from `route.options` types, `security`
should exist only as a top level property.
Fixed routes with incorrect config accordingly.
## Routes Impacted
Routes with disabled authorization (impact can be considered negligible)
```
/internal/entities/managed/enablement
/internal/entities/managed/enablement
/internal/entities/managed/enablement
/internal/entities/definition
/internal/entities/definition/{id}
/internal/entities/definition/{id?}
/internal/entities/definition/{id}/_reset
/internal/entities/definition/{id}
/api/streams/_enable
/api/streams/_resync
/api/streams/{id}/_fork
/api/streams/{id}
/api/streams/{id}
/api/streams/{id}
/api/streams
```
Routes with authorization (will be backported to `8.17.0`)
```
/internal/product_doc_base/status
/internal/product_doc_base/install
/internal/product_doc_base/uninstall
```
__Fixes: https://github.com/elastic/kibana/issues/201347__
… response-ops (#201141) This PR migrates test suites that use `renderHook` from the library `@testing-library/react-hooks` to adopt the equivalent and replacement of `renderHook` from the export that is now available from `@testing-library/react`. This work is required for the planned migration to react18. ## Context In this PR, usages of `waitForNextUpdate` that previously could have been destructured from `renderHook` are now been replaced with `waitFor` exported from `@testing-library/react`, furthermore `waitFor` that would also have been destructured from the same renderHook result is now been replaced with `waitFor` from the export of `@testing-library/react`. ***Why is `waitFor` a sufficient enough replacement for `waitForNextUpdate`, and better for testing values subject to async computations?*** WaitFor will retry the provided callback if an error is returned, till the configured timeout elapses. By default the retry interval is `50ms` with a timeout value of `1000ms` that effectively translates to at least 20 retries for assertions placed within waitFor. See https://testing-library.com/docs/dom-testing-library/api-async/#waitfor for more information. This however means that for person's writing tests, said person has to be explicit about expectations that describe the internal state of the hook being tested. This implies checking for instance when a react query hook is being rendered, there's an assertion that said hook isn't loading anymore. In this PR you'd notice that this pattern has been adopted, with most existing assertions following an invocation of `waitForNextUpdate` being placed within a `waitFor` invocation. In some cases the replacement is simply a `waitFor(() => new Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for point out exactly why this works), where this suffices the assertions that follow aren't placed within a waitFor so this PR doesn't get larger than it needs to be. It's also worth pointing out this PR might also contain changes to test and application code to improve said existing test. ### What to do next? 1. Review the changes in this PR. 2. If you think the changes are correct, approve the PR. ## Any questions? If you have any questions or need help with this PR, please leave comments in this PR.
…199653) ## Summary This PR updates the `cleanMlIndices` service method to no longer run with `esDeleteAllIndices` and thus no longer requires system index superuser privileges. ### Details / other changes - Not all ML items can be cleaned up through APIs (e.g. notifications), so tests have been adjusted to deal with pre-existing data - Some cleanup steps had to be re-ordered - Basic license tests didn't need the `cleanMlIndices` in their `before` so it was removed there - Observability serverless tests can't use `cleanMlIndices` as the APIs for DFA are not available for that project type, so the cleanup is changed to `cleanAnomalyDetection` for the AD tests and the `cleanMlIndices` is removed from the AI assistant helpers as the existing cleanup there should be enough
## Summary Fix an issue with auto-recovery of Knowledge Base setup. When the KB setup was initialized on an undersized cluster, the model failed to deploy correctly. This resulted in the KB ending up in a broken state, repeatedly displaying the Setup KB button. --------- Co-authored-by: kibanamachine <[email protected]>
…ThroughputPerMinutePerKibana was sufficient (#200578) In this PR, I'm fixing a bug where the task manager unhealthy logs were showing the wrong reason. Because the if condition was checking `assumedAverageRecurringRequiredThroughputPerMinutePerKibana` to be less than `capacityPerMinutePerKibana`, it would log this as the reason task manager is healthy. However whenever the value is less, it means task manager is running fine from a recurring task perspective. Changing the if condition allows the next step in the code to log which then logs `assumedRequiredThroughputPerMinutePerKibana` as the real reason why task manager is unhealthy. --------- Co-authored-by: kibanamachine <[email protected]>
Closes #200708 ## Summary This PR fixes deprecated usage of ApiActions get in [get_has_setup_privileges.ts](https://github.com/elastic/kibana/compare/main...jennypavlova:200708-profiling-ui-fix-deprecated-usage-of-apiactions-get?expand=1#diff-3ed5ba625d0b40a258485edf84456c4258de4ea21727ec342a440238a534bc97) --------- Co-authored-by: kibanamachine <[email protected]>
…sync/awaits, other small fixes (#197168) ## Summary For most of 8.x, both anecdotally from users and in development, timeline search strategy based apis would often seem slower than the equivalent search in discover or elsewhere in kibana, and I have long suspected that this came from how the timeline sever code formatted the elasticsearch responses for use in the UI, and while working on something else, noticed even higher than normal occurrences in logs of "][http.server.Kibana] Event loop utilization for /internal/search/timelineSearchStrategy exceeded threshold of..." and so I tried to refactor all of the functions in place as much as possible, keeping the apis similar, most of the unit tests, etc, but removing as many as possible of the Promise.alls, reduce within reduce, etc. This has lead to a substantial improvement in performance, as you can see below, and with larger result sets, I think the difference would only be more noticeable. After fix: ~40 ms for formatTimelineData with ~1000 docs <img width="1470" alt="image" src="https://github.com/user-attachments/assets/c664f940-aa37-4335-9204-2a9300fbafa0"> Before fix: ~18000 ms for formatTimelineData with ~1000 docs <img width="1464" alt="image" src="https://github.com/user-attachments/assets/124fa327-13b9-41ef-9489-8d27f853590c"> [chrome_profile_timeline_slow.cpuprofile](https://github.com/user-attachments/files/17825602/chrome_profile_timeline_slow.cpuprofile) [chrome_profile_timeline_fast.cpuprofile](https://github.com/user-attachments/files/17825606/chrome_profile_timeline_fast.cpuprofile) I've attached the chrome devtools profiles for each, the time was measured with the function: ``` async function measureAwait<T>(promise: Promise<T>, label: string): Promise<T> { const start = performance.now(); try { const result = await promise; const duration = performance.now() - start; console.log(`${label} took ${duration}ms`); return result; } catch (error) { const duration = performance.now() - start; console.log(`${label} failed after ${duration}ms`); throw error; } } ``` Wrapped around the call to formatTimelineData in x-pack/plugins/timelines/server/search_strategy/timeline/factory/events/all/index.ts ### Checklist - [ ] [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
## Summary "Total" should not have an action menu because its not a data stream <img width="757" alt="Screenshot 2024-11-22 at 10 37 02 AM" src="https://github.com/user-attachments/assets/37ea5c16-341f-47df-9b37-7b7cda91a757"> ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )