With the addition of the extension system #222 we should be measuring extension usage as part of our telemetry. If Elasticians or community members build extensions that gain a notable amount of usage, it helps us to determine whether there's a way to merge the extension as a built-in command, or improve the usability of other existing commands that do similar things.
This is slightly more complicated than our standard telemetry measurement technique of using an x-elastic-client-meta HTTP header, because we won't have control over the contents of requests that an extension sends to Elastic APIs.
A couple possible solutions:
- Record installs: ping Elasticsearch, Kibana or Cloud control plane (pick one of whichever is configured in the current context) with an
info request at extension install time, putting the extension name in the x-elastic-client-meta header.
- Record every extension invocation: use the same ping method, but run on every use of the extension
- Record one invocation per day per extension: same as above, but ping once a day max per extension, storing a timeout/lock value on the filesystem to keep track of the last ping
- New telemetry data set: capture and aggregate whatever extension use patterns we care about locally, in a cached JSON file, then at maximum once per day have a CLI invocation look for the file, publish it to Elastic's telemetry API directly, and delete
I prefer the first option, as it low volume and the least likely to be a privacy concern to users. The only downside is that it would not capture how often an extension is actually used.
With the addition of the extension system #222 we should be measuring extension usage as part of our telemetry. If Elasticians or community members build extensions that gain a notable amount of usage, it helps us to determine whether there's a way to merge the extension as a built-in command, or improve the usability of other existing commands that do similar things.
This is slightly more complicated than our standard telemetry measurement technique of using an
x-elastic-client-metaHTTP header, because we won't have control over the contents of requests that an extension sends to Elastic APIs.A couple possible solutions:
inforequest at extension install time, putting the extension name in thex-elastic-client-metaheader.I prefer the first option, as it low volume and the least likely to be a privacy concern to users. The only downside is that it would not capture how often an extension is actually used.