## Summary
Assign test files to obs ai assist team
Contributes to: #192979
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Creates the Streams app plugin, which renders UI for managing streams
(see https://github.com/elastic/kibana/pull/198713).
Additional changes in this PR:
- The menus were updated to conditionally add a link to the Streams app.
The Streams plugin itself returns a status$ observable which signals if
Streams have been enabled. This value is used to conditionally render
the link in the various flavors of menus.
- There's a small change in the ES types to allow for ordered params in
ES|QL (vs named params)
- `@kbn/server-route-repository` was updated to be able to override
`access` (instead of only inferring it from the endpoint name).
Additionally, we now allow all route options by default.
- `@kbn/typed-react-router-config` now also exports a `useBreadcrumbs`.
This was copied over from the APM implementation.
- the signature of the `esql` method in
`ObservabilityElasticsearchClient` was updated to separate processing
options from options that are sent over to the _query endpoint.
---------
Co-authored-by: Chris Cowan <chris@elastic.co>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[dependency-cruiser](https://github.com/sverweij/dependency-cruiser/tree/main)
is used for building dependency graph.
### Show all dependencies for a specific package/plugin or directory
#### Run for all plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins -o ./tmp/deps-result-all.json
```
#### Run for single plugin
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -o ./tmp/deps-result-single.json
```
#### Run for multiple plugins
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution x-pack/plugins/security -o ./tmp/deps-result-multiple.json
```
#### Run for `x-pack/packages`
```bash
bash scripts/dependency_usage.sh -p x-pack/packages -o ./tmp/deps-packages-1.json
```
#### Run for `packages`
```bash
bash scripts/dependency_usage.sh -p packages -o ./tmp/deps-packages-2.json
```
#### Benchmark
| Analysis | Real Time | User Time | Sys Time |
|-----------------------|-------------|-------------|------------|
| All plugins | 7m 21.126s | 7m 53.099s | 20.581s |
| Single plugin | 31.360s | 45.352s | 2.208s |
| Multiple plugins | 36.403s | 50.563s | 2.814s |
| x-pack/packages | 6.638s | 12.646s | 0.654s |
| packages | 25.744s | 39.073s | 2.191s |
#### Show all packages/plugins within a directory that use a specific
dependency
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins/security_solution
```
---
#### Show all packages/plugins within a directory grouped by code owner
```sh
bash scripts/dependency_usage.sh -d rxjs -p x-pack/plugins -g owner
```
---
#### Group by code owner with adjustable collapse depth for fine-grained
grouping
**Fine-grained grouping**:
```sh
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 4
```
**Collapsed grouping**: groups the results under a higher-level owner
(e.g., `security_solution` as a single group).
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -g owner --collapse-depth 1
```
---
#### Show all dependencies matching a pattern (e.g., `react-*`) within a
package
```bash
bash scripts/dependency_usage.sh -p x-pack/plugins/security_solution -d 'react-*' -o ./tmp/result.json
```
### Checklist
- [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
__Related: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to security-defend-workflows team
Contributes to: #192979
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to platform-security team
Contributes to: #192979
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## 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 <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Milton Hultgren <miltonhultgren@gmail.com>
## Summary
This PR is part of the Kibana Sustainable Architecture effort.
The goal is to start categorising Kibana packages into _generic
platform_ (`group: "platform"`) vs _solution-specific_.
```
group?: 'search' | 'security' | 'observability' | 'platform'
visibility?: 'private' | 'shared'
```
Uncategorised modules are considered to be `group: 'common', visibility:
'shared'` by default.
We want to prevent code from solution A to depend on code from solution
B.
Thus, the rules are pretty simple:
* Modules can only depend on:
* Modules in the same group
* OR modules with 'shared' visibility
* Modules in `'observability', 'security', 'search'` groups are
mandatorily `visibility: "private"`.
Long term, the goal is to re-organise packages into dedicated folders,
e.g.:
```
x-pack/platform/plugins/private
x-pack/observability/packages
```
For this first wave, we have categorised packages that seem
"straightforward":
* Any packages that have:
* at least one dependant module
* all dependants belong to the same group
* Categorise all Core packages:
* `@kbn/core-...-internal` => _platform/private_
* everything else => _platform/shared_
* Categorise as _platform/shared_ those packages that:
* Have at least one dependant in the _platform_ group.
* Don't have any `devOnly: true` dependants.
### What we ask from you, as CODEOWNERS of the _package manifests_, is
that you confirm that the categorisation is correct:
* `group: "platform", visibility: "private"` if it's a package that
should only be used from platform code, not from any solution code. It
will be loaded systematically in all serverless flavors, but solution
plugins and packages won't be able to `import` from it.
* `group: "platform", visibility: "shared"` if it's a package that can
be consumed by both platform and solutions code. It will be loaded
systematically in all serverless flavors, and anybody can import / use
code from it.
* `group: "observability" | "security" | "search", visibility:
"private"` if it's a package that is intented to be used exclusively
from a given solution. It won't be accessible nor loaded from other
solutions nor platform code.
Please refer to
[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)
for any related questions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Found a missing space character in the code owners file. This created
problems when trying to filter for all the areas owned by
@elastic/appex-sharedux
## Summary
Initially we kept under `appex-qa` the code ownership of the whole
`x-pack/test/api_integration/deployment_agnostic` directory.
It helped us to keep track of test migration, provide feedback to the
Observability Teams and make sure tests are deployment-agnostic by
design and continuous runs against Cloud (both MKI & ESS deployments)
have no major failures.
As of now, we believe Teams need less guidance and we can limit
`appex-qa` code ownership to shared services and config files, as it is
still critical assets for FTR tests stability.
For reviewers: please review that your Team ownership is properly
assigned.
## Summary
Assign test files to observability-ai-assistant team
Contributes to: #192979
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Assign test files to Core Team
Contributes to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: Robert Oskamp <robert.oskamp@elastic.co>
Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
## Summary
Assign test files to logstash team
Contributes to: https://github.com/elastic/kibana/issues/192979
---------
Co-authored-by: Robert Oskamp <robert.oskamp@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to data discovery team
Contributes to: #192979
---------
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
## Summary
Close https://github.com/elastic/kibana/issues/193473
Close https://github.com/elastic/kibana/issues/193474
This PR utilize the documentation packages that are build via the tool
introduced by https://github.com/elastic/kibana/pull/193847, allowing to
install them in Kibana and expose documentation retrieval as an LLM task
that AI assistants (or other consumers) can call.
Users can now decide to install the Elastic documentation from the
assistant's config screen, which will expose a new tool for the
assistant, `retrieve_documentation` (only implemented for the o11y
assistant in the current PR, shall be done for security as a follow up).
For more information, please refer to the self-review.
## General architecture
<img width="1118" alt="Screenshot 2024-10-17 at 09 22 32"
src="https://github.com/user-attachments/assets/3df8c30a-9ccc-49ab-92ce-c204b96d6fc4">
## What this PR does
Adds two plugin:
- `productDocBase`: contains all the logic related to product
documentation installation, status, and search. This is meant to be a
"low level" components only responsible for this specific part.
- `llmTasks`: an higher level plugin that will contain various LLM tasks
to be used by assistants and genAI consumers. The intent is not to have
a single place to put all llm tasks, but more to have a default place
where we can introduce new tasks from. (fwiw, the `nlToEsql` task will
probably be moved to that plugin).
- Add a `retrieve_documentation` tool registration for the o11y
assistant
- Add a component on the o11y assistant configuration page to install
the product doc
(wiring the feature to the o11y assistant was done for testing purposes
mostly, any addition / changes / enhancement should be done by the
owning team - either in this PR or as a follow-up)
## What is NOT included in this PR:
- Wire product base feature to the security assistant (should be done by
the owning team as a follow-up)
- installation
- utilization as tool
- FTR tests: this is somewhat blocked by the same things we need to
figure out for https://github.com/elastic/kibana-team/issues/1271
## Screenshots
### Installation from o11y assistant configuration page
<img width="1476" alt="Screenshot 2024-10-17 at 09 41 24"
src="https://github.com/user-attachments/assets/31daa585-9fb2-400a-a2d1-5917a262367a">
### Example of output
#### Without product documentation installed
<img width="739" alt="Screenshot 2024-10-10 at 09 59 41"
src="https://github.com/user-attachments/assets/993fb216-6c9a-433f-bf44-f6e383d20d9d">
#### With product documentation installed
<img width="718" alt="Screenshot 2024-10-10 at 09 55 38"
src="https://github.com/user-attachments/assets/805ea4ca-8bc9-4355-a434-0ba81f8228a9">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign home plugin and helper.
This pr is a follow up to a wrongly assigned entry within
https://github.com/elastic/kibana/pull/200142
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
Adds the new Defend Insights Elastic Assistant tool. This assistant tool
provides Elastic Defend configuration insights. For this initial PR,
only incompatible antivirus detection is supported. Telemetry is
collected for success and error events.
For incompatible antivirus detection, Defend Insights will review the
last 200 file events for the given endpoint and output suspected
antiviruses. Improvements such as customizable event count and date
range will come in the future.
This PR does not include any UI, that will come in a separate PR. 3
internal APIs for interacting with Defend Insights are provided here:
- `POST /defend_insights` for creating a new Defend Insight
- `GET /defend_insights/{id}` for getting a Defend Insight
- `GET /defend_insights` for getting multiple Defend Insights
- available optional query params:
- `size` - default 10
- `ids`
- `connector_id`
- `type` - `incompatible_antivirus`
- `status` - `running`, `completed`, `failed`, `canceled`
- `endpoint_ids`
This initial implementation does not include the LangGraph/output
chunking upgrades seen in Attack Discovery due to time constraints.
We'll look to make this upgrade in a future PR.
### 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
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
## Summary
close https://github.com/elastic/kibana/issues/194165
close https://github.com/elastic/kibana-team/issues/1245
### User-facing
<img width="1680" alt="image"
src="https://github.com/user-attachments/assets/6df4ee9f-1b4d-404c-a764-592998a1d430">
This PRs adds a new tab in the editor history component. You can star
your query from the history and then you will see it in the Starred
list. The started queries are scoped to a user and a space.
### Server
To allow starring ESQL query, this PR extends [favorites
service](https://github.com/elastic/kibana/pull/189285) with ability to
store metadata in addition to an id. To make metadata strict and in
future to support proper metadata migrations if needed, metadata needs
to be defined as schema:
```
plugins.contentManagement.favorites.registerFavoriteType('esql_query', {
typeMetadataSchema: schema.object({ query: schema.string(), timeRange:...., etc... }),
})
```
Notable changes:
- Add support for registering a favorite type and a schema for favorite
type metadata. Previosly the `dashboard` type was the only supported
type and was hardcoded
- Add `favoriteMetadata` property to a saved object mapping and make it
`enabled:false` we don't want to index it, but just want to store
metadata in addition to an id.
[code](https://github.com/elastic/kibana/pull/198362/files#diff-d1a39e36f1de11a1110520d7607e6aee7d506c76626993842cb58db012b760a2R74-R87)
- Add a 100 favorite items limit (per type per space per user). Just do
it for sanity to prevent too large objects due to metadata stored in
addtion to ids.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Stratoula Kalafateli <stratoula1@gmail.com>
Closes https://github.com/elastic/kibana/issues/199361
While investigating, I found that fetching DOM element with id
`app-fixed-viewport` is a common pattern. I created the hook
`useAppFixedViewport` to consolidate this logic into a single location.
The hook only performs the DOM look-up on first render and then avoids
the DOM look-up on each additional render.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to presentation team
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign maps test files to presentation team
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
## Summary
- Exposes the interfaces that define the format of the response of the
`/api/status` endpoint.
- Moves them from `@kbn/core-status-common-internal` to
`@kbn/core-status-common`.
- Removes the former package, as it no longer contains anything.
- Fixes some of the illegal dependencies uncovered by
https://github.com/elastic/kibana/pull/199630.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Assign test files to observability-ui team
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to stack-monitoring team
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Assign test files to apm teams
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to ops team
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Assign test files to obs-ux-management-team
Contributes to: #192979
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
