Quantify initial stability report edge cases.

components/metrics/proto/system_profile.proto

Index: components/metrics/proto/system_profile.proto
diff --git a/components/metrics/proto/system_profile.proto b/components/metrics/proto/system_profile.proto
index 1bf90ef47b09da04d6658f3572a277cfd0e9d676..a58d5b2f4a40f3622a210288949412e969653c81 100644
--- a/components/metrics/proto/system_profile.proto
+++ b/components/metrics/proto/system_profile.proto
@@ -440,7 +440,7 @@ message SystemProfileProto {
   // Figures that can be used to generate application stability metrics.
   // All values are counts of events since the last time that these
   // values were reported.
-  // Next tag: 28
+  // Next tag: 31
   message Stability {
     // Total amount of time that the program was running, in seconds,
     // since the last time a log was recorded, as measured using a client-side
@@ -549,6 +549,17 @@ message SystemProfileProto {
       optional int32 loading_error_count = 5;
     }
     repeated PluginStability plugin_stability = 22;
+
+    // The number of times a stability log's upload was deferred.
+    optional int32 deferred_count = 28;
+
+    // The number of times stability data was discarded. Note that this count
+    // is not version specific and instead accumulates across versions.
+    optional int32 discard_count = 29;
+
+    // The number of times the serialized system profile's version did not match
+    // the pref version.
+    optional int32 version_mismatch_count = 30;

[Alexei Svitkine (slow), 2016/08/30 21:25:59]

I'd actually prefer these be added as histograms.

Histograms have a number of advantages: not needing any server-side changes,
automatically useable from the various dashboards we have, less "set in stone" -
so that can be added/removed "easier".

You can still have the prefs that persist the values between sessions, but the
actual values can be logged as histograms.

[manzagop (departed), 2016/09/01 21:26:56]

Done.

   }
   optional Stability stability = 8;