# Backport
This will backport the following commits from `main` to `8.12`:
- [[Profiling,Infra,APM] Disable Profiling integration by default
(#175201)](https://github.com/elastic/kibana/pull/175201)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Mykola
Harmash","email":"mykola.harmash@gmail.com"},"sourceCommit":{"committedDate":"2024-01-24T11:44:26Z","message":"[Profiling,Infra,APM]
Disable Profiling integration by default (#175201)\n\nCloses
https://github.com/elastic/kibana/issues/175016\r\n\r\n##
Summary\r\n\r\nThis PR disables the Profiling integration in Infra and
APM by default\r\non the plugin configuration level because this
integration require users\r\nto first configure the main `profiling`
plugin. On-prem users will have\r\nto manually enable both integrations
once they enabled the Universal\r\nProfiling for their hosts. Cloud
users will have Infra and APM\r\nintegrations enabled by default because
on Cloud instances Universal\r\nProfiling is already configured. A PR
for the default Cloud settings\r\nwill follow after this one is
merged.\r\n\r\nChanges I've made:\r\n* Disabled the Infra integration be
default\r\n* Introduced a new APM feature flag for the Profiling
integration\r\n* Made sure all the places in APM that rely on Profiling
integration\r\nrespect the new feature flag\r\n* Fixed a bug in APM when
Universal Profiling was shown even though the\r\nintegration was
disabled in UI
settings\r\n\r\n\r\n65dfbb5b-1850-4d18-a92a-6ad59e0436a3\r\n\r\n##
How To Test\r\n\r\n1. Checkout locally\r\n2. Make sure you don't have
`xpack.infra.featureFlags.profilingEnabled`\r\nalready enabled in
`kibana.yml`\r\n3. Open kibana and make sure you don't see \"Universal
Profiling\" tab in\r\nHost and Service details\r\n4. Enabled both flags
in `kibana.yml`:\r\n`xpack.infra.featureFlags.profilingEnabled`
and\r\n`xpack.apm.featureFlags.profilingIntegrationAvailable:
true`\r\n5. Check that now you see \"Universal Profiling\" tab in the
details\r\nscreens in both Infra and APM\r\n6. Go to Infra settings view
and disable the Profiling integration, make\r\nsure the tab
disappears\r\n7. 6. Go to APM settings view and disable the Profiling
integration,\r\nmake sure the tab
disappears\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"abd3515dda40d48bd0c59f7d2861ffa86db133c1","branchLabelMapping":{"^v8.13.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport
missing","Team:obs-ux-infra_services","v8.12.1","v8.13.0"],"number":175201,"url":"https://github.com/elastic/kibana/pull/175201","mergeCommit":{"message":"[Profiling,Infra,APM]
Disable Profiling integration by default (#175201)\n\nCloses
https://github.com/elastic/kibana/issues/175016\r\n\r\n##
Summary\r\n\r\nThis PR disables the Profiling integration in Infra and
APM by default\r\non the plugin configuration level because this
integration require users\r\nto first configure the main `profiling`
plugin. On-prem users will have\r\nto manually enable both integrations
once they enabled the Universal\r\nProfiling for their hosts. Cloud
users will have Infra and APM\r\nintegrations enabled by default because
on Cloud instances Universal\r\nProfiling is already configured. A PR
for the default Cloud settings\r\nwill follow after this one is
merged.\r\n\r\nChanges I've made:\r\n* Disabled the Infra integration be
default\r\n* Introduced a new APM feature flag for the Profiling
integration\r\n* Made sure all the places in APM that rely on Profiling
integration\r\nrespect the new feature flag\r\n* Fixed a bug in APM when
Universal Profiling was shown even though the\r\nintegration was
disabled in UI
settings\r\n\r\n\r\n65dfbb5b-1850-4d18-a92a-6ad59e0436a3\r\n\r\n##
How To Test\r\n\r\n1. Checkout locally\r\n2. Make sure you don't have
`xpack.infra.featureFlags.profilingEnabled`\r\nalready enabled in
`kibana.yml`\r\n3. Open kibana and make sure you don't see \"Universal
Profiling\" tab in\r\nHost and Service details\r\n4. Enabled both flags
in `kibana.yml`:\r\n`xpack.infra.featureFlags.profilingEnabled`
and\r\n`xpack.apm.featureFlags.profilingIntegrationAvailable:
true`\r\n5. Check that now you see \"Universal Profiling\" tab in the
details\r\nscreens in both Infra and APM\r\n6. Go to Infra settings view
and disable the Profiling integration, make\r\nsure the tab
disappears\r\n7. 6. Go to APM settings view and disable the Profiling
integration,\r\nmake sure the tab
disappears\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"abd3515dda40d48bd0c59f7d2861ffa86db133c1"}},"sourceBranch":"main","suggestedTargetBranches":["8.12"],"targetPullRequestStates":[{"branch":"8.12","label":"v8.12.1","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.13.0","labelRegex":"^v8.13.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/175201","number":175201,"mergeCommit":{"message":"[Profiling,Infra,APM]
Disable Profiling integration by default (#175201)\n\nCloses
https://github.com/elastic/kibana/issues/175016\r\n\r\n##
Summary\r\n\r\nThis PR disables the Profiling integration in Infra and
APM by default\r\non the plugin configuration level because this
integration require users\r\nto first configure the main `profiling`
plugin. On-prem users will have\r\nto manually enable both integrations
once they enabled the Universal\r\nProfiling for their hosts. Cloud
users will have Infra and APM\r\nintegrations enabled by default because
on Cloud instances Universal\r\nProfiling is already configured. A PR
for the default Cloud settings\r\nwill follow after this one is
merged.\r\n\r\nChanges I've made:\r\n* Disabled the Infra integration be
default\r\n* Introduced a new APM feature flag for the Profiling
integration\r\n* Made sure all the places in APM that rely on Profiling
integration\r\nrespect the new feature flag\r\n* Fixed a bug in APM when
Universal Profiling was shown even though the\r\nintegration was
disabled in UI
settings\r\n\r\n\r\n65dfbb5b-1850-4d18-a92a-6ad59e0436a3\r\n\r\n##
How To Test\r\n\r\n1. Checkout locally\r\n2. Make sure you don't have
`xpack.infra.featureFlags.profilingEnabled`\r\nalready enabled in
`kibana.yml`\r\n3. Open kibana and make sure you don't see \"Universal
Profiling\" tab in\r\nHost and Service details\r\n4. Enabled both flags
in `kibana.yml`:\r\n`xpack.infra.featureFlags.profilingEnabled`
and\r\n`xpack.apm.featureFlags.profilingIntegrationAvailable:
true`\r\n5. Check that now you see \"Universal Profiling\" tab in the
details\r\nscreens in both Infra and APM\r\n6. Go to Infra settings view
and disable the Profiling integration, make\r\nsure the tab
disappears\r\n7. 6. Go to APM settings view and disable the Profiling
integration,\r\nmake sure the tab
disappears\r\n\r\n---------\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"abd3515dda40d48bd0c59f7d2861ffa86db133c1"}}]}]
BACKPORT-->
# Backport
This will backport the following commits from `main` to `8.12`:
- [Deprecate feature flag for Log threshold alert details page
(#172554)](https://github.com/elastic/kibana/pull/172554)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Bena
Kansara","email":"69037875+benakansara@users.noreply.github.com"},"sourceCommit":{"committedDate":"2023-12-07T07:35:01Z","message":"Deprecate
feature flag for Log threshold alert details page (#172554)\n\nResolves
https://github.com/elastic/kibana/issues/172379\r\n\r\n- Deprecates
following feature flag used for enabling/disabling Log\r\nthreshold
alert details
page:\r\n```\r\nxpack.observability.unsafe.alertDetails.logs.enabled\r\n```\r\n-
Removes usage of this flag from code.\r\n- Adding this flag in
`kibana.yml` will generate following warning:\r\n```\r\n[WARN
][config.deprecation] You no longer need to configure
\"xpack.observability.unsafe.alertDetails.logs.enabled\".\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by:
Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"6628232433c0144f7564b22d8e6d2941425431ae","branchLabelMapping":{"^v8.13.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v8.12.0","Team:obs-ux-management","v8.13.0"],"number":172554,"url":"https://github.com/elastic/kibana/pull/172554","mergeCommit":{"message":"Deprecate
feature flag for Log threshold alert details page (#172554)\n\nResolves
https://github.com/elastic/kibana/issues/172379\r\n\r\n- Deprecates
following feature flag used for enabling/disabling Log\r\nthreshold
alert details
page:\r\n```\r\nxpack.observability.unsafe.alertDetails.logs.enabled\r\n```\r\n-
Removes usage of this flag from code.\r\n- Adding this flag in
`kibana.yml` will generate following warning:\r\n```\r\n[WARN
][config.deprecation] You no longer need to configure
\"xpack.observability.unsafe.alertDetails.logs.enabled\".\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by:
Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"6628232433c0144f7564b22d8e6d2941425431ae"}},"sourceBranch":"main","suggestedTargetBranches":["8.12"],"targetPullRequestStates":[{"branch":"8.12","label":"v8.12.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.13.0","labelRegex":"^v8.13.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/172554","number":172554,"mergeCommit":{"message":"Deprecate
feature flag for Log threshold alert details page (#172554)\n\nResolves
https://github.com/elastic/kibana/issues/172379\r\n\r\n- Deprecates
following feature flag used for enabling/disabling Log\r\nthreshold
alert details
page:\r\n```\r\nxpack.observability.unsafe.alertDetails.logs.enabled\r\n```\r\n-
Removes usage of this flag from code.\r\n- Adding this flag in
`kibana.yml` will generate following warning:\r\n```\r\n[WARN
][config.deprecation] You no longer need to configure
\"xpack.observability.unsafe.alertDetails.logs.enabled\".\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by:
Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"6628232433c0144f7564b22d8e6d2941425431ae"}}]}]
BACKPORT-->
Co-authored-by: Bena Kansara <69037875+benakansara@users.noreply.github.com>
The empty state will show up when `has_setup` from the Profiling Status
API returns `false`.
<img width="1276" alt="Screenshot 2023-11-30 at 15 06 30"
src="97a313be-db4f-4a5a-af36-df574f9793d5">
<img width="1036" alt="Screenshot 2023-11-30 at 14 47 48"
src="2622cad6-6763-4abc-9469-fa292137efda">
- Removes old flamegraph code replacing it with the ES Flamegraph API
- Creates new user settings
- Adds a feature flag to use the kibana CO2/Cost calculations instead of
the new version
- Reads CO2 and Cost from /Stacktraces and /Flamegraph APIs
Where do we show the CO2 and Cost values?
- Flamegraph toolip
- Flamegraph Frame information flyout
- Diff Flamegraph Summary
- Functions table
- Function information flyout
- Diff Functions Summary
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/171962
## Summary
This integrated Profiling Top Functions embeddable into the Infra's
Profiling tab in asset details.
## How to Test
* Connect local kibana to oblt cluster that has Profiling configured
(e.g. edge)
* Add this to your dev `kibana.yml`
```
xpack.profiling.enabled: true
xpack.infra.profilingEnabled: true
# Direct ES URL on the oblt cluster that you're using, in case of edge it's https://edge-oblt.es.us-west2.gcp.elastic-cloud.com:443
xpack.profiling.elasticsearch.hosts: REMOTE_CLUSTER_ES_URL
# If needed create a new user on the remote oblt cluster
xpack.profiling.elasticsearch.username: REMOTE_CLUSTER_USER
xpack.profiling.elasticsearch.password: REMOTE_CLUSTER_PASWORD
```
* Open kibana, go to Hosts
* Open a flyout for one of the hosts and make sure you see the Profiling
tab with both Flamegraph and Top Functions
* Open Host details as a full page and also make sure you see the same
* Make sure Profiling data updates when you change dates in the date
picker
## Summary
Fixes https://github.com/elastic/kibana/issues/169524
Fix the painless script that evaluates the IS_NOT_BETWEEN for the Custom
Threshold, Metric, Infra rules.
<img width="1024" alt="Screenshot 2023-11-24 at 15 03 18"
src="38fa171e-9057-4f42-aa12-ce5138eece24">
---------
## Summary
This adds a new "Universal Profiling" tab to asset details with a
flamegrapth for a selected host. The tab is behind a feature flag and is
disabled by default. It will be enabled by default for clound/onprem
once we implement Profiling empty state, serverless is tbd.
* Added two new endpoints for fetching profiling status (not used by the
FE yet) and flamegraph data.
* Added a `profilingEnabled` feature flag
* Added a new tab in the UI and integrated the Flamegraph embeddable
## How to test
* Connect local kibana to oblt cluster that has Profiling configured
(e.g. edge)
* Add this to your dev `kibana.yml`
```
xpack.profiling.enabled: true
xpack.infra.profilingEnabled: true
# Direct ES URL on the oblt cluster that you're using, in case of edge it's https://edge-oblt.es.us-west2.gcp.elastic-cloud.com:443
xpack.profiling.elasticsearch.hosts: REMOTE_CLUSTER_ES_URL
# If needed create a new user on the remote oblt cluster
xpack.profiling.elasticsearch.username: REMOTE_CLUSTER_USER
xpack.profiling.elasticsearch.password: REMOTE_CLUSTER_PASWORD
```
* Open kibana, go to Hosts
* Open a flyout for one of the hosts and make sure you see the Profiling
tab with a flamegraph
* Open Host details as a full page and also make sure you see the new
tab
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#47477
### Summary
ML job IDs have a limit of 64 characters. For the log ML jobs we add the
string `kibana-logs-ui` plus the space and log view IDs as a prefix to
the job names (`log-entry-rate` and `log-entry-categories-count`) which
can quickly eat up the 64 character limit (even our own Stack Monitoring
log view hits the limit). This prevents users from being able to create
ML jobs and it's hard to rename a space or log view, and the limit is
not hinted at during space creation (because they are unrelated in some
sense).
In order to achieve a more stable length to the ID, this PR introduces a
new format for the prefix which creates a UUID v5 which uses the space
and log view ID as seed information (it then removes the dashes to still
be within the size limit for the categorization job).
Since there is no technical difference between the new and old format,
this PR makes an effort to continue to support the old format and allow
migration of old jobs as needed. The old jobs work and may contain
important data so the user should not feel forced to migrate.
The main addition is a new small API that checks if any ML jobs are
available and which format they use for the ID so that the app can
request data accordingly and the APIs have been modified to take the ID
format into account (except during creation which should always use the
new format).
The solution applied is not ideal. It simply passes the ID format along
with the space and log view ID to each point where the ID is re-created
(which is multiple). The ideal solution would be to store the job data
in the store and pass that around instead but that seemed like a
considerably larger effort. This PR does introduce some functional tests
around the ML job creation process, so such a future refactor should be
a bit safer than previously.
### How to test
* Start from `main`
* Start Elasticsearch
* Start Kibana
* Load the Sample web logs (Kibana home -> Try sample data -> Other
sample data sets)
* Visit the Anomalies page in the Logs UI
* Set up any of the two ML jobs or both, wait for some results to show
up
* Checkout the PR branch
* Visit the anomalies page and verify that it still works (requests go
to resolve the ID format, should return 'legacy' which should then load
the data for the legacy job)
* Recreate the ML job and verify that the new job works and results
still show up (new requests should go out with the new format being
used, which may be a mixed mode if you have two jobs and only migrate
one of them)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes: https://github.com/elastic/kibana/issues/170508
## Summary
This PR makes a small adjustment in the inventory UI, optimizing the
usage of the Snapshot API.
Basically, 2 things were changed:
1 - AbortController, to interrupt ongoing any requests when new ones are
made
2 - Stop requesting time-series data in the waffle map view (table view
and history section still need it)
### `/snapshot` with time-series data
<img width="1400" alt="image"
src="562aaaf0-299d-4170-87e2-0e92b309f50c">
<img width="1400" alt="image"
src="29d68239-17e6-416f-be7b-c5928cf1545c">
<img width="1400" alt="image"
src="619473b8-983a-4ba7-a279-b44b5f2bbfbd">
### `/snapshot` without time-series data
<img width="1400" alt="image"
src="4f25caf9-08cd-4388-8a54-7916a3c70786">
<img width="1400" alt="image"
src="5719d012-57ce-42aa-a186-f65827b487e0">
<img width="1400" alt="image"
src="2df40aed-8a5f-4428-af85-34997789f62a">
### How to test
- Navigate to `Infrastructure`
- Inspect the `/snapshot` request to see if time-series data was
returned
- it should be returned when: opening the History accordion and loading
table view
- it shouldn't be returned when: hovering on a waffle map item, loading
waffle map view
- Ongoing requests must be aborted when new ones are made
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes#170531
## Summary
This PR adds the query delay mechanism to the inventory rule type.
This PR also changes the inventory rule type consumer from
`infrastructure` to `observability`:
<img
src="e93da707-0e4e-4e49-80eb-17c4aebbb188"
width=400 />
## 🧪 How to test
- On serverless
- Create an inventory rule and make sure,
- by default, the query execution has 15s delay
- consumer field in alert is `observability`
- Change the query settings delay in the Observability rule setting and
ensure the specified delay is applied to the related query
- On stateful
- This mechanism is not applied to stateful, so the query execution time
should not have any delay
- Make sure consumer for inventory rule is `infrastructure` as before
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Resolves https://github.com/elastic/kibana/issues/168240
### Changes
- Removes `fields.message` from the `infrastructure-ui-source` saved
object who's value was being populated by
`xpack.infra.sources.default.fields.message` from config. See
https://www.elastic.co/guide/en/kibana/master/logs-ui-settings-kb.html
- Removes `getInternalSourceConfiguration` and
`defineInternalSourceConfiguration` functions introduced in
https://github.com/elastic/kibana/pull/36066 as I cannot see them being
used anywhere. Stops exposing `defineInternalSourceConfiguration` as
part of server plugin interface.
- Removes `getStaticDefaultSourceConfiguration` from InfraSources class
as we aren't using `sources` from kibana config in source configuration
anymore.
- Removes deprecations warning of removal in 8.0 for other fields
belonging to config xpack.infra.sources.* introduced in
https://github.com/elastic/kibana/pull/115103
- Removes `getAllSourceConfigurations` used only in removed deprecations
file
f427278322 (diff-081721894fc437938eb652beae0a0640ddeee532ec5e48af1f3093c8074f1eecL195)
- Removed `getAllSavedSourceConfigurations` only used in
`getAllSourceConfigurations`
### How to test
- `infrastructure-ui-source` saved object no longer has `fields`
attributes
- in kibana.yml set `xpack.infra.sources.default.fields.message:
['testmessage', '@testmessage']`
- go to Infra -> Settings
- Change the name and save the form
- view the `infrastructure-ui-source` saved object and no `fields`
attribute should exist (unless it previously existed in an already
existing `infrastructure-ui-source` saved object
- changes do not affect`fields.message` is used in logs_shared plugin
- i'm not sure how to easily test this and relying on someone with more
Logs knowledge to help out, but from what I can see logs accesses the
config directly (`xpack.infra.sources.default.fields.message`) and never
uses the saved object field being removed.
## Summary
Closes https://github.com/elastic/kibana/issues/166834
Moves the following components out of infra plugin so we can remove the
apm->infra dependency
- `/infra/metrics_explorer` route
- (Host|Pod|Container)MetricsTable components
- InfraAppId
- InfraLocators
### Testing
We should focus the testing on the metrics_explorer route which is used
by 1. Tables in the Infrastructure section of apm and 2. Infrastructure
> Metrics explorer app. No functionality was added so these apps should
have the same existing behavior. Easiest way to get these views loaded
is by connecting kibana to an edge-oblt cluster, alternatively load
service and metrics with a data loader.
### Follow up
- (Host|Pod|Container)MetricsTable components are part of the
metricsDataAccess plugin contract but should be moved to stateless
package
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
Closes https://github.com/elastic/kibana/issues/169339
## Summary
* Hides the "Alerts and rule" dropdown in the Infra header behind a
feature flag in serverless
* Moves serverless infra tests to the `index.feature_flags.ts` to
prevent failures on MKI
## How to test
* Run in serverless
* Make sure the Alerts and rules dropdown is not there anymore
* Run in stateful
* Make sure dropdown works as before
Resolves https://github.com/elastic/kibana/issues/164220
## Summary
Removes the lifecycle executor wrapper around the metric threshold rule
type executor so that this rule type is using the framework alerts
client to write alerts as data documents.
### Response ops changes
- Passing in task `startedAt` date to the alerts client. Lifecycle
executor rules use this standardized timestamp for the `@timestamp`
field of the AaD doc, as well as for the start and end time of an alert
### Metric threshold rule changes
- Switch to using the alerts client in the executor to report alerts and
to get recovered alert information.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes#168829
## Summary
This PR fixes the issue when a Metric threshold or Custom threshold rule
is created with the groupBy field and then gets updated, and the groupBy
field is removed. In this scenario, if no alert is triggered, a no-data
alert is generated wrongly.
This issue is due to saving `groupBy` field as an empty string in the
rule's saved object.
<img width="326" alt="Screenshot 2023-10-16 at 15 28 41"
src="458e1a94-7234-4fa5-89bd-afb8a8b5f158">
### 🧪 How to test
- Create a Metric threshold or Custom threshold rule with `groupBy`
field that does not trigger any alert
- Update the rule and remove the groupBy field
- You shouldn't see a no-data alert in this case anymore
Closes https://github.com/elastic/kibana/issues/164683
## Summary
This PR disables the infrastructure, metrics and logs alerts rule in
Serverless:
- Deletes the code responsible for the "Metric Anomaly" rule as it was
[previously disabled](https://github.com/elastic/kibana/pull/93813) with
plans to re-enable it as the previous PR describes but that never
happened.
- Adds feature flags for all three types of alert rules
- Prevents rules registration in serverless based on the feature flags
- Adds logic for showing/hiding items in the "Alerts and rules" dropdown
- Disables custom threshold rule in the Infra UI by default in
serverless as the rule needs to first be enabled by default by
@elastic/actionable-observability team
([context](https://elastic.slack.com/archives/C023GDA0WMP/p1696853751040269))
**Dropdown**
**Host details**
### How to test
- Checkout locally Run in Serveless mode
- Enable, Infra plugin, custom threshold in Infra, and custom threshold
rule in general:
```
xpack.infra.enabled: true
xpack.infra.featureFlags.customThresholdAlertsEnabled: true
xpack.observability.unsafe.thresholdRule.enabled: true
```
- Go to `/app/metrics/hosts` and make sure there are no "Infrastructure"
and "Metrics" items in the "Alerts and rules" dropdown
- Click on "Manage rules" in the "Alerts and rules" dropdown, then
"Create rule" to open the rule selection flyout
- Make sure there are no rules for "Inventory", "Metrics" or "Logs"
threshold
- Run Kibana in traditional mode
- Make sure the "Alerts and rules" dropdown looks as usual and you can
create "Infrastructure" and "Metrics" alerts
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes [#166802](https://github.com/elastic/kibana/issues/166802)
## Summary
This PR adds API tests for the Infra APIs used in the serverless. The
tests cover the endpoints:
- /api/infra/metadata
- /api/metrics/infra
- /api/metrics/process_list
- /api/metrics/snapshot
The tests use a [separate
fixture](https://github.com/elastic/kibana/pull/167684/files#diff-58cd3d70e2df2426acb0d9e9a1fffa3c8e953cf34ae865660819b20f94707542)
to make them more flexible in the future and independent from the
current tests (also it has less data for a single host for better
performance).
## Testing
To run the tests use serverless env for **observability**:
- Server: `node scripts/functional_tests_server.js --config
test_serverless/functional/test_suites/observability/config.ts`
- Tests: `node scripts/functional_test_runner
--config=x-pack/test_serverless/api_integration/test_suites/observability/config.ts
--info`
- `--info` is added to help read the results excluding the debug
messages
closes https://github.com/elastic/kibana/issues/166977
## Summary
This PR creates a feature flag to disable logs UI features in
serverless.
_Serverless_
**Frontend routes**
<img width="1466" alt="image"
src="a856055b-f78b-4d47-b27e-678e19bdfae4">
`/logs/stream`
<img width="1714" alt="image"
src="83d50be2-ed3a-4441-b31c-1afe6f8fd0b9">
`/logs/log-categories`
<img width="1714" alt="image"
src="85cd369d-55b2-46a2-a61a-135c5f18e299">
`/logs/anomalies`
<img width="1714" alt="image"
src="d68e6f91-fe29-483f-931d-d05f4303effa">
**Server routes**
These will return 404
```
POST kbn://api/infra/log_analysis/results/log_entry_anomalies_datasets
POST kbn://api/infra/log_analysis/results/log_entry_anomalies
POST kbn://api/infra/log_analysis/results/log_entry_categories
POST kbn://api/infra/log_analysis/results/latest_log_entry_category_datasets_stats
POST kbn://api/infra/log_analysis/results/log_entry_category_datasets
POST kbn://api/infra/log_analysis/results/log_entry_category_examples
POST kbn://api/infra/log_analysis/results/log_entry_examples
POST kbn://api/infra/log_analysis/results/log_entry_datasets
POST kbn://api/infra/log_analysis/results/log_entry_rate_indices
POST kbn://api/infra/log_alerts/chart_preview_data
```
_Stateful_
<img width="1716" alt="image"
src="4406434f-78e4-437f-b3b5-1b03dc23f3c0">
**Server routes**
These will return 400 - currently there is no way to pass `version` via
dev tools
```
POST kbn://api/infra/log_analysis/results/log_entry_anomalies_datasets
POST kbn://api/infra/log_analysis/results/log_entry_anomalies
POST kbn://api/infra/log_analysis/results/log_entry_categories
POST kbn://api/infra/log_analysis/results/latest_log_entry_category_datasets_stats
POST kbn://api/infra/log_analysis/results/log_entry_category_datasets
POST kbn://api/infra/log_analysis/results/log_entry_category_examples
POST kbn://api/infra/log_analysis/results/log_entry_examples
POST kbn://api/infra/log_analysis/results/log_entry_datasets
POST kbn://api/infra/log_analysis/results/log_entry_rate_indices
POST kbn://api/infra/log_alerts/chart_preview_data
```
### How to test
### How to test
- Start a local es instance: `yarn es serverless --kill --clean
--license trial --ssl`
- Enable `infra` in the `serverless.oblt.dev.yml` file:
- `xpack.infra.enabled: true`
- Start a local kibana instance: `yarn serverless-oblt --ssl`
- Verify the items listed above both on serverless and stateful
Closes https://github.com/elastic/kibana/issues/166612
## Summary
- Adds a `customThresholdAlertsEnabled` feature flag
- Based on the feature flag shows an additional menu item in the alerts
dropdown
- Adds flyout component for rendering the custom alerts flyout
**Serverless**
<video
src="4fc79427-1e0c-4692-8525-b3b35e8a04e9"
controls="controls"></video>
**Traditional**
## How to test
- Checkout locally and run in serverless mode (infra plugin on)
- Make sure you see the "Create custom threshold alert" menu item in the
"Alerts and rules" dropdown
- Click on the item and make sure you can create an alert
- Run Kibana in traditional mode and make sure the dropdown item is not
there
closes https://github.com/elastic/kibana/issues/163280
## Summary
Disables OSquery in serverless.
<img width="1670" alt="image"
src="0ece0503-a5f3-46a1-a99b-29285088526c">
<img width="1670" alt="image"
src="5d20aaa4-7bdc-47e5-b9c2-469ecf62ab1f">
<img width="1670" alt="image"
src="97874aee-be98-4f0a-984a-562abbd4187d">
Osquery is now only used in the Asset Details flyout/full-page view. The
header component in the Asset Details now checks the feature flag object
to show/hide the OSquery tab.
### How to test
- Start a local es instance: `yarn es serverless --kill --clean
--license trial --ssl`
- Enable `infra` in the `serverless.oblt.dev.yml` file:
- `xpack.infra.enabled: true`
- Start a local kibana instance: `yarn serverless-oblt --ssl` and see if
the side nav contains the Infrastructure item
- Navigate to `https://0.0.0.0:5601/ftw/app/metrics` and open the Asset
Details flyout from Inventory and Hosts View. Navigate to the details
view and check that Osquery tab isn't present.
- Confirm if OSquery tab is present in stateful.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/166301
Adds support for solution/category filtering to maintenance windows by
adding a new property: `category_ids`. Selecting one or more solutions
when creating/updating a maintenance window will cause the maintenance
window to only suppress rule types belonging to said solutions. In order
to achieve filtering by solution/category, we are adding a new field to
the rule types schema called `category`. This field should map to the
feature category that the rule type belongs to (`observability`,
`securitySolution` or `management`).
Our initial plan was to use feature IDs or rule type IDs to accomplish
this filtering, we decided against using rule type IDs because if a new
rule type gets added, we need to change the API to support this new rule
type. We decided against feature IDs because it's a very anti-serverless
way of accomplishing this feature, as we don't want to expose feature
IDs to APIs. We decided on app categories because it works well with
serverless and should be much easier to maintain if new rule types are
added in the future.
This means the `rule_types` API has to be changed to include this new
field, although it shouldn't be a breaking change since we're just
adding a new field. No migrations are needed since rule types are in
memory and maintenance windows are backwards compatible.
### Error state:
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
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>
Fixes#162299Fixes#162540
## Summary
This PR unskips the custom threshold rule executor unit test and removes
the warning implementation from the BE.
## 🧪 How to test
- Create a custom threshold rule, it should work as before. (Warning
implementation logic was already removed from FE; this PR only removes
the BE implementation.)
closes: https://github.com/elastic/kibana/issues/166428
## Summary
This PR removes code that is no longer needed after replacing the Node
Details View for Host with the Asset Details.
### TSVB
The TSVB files were apparently only used to display charts in the Node
Details view. Due to the Asset Details using Lens to power the charts,
corresponding `host` TSVB formulas and configs are no longer needed.
Therefore, `host*`, `hostK8s*`, and `hostDocker*` (the latter appears to
have never been used) have been removed. Additionally, `aws*` from
`required_metrics` was also removed because it was host-specific.
### FE Components
The main change is in the `useMetadata` hook. I have changed the hook
signature, making `requiredMetrics` optional. This parameter is used to
process additional filtering and is only used in asset types that the
old Node Details page supports. Not passing it is not expected to break
other places that depend on this hook.
### Server
Removing TSVB files has a direct impact on the
`api/metrics/node_details` endpoint. This endpoint is only used to
provide data to the Node Details page. It returns a 400 error if an
invalid metric is passed - which will be the case for hosts
**Example Request:**
```json
POST kbn:api/metrics/node_details
{
"metrics": [
"hostK8sCpuCap",
"hostSystemOverview"
],
"nodeId": "gke-release-oblt-release-oblt-pool-c4163099-bcaj",
"nodeType": "host",
"timerange": {
"from": 1695210522045,
"to": 1695214122045,
"interval": ">=1m"
},
"cloudId": "6106013995483209805",
"sourceId": "default"
}
```
**Response:**
```json
{
"statusCode": 400,
"error": "Bad Request",
"message": "Failed to validate: \n in metrics/0: \"hostK8sCpuCap\" does not match expected type \"podOverview\" | \"podCpuUsage\" | \"podMemoryUsage\" | \"podLogUsage\" | \"podNetworkTraffic\" | \"containerOverview\" | \"containerCpuKernel\" | \"containerCpuUsage\" | \"containerDiskIOOps\" | \"containerDiskIOBytes\" | \"containerMemory\" | \"containerNetworkTraffic\" | \"containerK8sOverview\" | \"containerK8sCpuUsage\" | \"containerK8sMemoryUsage\" | \"nginxHits\" | \"nginxRequestRate\" | \"nginxActiveConnections\" | \"nginxRequestsPerConnection\" | \"awsEC2CpuUtilization\" | \"awsEC2NetworkTraffic\" | \"awsEC2DiskIOBytes\" | \"awsS3TotalRequests\" | \"awsS3NumberOfObjects\" | \"awsS3BucketSize\" | \"awsS3DownloadBytes\" | \"awsS3UploadBytes\" | \"awsRDSCpuTotal\" | \"awsRDSConnections\" | \"awsRDSQueriesExecuted\" | \"awsRDSActiveTransactions\" | \"awsRDSLatency\" | \"awsSQSMessagesVisible\" | \"awsSQSMessagesDelayed\" | \"awsSQSMessagesSent\" | \"awsSQSMessagesEmpty\" | \"awsSQSOldestMessage\" | \"custom\"\n in metrics/1: \"hostSystemOverview\" does not match expected type \"podOverview\" | \"podCpuUsage\" | \"podMemoryUsage\" | \"podLogUsage\" | \"podNetworkTraffic\" | \"containerOverview\" | \"containerCpuKernel\" | \"containerCpuUsage\" | \"containerDiskIOOps\" | \"containerDiskIOBytes\" | \"containerMemory\" | \"containerNetworkTraffic\" | \"containerK8sOverview\" | \"containerK8sCpuUsage\" | \"containerK8sMemoryUsage\" | \"nginxHits\" | \"nginxRequestRate\" | \"nginxActiveConnections\" | \"nginxRequestsPerConnection\" | \"awsEC2CpuUtilization\" | \"awsEC2NetworkTraffic\" | \"awsEC2DiskIOBytes\" | \"awsS3TotalRequests\" | \"awsS3NumberOfObjects\" | \"awsS3BucketSize\" | \"awsS3DownloadBytes\" | \"awsS3UploadBytes\" | \"awsRDSCpuTotal\" | \"awsRDSConnections\" | \"awsRDSQueriesExecuted\" | \"awsRDSActiveTransactions\" | \"awsRDSLatency\" | \"awsSQSMessagesVisible\" | \"awsSQSMessagesDelayed\" | \"awsSQSMessagesSent\" | \"awsSQSMessagesEmpty\" | \"awsSQSOldestMessage\" | \"custom\""
}
```
### How to Test
- Start a local Kibana instance pointing to an oblt cluster.
- Navigate to `Infrastructure`.
- Try different asset types and navigate to the Node Details view.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is updating Discover's rule to be created under the
`stackAlerts` consumer and we created an [breaking change
issue](https://github.com/elastic/dev/issues/2344) to explain the
consequences of this update.
We also fix the rule's consumer for all rule types created under the
observability rule management to use their producer instead of `alerts`.
Also, we add the ability for the ES Query and new Generic Threshold
rules type to pick the consumer associated to the rule. The
`ensureAuthorized` and the `filter` functions have modified and
simplified to support this use case please check the newest unit test
added in
`x-pack/plugins/alerting/server/authorization/alerting_authorization.test.ts`.
There is now a dropdown in the rule form to prompt the user when
creating ES Query/Generic threshold rules to select the consumer based
on their authorized consumers (we can no longer use `alerts` for these).
If there is only 1 option, then the dropdown will not be shown and the
option will be chosen automatically.
Generic threshold rules will have the following possible consumers:
- infrastructure
- logs
ES query rules will have the following possible consumers:
- infrastructure
- logs
- stackAlerts (only from the stack management rule page)
## To Test:
### Single Consumer:
1. Create a user with only `logs` feature enabled (ensuring
`stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. Assert that the rule created has `logs` set in the `consumer` field
7. Repeat 5-6 for the generic threshold rule
8. Repeat 2-7 but on the Stack Management rules page
9. Repeat 1-8 for the `infrastructure` feature.
### Multiple Consumers:
1. Create a user with `logs`, `infrastructure` and `apm` features
enabled (ensuring `stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. A dropdown should prompt the user to select between 1 of the 3
consumers, select 1
7. Assert that the rule was created with the selected consumer
8. Repeat 5-7 for the generic threshold rule
9. Repeat 2-8 but on the Stack Management rules page
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes#166476 by fixing a bug where you can't repeat a variable
twice in the equation. This PR changes the code that converts the
variables from `A` to `params.A` by changing a `replace` to a
`replaceAll`.
The work around would be to duplicate the aggregation that needs to be
repeated so it has a unique variable name.
### Checklist
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: 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>
Closes https://github.com/elastic/kibana/issues/164594
## Summary
This PR adds tooltips to explain the time range used to collect process
data and metadata. The tooltips will be shown inside the overview
(metadata summary section) tab, metadata tab, and processes tab (both
flyout and full page views).
## Fixes
I saw that the icons showing different explanation/ docs links inside
the overveiew tab are not consistent ( sometimes we have
`questionInCircle` and sometimes `iInCircles`) - the designs are using
`iInCircles` so I changed it everywhere:
<img width="671" alt="icons"
src="edda271b-5030-4d83-9722-448fbae8cf8b">
## Testing
1. Go to host view and open the flyout for any host. The new explanation
and tooltips should be shown in:
- Overview tab
<img width="938" alt="overview"
src="ac4ae369-d825-4fba-8865-c9410de29c28">
- Metadata tab
<img width="945" alt="metadata"
src="4d174bf3-3411-40a5-a208-eb5df2266c61">
- Processed tab
<img width="937" alt="processes"
src="11d32c66-4a25-4fce-a95e-42698f2e1682">
2. Click Open as page and check the same on the asset details page
<img width="1653" alt="Screenshot 2023-08-28 at 11 28 47"
src="342d1565-bb51-4961-b8ac-8b8270c851ff">
<img width="1637" alt="Screenshot 2023-08-28 at 11 28 32"
src="63b66a12-d634-4ecc-83de-ad1e1b79334c">
<img width="1649" alt="Screenshot 2023-08-28 at 11 28 16"
src="59720bf3-88ad-44b1-8584-769b38d956ed">
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The rule `Threshold (Technical Preview)` was not anymore showing under
the rule form for a super user because of our latest
[PR](https://github.com/elastic/kibana/pull/163574) to build our filter
authorization from the feature ids that the user have access.
We brought it back by adding this new rule type id under the alerting
privileges of every o11y solutions.
FYI => We have a [branch
feature](https://github.com/elastic/kibana/tree/o11y-rbac-rule-feature-branch)
that will allow to create this rule for different roles and access
<img width="602" alt="image"
src="223e510a-0ee7-4d66-9517-d733c0cd9a0c">
Closes#163168
## Summary
This PR configures the "View rule in Kibana" URL to point to the
observability rule details for observability rule types.
Resolves: #160176
This PR intends to move the getting alert-as-data fetching logic from
ruleRegistry to alerting framework.
`getPersistentAlerts` method fetches the alerts-as-data as long as the
ruleType has `alerts` settings (fields, formatAlert etc.)
## To verify:
All the rules that use alert-as-data should be still working as they
are.
## Summary
Remove `SavedObjectReference` type from `@kbn/core-saved-objects-common`
in favor of `@kbn/core/server`
Closes https://github.com/elastic/kibana/issues/162725
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#159777
## 📝 Summary
In this PR, I changed the timestamp used in rule execution and the
preview chart of the new threshold rule.
I created a separate ticket
(https://github.com/elastic/kibana/issues/162560) to implement
`infra/metrics_explorer` in the observability plugin, and in the
meantime, I adjusted the API also to accept timeFieldName.
Also, I have a separate ticket for improving data view validation
(https://github.com/elastic/kibana/issues/162554)
## 🧪 How to test
### New threshold rule
- Create a data view of a timestamp other than `@timestamp`
- Create a rule with this data view and make sure the preview and
generated alerts are as expected
- Create a rule with grouping and filtering and check the preview and
generated alerts
### Metric threshold rule
- Create a metric threshold rule to make sure preview and rule execution
works as before
## Summary
This PR fixes#155534 by ensuring result for the group by is set before
adding it to the evaluation results. I also applied the fix to the new
Observability Threshold Rule since we are using it as a starting point
for the new combined rule.
## 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.
closes [#157520](https://github.com/elastic/kibana/issues/157520)
## Summary
This PR adds strict payload validation to `metrics_explorer_views`
endpoint. This PR depends on this to be merged
https://github.com/elastic/kibana/pull/160852
### How to test
- Call the endpoint below trying to use invalid values. see
[here](https://github.com/elastic/kibana/pull/160982/files#diff-4573683b3b62cdf5f6426ec345b7ad6c7d6e6328237b213ca7519f686d8fa951R125-R131).
```bash
[POST|PUT] kbn:/api/infra/metrics_explorer_views
{
"attributes": {
"name": "Ad-hoc",
"options": {
"aggregation": "avg",
"metrics": [
{
"aggregation": "avg",
"field": "system.cpu.total.norm.pct",
"color": "color0"
},
],
"source": "default",
"groupBy": [
"host.name"
]
},
"chartOptions": {
"type": "line",
"yAxisMode": "fromZero",
"stack": false
},
"currentTimerange": {
"from": "now-1h",
"to": "now",
"interval": ">=10s"
}
}
}
```
- Set up a local Kibana instance
- Navigate to `Infrastructure > Metrics Explorer`
- In the UI, use the Saved View feature and try different field
combinations
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
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 [#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#159520
<img width="573" alt="Screenshot 2023-06-12 at 3 12 27 PM"
src="ec16b8d7-25a5-435c-bf29-7392747b8c0f">
### Checklist
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Patryk Kopyciński <contact@patrykkopycinski.com>
## Summary
This PR is the first step towards making metrics across infra
consistent. For the Hosts view, these are the new metrics:
<img width="667" alt="image"
src="6bcbc9a2-b9d5-42fc-bee0-d74edffa9960">
_note: KPI's titles are now capitalized._
<img width="667" alt="image"
src="16c51b3f-ccfc-400f-ad86-cbca53dd2f6a">
### How to test
- Start a local Kibana instance
- Navigate to `Infastructure > Hosts`
### For reviewer
- Some translation keys had to be changed and others removed because the
metrics no longer exist or the copy has completely changed. No new
translations have been added.
- All tooltips are temporary, they will be addressed in another PR
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
