1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/services/docs/metrics.rst Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,130 @@
1.4 +.. _services_metrics:
1.5 +
1.6 +============================
1.7 +Metrics Collection Framework
1.8 +============================
1.9 +
1.10 +The ``services/metrics`` directory contains a generic data metrics
1.11 +collecting and persisting framework for Gecko applications.
1.12 +
1.13 +Overview
1.14 +========
1.15 +
1.16 +The Metrics framework by itself doesn't do much: it simply provides a
1.17 +generic mechanism for collecting and persisting data. It is up to users
1.18 +of this framework to drive collection and do something with the obtained
1.19 +data. A consumer of this framework is :ref:`firefox_health_report`.
1.20 +
1.21 +Relationship to Telemetry
1.22 +-------------------------
1.23 +
1.24 +Telemetry provides similar features to code in this directory. The two
1.25 +may be unified in the future.
1.26 +
1.27 +Usage
1.28 +=====
1.29 +
1.30 +To use the code in this directory, import Metrics.jsm. e.g.
1.31 +
1.32 + Components.utils.import("resource://gre/modules/Metrics.jsm");
1.33 +
1.34 +This exports a *Metrics* object which holds references to the main JS
1.35 +types and functions provided by this feature. Read below for what those
1.36 +types are.
1.37 +
1.38 +Metrics Types
1.39 +=============
1.40 +
1.41 +``Metrics.jsm`` exports a number of types. They are documented in the
1.42 +sections below.
1.43 +
1.44 +Metrics.Provider
1.45 +----------------
1.46 +
1.47 +``Metrics.Provider`` is an entity that collects and manages data. Providers
1.48 +are typically domain-specific: if you need to collect a new type of data,
1.49 +you create a ``Metrics.Provider`` type that does this.
1.50 +
1.51 +Metrics.Measurement
1.52 +-------------------
1.53 +
1.54 +A ``Metrics.Measurement`` represents a collection of related pieces/fields
1.55 +of data.
1.56 +
1.57 +All data recorded by the metrics framework is modeled as
1.58 +``Metrics.Measurement`` instances. Instances of ``Metrics.Measurement``
1.59 +are essentially data structure descriptors.
1.60 +
1.61 +Each ``Metrics.Measurement`` consists of a name and version to identify
1.62 +itself (and its data) as well as a list of *fields* that this measurement
1.63 +holds. A *field* is effectively an entry in a data structure. It consists
1.64 +of a name and strongly enumerated type.
1.65 +
1.66 +Metrics.Storage
1.67 +---------------
1.68 +
1.69 +This entity is responsible for persisting collected data and state.
1.70 +
1.71 +It currently uses SQLite to store data, but this detail is abstracted away
1.72 +in order to facilitate swapping of storage backends.
1.73 +
1.74 +Metrics.ProviderManager
1.75 +-----------------------
1.76 +
1.77 +High-level entity coordinating activity among several ``Metrics.Provider``
1.78 +instances.
1.79 +
1.80 +Providers and Measurements
1.81 +==========================
1.82 +
1.83 +The most important types in this framework are ``Metrics.Provider`` and
1.84 +``Metrics.Measurement``, henceforth known as ``Provider`` and
1.85 +``Measurement``, respectively. As you will see, these two types go
1.86 +hand in hand.
1.87 +
1.88 +A ``Provider`` is an entity that *provides* data about a specific subsystem
1.89 +or feature. They do this by recording data to specific ``Measurement``
1.90 +types. Both ``Provider`` and ``Measurement`` are abstract base types.
1.91 +
1.92 +A ``Measurement`` implementation defines a name and version. More
1.93 +importantly, it also defines its storage requirements and how
1.94 +previously-stored values are serialized.
1.95 +
1.96 +Storage allocation is performed by communicating with the SQLite
1.97 +backend. There is a startup function that tells SQLite what fields the
1.98 +measurement is recording. The storage backend then registers these in
1.99 +the database. Internally, this is creating a new primary key for
1.100 +individual fields so later storage operations can directly reference
1.101 +these primary keys in order to retrieve data without having to perform
1.102 +complicated joins.
1.103 +
1.104 +A ``Provider`` can be thought of as a collection of ``Measurement``
1.105 +implementations. e.g. an Addons provider may consist of a measurement
1.106 +for all *current* add-ons as well as a separate measurement for
1.107 +historical counts of add-ons. A provider's primary role is to take
1.108 +metrics data and write it to various measurements. This effectively
1.109 +persists the data to SQLite.
1.110 +
1.111 +Data is emitted from providers in either a push or pull based mechanism.
1.112 +In push-based scenarios, the provider likely subscribes to external
1.113 +events (e.g. observer notifications). An event of interest can occur at
1.114 +any time. When it does, the provider immediately writes the event of
1.115 +interest to storage or buffers it for eventual writing. In pull-based
1.116 +scenarios, the provider is periodically queried and asked to populate
1.117 +data.
1.118 +
1.119 +SQLite Storage
1.120 +==============
1.121 +
1.122 +``Metrics.Storage`` provides an interface for persisting metrics data to a
1.123 +SQLite database.
1.124 +
1.125 +The storage API organizes values by fields. A field is a named member of
1.126 +a ``Measurement`` that has specific type and retention characteristics.
1.127 +Some example field types include:
1.128 +
1.129 +* Last text value
1.130 +* Last numeric value for a given day
1.131 +* Discrete text values for a given day
1.132 +
1.133 +See ``storage.jsm`` for more.
