Makes sure keys from plain objects in arrays are validated as well.
---------
Co-authored-by: Søren Louv-Jansen <soren.louv@elastic.co>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/3331
Given the needs described in the linked issue about having a centralized
and async way to consume field metadata across Kibana, this work focuses
on providing server/client services to consume field metadata on demand
from static ECS definition and integration manifests, with the chance to
extend further the possible resolution sources.
3b2d9027-5c29-4081-ab17-1b43618c62a7
## 💡 Reviewers hints
This PR got quite long as it involves and touches different parts of the
codebase, so I'll break down the interesting parts for an easier review.
More details, code examples and mechanics description can be found in
the README file for the plugin.
### `@kbn/fields-metadata-plugin`
To avoid bundling and consuming the whole ECS static definition
client-side, a new plugin `@kbn/fields-metadata-plugin` is created to
expose the server/client services which enable retrieving only the
fields needed on a use-case basis.
### FieldsMetadataService server side
A `FieldsMetadataService` is instantiated on the plugin setup/start
server lifecycle, exposing a client to consume the fields and setup
tools for registering external dependencies.
The start contract exposes a `FieldsMetadataClient` instance. With this,
any application in Kibana can query for some fields using the available
methods, currently:
- `FieldsMetadataClient.prototype.getByName()`: retrieves a single
`FieldMetadata` instance.
- `FieldsMetadataClient.prototype.find()`: retrieves a record of
matching `FieldMetadata` instances.
`FieldsMetadataClient` is instantiated with the source repositories
dependencies. They act as encapsulated sources which are responsible for
fetching fields from their related source. Currently, there are 2 field
repository sources used in the resolution step, but we can use this
concept to extend the resolution step in future with more sources (LLM,
OTel, ...).
The currently used sources are:
- `EcsFieldsRepository`: allows fetching static ECS field metadata.
- `IntegrationFieldsRepository`: allows fetching fields from an
integration package from EPR, where the fields metadata are stored. To
correctly consume these fields, the `fleet` plugin must be enabled,
otherwise, the service won't be able to access the registered fields
extractor implemented with the fleet services.
As this service performs a more expensive retrieval process than the
`EcsFieldsRepository` constant complexity access, a caching layer is
applied to the retrieved results from the external source to minimize
latency.
### Fields metadata API
To expose this service to the client, a first API endpoint is created to
find field metadata and filter the results to minimize the served
payload.
- `GET /internal/fields_metadata/find` supports some initial query
parameters to narrow the fields' search.
### FieldsMetadataService client side
As we have a server-side `FieldsMetadataService`, we need a client
counterpart to consume the exposed API safely and go through the
validation steps.
The client `FieldsMetadataService` works similarly to the server-side
one, exposing a client which is returned by the public start contract of
the plugin, allowing any other to directly use fields metadata
client-side.
This client would work well with existing state management solutions, as
it's not decoupled from any library.
### useFieldsMetadata
For simpler use cases where we need a quick and easy way to consume
fields metadata client-side, the plugin start contract also exposes a
`useFieldsMetadata` react custom hook, which is pre-created accessing
the FieldsMetadataService client described above. It is important to
retrieve the hook from the start contract of this plugin, as it already
gets all the required dependencies injected minimizing the effort on the
consumer side.
The `UnifiedDocViewer` plugin changes exemplify how we can use this hook
to access and filter fields' metadata quickly.
### `registerIntegrationFieldsExtractor` (@elastic/fleet)
Getting fields from an integration dataset is more complex than
accessing a static dictionary of ECS fields, and to achieve that we need
access to the PackageService implemented by the fleet team.
To get access to the package, maintain a proper separation of concerns
and avoid a direct dependency on the fleet plugin, some actions were
taken:
- the `PackageService.prototype.getPackageFieldsMetadata()` method is
implemented to keep the knowledge about retrieving package details on
this service instead of mixing it on parallel services.
- a fleet `registerIntegrationFieldsExtractor` service is created and
used during the fleet plugin setup to register a callback that accesses
the service as an internal user and retrieves the fields by the given
parameters.
- the fields metadata plugin returns a
`registerIntegrationFieldsExtractor` function from its server setup so
that we can use it to register the above-mentioned callback that
retrieves fields from an integration.
This inverts the dependency between `fields_metadata` and `fleet`
plugins so that the `fields_metadata` plugin keeps zero dependencies on
external apps.
## Adoption
We currently have places where the `@elastic/ecs` package is directly
accessed and where we might be able to refactor the codebase to consume
this service.
**[EcsFlat usages in
Kibana](https://github.com/search?q=repo%3Aelastic%2Fkibana%20EcsFlat&type=code)**
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Add the `sideEffects` meta to packages without side effects to optimize
tree-shaking on browser-side bundles.
Notes:
- it mostly impacts the `securitySolution` app (almost 2mb reduction)
- it's not always beneficial for all apps, some apps gain some weight,
likely related to the way webpack optimizes the chunks, but I feel like
it's still overall beneficial (don't hesitate to say if you think
otherwise)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
closes#88290
## 📝 Summary
As described in #88290 we need to add `date_nanos` support to the Stream
UI page. In this PR the necessary changes have been made all over the
Stream UI and the usages of it.
## ✅ Testing
⚠️ Testing the Stream UI with old timestamp indices is important to make
sure that the behavior is still as before and not affected at all. This
can be done by running local env from the PR and simulating all
interactions on edge-lit cluster for example, to make sure that the
behavior is not changed.
For testing the new changes with support of `date_nano`:
1. You can use [the steps
here](https://github.com/elastic/kibana/issues/88290#issuecomment-1713400873)
to create and ingest documents with nano precision.
2. Navigate to the stream UI and the documents should be displayed
properly.
3. Sync with the URL state should be changed from timestamp to ISO
string date.
4. Changing time ranges should behave as before, as well as Text
Highlights.
5. Open the logs flyout and you should see the timestamp in nano
seconds.
6. Play around with the minimap, it should behave exactly as before.
### Stream UI:
<img width="2556" alt="Screenshot 2023-11-02 at 14 15 49"
src="596966cd-0ee0-44ee-ba15-f387f3725f66">
- The stream UI has been affected in many areas:
- The logPosition key in the URL should now be in ISO string, but still
backward compatible incase the user has bookmarks with timestamps.
- The minimap should still behave as before in terms of navigation
onClick and also highlighting displayed areas
### Stream UI Flyout:
<img width="2556" alt="Screenshot 2023-11-02 at 14 15 23"
src="6081533c-3bed-43e1-872d-c83fe78ab436">
- The logs flyout should now display the date in nanos format if the
document is ingested using a nano format.
### Anomalies:
<img width="1717" alt="Screenshot 2023-11-01 at 10 37 22"
src="b6170d76-40a4-44db-85de-d8ae852bc17e">
-Anomalies tab under logs as a navigation to stream UI which should
still behave as before passing the filtration and time.
### Categories:
<img width="1705" alt="Screenshot 2023-11-01 at 10 38 19"
src="c4c19202-d27f-410f-b94d-80507542c775">
-Categories tab under logs as a navigation to stream UI which should
still behave as before passing the filtration and time.
### External Links To Stream:
- All links to the Stream UI should still work as before:
- APM Links for traces, containers, hosts
- Infra links in Inventory and Hosts views
## 🎥 Demo
9a39bc5a-ba37-49e0-b7f2-e73260fb01f0
Updates new teams as codeowners for Observability team changes.
Also took the opportunity to:
- Delete some paths that no longer exist
- Split infra code ownership between teams (from #168992)
Implements chat & function calling for the Observability AI Assistant.
The APM related changes are due to a correction in the `toBooleanRt`
type.
Code in `x-pack/observability_ai_assistant` has been reviewed via
feature branches.
---------
Co-authored-by: Coen Warmer <coen.warmer@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
closes [#157505](https://github.com/elastic/kibana/issues/157505)
fixes [#157740](https://github.com/elastic/kibana/issues/157740)
## Summary
This PR adds strict payload validation to `inventory_views` endpoint. I
tried to make the types consistent between sever and frontend code and
because of that more changes had to be made. I also refactored the
`toolbar_control` component, decoupling them from Inventory View and
Metrics Explorer View types
### How to test
- Call the endpoint below trying to use invalid values. see
[here](https://github.com/elastic/kibana/pull/160852/files#diff-058b21e249ebbe2795d450d07025d8904a58cfb07a97979e85975f87e931ffceR133-R143).
```bash
[POST|PUT] kbn:/api/infra/inventory_views
{
"attributes": {
"metric": {
"type": [TYPE]
},
"sort": {
"by": "name"
"direction": "desc"
},
"groupBy": [],
"nodeType": "host",
"view": "map",
"customOptions": [],
"customMetrics": [],
"boundsOverride": {
"max": 1,
"min": 0
},
"autoBounds": true,
"accountId": "",
"region": "",
"autoReload": false,
"filterQuery": {
"expression": "",
"kind": "kuery"
},
"legend": {
"palette": "cool",
"steps": 10,
"reverseColors": false
},
"timelineOpen": false,
"name": "test-uptime"
}
}
```
- Set up a local Kibana instance
- Navigate to `Infrastructure`
- In the UI, use the Saved View feature and try different field
combinations
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/2655
This PR introduces a customized log consumption experience in the
Discover plugin. By leveraging the new `discover_log_explorer` plugin
and utilizing the `discover.customize` functionality, we have curated a
more tailored user experience.
The key feature of this implementation is the `DatasetSelector`
component, which replaces the original Discover `DataViewPicker`. It
handles the retrieval, rendering, and navigation of integrations and
data streams related to logs, providing an improved user interface.
This PR involves significant development efforts, including the creation
of the `discover_log_explorer` plugin, implementation of services, state
machines, custom hooks, and enhancements to presentational components.
The following overview will help reviewers understand the
responsibilities of each component in this implementation.
d725b699-452e-4718-8189-8dc1fab4d044
## DatasetsService & DatasetsClient
The DatasetsService is introduced, a crucial component that mediates
access to the newly implemented DatasetsClient. During the plugin's
lifecycle, the DatasetsService exposes a client property through its
start() method, providing convenient access to a DatasetsClient
instance.
The DatasetsClient is responsible for abstracting the data fetching
process for two endpoints: the integrations endpoint and the data
streams listing endpoint. These endpoints are utilized to populate the
selector options in the user interface. To facilitate this, the
DatasetsClient exposes the findIntegrations and findDatasets methods,
which handle the respective data fetching.
## Discover Customization
The critical part of this work consists of where the customization is
applied.
Inside the `public/plugin.tsx`, we lazy load and create, injecting the
required dependencies, the `CustomDatasetSelector`, which already
encapsulates all the logic required to make the selector work with the
external APIs.
We kept separating the data fetching logic from how the selector works,
and all the data and events are passed into the UI component with
properties.
```ts
discover.customize(
DISCOVER_LOG_EXPLORER_PROFILE_ID,
({ customizations, stateContainer }) => {
customizations.set({
id: 'search_bar',
CustomDataViewPicker: createLazyCustomDatasetSelector({
datasetsClient: datasetsService.client,
stateContainer,
}),
});
...
```
## Data fetching state machines & custom hooks
To handle the data fetching of integrations and unmanaged data streams,
we created two different state machines to separately handle the related
action for each dataset, such as remote search, in-memory search, error
handling etc.
### Integration machine and useIntegrations
The integrations state machine handles automatic data fetching of the
resources and additionally provides transitions for loading more
integrations, searching integrations by HTTP request, searching locally
into integration streams, and all the related loading and error handling
states.
It is then interpreted inside the `useIntegrations` custom hook, which
exposes the fetched data and handlers for all the above-mentioned
actions.
<img width="1975" alt="Screenshot 2023-05-30 at 09 44 42"
src="6daeca9f-826d-4a0f-bd90-eb4826ed1bde">
### Datasets machine and useDatasets
Similar to the integrations state machine, but simplified since the data
streams search can only happen with HTTP requests and there is no
pagination that requires to handle the load of more entries.
It is interpreted inside the `useDatasets` custom hook, which also
exposes the fetched data and handlers for the available actions.
<img width="1692" alt="Screenshot 2023-05-30 at 09 45 11"
src="5f9690e2-4e8f-439e-9ffd-f3b34cf3eaf5">
## DatasetSelector
The `DatasetSelector` component contains all the logic that manages the
navigation and searches across the different panels that render
integrations, integrations' streams or unmanaged streams.
As the datasets come from different APIs or are performed in-memory, the
search work follow this logic:
- When listing the integrations list (first level of the
`EuiContextMenu`), the search is done with an HTTP request.
- When listing the data streams list for a specific integration (second
level of the `EuiContextMenu`), the search is done in-memory, filtering
and sorting directly in the client.
- When listing the unmanaged data streams list (second level of the
`EuiContextMenu`), the search is done again with an HTTP request.
To handle these possible user journeys correctly without side effects,
we created another state machine and exposed its actions with an
internal `useDatasetSelector` custom hook.
<img width="1978" alt="Screenshot 2023-05-30 at 09 46 04"
src="84aa4247-c65d-40de-9eb6-6117bee731f8">
## Next steps
This component will change quite a lot until we won't get to a final
design. As soon as a first solid mvp is defined for production, a
complete test for the component will be implemented, among with a more
generic functional test for the core customization features.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
closes https://github.com/elastic/kibana/issues/154147
## Summary
This PR introduces `io-ts` runtime validation to asset manager
endpoints.
The parameters will be validated as follows:
- `maxDistance`: range from 1 to 5
- `size`: range from 1 to 100
- `type`: `k8s.pod` or `k8s.cluster` or `k8s.node`
- `relation`: `ancestors` or `descendants` or `references`
- any date parameter: Date ISO or DateMath formats
### How to test this PR
- enable `xpack.assetManager.alphaEnabled` in kibana.dev.yml
- Call the endpoints below and try to pass invalid parameters where
they're applicable:
- `GET
kbn:/api/asset-manager/assets?from=2023-03-25T17:44:44.000Z&to=2023-03-25T18:44:44.000Z`
- `GET
kbn:/api/asset-manager/assets/diff?aFrom=2022-02-07T00:00:00.000Z&aTo=2022-02-07T01:30:00.000Z&bFrom=2022-02-07T01:00:00.000Z&bTo=2022-02-07T02:00:00.000Z`
- `GET
kbn:/api/asset-manager/assets/related?ean=k8s.node:node-101&relation=ancestors&maxDistance=1&from=2023-04-18T13:10:13.111Z&to=2023-04-18T15:10:13.111Z`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Part of #152617Closes#155158
This PR implements the CRUD endpoints for the inventory views.
Following the approach used for the LogViews service, it exposes a
client that abstracts all the logic concerned to the `inventory-view`
saved objects.
It also follows the guideline provided for [Versioning
interfaces](https://docs.elastic.dev/kibana-dev-docs/versioning-interfaces)
and [Versioning HTTP
APIs](https://docs.elastic.dev/kibana-dev-docs/versioning-http-apis),
preparing for the serverless.
## 🤓 Tips for the reviewer
You can open the Kibana dev tools and play with the following snippet to
test the create APIs, or you can perform the same requests with your
preferred client:
```
// Get all
GET kbn:/api/infra/inventory_views
// Create one
POST kbn:/api/infra/inventory_views
{
"attributes": {
"name": "My inventory view"
}
}
// Get one
GET kbn:/api/infra/inventory_views/<switch-with-id>
// Update one
PUT kbn:/api/infra/inventory_views/<switch-with-id>
{
"attributes": {
"name": "My inventory view 2"
}
}
// Delete one
DELETE kbn:/api/infra/inventory_views/<switch-with-id>
```
## 👣 Next steps
- Replicate the same logic for the metrics explorer saved object
- Create a client-side abstraction to consume the service
- Update the existing react custom hooks to consume the endpoint
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
closes#146517
This PR expands the current `includeTimeseries` parameter behaviour, by
not using the `date_histogram` in the `composite` aggregation when it is
set to `false`.
This way, not only the API won't return a `timeseries` object, but the
query will calculate the aggregations on ES side as opposed to when
`includeTimeseries` is true, that does an extra `avg` and `max`
calculation on TS side using the histogram buckets.
The main motivation behind this change is to run the snapshot query
without the need of returning buckets, to avoid the max bucket error.
### How to test
- Enable the system module on metricbeat
- Start a local Kibana
- Start metricbeat
- Explore `Infrastructure > Metrics`, `Infrastructure > Inventory` and
`Infrastructure > Hosts` and play with the filters
#### cURL
##### Run a query with Composite aggregation
###### With timeseries
```bash
curl -XPOST -f 'http://0.0.0.0:5601/ftw/api/metrics/snapshot' \
-H 'kbn-xsrf:localhost' \
-H 'Content-Type: application/json' \
--data-raw '{"filterQuery":"{\"bool\":{\"must\":[],\"filter\":[],\"should\":[],\"must_not\":[]}}","metrics":[{"type":"memory"}],"groupBy":[],"nodeType":"host","sourceId":"default","accountId":"","region":"","timerange":{"from":1670859470896,"to":1670861030896,"interval":"1m","ignoreLookback":true},"includeTimeseries":true}' \
-u elastic:changeme
```
###### Without timeseries
```bash
curl -XPOST -f 'http://0.0.0.0:5601/ftw/api/metrics/snapshot' \
-H 'kbn-xsrf:localhost' \
-H 'Content-Type: application/json' \
--data-raw '{"filterQuery":"{\"bool\":{\"must\":[],\"filter\":[],\"should\":[],\"must_not\":[]}}","metrics":[{"type":"memory"}],"groupBy":[],"nodeType":"host","sourceId":"default","accountId":"","region":"","timerange":{"from":1670859470896,"to":1670861030896,"interval":"1m","ignoreLookback":true},"includeTimeseries":false}' \
-u elastic:changeme
```
##### Run a query with just Date Histogram
###### With timeseries
```bash
curl -XPOST -f 'http://0.0.0.0:5601/ftw/api/metrics/snapshot' \
-H 'kbn-xsrf:localhost' \
-H 'Content-Type: application/json' \
--data-raw '{"filterQuery":"{\"bool\":{\"must\":[],\"filter\":[],\"should\":[],\"must_not\":[]}}","metrics":[{"type":"memory"}],"groupBy":null,"nodeType":"host","sourceId":"default","accountId":"","region":"","timerange":{"from":1670859470896,"to":1670861030896,"interval":"1m","ignoreLookback":true},"includeTimeseries":true}' \
-u elastic:changeme
```
##### Without timeseries
```bash
curl -XPOST -f 'http://0.0.0.0:5601/ftw/api/metrics/snapshot' \
-H 'kbn-xsrf:localhost' \
-H 'Content-Type: application/json' \
--data-raw '{"filterQuery":"{\"bool\":{\"must\":[],\"filter\":[],\"should\":[],\"must_not\":[]}}","metrics":[{"type":"memory"}],"groupBy":null,"nodeType":"host","sourceId":"default","accountId":"","region":"","timerange":{"from":1670859470896,"to":1670861030896,"interval":"1m","ignoreLookback":true},"includeTimeseries":false}' \
-u elastic:changeme
```
### For maintainers
The `logRate` metric type <b>doesn't</b> work without being in a date
histogram, because it uses [cumulative
sum](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-pipeline-cumulative-sum-aggregation.html).
Therefore `includeTimeseries` false in a `composite` aggregation will
return a 400 error. I haven't found anywhere that would make a request
like below.
#### 400 error
```bash
curl -XPOST -f 'http://0.0.0.0:5601/ftw/api/metrics/snapshot' \
-H 'kbn-xsrf:localhost' \
-H 'Content-Type: application/json' \
--data-raw '{"filterQuery":"{\"bool\":{\"must\":[],\"filter\":[],\"should\":[],\"must_not\":[]}}","metrics":[{"type":"logRate"}],"groupBy":[],"nodeType":"host","sourceId":"default","accountId":"","region":"","timerange":{"from":1670859470896,"to":1670861030896,"interval":"1m","ignoreLookback":true},"includeTimeseries":false}' \
-u elastic:changeme
```
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes [#145238](https://github.com/elastic/kibana/issues/145238)
## Summary
These changes add validation to the Metric Indices passed into the
Metrics settings page.
New validation is added both in the UI and in the endpoint, performing
the following checks:
- Index pattern is not an empty string
- Index pattern does not contain empty spaces (start, middle, end) (the
pattern is not trimmed)
- Index pattern does not contain empty entries, comma-separated values
should have an acceptable value.
In case the value is not valid, the UI will render an appropriate error
message.
If the `PATCH /api/metrics/source/{sourceId}` request to update the
value is manually sent with an invalid value, the server will respond
with a 400 status code and an error message.
Also, for retro compatibility and to not block the user when the
configuration can't be successfully retrieved, in case of internal error
the `GET /api/metrics/source/{sourceId}` will return a 404 and on the
UI, instead of rendering a blank page, the user will see the empty form
and will be able to re-insert the right values.
## Testing
Navigate to `Inventory`-> Click on `Settings` on the topbar -> Start
writing different metric indices in the Metric Indices field.
### Editing Metric Indices validation
https://user-images.githubusercontent.com/34506779/203763021-0f4d8926-ffa4-448a-a038-696732158f4e.mov
### Missing/Broken configuration response
https://user-images.githubusercontent.com/34506779/203763120-ffc91cd3-9bf4-43da-a04f-5561ceabf591.mov
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* [packages] add kibana.jsonc files
* auto-migrate to kibana.jsonc
* support interactive pkg id selection too
* remove old codeowners entry
* skip codeowners generation when .github/CODEOWNERS doesn't exist
* fall back to format validation if user is offline
* update question style
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* refact(NA): apply root_input_dir=src to each already created pkg
* refact(NA): update package generator
* fix(NA): correctly use rootDir
* fix(NA): use root input dir on latest introduced pkgs for jsts_transpiler macro
* chore(NA): merge with main
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [type-summarizer] reimplement for broader support
* Enable sourceMaps in all packages
* include naming collision in summarizePackage test
* fix readmes
* remove unnecessary transient dependency
* remove code that was commented out
* remove outdated todo comment
* ensure errors triggered by untyped-exports are ligible
* remove unused import
* break out snippet generation from AstIndexer
* refactor several massive files into smaller pieces and add more inline docs
* fix typos
* update jest snapshots
* add sections to readme that points people to the useful parts of the source code along with a high-level overview of how the type-summarizer works
* remove --dump flag, it doesn't work
* use decName instead of calling names.get a second time
* include `export` as invalid name
* [build_ts_refs] improve caches, allow building a subset of projects
* cleanup project def script and update refs in type check script
* rename browser_bazel config to avoid kebab-case
* remove execInProjects() helper
* list references for tsconfig.types.json for api-extractor workload
* disable composite features of tsconfig.types.json for api-extractor
* set declaration: true to avoid weird debug error
* fix jest tests
Co-authored-by: spalger <spalger@users.noreply.github.com>
* [APM] @kbn/typed-router-config
* [APM] typed route config
* Breadcrumbs, wildcards
* Migrate settings, home
* Migrate part of service detail page
* Migrate remaining routes, tests
* Set maxWorkers for precommit script to 4
* Add jest types to tsconfigs
* Make sure transaction distribution data is fetched
* Fix typescript errors
* Remove usage of react-router's useParams
* Add route() utility function
* Don't use ApmServiceContext for alert flyouts
* Don't add onClick handler for breadcrumb
* Clarify ts-ignore
* Remove unused things
* Update documentation
* Use useServiceName() in ServiceMap component
* Set up Observability rule APIs
* Populate alerts table with data from API
* Move field map types/utils to common
* Format reason/link in alert type
* Format reason/link in alert type
* Fix issues with tsconfigs
* Storybook cleanup for example alerts
* Use `MemoryRouter` in the stories and `useHistory` in the component to get the history
* Replace examples with ones from "real" data
* Use `() => {}` instead of `jest.fn()` in mock registry data
* Store/display evaluations, add active/recovered badge
* Some more story fixes
* Decode rule data with type from owning registry
* Use transaction type/environment in link to app
* Fix type issues
* Fix API tests
* Undo changes in task_runner.ts
* Remove Mutable<> wrappers for field map
* Remove logger.debug calls in alerting es client
* Add API test for recovery of alerts
* Revert changes to src/core/server/http/router
* Use type imports where possible
* Update limits
* Set limit to 100kb
Co-authored-by: Nathan L Smith <smith@nlsmith.com>
