Currently, "usage" reports are sent, which are aggregated.
Add "event" variant, which won't be aggregated.
For compatibility, the "usage" events remain and nothing has
changed in terms of how they parse the command args, for example.
This will ensure continued functioning of anything that relies
on these metrics.
For the "event" variants, the CLI parsing is slightly different
in an attempt to improve data analysis capabilities while still
being respectful of user privacy (i.e. only known values of Docker
CLI commands/flags are ever recorded). Additionally, execution
duration information is now reported with these events.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Add a timer around command invocations to be reported with metrics.
This isn't actually sent anywhere currently, as it's meant for
evented data which is forthcoming. (We could report it with the
current events, but it's not clear that there's any value in doing
so.)
The signature for `Track()` has been changed to take an object with
all the fields. This is both for sanity to keep the method from
getting ridiculously long, and to make it easier to unify the usage
(heartbeat) and event code paths by ensuring we have all the data
for both.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Compose doesn't actually currently use this code, it's only used
here. Moving it inline so that we can drop it from Compose in the
future or make changes as needed without worrying about this as a
dependency.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Refactor the metrics client slightly to add the concept of a
"reporter" that actually sends the metrics.
The primary implementation is HTTP-based as before, but a key
difference now is that there's another variant that writes to
a file for simplified debugging. This is activated by setting
the `DOCKER_METRICS_DEBUG_LOG` environment variable to a file
path to write events to as JSON lines.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
