Persist setup metrics and have Chrome report them during UMA upload.

chrome/installer/setup/setup_main.cc

 // Copyright (c) 2012 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/installer/setup/setup_main.h"
 
 #include <windows.h>
 #include <msi.h>
 #include <shellapi.h>
 #include <shlobj.h>
 #include <stddef.h>
 #include <stdint.h>
 
 #include <string>
 
 #include "base/at_exit.h"
 #include "base/command_line.h"
 #include "base/file_version_info.h"
 #include "base/files/file_path.h"
 #include "base/files/file_util.h"
 #include "base/files/scoped_temp_dir.h"
 #include "base/macros.h"
 #include "base/memory/scoped_ptr.h"
+#include "base/metrics/histogram_base.h"
+#include "base/metrics/histogram_persistence.h"
+#include "base/metrics/persistent_memory_allocator.h"
 #include "base/path_service.h"
 #include "base/process/launch.h"
 #include "base/process/memory.h"
 #include "base/strings/string16.h"
 #include "base/strings/string_number_conversions.h"
 #include "base/strings/string_util.h"
 #include "base/strings/stringprintf.h"
 #include "base/strings/utf_string_conversions.h"
 #include "base/values.h"
 #include "base/version.h"
@@ skipping 28 matching lines @@
 #include "chrome/installer/util/installer_state.h"
 #include "chrome/installer/util/installer_util_strings.h"
 #include "chrome/installer/util/l10n_string_util.h"
 #include "chrome/installer/util/logging_installer.h"
 #include "chrome/installer/util/lzma_util.h"
 #include "chrome/installer/util/master_preferences.h"
 #include "chrome/installer/util/master_preferences_constants.h"
 #include "chrome/installer/util/self_cleaning_temp_dir.h"
 #include "chrome/installer/util/shell_util.h"
 #include "chrome/installer/util/user_experiment.h"
+#include "chrome/installer/util/util_constants.h"
 
 #if defined(GOOGLE_CHROME_BUILD)
 #include "chrome/installer/util/updating_app_registration_data.h"
 #endif
 
 using installer::InstallerState;
 using installer::InstallationState;
 using installer::InstallationValidator;
 using installer::MasterPreferences;
 using installer::Product;
