closes https://github.com/elastic/observability-dev/issues/3737
## Summary
- When FF is disabled it shows the existing no data page
- The no data config is very limited in the template, thus we had to go
against the guidelines and create a custom no data page for the new
experience.
- The user needs to have permissions to enable EEM, othewise same modal
appears with slightly different copy
Additionally, the PR includes
- Small refactoring in the enablement component in order to share it
- Add short link that was misseed
https://github.com/user-attachments/assets/5d3bbe83-682a-47a1-a9af-770f1ca42876
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes control editing so that, when the control type is changed,
extra state from the old type gets removed. Prior to this, controls were
keeping unrelated state - for example, switching from a range slider to
a search control would result in a search control with the "step"
property.
### Checklist
- [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
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
This PR updates the screenshots related to log rate analysis and log
pattern analysis in the AIOps Labs documentation to reflect that those
features are GA.
## Part of https://github.com/elastic/connectors/issues/2686
## Summary
The following set of connectors gained support for the advanced sync
rules feature in a later release compared to the one where they were
made available as native connector. Consequently, enabling advanced
rules for these connectors was missed.
- Postgres
- Network Drive
- MSSQL
- GitHub
- OneDrive
- Salesforce
- S3
- GMail
- Notion
Co-authored-by: Navarone Feekery <13634519+navarone-feekery@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/observability-dev/issues/3345
Refactoring the tags portion of the table list view to return focus
after closing the tags popover
---------
Co-authored-by: Sébastien Loix <sebastien.loix@elastic.co>
## Summary
Close https://github.com/elastic/kibana/issues/184836
Adds a new endpoint: `/api/_elu_history` for the purposes of tracking
load.
```ts
interface Response {
/**
* Event-loop utilization represented as an average of a number of collections as buckets
* @remark 3 load windows borrows from the `uptime` CLI tool on macOS and Linux, but is not necessarily 1m, 5m, 15m. The
* actual time range covered is determined by our collection interval (configured via `ops.interval`, default 5s)
* and the number of samples held in each window. So by default short: 15s, medium: 30s and long 60s.
*/
history: {
/** The average ELU for the short window */
short: number;
/** The average ELU for the medium window */
medium: number;
/** The average ELU for the long window */
long: number;
};
}
```
## How to test
Start Kibana locally (`yarn start --no-base-path`) and immediately run
the script below.
```bash
watch -n1 curl -s http://localhost:5601/api/_elu_history
```
Once Kibana starts responding you should see the `short > medium >
long`, then `short < medium < long` and eventually `short ~= medium ~=
long` if you let Kibana idle (basically, long needs to "lag" behind
short and medium).
## Questions
1. An alternative implementation exposes this directly via the
`/api/stats` endpoint as a new section under `event_loop_utilization`.
I'm assuming this approach is preferable.
2. Naming... What shall we call this endpoint?
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of #187684.
This moves functions related to log rate changes to the
`@kbn/aiops_log_rate_analysis` package.
- `getLogRateAnalysisType` was renamed to
`getLogRateAnalysisTypeForHistogram` to indicate its use with histogram
data.
- `getLogRateAnalysisTypeForCounts` was added for cases where we don't
have the histogram data available but just the doc counts for baseline
an deviation time ranges. This isn't used yet as of this PR but will be
in a follow up in combination with the o11y AI assistant.
- `getSwappedWindowParameters` is a helper to consolidate inline code
that's used to swap baseline and deviation when we detected a dip in log
rate.
- Rounding for the log rate change messages was tweaked. Changes below
`10x` will now be rounded to one digit to avoid messages like `1x
increase`.
- Tweaked/Shortened the message for 0 in baseline or deviation to just
`45 up from 0 in baseline` / `down to 0 from 45 in baseline`.
### Checklist
- [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] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
This PR converts the identity fields in the latest transform from a
`terms` aggregation to a `top_metric` aggregation in an effort to
simplify the implementation since we have to convert a terms aggregation
from keys to an array of strings. With the `top_metrics` implementation,
we just need to use the `dot_expander` processors along with a `set`
processor to get a single (non-array) field.
---------
Co-authored-by: Chris Cowan <chris@elastic.co>
Closes https://github.com/elastic/kibana/issues/186631
Closes https://github.com/elastic/kibana-operations/issues/151
Adds a daily pipeline for running our jest and integration tests against
a Node.js distribution with pointer compression enabled. This is enabled
by setting the environment variable
`CI_FORCE_NODE_POINTER_COMPRESSION=true`
I would prefer a cleaner implementation, but I'm not seeing a way around
it without changing our defaults globally. Open to ideas. We have to
update three downloads:
1) base node.js install, for jest
2) build node.js install, for integration tests
3) bazel workspace install, for dependencies
https://buildkite.com/elastic/kibana-pointer-compression/builds/6
---------
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Closes https://github.com/elastic/kibana/issues/174959
## Summary
This PR converts the Saved Search embeddable to the new React embeddable
framework. There should not be **any** changes in user-facing behaviour
(except for the intentional change described
[here](https://github.com/elastic/kibana/pull/180536#discussion_r1647924825))
- therefore, testing of this PR should be focused on ensuring that no
behaviour is changed and/or broken with this refactor.
> [!WARNING]
> The saved search embeddable takes **many forms** and so, while I tried
my best to test everything thoroughly, it is very, very likely that I
missed some test cases due to not being the expert in this area. It is
important that @elastic/kibana-data-discovery in particular approaches
this PR review with a fine-tooth comb 🙇 Thanks so much.
### Notes about the embeddable state:
As part of this refactor, I made three significant changes to how the
state is managed:
1. Once the embeddable is being built in `buildEmbeddable`, the **only
difference** between the runtime state of a by reference and a by value
panel is that the by reference one will have three saved object-specific
keys: `savedObjectId`, `savedObjectDescription`, and `savedObjectTitle`.
2. Number 1 made it possible for me to "flatten out" the runtime state
of the embeddable by removing the `attributes` key, which makes it
easier to access the pieces of state that you need.
3. Previously, the `savedSearch` element of the Saved Search embeddable
object was never modified; instead, changes made to the columns, sort,
sample size, etc. from the dashboard were stored in `explicitInput`.
This essentially created two sources of truth.
With the new embeddable system, we only ever want **one** source of
truth - so, the saved search is now modified **directly** when making
changes from the dashboard. However, in order to keep behaviour
consistent with the old embeddable, changes made from the dashboard to a
by reference saved search **should not** modify the underlying saved
object (this behaviour will have to change if we ever want inline
editing for saved searches, but that is another discussion) - therefore,
when **serializing** the runtime state (which happens when the dashboard
is saved), we [only serialize state that has **changed** from the
initial
state](https://github.com/elastic/kibana/pull/180536/files#diff-7346937694685b85c017fb608c6582afb3aded0912bfb42fffa4b32a6d27fdbbR93-R117);
then, on deserialization, we take this "changed" state and
[**overwrite** the state of the saved search with
it](https://github.com/elastic/kibana/pull/180536/files#diff-7346937694685b85c017fb608c6582afb3aded0912bfb42fffa4b32a6d27fdbbR44-R54).
Note that this **only** applies to by reference saved searches - with by
value saved searches, we don't have to worry about this and can freely
modify the state.
I also had to make changes to how the **search source** is stored in
runtime state. Previously, when initializing the embeddable, fetching
the saved search saved object also created and returned an
**unserializable** search source object. However, in the new system,
runtime state **most always be serializable** (see
https://github.com/elastic/kibana/pull/186052) - therefore, I've had to
instead use the **serialized** search source in my runtime state saved
search - therefore, I've had to make changes to `toSavedSearch` method
to [allow for a **serializable** saved search to be
returned](https://github.com/elastic/kibana/pull/180536/files#diff-3baaeaeef5893a5a4db6379a1ed888406a8584cb9d0c7440f273040e4aa28166R160-R169).
| | Runtime state (`input`) before | Runtime state after |
|--------|--------|--------|
| **By value** |
|
|
| **By reference** |
|
|
### Checklist
- [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] [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] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/186533
## Summary
Stage 1 of `ExecutionHandler` refactor:
* Rename `ExecutionHandler` to `ActionScheduler`.
* Create schedulers to handle the 3 different action types
(`SummaryActionScheduler`, `SystemActionScheduler`,
`PerAlertActionScheduler`)
* Splits `ExecutionHandler.generateExecutables` function into the
appropriate action type class and combine the returned executables from
each scheduler class.
GH is not recognizing the rename from `ExecutionHandler` to
`ActionScheduler` so I've called out the primary difference between the
two files (other than the rename) which is to get the executables from
each scheduler class instead of from a `generateExecutables` function.
Removed the `generateExecutables` fn from the `ActionScheduler` and any
associated private helper functions.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
- https://github.com/elastic/kibana/issues/187630
- https://github.com/elastic/kibana/issues/187768
These changes fix the error on saving the alert
> An error occurred during rule execution: message: "[1:6952] failed to
parse field [event.original] of type [keyword] in document with id
'330b17dc2ac382dbdd2f2577c28e83b42c5dc66eaf95e857ec0f222abfc486fa'..."
The issue happens when source index has non-ECS compliant text field
which is expected to be a keyword. If the text value is longer than
32766 bytes and keyword field does not have ignore_above parameter set,
then on trying to store the text value in keyword field we will hit the
Lucene's term byte-length limit (for more details see [this
page](https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html)).
See the main ticket for steps to reproduce the issue.
---------
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
## Summary
Leftover work from https://github.com/elastic/kibana/pull/186615
- Removes remaining usage of `rule_schema_legacy` types. In this PR,
simply inlines the last io-ts types used, to be able to get rid of the
legacy folder.
- The remaining files that need to be migrated to using Zod schema types
are:
-
`x-pack/plugins/security_solution/common/api/detection_engine/rule_exceptions/find_exception_references/find_exception_references_route.ts`
- `x-pack/plugins/security_solution/common/api/timeline/model/api.ts`
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
## Summary
Follow-up to #188825
@crespocarlos reported that some Oblt configs after missing after
#187440
I was using `node scripts/check_ftr_configs.js` to validate I did not
miss anything and decided to debug the script.
We had a pretty strict config file content validation like
`testRunner|testFiles`, that was skipping some FTR configs like
`x-pack/test/apm_api_integration/basic/config.ts`
I extended file content check to look for default export function and
also skip test/suite or Cypress-own config files.
In the end 7 FTR configs were discovered, but only 2 are with tests. I
will ask owners to confirm if it should be enabled/disabled. Script run
output:
```
node scripts/check_ftr_configs.js
ERROR The following files look like FTR configs which are not listed in one of manifest files:
- x-pack/plugins/observability_solution/uptime/e2e/config.ts
- x-pack/test/functional_basic/apps/ml/config.base.ts
- x-pack/test/functional_basic/apps/transform/config.base.ts
- x-pack/test/security_solution_api_integration/config/ess/config.base.trial.ts
- x-pack/test_serverless/functional/test_suites/observability/cypress/oblt_config.base.ts
Make sure to add your new FTR config to the correct manifest file.
Stateful tests:
.buildkite/ftr_platform_stateful_configs.yml
.buildkite/ftr_oblt_stateful_configs.yml
.buildkite/ftr_security_stateful_configs.yml
.buildkite/ftr_search_stateful_configs.yml
Serverless tests:
.buildkite/ftr_base_serverless_configs.yml
.buildkite/ftr_oblt_serverless_configs.yml
.buildkite/ftr_security_serverless_configs.yml
.buildkite/ftr_search_serverless_configs.yml
ERROR Please add the listed paths to the correct manifest file. If it's not an FTR config, you can add it to the IGNORED_PATHS in packages/kbn-test/src/functional_test_runner/lib/config/run_check_ftr_configs_cli.ts or contact #kibana-operations
```
## Summary
This PR closes https://github.com/elastic/kibana/issues/188171 by
converting the route validate to Zod for `get`, `reset`, and `delete`
APIs. This also changes the validation for the `create` API to use
`buildRouteValidationWithZod` along with adding `strict()` to each of
the schemas.
Closes https://github.com/elastic/elastic-entity-model/issues/103
---------
Co-authored-by: Kevin Lacabane <kevin.lacabane@elastic.co>
adduser is used in the deb post install script. Installing kibana.deb in
a container won't have the necessary dependencies by default
Closes#182537
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
**Relates to:** https://github.com/elastic/security-team/issues/9401
## Summary
Disabling OpenAPI spec linting in https://github.com/elastic/kibana/pull/179074 lead to accumulating invalid OpenAPi specs.
This PR enables OpenAPI linting for Security Solution plugin and make appropriate fixes to make the linting pass.
## Details
OpenAPI linting is a part of code generation. It runs automatically but can be disabled via `skipLinting: true`. Code generation with disabled linting isn't able to catch all possible problems in processing specs.
The majority of problems came from Entity Analytics and Osquery OpenAPI specs. These specs were fixed and refactored to enable code generation and integrate generated artefacts into routes to make sure OpenAPI spec match API endpoints they describe. It helped to catch some subtle inconsistencies.
## Summary
- Fixes the API route for response actions file information and file
download to ensure that user only needs Authz to the Execute action.
- Centralizes the logic to determine the platform for a given host which
was (under certain data conditions) causing the platform icon to not be
shown in the response console.
## Summary
### Acceptance Criteria
- [x] When starting Kibana, the global entity index templates are no
longer created
- [x] When installing a definition, an index template is generated and
installed scoped to the definition ID
- [x] When deleting a definition, the related index template is also
deleted
- [x] The index template composes the current component templates (base,
entity, event) as well as the new custom component templates with the
setting ignore_missing_component_templates set to true
- [x] The new component templates should be named:
<definition_id>@platform, <definition_id>-history@platform,
<definition_id>-latest@platform, <definition_id>@custom,
<definition_id>-history@custom and <definition_id>-latest@custom
- [x] The ingest pipelines include a pipeline processor that calls out
the pipelines named <definition_id>@platform and
<definition_id>-history@platform or <definition_id>-latest@platform,
<definition_id>@custom and <definition_id>-history@custom or
<definition_id>-latest@custom if they exist
- [x] The index template should have a priority of 200 and be set to
managed
- [x] The @custom component template should take precedence over the
@platform component template, allowing users to override things we have
set if they so wish
- [x] set managed_by to 'elastic_entity_model',
### Checklist
- [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
---------
Co-authored-by: Kevin Lacabane <kevin.lacabane@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/188677
Monaco editor has different [kinds of completion
triggers](https://microsoft.github.io/monaco-editor/typedoc/enums/languages.CompletionTriggerKind.html).
However, the current tests only validate the "TriggerCharacter" events.
This PR prepares the tests to support validating "Invoke" as well.
**Note:** It does change many of the tests from a "TriggerCharacter" to
an "Invoke" scenario. I think this is okay because
- there are still plenty of "TriggerCharacter" tests
- it would take a lot of work to update all the tests
- I will be adding a full set of tests to cover both scenarios as part
of https://github.com/elastic/kibana/issues/188677
- We may rely less and less on trigger characters in the future
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
