## Summary
We decided to group `Kibana API helpers` under a single fixture:
`apiServices` instead of individual fixtures. It should simplify the
search of existing helpers and reduce a risk for Teams to create the
same helper like we see today with FTR.
Adding just `apiServices` in test context and adding dot will expand a
list of all available API helpers + it can be extended for individual
solution (e.g. @kbn/scout-oblt) and directly in plugin (if there is no
chance to re-use it in other plugins)
<img width="699" alt="image"
src="https://github.com/user-attachments/assets/34a76659-04af-48c4-ab69-abda0c950206"
/>
Before:
```
test('should create something', async ({
fleetApi,
onboardingApi,
alertingApi,
}) => {
await fleetApi.integration.install(integrationName);
await onboardingApi.updateInstallationStepStatus(
onboardingId,
'ea-download',
'complete'
);
await alertingApi.waitForAlert(alertId);
```
After:
```
test('should create something', async ({
apiServices,
}) => {
await apiServices.fleet.integration.install(integrationName);
await apiServices.onboarding.updateInstallationStepStatus(
onboardingId,
'ea-download',
'complete'
);
await apiServices.alerting.waitForAlert(alertId);
```
This PR introduces evaluation functionality to Defend Insights, enabling
us to trigger LangSmith experiments directly from Kibana.
Additionally, we’ve migrated to the new prompt storage system used in
Attack Discovery (see commit bcbb12b732).
## Summary
Stop emitting any `.js` files during typechecking. We only depend on the
declarations, not the emitted, compiled javascript files.
An added benefit, is making some bad import errors more obvious.
We'll no longer try to build javascript files in place if a poor
import/require is made, rather the error of importing outside projects
(in the forest of a bunch of errors possibly) will be visible in the
typescript logs:
```
# instead of:
proc [tsc] error TS5055: Cannot write file '/opt/buildkite-agent/builds/bk-agent-prod-gcp-1741789017236110254/elastic/kibana-pull-request/kibana/src/platform/packages/shared/kbn-babel-register/cache/no_cache_cache.js' because it would overwrite input file.
# we'll see:
... several others like this
proc [tsc] src/platform/packages/shared/kbn-grok-ui/scripts/generate_patterns.js:10:9 - error TS6307: File '/Users/alex/Git/elastic-kibana/src/setup_node_env/index.js' is not listed within the file list of project '/Users/alex/Git/elastic-kibana/src/platform/packages/shared/kbn-grok-ui/tsconfig.type_check.json'. Projects must list all files or use an 'include' pattern.
proc [tsc]
proc [tsc] 10 require('../../../../../setup_node_env');
... several others like this
```
## Summary
Updates [axios to
1.8.3](https://github.com/axios/axios/releases/tag/v1.8.3).
Axios 1.8.2 fixed a vulnerability, but forgot to reflect the new flag in
their type definitions. This is probably required to allow the changes
smoothly.
## Summary
Closes#213074
This PR fixes the scenario where the entry waterfall transaction is
treated as an orphan, causing it to reparent itself and be duplicated
multiple times.
---------
Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
Closes https://github.com/elastic/observability-dev/issues/4238🔒
Closes https://github.com/elastic/observability-dev/issues/3513🔒
This change add logic for triggering [the page rendering performance
metrics](https://docs.elastic.dev/kibana-dev-docs/tutorial/performance/adding_custom_performance_metrics#report-kibanaplugin_render_time-metric-event)
for:
* Onboarding home screen
* Host auto-detect flow
* Host OTel flow
* Host K8S flow
* K8S OTel flow
* Firehose flow
## How to test
1. Run Kibana locally
2. Open browser dev tools
3. Navigate to one of the above mentioned onboarding screens
4. Observe `kibana:plugin_render_time` EBT event emitted in the Network
tab of the dev tools
Events emitted from local Kibana end up in the Staging Telemetry
cluster, there is a [dedicated rendering performance
dashboard](f240fff6-fac9-491b-81d1-ac39006c5c94?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:now-24h%2Fh,to:now))),
onboarding events can be filtered using `observabilityOnboarding`
application ID. (note that it takes some time for events to be indexed
and they appear in the cluster with a significant delay)
## Summary
Unskips some recently skipped tests in the notes reducer, I believe
because the time for each mock was just Date.now(), resulting in
slightly different times for each mock on ci, whereas locally the time
is the same.
### Checklist
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
## Summary
Changing code owners as discussed with @thomasneirynck and @davismcphee.
I also bumped CPU time limit as it fails few times passing over `1.55`
sec.
## Summary
This PR adds EBT telemetry to the Streams backend and UI. For the
backend APIs, we are only measuring latency on the "write" endpoints
that have the highest potential for being slow:
- `POST /api/streams/{name}/processing/_simulate 2023-10-31`
- `POST /api/streams/{name}/processing/_suggestions 2023-10-31`
- `POST /api/streams/{name}/_fork 2023-10-31`
- `PUT /api/streams/{name}/dashboards/{dashboardId} 2023-10-31`
- `PUT /api/streams/{name} 2023-10-31`
- `PUT /api/streams/{name}/_group 2023-10-31`
- `PUT /api/streams/{name}/_ingest 2023-10-31`
- `DELETE /api/streams/{name} 2023-10-31`
- `POST /api/streams/_enable 2023-10-31`
- `POST /api/streams/_disable 2023-10-31`
- `POST /api/streams/_resync 2023-10-31`
This is controlled by an allow list located in the server's telemetry
client.
For the UI, I've added the following tracking:
- **Number of Dashboards associated with a Stream** – This captures the
stream name and the number of dashboards associated with it. It's
attached to the dashboard hook, this means that we only track dashboard
counts on streams that users are actually using.
- **Clicks on Dashboards** – This captures the name of the dashboard,
the dashboard id, and the stream name
- **Latency of AI Grok Suggestions** – This captures the name of the
stream, the field used, the number of suggested patterns, the success
rates of the suggest patterns, and the connector id of the LLM. This
will also capture if the AI returned ZERO suggestions.
- **When a user accepts an AI Grok Suggestion** – This captures the name
of the stream, the name of the field, the success rate of the pattern,
and number of fields detected.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Add locator to some guidecards and simplify the flow by updating the
links
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds a basic api for finding suggested dashboards by alert.
This internal API is currently not in use anywhere.
This api finds suggested dashboards in two ways:
1. Finding dashboards with lens visualizations that query against the
same data view
2. Finding dashboards with lens visualizations that utilize fields in
the rule configuration, or alert data.
These are two naive approaches to finding suggested dashboards. These
heuristics will be improved over time and incorporate more sophisticated
approaches that have been explored by numerous engineers across
Observability.
## Testing
A basic api integration test is included that covers matching dashboards
by index and field, across spaces. As we develop this feature further
over time more fine grain tests will be added
### Manual Testing
1. Run
```
node x-pack/scripts/data_forge.js --events-per-cycle 200 --lookback now-1h --ephemeral-project-ids 10 --dataset fake_stack --install-kibana-assets --kibana-url http://localhost:5601 --event-template bad
```
2. Save the file as a .ndjson file and import it via saved objects
import
https://p.elstc.co/paste/3BWKIHLU#f0WfGYx7G9DhWy88yDXhaEXTX16Fn+ovDcomNIx6E3a
3. Navigate to the alert details page, you should start to see a lot of
alerts
4. Click on one, and copy the alert id
5. Navigate to console and paste `GET
kbn:/internal/observability/alerts/suggested_dashboards?alertId=[YOUR_ALERT_ID]`
to see the recommended dashboards
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
## Summary
This PR adds `eventName` property to the Siem Migrations telemetry. This
change is non-destructive to previous format and simply adds a new
property `eventName`.
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### Authz API migration for unauthorized routes
This PR migrates last unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
This PR:
- Makes a backup copy of the `kibana-alert-action-settings.yml` file
just in case I mess things up badly.
- Converts all of the descriptions and examples in the original file to
Markdown format.
- Adds the versioning info as follows:
- supported on ESS/ECH:
```
applies_to:
stack: ga
deployment:
self: ga
ess: ga
```
- not supported on ESS/ECH:
```
applies_to:
stack: ga
deployment:
self: ga
```
In the current Kibana settings docs we indicate settings available on
ESS/ECH. We don't indicate anything for other deployment types such as
ECK or ECE. I assume that no settings are available on Serverless. So,
the above versioning basically just copies what we document currently.
Once merged, I expect that we can test rendering the docs HTML pages
(like [this
one](https://www.elastic.co/guide/en/kibana/8.x/alert-action-settings-kb.html))
directly from this [YAML
source](https://github.com/elastic/kibana/blob/main/docs/settings-gen/source/kibana-alert-action-settings.yml).
@florent-leborgne and @wajihaparvez Sorry, I know this is kind of big.
I'd appreciate any input, especially on the versioning / `applies_to`
part since that's still a bit new.
Just for my own reference, I cut and pasted all of the Markdown from
[here](https://github.com/elastic/asciidocalypse/blob/main/docs/kibana/docs/reference/configuration-reference/alerting-settings.md?plain=1).
Closes: https://github.com/elastic/ingest-docs/issues/1659
## Summary
Closes https://github.com/elastic/kibana/issues/213216
This PR adds the functionality to properly highlight filtered values
within badges.
Previously, the content was treated as `text` instead of `html`, which
prevented the highlighted values from being displayed correctly.
The content is now rendered with the `<mark>` tag, allowing matching
values to be properly highlighted within the badges.
>[!NOTE]
>By looking at the code I assumed the `<mark>` tag is the only one we
introduce, so the proposed solution only handles that.
|Before|After|
|-|-|
|||
### How to test
- Make sure you are in a space with Observability as solution view
- Select the "All logs" data view
- Add any filter that matches the displayed badges value
## Summary
Resolves [this issue](https://github.com/elastic/kibana/issues/210168)
Vital links / clickable items should not be hidden behind tooltips that
require an additional click, as they do not include necessary indicators
for screen readers. Converting the clickable tooltip with the core web
vitals docs to a standard link.
<img width="1727" alt="Screenshot 2025-03-10 at 9 33 30 AM"
src="https://github.com/user-attachments/assets/ab611238-1fa1-455b-b0c4-563ae875e51d"
/>
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/212075
This change replaces the `--no-progress-meter` curl parameter with a
combination of `--silent` and `--show-error` to suppress verbose
progress output. `--no-progress-meter` was introduced in curl `v7.67.0`
which is not available on some popular OSs like RHEL 8.
## How to test
1. Create an RHEL 8 instance in GCP and login via SSH
2. Open auto detect flow on the Kibana instance deployed from this PR
3. Go through the flow and make sure the auto detect script goes through
all steps successfully
Minor refactor to extract get registration of `get_data_on_screen`. This
way the function co-located with the other LLM functions making it
easier to find and test.
This fixes an issue with the inference flyout where a 'secret' field
that wasn't required would defocus after every keypress. This happened
because the validation accidentally removed those secrets from the
schema, which forced a destruction of the components, and then on the
next render they got added back in.
This fixes that by no longer filtering out documents in the validation,
but only mapping them.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Summary
This PR changes the behavior of the Preview rule button in the create
rule form. Now the button will always be enabled, but upon clicking it
the validation of the define rule form will be triggered. If the form is
invalid, it will show a warning redirecting the user to the form in
order to fix the errors.
This PR removes the helper function `getIsRulePreviewDisabled` after
verifying that all the validations that it was doing are already covered
by the validation rules of the define rule form.
This solves issue #173930
---------
Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com>
