Uptime Integration with Infrastructure UI / Log UI

[dov0211]

Capturing the notes from the mail thread.
Integrations between observability solutions (Uptime + Infrastructure IU/ Log UI) will be valuable for our existing customers and appears to be a low hanging fruit
Heartbeat reports the monitor.ip (the monitored instance), in case we have a running Filebeat or Metricbeat on that same instance, we can provide a link to Infrastructure or log UI

[Andrew C]
We currently use host.* for the beat itself (as in host.geo)
ECS doesn't fit us that well, we could:

1. Switch all host fields to observer.*
2. Use a new target namespace for what we're monitoring.

The rationale is that host doesn't fit that well given the ECS definition of ' the host on which the event happened'.

[Nicolas R]
host.ip sounds like the right place for me and moving the host data to observer also the right move.

[andrewvc]

@ruflin the key question is can we do this in 7.0 post FF? My worry is that this has other implications, because it affects our use of the add_host_metadata processor as well. We could add a new one called add_observer_metadata I suppose...

[ruflin]

As these would be potential breaking changes I don't think we can still do these changes. add_host_metadata is not enabled by default on the code side but in the default config: https://github.com/elastic/beats/blob/master/heartbeat/heartbeat.yml#L134 We made breaking changes to this in the past also in minors. The argument here is that if someone keeps the config, he will keep also the same behaviour.

In the case of heartbeat I think both the host and cloud metadata do not make too much sense, so they should be removed here which will then allow some interesting options.

[legrego]

Something to keep in mind as this is getting developed: The introduction of Feature Controls will make it trivial for kibana admins to disable apps for groups of users and/or spaces. We should design this integration with the assumption that Infra/Logs will not always be available to the end user.

We'll be providing more guidance soon on how to perform these checks -- don't worry, we've made it easy!

[dov0211]

@legrego as this integration been developed by @justinkambic, can you provide us with some guidance?

[justinkambic]

++ this is something we'll want to integrate into the features I am actively adding to our UI.

[legrego]

@dov0211 @justinkambic absolutely!

For your immediate needs, you can figure out if Infra/Logs are available for the current user/space by doing something like this on the client-side:

import { uiCapabilities } from 'ui/capabilities';

const isInfraAppAvailable = uiCapabilities.infrastructure && uiCapabilities.infrastructure.show;
const isLogsAppAvailable = uiCapabilities.logs && uiCapabilities.logs.show;

If you're in a React app, we also have UICapabilities available via context, so you don't have to use the static import if you don't want to. See ui_capabilities_provider and inject_ui_capabilities. The Infra/Logs apps are using these react constructs, so you can check their plugin out for an example if you want to take this route.

The two "show" capabilities are registered in the Infra plugin via its call to xpackMainPlugin.registerFeature(). Uptime has a call to this function as well, which is what allows it to appear in Spaces Management and Role Management as a feature we can enable/disable.

I'm happy to go into more detail in a zoom if that's helpful, but this should get you started in the meantime. Let me know if there's anything else I can do to help!

[dov0211]

thank you @legrego , I guess this also implies to APM (in addition to logs and Infra)

[legrego]

@dov0211 yes, for APM, you can check uiCapabilities.apm.show

[andrewvc]

Was completed and shipped in 7.2