Licensed feature usage - alerts and actions

[kobelb]

In an effort to track the usage of of licensed features, a licensed feature usage API has been added to the licensing plugin. The immediate concern is integrating the Kibana specific features, which don't have an Elasticsearch counterpart, with the new licensed feature usage API. The current implementation of the licensed feature usage API requires that a separate method call is made from the server whenever a licensed feature is used. While we intend to improve this experience long-term, it's what we have for the immediate future.

The licensed feature usage API requires that features and their corresponding license level are registered during the setup lifecycle event, prior to the method invocation denoting their usage in the start lifecycle:

public async setup(core: CoreSetup, { licensing }: PluginSetupDependencies) {
    licensing.featureUsage.register('Foo feature', 'gold');
    ...
}

public async start(core: CoreSetup, { licensing }: PluginStartDependencies) {
  // elsewhere where license checking is done prior to a feature being consumed
    if (check.isValid) {
      licensing.featureUsage.notifyUsage('Foo feature');
      return;
    }    
  }
}

It's my understanding that actions are the only part of Alerting that enforce a minimum required license, and the alert types are extensible in nature. If that is correct, we should call FeatureUsageServiceSetup::register whenever an action type is registered, and then call FeatureUsageServiceSetup::notifyUsage whenever the license checking is performed prior to the action executing.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

I'm curious about the semantics of "usage":

call FeatureUsageServiceSetup::notifyUsage whenever the license checking is performed prior to the action executing

This seems like it should be straight-forward (so, probably won't be! :-) ). Wondering if there are there other cases where we'd want to notify about usage?

One example is that if a customer adds an action to an alert, but the alert never fires, and we only call notifyUsage() on the action execution, notifyUsage() would never get called. But we could call notifyUsage() when a customer adds actions to an alert during alert creation/update.

Depends on your definition of "usage".

Another possibility would be to call notifyUsage() for every action referenced from an alert when the alert executor fires, regardless of whether the actions are actually executed or not.

Perhaps these are multiple different "types" of usage, each with their own registration and notifier calls (different "feature names").

[pmuellr]

I suppose another question would be if somehow this data could be plumbed from other sources, rather than adding more code bits - the telemetry data we collect, and the alerting/actions event log immediately come to mind. Guessing the data we collect for telemetry won't be precise enough (but maybe!), and that the event log probably would be good enough.

The idea being that we would send pass this data in bulk on some kind of interval (hourly?).

[kobelb]

But we could call notifyUsage() when a customer adds actions to an alert during alert creation/update.

I think it'd make sense to call notifyUsage here.

In the future, we want the usage notification to be part of the license checking (with an optional flag), so the general guidance is anywhere that you'd normally do a license check, we should be notifying usage.

With regard to deriving this information from other sources, it's definitely possible but there are some drawbacks. Using telemetry to derive this information is possible, and it's what we're doing in the short-term. However, it requires rather complicated logic to derive this information. Given the future direction of telemetry, the structure of the telemetry data is also likely to change, so this creates a maintenance burden. This could also be derived from the event log, with similar stipulations about maintenance cost. In the future, we want this to be as easy as licensedFeatures.check('actions_service_now', { notifyUsage: true }), to reduce the maintenance cost and ensure that we're tracking the usage everywhere that we can. This is just a baby-step in that direction.

[kobelb]

I've updated the description to reflect the changes introduced by #67712

[mikecote]

@kobelb

It's my understanding that actions are the only part of Alerting that enforce a minimum required license, and the alert types are extensible in nature.

The actions plugin requires basic license at the feature level but some action types will require >= gold licenses to be used. By looking at the register API register(feature, license);. I'd have to put actions and basic as the values but I have a feeling this should capture the >= gold usage, right? If so, would the expectation be to do something like register a different feature per action type / license level? Ex: actions-basic, actions-gold, etc.

[kobelb]

@mikecote unfortunately, I think we should be registering a different feature for each of the different actions. The names and descriptions of the features will be displayed to end-users, and we want it to be obvious which feature they're using which is in which license-level.

[mikecote]

@kobelb 👌 thanks for the clarification, I'll go forward with that path.

[mikecote]

After starting to implement this and doing some analysis, it's not a problem to implement the following hooks (would be curious if I'm missing any?):

• Executing a connector (via HTTP API and via plugin API)
• Enqueuing an execution (via plugin API)
• Actions client (Create, Update)
• Alert create / update (notify per action)
• Preconfigured connectors?

Unrelated questions that could impact billing:

• How will this work with preconfigured connectors? Since all clusters in cloud would have one of these eventually, should we skip notify usage of these existing and only notify usage from alerts / execution?
• How will this work with the upcoming out of the box alerts that use a preconfigured connector? In cloud this would also eventually notify usage for every cluster. Should it notify usage for each alert action on Kibana startup or skip usage collection all together?

[mikecote]

As I'm continuing my work on this (here: #77679), two questions came up:

• Do we need to notify usage when deleting a connector? We don't do license checks there in case the user is on a downgraded / expired license and wants to delete now-invalid connectors.

But we could call notifyUsage() when a customer adds actions to an alert during alert creation/update.

• Do we want to notify there or notify at every interval the alert runs? Any or both are easily doable.

[kobelb]

Since all clusters in cloud would have one of these eventually, should we skip notify usage of these existing and only notify usage from alerts / execution?

This sounds reasonable to me. If a connector is specified in the kibana.yml but never consumed by anything, I think it's safe to consider it "unused".

How will this work with the upcoming out of the box alerts that use a preconfigured connector? In cloud this would also eventually notify usage for every cluster. Should it notify usage for each alert action on Kibana startup or skip usage collection all together?

For pre-configured connectors, if we only denote their usage when they're consumed, this seems to remedy this concern.

Do we need to notify usage when deleting a connector? We don't do license checks there in case the user is on a downgraded / expired license and wants to delete now-invalid connectors.

No, I don't think we should consider deleting something usage, it's "anti usage".

Do we want to notify there or notify at every interval the alert runs? Any or both are easily doable.

If the user configures an alert to use an action, I think it's safe to consider this "usage". Same with when an alert runs. So, both 😄