Lines Matching defs:log
11 // is the central controller for the acquisition of log data, and the automatic
12 // transmission of that log data to an external server. Its major job is to
17 // transmission. Transmission includes submitting a compressed log as data in a
24 // There is at most one initial log sent for each complete run of the chromium
25 // product (from startup, to browser shutdown). An initial log is generally
28 // external server's response to the initial log conceptually tells this MS if
33 // After the above initial log, a series of ongoing logs will be transmitted.
34 // The first ongoing log actually begins to accumulate information stating when
35 // the MS was first constructed. Note that even though the initial log is
36 // commonly sent a full minute after startup, the initial log does not include
40 // periods without any (ongoing) log transmissions. Ongoing logs typically
43 // ongoing log is closed out, a call is made to gather memory statistics. Those
44 // memory statistics are deposited into a histogram, and the log finalization
51 // log that has not yet been transmitted. At shutdown time, that fragment
55 // ongoing log is then stored persistently as a string in the PrefServices, for
62 // transmit the initial log have failed, and a lot(?) of data has accumulated in
63 // the ongoing log (which didn't yet get closed, because there was never even a
65 // situation, where a loss of connection prevented an ongoing log from being
66 // transmitted, and a (still open) log was stuck accumulating a lot(?) of data,
67 // while the earlier log retried its transmission. In both of these
73 // the initial log is even formed or transmitted. In that situation, no logging
75 // in a future run's initial log. (i.e., we don't lose crash stats).
83 // INIT_TASK_DONE, // Waiting for timer to send initial log.
84 // INITIAL_LOG_READY, // Initial log generated, and waiting for reply.
93 // initial log.
102 // INIT_TASK_DONE, // Waiting for timer to send initial log.
103 // The callback has arrived, and it is now possible for an initial log to be
107 // INITIAL_LOG_READY, // Initial log generated, and waiting for reply.
108 // This state is entered only after an initial log has been composed, and
113 // This state indicates that the initial log for this session has been
125 // Current logs are being accumulated. Typically every 20 minutes a log is
126 // closed and finalized for transmission, at the same time as a new log is
134 // happens, any pending (transmission in progress) log is pushed into the list
136 // initial log, or an ongoing log). An addition, any log that is currently
137 // accumulating is also finalized, and pushed into the unsent log list. With
139 // case the user enables log recording again during this session. This way
144 // modified (i.e., when we send an old log), we mirror the list of logs into
148 // Due to race conditions, it is always possible that a log file could be sent
149 // twice. For example, if a log file is sent, but not yet acknowledged by
150 // the external server, and the user shuts down, then a copy of the log may be
225 // The delay, in seconds, after startup before sending the first log message.
232 // The maximum number of events in a log uploaded to the UMA server.
236 // will discard the log, and not try to retransmit it. We also don't persist
237 // the log to the prefs for transmission during the next chrome session if this
242 // delay (in seconds) between each log transmission.
245 // Minimum time a log typically exists before sending, in seconds.
248 // sending the next log. If the channel is busy, such as when there is a
249 // failure during an attempt to transmit a previous log, then a log may wait
250 // (and continue to accrue new log entries) for a much greater period of time.
253 // When we don't succeed at transmitting a log to a server, we progressively
254 // wait longer and longer before sending the next log. This backoff process
257 // The following is the constant we use to expand that inter-log duration.
272 // send during a this or future sessions. Note that each log may be pretty
273 // large, as presumably the related "initial" log wasn't sent (probably nothing
274 // was, as the user was probably off-line). As a result, the log probably kept
275 // accumulating while the "initial" log was stalled (pending_), and couldn't be
277 // A "standard shutdown" will create a small log, including just the data that
286 // This is used to quickly log stats from child process related notifications in
668 // case, the log transmissions should have stopped. Here we start them up
856 // for sending the initial log. This avoids blocking the main UI
864 void MetricsService::StopRecording(MetricsLogBase** log) {
870 // TODO(jar): Integrate bounds on log recording more consistently, so that we
873 UMA_HISTOGRAM_COUNTS("UMA.Discarded Log Events",
878 StartRecording(); // Start trivial log to hold our histograms.
882 // end of all log transmissions (initial log handles this separately).
884 if (log) {
894 if (log)
895 *log = current_log_;
908 // We may race here, and send second copy of initial log later.
928 // log. It wasn't supposed to be uploaded anyway.
933 UMA_HISTOGRAM_COUNTS("UMA.Large Accumulated Log Not Persisted",
944 // If we're not reporting, there's no point in starting a log transmission
1016 // If we're getting no notifications, then the log won't have much in it, and
1044 // MakePendingLog should have put something in the pending log, if it didn't,
1062 // Compression failed, and log discarded :-/.
1065 // TODO(jar): If compression failed, we should have created a tiny log and
1092 // We need to wait for the initial log to be ready before sending
1151 MetricsLog* log = new MetricsLog(client_id_, session_id_);
1152 log->set_hardware_class(hardware_class_); // Adds to initial log.
1153 log->RecordEnvironment(plugins_, profile_dictionary_.get());
1157 current_log_ = log;
1158 RecordCurrentHistograms(); // Into current_log_... which is really log.
1161 log->CloseLog();
1163 pending_log_ = log;
1258 // We encode the compressed log as Value::CreateStringValue() expects to
1312 VLOG(1) << "COMPRESSED FOLLOWING METRICS LOG: " << pending_log_text;
1314 LOG(DFATAL) << "Failed to compress log for transmission.";
1381 UMA_HISTOGRAM_COUNTS("UMA.Large Rejected Log was Discarded",
1394 } else { // Successful receipt (or we are discarding log).
1422 // Since we sent a log, make sure our in-memory state is recorded to disk.
1445 VLOG(1) << "METRICS: Recorder shutdown during log transmission.";
1510 // the log overflows. For now, we won't record these events.
1571 // log data is available.
1742 // We simply don't log anything to UMA if there is a single incognito
