| commit | 915d9dae578491f22652307157fe7ddb019648ca | [log] [tgz] |
|---|---|---|
| author | Steve Fung <stevefung@google.com> | Sat Mar 05 00:45:10 2022 +0000 |
| committer | Commit Bot <commit-bot@chromium.org> | Sat Mar 05 00:45:10 2022 +0000 |
| tree | 09bc50ebac497c8ebc0035675029040057110941 | |
| parent | c340414868699d0db40caae115bb428ae5e4a9e2 [diff] |
[internal_metrics] Add replacement metrics for component-based metrics Three of the metrics in the cobalt internal metrics project uses component strings, which is not supported in Cobalt 1.1. Add replacement metrics for these metrics, using a dimension instead of a component string. The two metrics that track bytes stored and uploaded will use an INTEGER metric type, while the metric that tracks logger calls will use an OCCURRENCE metric type. The dimension will enumerate the list of Cobalt projects, and will need to be periodically updated as new projects are added. The client code will also need to maintain a mapping of customer/project IDs to these enum values in order to log the correct dimension value. This was chosen over using an un-enumerated dimension with a max event code and logging the customer and project IDs directly, due to limitations on the max event code value being lower than the legacy project IDs, as well as that pattern being a non-ideal workaround not suggested for typical uses. Additionally, the mapping of projects should be fairly small so should not provide significant impact on the client's size and memory usage. Bug: 64989 Change-Id: I7e0cd2e5eb89cdb73577e3a3e443ef6eaec319a5 Reviewed-on: https://fuchsia-review.googlesource.com/c/cobalt-registry/+/652926 Reviewed-by: Cameron Dale <camrdale@google.com> Reviewed-by: Zach Bush <zmbush@google.com> Fuchsia-Auto-Submit: Steve Fung <stevefung@google.com> Privacy-Approval: Steve Fung <stevefung@google.com> Commit-Queue: Auto-Submit <auto-submit@fuchsia-infra.iam.gserviceaccount.com>
This Git repo contains the registry of customers, projects, metrics and reports for the Cobalt telemetry system.
Cobalt is a system for telemetry with built-in privacy. It is a pipeline for collecting metrics data from user-owned devices in the field and producing aggregate reports. Cobalt includes a suite of features for preserving user privacy and anonymity while giving product owners the data they need to improve their products. A software or hardware developer would use Cobalt to learn about the behavior of their products in the field, in order to make them better.
In order to use Cobalt, a developer must register a project. Within the project a developer must register one or more metrics. Within a metric a developer must register one or more reports. These registrations all involve entries into .yaml files in this repository.
You will need a project, one or more metrics, and one or more reports.
If you are part of a team that is already using Cobalt you likely can use your team's existing project. Projects are grouped into Customers. A customer represents a larger organization consisting of many teams. For example, as of this writing, fuchsia is a customer representing the group of people and projects involved in developing the Fuchsia operating system. Within the Fuchsia customer there are several projects such as connectivity_wlan and local_storage.
The list of customers and projects is in projects.yaml. Add a new customer or project to that file as necessary.
Associated with each customer there is a directory in this repo and associated with each project there is a directory below the parent customer directory. For example associated with the connectivity_wlan project within the fuchsia customer is the directory fuchsia/connectivity_wlan. If you create a new project you must also create a new project directory of the same name.
Within your project's directory (see Register a project above) there must be a file named metrics.yaml. This is where you register your metrics and reports. If you just created a new project you should now create metrics.yaml. In this case you can copy one of the metrics.yaml files from one of the other projects to use as a template.
Inside of metrics.yaml there is a field called metric_definitions that contains a list of metric definitions. You must add a new entry for your new metric. You must give your new metric a name distinct from the names of the other metrics in the file and you must assign it the next available integer ID.
The reports field within a metric definition contains the list of registered reports associated with the metric. You do not need to register any reports in order to start logging data for the new metric. But Cobalt will not send any data to the server nor generate any reports for the metric until you do.
Under the hood, Cobalt will translate the data in metrics.yaml into a protocol buffer message. It is useful to know this because then you can use the definition of the proto messages as the specification for the corresponding fields in the yaml file. Each metric definition entry will be translated into a MetricDefinition proto message as defined in metric_definition.proto and each report definition entry will be translated into a ReportDefinition proto message as defined in report_definition.proto. This translation is accomplished at build time by Cobalt's registry parser.