| ads.rs |
|
2840 |
0 % |
| ads_store |
|
|
- |
| ads_store.rs |
|
2699 |
- |
| bytesize.rs |
|
2848 |
0 % |
| client |
|
|
0 % |
| client.rs |
|
20899 |
16 % |
| clock.rs |
|
1235 |
0 % |
| ffi |
|
|
22 % |
| ffi.rs |
|
17717 |
23 % |
| http_cache |
|
|
18 % |
| http_cache.rs |
|
17412 |
14 % |
| lib.rs |
|
7297 |
8 % |
| mars |
|
|
1 % |
| mars.rs |
|
13351 |
7 % |
| request.rs |
|
7465 |
- |
| telemetry |
|
|
54 % |
| telemetry.rs |
Metric recording for the ads client.
Telemetry is a process-wide singleton: recording a metric is a plain
function call from wherever the interesting thing happened, much like a
`tracing` macro. Nothing has to be threaded through the clients, stores or
transports.
This is the same API the crate will expose once metrics are recorded
straight from Rust through [`glean-sym`]. Until then, the backend forwards
to the [`Telemetry`] implementation the FFI layer installs, which wraps the
callback the consumer hands to `MozAdsClientBuilder::telemetry()`; see
`telemetry/backend.rs`. Moving to
glean-sym means swapping that backend for one that talks to the generated
metrics, and none of the recording sites have to change.
Every function here is infallible and silent by design. Telemetry must never
change the outcome of the operation it is describing.
[`glean-sym`]: https://github.com/mozilla/glean/tree/main/glean-core/glean-sym |
7723 |
10 % |
| test_utils.rs |
|
9915 |
- |