Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(1)

Side by Side Diff: src/platform/metrics/README

Issue 1989004: First draft of the metrics doc. (Closed) Base URL: ssh://git@chromiumos-git/chromeos
Patch Set: Address review comments. Created 10 years, 7 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
1 This packages contains all scripts and programs assoicated with metrics 1 Copyright (c) 2010 The Chromium OS Authors. All rights reserved.
2 collection for both Chrome's User Metrics Server and automated performance 2 Use of this source code is governed by a BSD-style license that can be
3 metrics collection via Autotest. 3 found in the LICENSE file.
4 4
5 The package includes the metrics daemon for Chrome OS. This program 5 The Chrome OS "metrics" package contains utilities for client-side
6 runs as a daemon and collects events by polling and listening for 6 user metric collection. The collected data is sent to Chrome for
7 d-bus signals. It then adds timing (if needed) and sends the events 7 transport to the UMA server.
8 to Chrome for transport to the UMA server at Google. 8
9
10 ================================================================================
11 The Metrics Library: libmetrics
12 ================================================================================
13
14 libmetrics is a small library that implements the basic C++ API for
15 metrics collection. All metrics collection is funneled through this
16 library. The easiest and recommended way for a client-side module to
17 collect user metrics is to link libmetrics and use its APIs to send
18 metrics to Chrome for transport to UMA. In order to use the library in
19 a module, you need to do the following:
20
21 - Add a dependence (DEPEND and RDEPEND) on chromeos-base/metrics to
22 the module's ebuild.
23
24 - Link the module with libmetrics (for example, by passing -lmetrics
25 to the module's link command). Both libmetrics.so and libmetrics.a
26 are built and installed under $SYSROOT/usr/lib/. Note that by
27 default -lmetrics will link against libmetrics.so, which is
28 preferred.
29
30 - To access the metrics library API in the module, include the
31 <metrics_library.h> header file. The file is installed in
32 $SYSROOT/usr/include/ when the metrics library is built and
33 installed.
34
35 - Currently, the API includes two static methods:
36
37 bool MetricsLibrary::SendToChrome(const std::string& name, int sample,
38 int min, int max, int nbuckets)
39 sends a sample for a regular (exponential) histogram.
40
41 bool MetricsLibrary::SendEnumToChrome(const std::string& name, int sample,
42 int max)
43 sends a sample for an enumeration (linear) histogram.
44
45 See API documentation in metrics_library.h under
46 src/platform/metrics/.
47
48 TODO: It might be better to convert the API to a dynamic object.
49
50 - On the target platform, shortly after the sample is sent it should
51 be visible in Chrome through "about:histograms".
52
53
54 ================================================================================
55 Histogram Naming Convention
56 ================================================================================
57
58 Use TrackerArea.MetricName. For example:
59
60 Logging.CrashCounter
61 Network.TimeToDrop
62 Platform.BootTime
63
64
65 ================================================================================
66 Server Side
67 ================================================================================
68
69 If the histogram data is visible in about:histograms, it will be sent
70 by an official Chrome build to UMA, assuming the user has opted into
71 metrics collection. To make the histogram visible on
72 "chromedashboard", the histogram wiki needs to be updated (steps 2 and
73 3 after following the "Details on how to add your own histograms" link
74 under the Histograms tab).
75
76 The UMA server logs and keeps the collected field data even if the
77 metric's name is not added to the histogram wiki. However, the
78 dashboard histogram for that metric will show field data as of the
79 histogram wiki update date; it will not include data for older
80 dates. If past data needs to be displayed, manual server-side
81 intervention is required. In other words, one should assume that field
82 data collection starts only after the histogram wiki has been updated.
83
84
85 ================================================================================
86 The Metrics Client: metrics_client
87 ================================================================================
88
89 metrics_client is a simple shell command-line utility for sending
90 histogram samples. It's installed under /usr/bin on the target
91 platform and uses libmetrics to send the data to Chrome. The utility
92 is useful for generating metrics from shell scripts.
93
94 For usage information and command-line options, run "metrics_client"
95 on the target platform or look for "Usage:" in metrics_client.cc.
96
97
98 ================================================================================
99 The Metrics Daemon: metrics_daemon
100 ================================================================================
101
102 metrics_daemon is a daemon that runs in the background on the target
103 platform and is intended for passive or ongoing metrics collection, or
104 metrics collection requiring feedback from multiple modules. For
105 example, it listens to D-Bus signals related to the user session and
106 screen saver states to determine if the user is actively using the
107 device or not and generates the corresponding data. The metrics daemon
108 uses libmetrics to send the data to Chrome.
109
110 The recommended way to generate metrics data from a module is to link
111 and use libmetrics directly. However, the module could instead send
112 signals to or communicate in some alternative way with the metrics
113 daemon. Then the metrics daemon needs to monitor for the relevant
114 events and take appropriate action -- for example, aggregate data and
115 send the histogram samples.
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698