@@ skipping 1532 matching lines @@
 }  // namespace installer
 
 int WINAPI wWinMain(HINSTANCE instance, HINSTANCE prev_instance,
                     wchar_t* command_line, int show_command) {
   // Check to see if the CPU is supported before doing anything else. There's
   // very little than can safely be accomplished if the CPU isn't supported
   // since dependent libraries (e.g., base) may use invalid instructions.
   if (!installer::IsProcessorSupported())
     return installer::CPU_NOT_SUPPORTED;
 
+  // Create a persistent space for any histograms that can be reported later

[grt (UTC plus 2), 2016/02/04 15:36:42]

how about creating an installer_metrics.{cc,h} pair (or somesuch) with two
functions, one each for this block of code and the one below?

[bcwhite, 2016/02/04 21:51:13]

Done.

+  // by the Chrome process. The "id" is a timestamp so that Chrome can tell

[grt (UTC plus 2), 2016/02/04 15:36:42]

nit: The comment on line 1795 refers to the browser rather than Chrome. If it
truly is the browser process that is responsible for picking up the data and
reporting it (I think this is true), please harmonize both comments to "...by
the browser process...".

[bcwhite, 2016/02/04 21:51:13]

Done.

+  // if it has already reported these metrics. No name is given so no internal
+  // histograms are created or managed; such would be pointless because they
+  // would have to be created on the heap and thus never be persisted for
+  // reporting.
+  uint64_t allocator_id = base::Time::Now().ToTimeT();
+  base::SetPersistentHistogramMemoryAllocator(
+      new base::LocalPersistentMemoryAllocator(1 << 20,  // 1 MiB
+                                               allocator_id,
+                                               std::string()));
+
+  // Now that histograms have a persistent place to be stored, the allocator
+  // itself can create histograms within that space.
+  base::GetPersistentHistogramMemoryAllocator()
+      ->CreateTrackingHistograms(installer::kSetupHistogramAllocatorName);
+
   // The exit manager is in charge of calling the dtors of singletons.
   base::AtExitManager exit_manager;
   base::CommandLine::Init(0, NULL);
 
   // install_util uses chrome paths.
   chrome::RegisterPathProvider();
 
   const MasterPreferences& prefs = MasterPreferences::ForCurrentProcess();
   installer::InitInstallerLogging(prefs);
 
@@ skipping 129 matching lines @@
   // MSI demands that custom actions always return 0 (ERROR_SUCCESS) or it will
   // rollback the action. If we're uninstalling we want to avoid this, so always
   // report success, squashing any more informative return codes.
   if (!(installer_state.is_msi() && is_uninstall)) {
     // Note that we allow the status installer::UNINSTALL_REQUIRES_REBOOT
     // to pass through, since this is only returned on uninstall which is
     // never invoked directly by Google Update.
     return_code = InstallUtil::GetInstallReturnCode(install_status);
   }
 
+  // Save all the persistent histograms to a single file on disk for reading

[grt (UTC plus 2), 2016/02/04 15:36:42]

using a single file means that we'll get only a random subset of installer UMA
data. is it possible to not lose data in some reasonable way? multiple files,
perhaps?

[bcwhite, 2016/02/04 21:51:13]

All things are possible... for a cost.  Metrics are reported at launch and every
30 minutes after that.  We'll only fail to report data if there are multiple
runs between those times.

Once read/write memory-mapped files are supported (a few months down my
timeline), it may be possible to switch to that which will mean that no records
will get lost no matter how many runs occur.

[grt (UTC plus 2), 2016/02/08 18:09:18]

Okay. Getting some data is better than none, so I'm okay with this for now. Is
there a way to measure how much data we're losing in the current scheme? Please
open a new crbug issue for this (r/w mapped files so there's no data loss) so
that it isn't forgotten about.

[bcwhite, 2016/02/09 21:08:45]

I've got some ideas on how to extend this but it needs more thought.  It's
complicated by the privilege separation (i.e. Chrome can't change, delete, or
rename files created by setup).

[grt (UTC plus 2), 2016/02/10 16:01:53]

For a system-level install, setup.exe and chrome.exe can interact via
ClientStateMedium. Perhaps chrome.exe can relay its collection state to
setup.exe by way of a value there. Happy to brainstorm with you when the time is
right.

+  // by the browser so it can be reported. For atomicity, first write to a
+  // temporary file and then rename it. The ImportantFileWriter would be good
+  // for this except it supports only std::string for its data.
+  base::FilePath file_path = installer_state.target_path().AppendASCII(
+      installer::kSetupHistogramAllocatorName).AddExtension(L".pma");
+  base::FilePath tmp_file_path;
+  base::DeleteFile(file_path, false);
+  if (base::CreateTemporaryFileInDir(file_path.DirName(), &tmp_file_path)) {
+    base::File histograms(tmp_file_path,
+                          base::File::FLAG_OPEN | base::File::FLAG_WRITE);
+    if (histograms.IsValid()) {
+      base::PersistentMemoryAllocator* alloc =
+          base::GetPersistentHistogramMemoryAllocator();
+      int used = static_cast<int>(alloc->used());
+      if (histograms.Write(0, static_cast<const char*>(alloc->data()),
+                           used) == used &&
+          histograms.Flush()) {
+        histograms.Close();
+        if (base::ReplaceFile(tmp_file_path, file_path, nullptr)) {

[grt (UTC plus 2), 2016/02/04 15:36:42]

this will fail so long as chrome.exe has the |file_path| mapped in memory since
FileMetricsProvider::CheckAndMapNewMetrics opens the file without SHARE_DELETE.

[bcwhite, 2016/02/04 21:51:13]

Basically part of the multiple-runs problem.  FileMetricsProvider only keep the
file mapped until the values are sent, after which it releases it.

[grt (UTC plus 2), 2016/02/08 18:09:18]

Right now that window is pretty big (~30m), right? Are you planning to change
the Chrome side so that it reads the file during the scanning phase rather than
keeping it mapped until histograms are collected?

[bcwhite, 2016/02/09 21:08:45]

Yes.  Either I'll pre-read it into an alternate memory buffer or do everything
off the UI thread or... something else.

+          VLOG(1) << "Persistent histograms saved in file: "
+                  << file_path.AsUTF8Unsafe();
+        }
+      }
+    }
+  }
+  base::DeleteFile(tmp_file_path, false);
+
   VLOG(1) << "Installation complete, returning: " << return_code;
 
   return return_code;
 }