Adding reporting of metrics sampling rate.

chrome/browser/metrics/sampling_metrics_provider.cc

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/metrics/sampling_metrics_provider.h"
+
+#include "base/metrics/sparse_histogram.h"
+#include "chrome/browser/metrics/chrome_metrics_services_manager_client.h"
+#include "components/metrics/metrics_provider.h"
+
+namespace metrics {
+
+SamplingMetricsProvider::SamplingMetricsProvider() {}
+SamplingMetricsProvider::~SamplingMetricsProvider() {}
+
+void SamplingMetricsProvider::ProvideGeneralMetrics(

[Alexei Svitkine (slow), 2016/08/01 17:23:51]

Maybe this should be ProvideStabilityMetrics - so this is also included with UMA
reports from the previous session with stability counts?

[jwd, 2016/08/01 18:57:14]

Ok, so UMA_STABILITY_HISTOGRAM_ENUMERATION will just log it as usual?
Are we fine with a non-sparse histogram with 1000 buckets?

[Alexei Svitkine (slow), 2016/08/01 18:59:02]

I think we should still use a sparse histogram. You can deconstruct the sparse
macro and pass in the flag that marks it to be reported as a stability metric in
call.

[jwd, 2016/08/01 20:11:35]

Done.

+    ChromeUserMetricsExtension* uma_proto) {
+  UMA_HISTOGRAM_SPARSE_SLOWLY(

[Alexei Svitkine (slow), 2016/08/01 17:23:51]

Should we just not log this for users who are not being sampled? I think that
would be best, since platforms where we're not doing sampling at all don't need
to send the extra histograms. Also, server-side we need to handle those cases
anyways since there will be old clients who don't send this anyway.

[jwd, 2016/08/01 18:57:14]

Done.

+      "UMA.SamplingRatePerMille",
+      ChromeMetricsServicesManagerClient::GetSamplingRatePerMille());
+}
+
+}  // namespace metrics