Closes#163282
## Summary
This PR:
* Adds a `featureFlags.metricsExplorerEnabled` property to the Infra
plugin config to enable and disable Metrics Explorer depending on the
offering type
* Prevents `MetricsExplorerViewsService` initialization for serveless
based on the feature flag
* Prevents creating Metrics Explorer frontend routes when in serverless
* Prevents registration of the MetricsExplorerViews saved object when in
serverless
* Prevents initialization of the `metrics_explorer_views` API routes
when in serverless
**Trying to access Metrics Explorer in serverless**
<img width="1829" alt="CleanShot 2023-09-22 at 12 59 35@2x"
src="2b039925-0f0b-4c07-be29-bbe910de7a34">
**Trying to access views API**
<img width="1829" alt="CleanShot 2023-09-22 at 13 00 00@2x"
src="15269ec2-becd-4ee3-9b5e-d916df28a7b8">
**`infra/metrics_explorer` API still works as per ticket requirements**
<img width="1829" alt="CleanShot 2023-09-22 at 13 00 06@2x"
src="fb23f912-c6fd-46c8-9084-c17c51e5b064">
## How to test
* Checkout locally
* Enable Infra in `serverless.oblt.yml`: `xpack.infra.enabled: true`
* Run Kibana in serverless mode
* Try accessing `/app/metrics/explorer` route and make sure it's not
available
* Make sure other Infra routes (`/app/metrics/inventory` and
`/app/metrics/hosts`) still load as expected
* In Kibana dev console make sure you get 404 for `GET
kbn:/api/infra/metrics_explorer_views`
* Also check that you don't see `metrics-explorer-view` saved object in
the response for `GET
kbn:/api/kibana/management/saved_objects/_allowed_types`
* Run Kibana in non-serverless mode and make sure Metrics Explorer is
accessible and works as usual
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161876
Creates a plugin providing utilities to access metrics data. The plugin
only exposes a server API which includes a client with two methods:
- `getMetricIndices` to retrieve the user-defined indices where metrics
are located
- `updateMetricIndices` to update the indices
The client is now used where we previously relied on infra plugin to
provide the configuration, in APM and Infra.
The plugin persists the configuration in a new saved object
`metrics-data-source`. Because this configuration was previously stored
in the `infrastructure-ui-source`, the plugin relies on a fallback to
reuse any existing value (see additional context
https://github.com/elastic/kibana/issues/161876#issuecomment-1673537400).
### Reviewers
There are no functional changes outside of Infra Monitoring UI and APM
UI, other codeowners are involved because this introduces a new saved
object
- APM - the change introduces a drop-in replacement of the
`infra.getMetricIndices` call. The ui code still relies on infra plugin
for a couple of components so we can't drop the dependency yet, those
we'll need to be moved to a tier 2 plugin (more details in
https://github.com/elastic/observability-dev/discussions/2787
(internal)) in a separate issue
### Testing
You'll need metrics data to verify data fetching works (I've used an
edge-oblt cluster)
1. Navigate to Infrastructure Settings and verify metric indices are
configured with the default value of `infrastructure-ui-source`
2. Update metric indices settings (if connected to oblt cluster add
`remote_cluster:..` indices)
3. Verify `metrics-data-source` saved object is persisted with correct
attributes
4. Verify Infrastructure Inventory is pulling data from the newly
configured indices
5. Go to APM services, verify service Infrastructure pulls data from
newly configured indices
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
## Summary
This moves alerting in Serverless Search to the Stack Management
alerting page, and removes
To remove these rule types, I had to disable the observability,
securitySolution, uptime, monitoring and infra plugins and make sure
that their server plugins (not just the frontend plugins) respected the
`enabled: false` flag.
Fixes#161117
## Summary
If `xpack.observability.unsafe.alertDetails.logs.enabled` is enabled, we
will use the new alert details page URL in `context.alertDetailsUrl`
otherwise, we send the user to the alerts page filtered for that alert.
(Partially brings back [the logic for alert details
URL](https://github.com/elastic/kibana/pull/157987/files#diff-a71ca536380c1fde8805744b23566ce795707f92b94a03af73347cac46ccac63L1027)
and
[getAlertDetailsConfig](https://github.com/elastic/kibana/pull/157987/files#diff-a71ca536380c1fde8805744b23566ce795707f92b94a03af73347cac46ccac63L1027))
## 🧪 How to test
1. Set `xpack.observability.unsafe.alertDetails.logs.enabled` as false
in Kibana yml config or remove the config
2. Create a log threshold rule with an action for both active state and
recovered state
3. When the alert is triggered, check the default message, it should
include the alertDetailsURL, by clicking on that, you should land on the
alerts page filtered for that alert
4. Make the alert recovered and check and similar URL should be
generated
New alert details page:
1. Set `xpack.observability.unsafe.alertDetails.logs.enabled` as true in
Kibana yml config
2. Repeat the steps 2,3,4 as mentioned before
3. This time, you should land on the new alert details page
## 📓 Summary
Closes#159128
Due to a dependencies issue when disabling a plugin in serverless mode,
the LogStream feature and related logic were disabled for every
consumer.
We decided to split this shared component and endpoint into their own
plugin of shared logs utilities, reducing to the minimum the required
dependency that could disable the plugin.
What we moved can be summarized with:
- `infrastructure-monitoring-log-view` saved object definition and
registration
- LogViews server/client services (exposed with start contract) +
related endpoints
- LogEntries server service + related endpoints
- LogEntriesDomain logic (exposed with start contract)
- `<LogStream />` component
- `<ScrollableLogTextStreamView />` component and related logic
- LogView state machine
- Containers/Hooks to consume the moved APIs.
- Common types/utils definition, now exported and consumed as a
dependency from the `infra` plugin.
## 🤓 Review hints
Most of the changes are just renaming and moving stuff into the new
plugin, but for some operations was required to implement new logic,
which may deserve a more critical review:
- server/public `plugin.ts` files for the `infra` and `logs_shared`
plugins. The new plugin now registers the fallback actions to retrieve a
source configuration if there's no stored log view. It also set the
configuration for the message field and registers the log view saved
object.
- the `logEntriesDomain` has also been moved inside the new plugin, but
is also used by the logs-analysis endpoints, so it is exposed by the
logs_shared plugin and consumed by `infra`.
## 👣 Following steps
We currently are still using the `observability` plugin for consuming
the CoPilot feature on our LogsStream flyout.
The plugin dependency is marked as optional, so disabling the
`observability` plugin in a serverless environment won't disable also
the exposed features in this new plugin, but it'll affect only the
CoPilot feature, which won't be loaded.
In future, would be nice to extract the CoPilot feature into its own
package/plugin, so that also serverless projects can consume it without
depending on `observability.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#157284, closes#158437
## Summary
This PR updates the default action and recovery message for
observability rule types. Only uptime is excluded in this PR, I will add
that after synching with the synthetics team.
[Here](https://docs.google.com/spreadsheets/d/15cJanv0xi4EKo1QZVXsi_NcFcPa_VQze3nQc4P8GZrQ/edit?pli=1#gid=0)
you can find the list of default messages and the new proposals.
## 🧪 How to test
- Ensure that `server.publicBaseUrl` is configured in kibana.dev.yml
- Create an observability rule with an action such as Email to use the
default messages (both for alert and recover states)
- After an alert is triggered, check the generated action message, it
should
- match the message mentioned in the list
- contain an alert details link pointing to the Alerts page filtered for
that specific alert
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes#157042
After the implementation of
https://github.com/elastic/kibana/pull/156837, we are now able to limit
the `logs.app_target` configuration to be accepted only in a serverless
environment, otherwise, it'll not be accepted.
Since we still need to use a default fallback value for the logs UI app,
the fallback will be applied internally when looking for this config, to
keep the original behaviour unchanged.
## 🧪 Testing
### Serverless environment
- Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
serverless-oblt`
- Verify that when navigating to Logs pages through the sidebar links or
directly accessing the url `/app/logs` it redirects to discover.
### Normal environment
- Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
start`
- Verify that when navigating to Logs pages through the sidebar links or
directly accessing the url `/app/logs` the log stream is rendered
correctly.
### Limited to serverless env
To verify that the configuration is only accepted under a serverless
context, set into your kibana.yml or `kibana.dev.yml` the configuration
```yml
xpack.infra.logs.app_target: discover
```
and verify that it triggers a validation error when running Kibana.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes#156534
## Summary
This PR adds the alertDetailsUrl to the infra rules. The value of this
variable is a link to the `observability > alerts` page filtered for
this instance of alert.
Here is an example of this action variable:
|alertDetailsUrl as action variable|Result of action|
|---|---|
||
**Note**
- I will change this field to `kibana.alert.url` in another
[ticket](https://github.com/elastic/kibana/issues/158359)
## 🧪 How to test
- Ensure that `server.publicBaseUrl` is configured in kibana.dev.yml
- Create a metric threshold/inventory/logs rule and use the
`context.alertDetailsUrl` in action for this rule
- After an alert is triggered, open the link provided by alertDetailsUrl
and make sure that the alert is filtered correctly
- Check the time range, it should be set for 5 mins before the alert
start time
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/104855
This PR creates 2 registered locators:
1. Logs Locator
2. Node Logs Locator
With these 2 locators, we now have a typed navigation to the logs UI
which also redirects to Discover in serverless mode.
## Testing
### Normal behaviour
When Kibana is used as always then on any navigation to the logs UI, the
user will be redirected to the stream UI.
All links to `link-to` routes should still behave as before.
- Launch the Kibana dev environment with `yarn start`
- Navigate to Hosts UI
- Click the logs tab
- Add a filter text in the search bar
- Click on the Open in Logs link
- Verify that navigation to the Stream view and the state is maintained
https://user-images.githubusercontent.com/11225826/234514430-ddc1ffaa-0cb2-4f2a-84e9-6c6230937d9f.mov
### Serverless behaviour
When Kibana is used in serverless mode, we want to redirect any user
landing to Logs UI to the Discover page
- Launch the Kibana dev environment with `yarn serverless-oblt`
- Navigate to Hosts UI
- Click the logs tab
- Add a filter text in the search bar
- Click on the Open in Logs link
- Verify to be redirected to Discover and that the state is maintained
https://user-images.githubusercontent.com/11225826/234514454-dfb2774e-d6f1-4f4c-ba10-77815dc1ae9d.mov
### Next Steps
A separate PR will be created to fulfill the below AC
- All usages of link-to routes in other apps are replaced with usage of
the appropriate locator.
## 📓 Summary
Part of #152617Closes#155111
This PR implements the CRUD endpoints for the metrics explorer views.
Following the approach used for the InventoryView service, it exposes a
client that abstracts all the logic concerned to the
`metrics-explorer-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/metrics_explorer_views
// Create one
POST kbn:/api/infra/metrics_explorer_views
{
"attributes": {
"name": "My view"
}
}
// Get one
GET kbn:/api/infra/metrics_explorer_views/<switch-with-id>
// Update one
PUT kbn:/api/infra/metrics_explorer_views/<switch-with-id>
{
"attributes": {
"name": "My view 2"
}
}
// Delete one
DELETE kbn:/api/infra/metrics_explorer_views/<switch-with-id>
```
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
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>
## 📓 Summary
Closes#153890
The implementation creates a new LogsApp service where we should keep
any logic concerned with what `target_app` parameter is configured and
the actions related to a specific configuration. I thought it could be a
good approach to avoid drilling down the global config till we need it
and keep it cleaner by injecting only the service with predefined
actions.
In this first case, we create a redirect to discover using its locator,
and the exposed method can be used anywhere across the app for
triggering the redirect.
## 🧪 Testing
### Normal behaviour
When Kibana is used as always, we want to keep the current behaviour and
the user will stay on the Logs UI pages.
- Launch the Kibana dev environment with `yarn start`
- Navigate to Logs UI
- Verify the navigation works normally and that no redirect to Discover
occurs
### Serverless behaviour
When Kibana is used in serverless mode, we want to redirect any user
landing to Logs UI to the Discover page, configuring the same data view
or creating an ad-hoc one starting from the index pattern
- Launch the Kibana dev environment with `yarn serverless-oblt`
- Navigate to Logs UI
- Verify to be redirected to Discover and a temporary data view is
created from the current index pattern
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/151697
## Summary
In a previous [PR](https://github.com/elastic/kibana/pull/145581) we
started installing a context-specific component templates, index
templates and concrete write indices for framework alerts as data when
the `xpack.alerting.enableFrameworkAlerts` config flag is set to true.
In that PR we used a different naming pattern than what is used by the
rule registry for those resources. In this PR, we are aligning the
naming of these resources with the rule registry and installing these
resources on alerting plugin setup when `enableFrameworkAlerts: true`.
If the flag is set to false, the rule registry will continue to handle
this resource installation.
In this PR we are doing the following:
* Registering all rules currently registered with the rule registry with
the alerting framework. This registration allows the alerting framework
to build context specific component templates. Because this PR only
addresses resource installation, rules will continue to be registered
with the rule registry.
* When `enableFrameworkAlerts: true`:
* The framework installs the context specific component template with
the following naming convention: `.alerts-{context}.alerts-mappings`.
This matches what the rule registry currently installs so the transition
should be seamless
* The framework installs the context specific index template for the
`default` space with the following name:
`.alerts-{context}.alerts-default-index-template`. Space awareness will
be addressed in a followup PR. This matches the current rule registry
naming.This index template will reference
(1) ECS component template (if `useEcs: true`),
(2) context-specific component template,
(3) legacy alert component template and
(4) framework component template
where the legacy alert component template + framework component template
= technical component template (from the rule registry).
* The framework creates or updates the concrete write index for the
`default` space with the naming convention:
`.internal.alerts-{context}.alerts-default-000001`. Space awareness will
be addressed in a followup PR. This matches the current rule registry
naming.
* The installation of the index template & write index differs from the
rule registry in that it occurs on alerting plugin start vs the first
rule run.
* We modified the rule registry resource installer to skip installation
of these resources when `enableFrameworkAlerts: true`. In addition, it
will wait for the alerting resource installation promise so if a rule
runs before its resources are fully initialized, it will wait for
initialization to complete before writing.
## To Verify
The following rule registry contexts are affected:
`observability.apm`
`observability.logs`
`observability.metrics`
`observability.slo`
`observability.uptime`
`security`
For each context, we should verify the following:
`Note that if your rule context references the ECS mappings, there may
be differences in those mappings between main and this branch depending
on whether you're running main with enableFrameworkAlerts true or false.
These differences are explained in the summary of this prior PR:
https://github.com/elastic/kibana/pull/150384 but essentially we're
aligning with the latest ECS fields. In the instructions, I suggest
running main with enableFrameworkAlerts: true to minimize the
differences caused by ECS changes`
**While running `main` with `enableFrameworkAlerts: true`:**
1. Get the context specific component template `GET
_component_template/.alerts-{context}.alerts-mappings`
2. Create rule for this context that creates an alert and then
3. Get the index template `GET
_index_template/.alerts-{context}.alerts-default-index-template`
4. Get the index mapping for the concrete index: `GET
.internal.alerts-{context}.alerts-default-000001/_mapping`
**While running this branch with `xpack.alerting.enableFrameworkAlerts:
true` (with a fresh ES instance):**
5. Get the context specific component template `GET
_component_template/.alerts-{context}.alerts-mappings`
6. Get the index template `GET
_index_template/.alerts-{context}.alerts-default-index-template`
7. Get the index mapping for the concrete index: `GET
.internal.alerts-{context}.alerts-default-000001/_mapping`
Note that you should not have to create a rule that generates alerts
before seeing these resources installed.
**Compare the component templates**
Compare 1 and 5. The difference should be:
* component template from this branch should have `_meta.managed: true`.
This is a flag indicating to the user that these templates are system
managed and should not be manually modified.
**Compare the index templates**
Compare 3 and 6. The differences should be:
* index template from this branch should have `managed: true` in the
`_meta` fields
* index template from this branch should not have a `priority` field.
This will be addressed in a followup PR
* index template from this branch should be composed of
`.alerts-legacy-alert-mappings` and `.alerts-framework-mappings` instead
of `.alerts-technical-mappings` but under the hood, these mappings are
equivalent.
**Compare the index mappings**
Compare 4 and 7. The difference should be:
* index mappings from this branch should have `_meta.managed: true`.
### Verify that installed resources templates work as expected
1. Run this branch on a fresh ES install with
`xpack.alerting.enableFrameworkAlerts: true`.
2. Create a rule in your context that generates alerts.
3. Verify that there are no errors during rule execution.
4. Verify that the alerts show up in your alerts table as expected.
5. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rules in a
non-default space continue to create resources on first rule run and run
as expected.
6. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rule preview
continue to work as expected
### Verify that installed resources templates work with existing rule
registry resources.
1. Run `main` or a previous version and create a rule in your context
that generates alerts.
2. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: false` and verify Kibana starts
with no rule registry errors and the rule continues to run as expected.
3. Using the same ES data, switch to this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify Kibana starts
with no alerting or rule registry errors and the rule continues to run
as expected.
4. Verify the alerts show up on the alerts table as expected.
5. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rules in a
non-default space continue to create resources on first rule run and run
as expected.
6. (For detection rules only): Run this branch with
`xpack.alerting.enableFrameworkAlerts: true` and verify rule preview
continue to work as expected
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes#149973
# Summary
This PR makes `spaces` an optional plugin. In Logs UI we use only the
space id and there we want to fallback to the default space id when the
space plugin is disabled. The difference to the changes in the other PRs
is that we will consider the default space as "active" space if the
space plugin is disabled: so in this case we will return the default
space id as this is the only property we need from the `getActiveSpace`
response.
# Testing
1. In the `kibana.dev.yaml` add `xpack.spaces.enabled: false`
2. Before we have this
[PR](https://github.com/elastic/kibana/pull/151147) merged you should do
[this
change](https://github.com/elastic/kibana/pull/151147/files#diff-1b17eae66f358505fae8d86df37e155a25e8db996fce93ee6016582fb341092e)
on the branch while testing
3. Inside Logs the `Anomalies` and `Categories` pages should load the
default space
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* Exposes required functions via the common folder
* Revert "Exposes required functions via the common folder"
This reverts commit db34cf9a6c.
* Expose only the getAlertLink as a common code
* Add viewInApp URL to Logs rule type
* Add kibanaBaseUrl to the infra plugin to build the full link
* Clean up code and extract kibana path name
* Fix URL
* Fix tests
* Fix lint
* Fix lint
* fix i18n
* typo
* Optimization - code review
* Uptdate tests
* Code review
* Remove unsed functions
* Fix checks
* Update getLogsAppAlertUrl
* Remove join
* Optim - code review
* Comment tests related to alertUpdater
* Comments imports
* Add issue link
* Uncomment/update tests
* [Metrics UI] Use bucket selector to evaluate Inventory Threshold Rule with Elasticsearch
* updating tests
* Remove unused dependencies
* Adding fallback for empty triggers
* Lowering the composite size to a safe value
* Reverting composite size change for Metric Threshold
* Adding some checks to ensure the bucket_script is available
* fixing typo
* Fix reason bug for bits. The formatter assumes it's listed in bytes.
* Fixing bug where results might not exist in each result set
* Converting boolean[] to boolean
* removing unused deps
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [Metrics UI] Increase composite size for Metric Threshold Rule to 10K
* Adding performance optimizations
* Fixing metrics_alerting integration test
* fixing tests
* Fixing integration test and config mock
* Removing the setTimeout code to simplify to a for/of
* Adding new setting to docs
* Adding metric_threshold identifier to the config setting
* [Logs UI][Metrics UI] Remove deprecated config fields from APIs
* Fix typecheck
* Fix typecheck
* Fix typecheck
* Fix jest
* Fix functional test
* Remove extraneous timeField args
* Typecheck fix
* Consolidate log file changes to ResolvedLogSourceConfiguration
* Fix merge
* Revert additional logs files
* Revert inventory models
* Revert log_analysis api
* Fix timefield reference in process list
* Restore logs page files, fix typecheck on mock
* Fix functional test
* Restore inventory models index
* Fix typecheck on getFilteredMetrics
* Look CI if you don't tell me all the type errors at once I can't fix them all
* Maybe this is the last typecheck fix who knows
* Restore reading timestamp field from data view
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [Logs UI][Metrics UI] Remove deprecated config fields from APIs
* Fix typecheck
* Fix typecheck
* Fix typecheck
* Fix jest
* Fix functional test
* Remove extraneous timeField args
* Typecheck fix
* Consolidate log file changes to ResolvedLogSourceConfiguration
* Fix merge
* Revert additional logs files
* Revert inventory models
* Revert log_analysis api
* Fix timefield reference in process list
* Restore logs page files, fix typecheck on mock
* Fix functional test
* Restore inventory models index
* Fix typecheck on getFilteredMetrics
* Look CI if you don't tell me all the type errors at once I can't fix them all
* Maybe this is the last typecheck fix who knows
* [Logs/Metrics UI] Add deprecated field configuration to Deprecations API
* Add correction steps
* Add unit test for source config deprecations
* Apply suggestions from code review
Co-authored-by: Chris Cowan <chris@chriscowan.us>
* Lint fix
Co-authored-by: Chris Cowan <chris@chriscowan.us>
* change composite.size of snapshot query to improve speed
* use value from kibana config to set compositeSize, clean up unused config properties
* fix test
* change config name
* fix reference
* Rename alerts plugin to alerting
* Deprecate old config values
* Few more renames
* Update plugin list
* Rename xpack.alerts -> xpack.alerting
* Fix some ESLint rules
* Fix typecheck
* Fix some test failures
* Some more renames
* Fix ESLint
* Fix some test failures
* Fix failing jest test
* Undo exclusive test
* Fix APM deps
* Fix docs
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* first pass
* migrate more plugins
* migrate yet more plugins
* more oss plugins
* fix test file
* change Plugin signature on the client-side too
* fix test types
* migrate OSS client-side plugins
* migrate OSS client-side test plugins
* migrate xpack client-side plugins
* revert fix attempt on fleet plugin
* fix presentation start signature
* fix yet another signature
* add warnings for server-side async plugins in dev mode
* remove unused import
* fix isPromise
* Add client-side deprecations
* update migration examples
* update generated doc
* fix xpack unit tests
* nit
* (will be reverted) explicitly await for license to be ready in the auth hook
* Revert "(will be reverted) explicitly await for license to be ready in the auth hook"
This reverts commit fdf73feb
* restore await on on promise contracts
* Revert "(will be reverted) explicitly await for license to be ready in the auth hook"
This reverts commit fdf73feb
* Revert "restore await on on promise contracts"
This reverts commit c5f2fe51
* add delay before starting tests in FTR
* update deprecation ts doc
* add explicit contract for monitoring setup
* migrate monitoring plugin to sync
* change plugin timeout to 10sec
* use delay instead of silence
This replaces the log item API with a single-log-entry search strategy. This is used to fetch the data for display in the details flyout. There should be no significant visual difference to the user.
* bump version to 4.1.1-rc
* fix code to run kbn bootstrap
* fix errors
* DO NOT MERGE. mute errors and ping teams to fix them
* Address EuiSelectableProps configuration in discover sidebar
* use explicit type for EuiSelectable
* update to ts v4.1.2
* fix ts error in EuiSelectable
* update docs
* update prettier with ts version support
* Revert "update prettier with ts version support"
This reverts commit 3de48db3ec.
* address another new problem
Co-authored-by: Chandler Prall <chandler.prall@gmail.com>
