We need to collect some telemetry on CRLite - initially this will include revocation numbers (would a cert be blocked under the new mechanism) but we will likely want mnore detail.

We need to define what we need to collect.

The first two probes are landing in Bug 1488865.

This bug should cover the remaining queries. The first ones we've identified are:

• CRLITE_QUERY_TIME_MS :: timestamp
  How long it takes to query the bloom filter and get a result.

• CRLITE_QUERY_RESULT :: { hitRevoked, hitValid, miss }
  Whether results are revoked, valid, or there was no result

The next two queries are for running CRLite and OCSP simultaneously to compare performance:

• CRLITE_OCSP_AGREEMENT :: { agree, ocspRevokedCrliteValid, ocspValidCrliteRevoked, ocspErrorCrliteValid, ocspErrorCrliteRevoked, ocspRevokedCrliteMiss, ocspValidCrliteMiss, ocspErrorCrliteMiss }
  When a result returns from both the bloom filter and OCSP, do they agree or disagree, and if they disagree, how?

• CRLITE_OCSP_SPEEDUP_MS :: signed number of milliseconds CRLite is faster (or slower, if negative) (edited)
  When a result returns from both the bloom filter and OCSP, did the bloom filter respond faster, and if so how much faster?

Telemetry doesn't support signed measures, so you may wish to recast CRLITE_OCSP_SPEEDUP as being either proportional to each other (Accumulate(125) if CRLite was 125% faster than OCSP, for instance) or to adjust the "0" to be somewhat higher (Accumulate(FAKE_ZERO + (-250)) if CRLite was 250ms slower than OCSP. FAKE_ZERO could be 1000 or something).

I recommend playing with the histogram simulator to see what limitations histograms have. You can even supply your own custom data.

Note: Data-review request in https://bugzilla.mozilla.org/attachment.cgi?id=9062379
Data-review+ in https://bugzilla.mozilla.org/show_bug.cgi?id=1488865#c5