If there's no `COMPILE_ENVIRONMENT`, generate jogfile.json during build.
It contains information about all the metrics and pings.
If we are both not MOZILLA_OFFICIAL _and_ mozilla::IsDevelopmentBuild,
we look for the jogfile on the first use of the Glean or GleanPings global.
If we find the jogfile, we load our metric and ping info from there,
making it available to JS.
JOG isn't instrumented as it only does anything when !MOZILLA_OFFICIAL,
which is exactly the condition for disabling ping upload (see rust feature
`glean_disable_upload`), so we wouldn't expect to ever hear anything.
Differential Revision: https://phabricator.services.mozilla.com/D160540
If there's no `COMPILE_ENVIRONMENT`, generate jogfile.json during build.
It contains information about all the metrics and pings.
If we are both not MOZILLA_OFFICIAL _and_ mozilla::IsDevelopmentBuild,
we look for the jogfile on the first use of the Glean or GleanPings global.
If we find the jogfile, we load our metric and ping info from there,
making it available to JS.
JOG isn't instrumented as it only does anything when !MOZILLA_OFFICIAL,
which is exactly the condition for disabling ping upload (see rust feature
`glean_disable_upload`), so we wouldn't expect to ever hear anything.
Differential Revision: https://phabricator.services.mozilla.com/D160540
If there's no `COMPILE_ENVIRONMENT`, generate jogfile.json during build.
It contains information about all the metrics and pings.
If we are both not MOZILLA_OFFICIAL _and_ mozilla::IsDevelopmentBuild,
we look for the jogfile on the first use of the Glean or GleanPings global.
If we find the jogfile, we load our metric and ping info from there,
making it available to JS.
JOG isn't instrumented as it only does anything when !MOZILLA_OFFICIAL,
which is exactly the condition for disabling ping upload (see rust feature
`glean_disable_upload`), so we wouldn't expect to ever hear anything.
Differential Revision: https://phabricator.services.mozilla.com/D160540
This reduces the number of times we re-parse the same glean file, and means we
only use 2 GeneratedFiles directives to generate the relevant files for Glean.
This will also make errors generated by the validator only print once.
The problem in the original patch appears to be caused by the use of the rust
file ('api/src/metrics.rs'), as the first argument to the GeneratedFile. This
messed with the location of things like generated deps files for the build
script, and the path of the stub file, which were placed alongside the
`metrics.rs` file, and not in the directory the build system was expecting.
This issue appears to be fixed if the arguments are re-ordered, such that a
header file appears first instead.
Differential Revision: https://phabricator.services.mozilla.com/D158273
Pieces include
* A script for collecting all the ids for metric _types_
* A template for generating the factory that can build each of those types
* mozbuild integration
Differential Revision: https://phabricator.services.mozilla.com/D143048
Previously we used the 27th bit to signal if a metric instance was actually a
labeled_* metric's "submetric". This bit is actually part of the metric type
part of the lower (upper?) 32 bits of the metric_entry_t, but that was okay
because builtin metrics all have their top 5 bits scrubbed.
itsFreeRealEstate.jpg
This can no longer work, though, since JOG will need to be able to have its
own submetrics that don't conflict _and_ will need to keep the type bits
around so we know what instances to build.
(( Yes, yes, I could've designed the system so that we didn't need to,
but this was the less complicated way. We can go down this route when we
provision the 34 Millionth metric and run out of space. ))
So that means taking two bits away from the id portion: one for runtime (we'll
give it 2^26) and one for submetric (2^25).
Differential Revision: https://phabricator.services.mozilla.com/D143044
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
This adds both the core Rust implementation and the
code to enable the needed language bindings. This
additionally enables GIFFT on the URL type, mirroring
them to a string scalar.
Differential Revision: https://phabricator.services.mozilla.com/D145215
We need to clear state at shutdown that we hold for GIFFT mirroring purposes.
However, more data can come in even later (there's nothing stopping it. Plus,
Glean can meaningfully record later given its shutdown happens in a later
phase), so the naive approach of lazy-instantiate and RunOnShutdown-clear
doesn't work.
Since Telemetry is only good to AppShutdownTelemetry, we now fail to mirror to
it after AppShutdownTelemetry and clear state in the immediately-next phase.
Also, data can come in earlier than we have a main thread to dispatch to,
requiring some careful finagling of threads to ensure our cleanup routine
is appropriately registered.
Differential Revision: https://phabricator.services.mozilla.com/D143522
If we don't, we assert if the first GIFFT-enabled timing distribution's
instrumentation thread on a given process is not the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D141632
Based on our experience with Firefox for Android, annotating Glean metrics
with issue tracker component information can provide valuable context to
anyone searching for metrics.
This adds a new set of tags corresponding to the components in the
tree, annotates the existing Glean metrics. Finally, it also adds a new
mach command called `update-glean-tags` to update the tags files based
on build metadata.
Differential Revision: https://phabricator.services.mozilla.com/D134332
Based on our experience with Firefox for Android, annotating Glean metrics
with issue tracker component information can provide valuable context to
anyone searching for metrics.
This adds a new set of tags corresponding to the components in the
tree, annotates the existing Glean metrics. Finally, it also adds a new
mach command called `update-glean-tags` to update the tags files based
on build metadata.
Differential Revision: https://phabricator.services.mozilla.com/D134332
This replaces the default-used `RandomState`[1] on the hashmaps used in
FOG's IPC with a simple wrapper around `DefaultHasher`.
`RandomState` uses `DefaultHasher` internally, which at the moment of
this commit, uses `SipHasher13` internally.
Our `HashState` does the same, but with default keys of `(0, 0)`
(whereas `RandomState` uses some random keys).
This will result in the same hashes used for the same values in
different hashmaps.
But this should be fine for the use here:
The key for all those hash maps is a `MetricId`, which is a simple `u32`.
It's already a unique identifier generated from defined metrics and not
user-manipulated.
Therefore we shouldn't need to worry about HashDos-resistance.
[1]: https://doc.rust-lang.org/std/collections/hash_map/struct.RandomState.html
Differential Revision: https://phabricator.services.mozilla.com/D135208
With the former 3 enabled we can enable labeled metrics as well,
because they only exist for these 3.
That also makes testing easier because we don't need to special case
that.
Differential Revision: https://phabricator.services.mozilla.com/D126800
The code was already trying to do this but was comparing tuples instead of
mirror probe names. Guess it got missed in a refactor.
Amusingly I was violating the invariant in two places and had to fix 'em : |
Differential Revision: https://phabricator.services.mozilla.com/D127546
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
