-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Licensed feature usage - alerts and actions #64849
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
I'm curious about the semantics of "usage":
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 Depends on your definition of "usage". Another possibility would be to call Perhaps these are multiple different "types" of usage, each with their own registration and notifier calls (different "feature names"). |
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?). |
I think it'd make sense to call 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 |
I've updated the description to reflect the changes introduced by #67712 |
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 |
@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. |
@kobelb 👌 thanks for the clarification, I'll go forward with that path. |
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?):
Unrelated questions that could impact billing:
|
As I'm continuing my work on this (here: #77679), two questions came up:
|
This sounds reasonable to me. If a connector is specified in the
For pre-configured connectors, if we only denote their usage when they're consumed, this seems to remedy this concern.
No, I don't think we should consider deleting something usage, it's "anti usage".
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 😄 |
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 thestart
lifecycle: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 callFeatureUsageServiceSetup::notifyUsage
whenever the license checking is performed prior to the action executing.The text was updated successfully, but these errors were encountered: