Yes we've discussed this in the past.  I think it would be OK to use enumerated histograms, where each sample is a 32-bit quantity.  The USB ID can be used directly, since the pipeline should be able to deal with a few thousand entries.  One would create a separate histogram for each event type, such as "connect", "disconnect" etc.  Unfortunately I don't think we can measure things such as "how long has this device been connected" because that would be two-dimensional.  You could do a very coarse one with multiple histograms: ConnectedLessThanFiveMinutes, ..., ConnectedMoreThanTwentyFourHours.  But I woul d not recommend that.

If possible, it would be good to have a flag / parameter with the events that would allow them to be binned into the following categories:

The event happened:
1) With no users signed in.
2) While a user was signed in:
  a) screen unlocked
  b) screen locked

#4: unfortunately the 32-bit space for sample values is used up by the USB ID.  So one would need separate histograms for each event binning.  (For instance: USB.Device.Inserted.ScreenLocked.)

One could also hash the flag/parameter and the USB ID together, and live with the collisions.  But it gets messy: the histograms would be much harder to read.

Also, it would be good to know how this information would be used.

Has anybody tried to extract this information from the logs in the feedback reports?  Statistical results will be noisier and biased, but could still be interesting.

#5 I don't know that it would make sense to loose the ID over tracking that state.

I am interested in knowing if there are valid use cases we didn't think about when trying to block unrecognized devices at the lock screen.

#6 sounds interesting. After a quick plx search I didn't see any quick way to do it. A borg chron job to process the logs would probably do the trick and this pattern would extract out the information:

USB device (added|removed): path=\S vendor=([0-9]+) ".*", product=([0-9]+)

Though it might be nice to have the time of the event if you wanted to know how long a device was connected.

What would the benefit be of using metrics over gathering this information from feedback logs? Histograms feel somewhat ugly for collecting useful information here.

Would it make sense to use sparse samples to track the USB ID and count the number of minutes each is connected? Then if we want to include some other state information like mentioned in #4 we could create a histogram for each.

#6, re your first suggestion: the feedback logs may be interesting but will give an incomplete and biased view.  Most users never file feedback.  Those who do are probably underrepresented in the K-12 population.

re the second suggestion: it should be possible to maintain (probably in the metrics daemon) the list of connected USB IDs, and every few minutes send a sample for every connected device.  The resulting histogram will show the overall usage of each device, across all chromebooks.  It won't show how long a device has been connected.  To do that, you would need a separate histogram for each device ID.

Luigi: Is there value in collecting all USB IDs rather than just classes?

There are a lot of USB vid:pids, and just gathering all of them doesn't necessarily allow us to answer the question about how often USB hubs are used.

Instead, could we use coarser buckets that represent device classes?

#10 well yes of course, you could do that, but how many device classes are there?  20 or so?  20 times some number of histograms may be still too many for comfort.

But you could certainly send a sample every x minutes for every class that is connected at that instant, as I mentioned in #9.  Do you particularly care about the distribution of the length of connections?

If you see, for instance, that on a certain day a device of class X was connected for 10,000,000 minutes, and on that day 1,000,000 devices were on at some point, is that enough info?  If it is, you're done.  Of course you won't know how the 10,000,000 minutes distribute across the devices.

I uploaded a patch for review
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1250125/1

This only records a very basic set of metrics like what was mentioned in #3 ("connect" and "disconnect events).

I think it would be a good idea to adjust/expand this to include a more useful set of histograms, but figured this would be a good place to start.

FWIW, when designing metrics, I would recommend starting with identifying what questions you want to answer. Once the questions are identified, you can implement metrics to precisely answer those questions. There's not currently an easy way to collect "general" information and then decide what questions to ask at analysis time. (UKM could potentially provide some more structured metrics, but it is also more expensive than UMA.)

So, starting with a simple set of metrics and gradually expanding it as needed sounds like a good approach.