Please list the metric's owners. Add more owner tags as needed. Chrome OS (ARM Chromebooks using Exynos 5250 only) Adaptive Support Voltage Group, recorded once per bootup. Indicates which "bin" the SoC is part of, which sets the voltage that different rails on the system will run at. The values 0-11 are valid. A value of 12 indicates an error parsing dmesg and should be investigated. See also Platform.LotIdEnum. cernekee@chromium.org Indicates whether the kernel's ACPI Smart Battery System driver logged an error trying to find the battery on boot. yich@google.com cros-hwsec-userland-eng+uma@google.com Record the bootlockbox space availability when bootlockbox started. dossym@chromium.org Indicates the status of the developer switch on Chrome OS hardware. The developer switch allows users to run their own code on the device. dossym@chromium.org On Chrome OS hardware, indicates whether flash write protection is enabled for the firmware indicated by the histogram suffix. dossym@chromium.org Indicates the status of the hardware write protect switch on Chrome OS hardware. The write protect switch protects firmware from being rewritten. sonnyrao@chromium.org chromeos-performance@google.com Chrome OS number of disk sectors read at boot from kernel start to login-prompt-ready. sonnyrao@chromium.org chromeos-performance@google.com Chrome OS number of disk sectors written at boot from kernel start to login-prompt-ready. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the status code when Chaps needs to reinitializing token. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps session decrypt operation. The return code is defined in pkcs11 specification. There is exactly one sample logged for every chaps session decrypt operation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps session digest operation. The return code is defined in pkcs11 specification. There is exactly one sample logged for every chaps session digest operation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps session encrypt operation. The return code is defined in pkcs11 specification. There is exactly one sample logged for every chaps session encrypt operation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps session sign operation. The return code is defined in pkcs11 specification. There is exactly one sample logged for every chaps session sign operation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps session verify operation. The return code is defined in pkcs11 specification. There is exactly one sample logged for every chaps session verify operation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps token manager load token operation. There is exactly one sample logged for every call to SlotManagerImpl::LoadToken(). chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the return value of a chaps token manager unload token operation. There is exactly one sample logged for every call to SlotManagerImpl::UnloadToken(). chenyian@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the TPM Availability status. sonnyrao@chromium.org chromeos-memory@google.com Chrome OS size of allocated swap area in megabytes (before compression) mutexlox@google.com kendraketsui@google.com cros-telemetry@google.com (ChromeOS only) An enum indicating the reasons why adding a weight to crash reports succeeded or failed. This is recorded after each crash with client-side weighting -- most commonly, those detected by anomaly_detector. Specifically, these metrics are recorded in CrashCollector::AddCrashMetaWeight() and CrashCollector::AddCrashMetaUploadData(). iby@chromium.org mutexlox@chromium.org cros-telemetry@google.com (Chrome OS only) An enum indicating the reasons for removal of crash reports on devices. Generally, we'll remove crash reports after successfully sending them, but there are other reasons for removal (e.g. if the metadata file was malformed). These should be rare, but bugs in the crash reporting system may cause us to start removing crashes before sending them more often. This metric is intended to monitor crash reporting system health. iby@chromium.org mutexlox@chromium.org vapier@chromium.org Generic event of interest from Chrome OS. Intended mainly to help assess the frequency of rare error conditions. semenzato@chromium.org bsimonnet@chromium.org Total CPU time accumulated since the last version update. Reported at most once a day. semenzato@chromium.org bsimonnet@chromium.org mutexlox@chromium.org iby@chromium.org cros-telemetry@google.com Total use time (device ON and not asleep) in the previous day, or the most recent day the device was in use. Reported at most once a day. fshao@chromium.org phoenixshen@chromium.org chromeos-kukui@google.com Ratio of time a detachable base keyboard is active, i.e. when the USB interface is not auto-suspended. Reported every 30 seconds when the base is connected. fshao@chromium.org phoenixshen@chromium.org chromeos-kukui@google.com For devices with a detachable base: whether or not the base is connected on boot. Recorded by upstart task on boot. fshao@chromium.org phoenixshen@chromium.org chromeos-kukui@google.com Result of a detachable base pair operation. fshao@chromium.org phoenixshen@chromium.org chromeos-kukui@google.com Detachable base firmware updates can be configured to only occur on boot. In this mode, any update will be considered "pending" until the system is rebooted, at which point the update may take place. Every time a detachable base is connected to the system, a metric representing the pending update status is recorded. Its possible values are as follows: (0) communication error; (1) no update available; (2) critical update available; or (3) non-critical update available. The definition of "critical" is up to the software performing updates, and would typically be used in the case of a security issue, or broken functionality in a previous firmware version. fshao@chromium.org phoenixshen@chromium.org chromeos-kukui@google.com Result of a detachable base RO firmware update. fshao@chromium.org phoenixshen@chromium.org chromeos-kukui@google.com Result of a detachable base RW firmware update. dlunev@chromium.org chromeos-storage@google.com Emits when io-burst-triggered Write Boost expires. Specifies how well the Write Boost is utilized, i.e. amount of cycles with bandwidth over trigger threshold divided by total amount of cycles Write Boost was enabled. dlunev@chromium.org chromeos-storage@google.com Emits when io-burst-triggered Write Boost expires. Specifies length of io-burst-triggered Write Booster period. dlunev@chromium.org chromeos-storage@google.com Emits when the io-burst ends or when the burst triggers WriteBoost. Specifies if the burst resulted in enabling Write Booster. dlunev@chromium.org chromeos-storage@google.com Emits when application-triggered Write Boost expires. Specifies how well the Write Boost is utilized, i.e. amount of cycles with bandwidth over trigger threshold divided by total amount of cycles Write Boost was enabled. dlunev@chromium.org chromeos-storage@google.com Emits when applications-triggered Write Boost expires. Specifies length of application-triggered Write Booster period. achuith@chromium.org tls@chromium.org Number of users home directories on the device. Logged once a day. achuith@chromium.org omrilio@chromium.org Number of days between now and the last login of the device's least recent user. Logged once a day, if disk usage is high. achuith@chromium.org omrilio@chromium.org Number of user home dirs on device. Logged once a day, if disk usage is high. sarthakkukreti@google.com chromeos-storage@google.com Chrome OS KB in use in the /home/chronos filesystem tree. Logged once a day during log file cleanup. Warning: this histogram was expired from 2022-04-10 to 2023-06-01; data may be missing. sarthakkukreti@google.com chromeos-storage@google.com Chrome OS KB in use in the /var filesystem tree. Logged once a day during log file cleanup. Warning: this histogram was expired from 2022-05-01 to 2023-06-01; data may be missing. kimjae@chromium.org chromeos-core-services@google.com The result of an attempt to Install a DLC package. DLCs are ChromiumOS Software packages that are installed in the stateful partition. kimjae@chromium.org chromeos-core-services@google.com The result of an attempt to Uninstall a DLC package. DLCs are ChromiumOS Software packages that are installed in the stateful partition. gwendal@google.com chromeos-storage@google.com eMMC [5.0] Device lifetime estimation for flash. This field provides an estimated indication about the device lifetime that is reflected by the averaged wear out of memory of a given type relative to its maximum estimated lifetime. iby@google.com mutexlox@google.com cros-telemetry@google.com On ChromeOS, number of external metrics samples read in from the platform. Emitted once every 30 seconds. If this is too large (over 100,000), we will silently lose metrics. Additionally, 100,000 is the largest number we'll ever record here: we stop counting when we hit 100,000. kendraketsui@google.com mutexlox@google.com cros-telemetry@google.com Records number of boot attempts on a device since receiving a variations safe seed from Chrome. This value is reported every time a device boots. gwendal@google.com chromeos-storage@google.com Number of file system errors, as reported by dumpe2fs "FS Error count" field. Reported once per boot. gwendal@google.com chromeos-storage@google.com True when kernel reports that the file system needs deep recovery. File system has corruption the kernel can not fix by itself. Reported once per boot. gwendal@google.com chromeos-storage@google.com True when kernel reports that the file system needed recovery at boot. It indicates the filesytem was not properly unmounted, but was recovered. Reported once per boot. yuanpengni@chromium.org chromeos-core-services@google.com Records if the system firmware mismatched OS bundled firmware. Reported once per boot by dev_debug_vboot. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the device has permission to send hardware data and whether it is due to enabled policies or end-user opt-in. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. ChromeOS Flex Hardware Information Service (flex_hwis) checks if the device is authorized to send hardware data to the server. If the device is managed, management policies will be checked. If the device is unmanaged, the service will check if consent has been granted via the OOBE or settings screen before sending any data. Once the hardware data has been successfully transmitted to the server, no further transmission or related checks will be performed for the next 24 hours. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the flex_hwis utility successfully calls POST API to create data. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. In ChromeOS Flex Hardware Information Service (flex_hwis), each device has a unique identifier. If the unique identifier was just generated by the service client side, the service will then call the POST API to create the data slot on the server side and record whether the API request was successful. Once the hardware data has been successfully transmitted to the server, no further transmission or related checks will be performed for the next 24 hours. tinghaolin@google.com chromeos-flex-eng@google.com Result of checking if the flex_hwis utility successfully calls PUT API to update data. When a user logs in to a ChromeOS Flex device, hardware data transmission and related checks will be initiated. In ChromeOS Flex Hardware Information Service (flex_hwis), each device has a unique identifier. If the unique identifier already exists on the service client side, the service will then call the PUT API to update the data slot on the server side and record whether the API request was successful. Once the hardware data has been successfully transmitted to the server, no further transmission or related checks will be performed for the next 24 hours. campello@google.com chromeos-fwupd@google.com Indicates the return value of a firmware activation operation via fwupd. Reported once per activation operation. campello@google.com chromeos-fwupd@google.com Time elapsed during the firmware update operation. Sent after every sucessful update firmware operation via fwupd. campello@google.com chromeos-fwupd@google.com Indicates the return value of a firmware update operation via fwupd. Reported once per update operation. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The reason why an attempt to hibernate was aborted. Reported when a hibernation attempt is aborted. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The errno reported by Linux when the hibernate image can not be created or saved to storage. Recorded when the hibernate image can not be created or saved. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The difference between the amount of memory and swap available and the amount of space needed to successfully hibernate on ChromeOS devices when there is not enough memory available when hibernate is triggered. Recorded at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The percentage of pages that were dropped by the kernel from the hibernate image because their content was all zeroes. Recorded after a successful suspend to hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com Tracks the top level events of the hibernate cycle: suspend attempt/failure and resume attempt/success/failure. Reported at resume from hibernate or failure to hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The difference between the amount of memory and swap available and the amount of space needed to successfully hibernate on ChromeOS devices when there is more memory available than needed when hibernate is triggered. Recorded at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com Result of 'hibermeta' file system checks. Reported at resume from hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com Time the system was hibernated. Reported at resume from hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The duration in seconds spent moving in the hibernate image on ChromeOS devices. Reported at resume from hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The rate in MiB/s we are moving the hibernate image on ChromeOS devices. Reported at resume from hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The size in KiB of the hibernate image we are moving on ChromeOS devices. Reported at resume from hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The duration in seconds spent writing the hibernate image on ChromeOS devices. Reported at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The rate in MiB/s we wrote the hibernate image on ChromeOS devices. Reported at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The size in KiB of the hibernate image we wrote on ChromeOS devices. Reported at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com ChromeOS total memory and swap available in MiB when hibernate is triggered. Reported at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com ChromeOS memory available in MiB when hibernate is triggered. Reported at hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The duration in milliseconds we waited for the HibernateResumeReady signal from powerd on ChromeOS devices. Reported at resume from hibernate. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The time it takes the hibernated kernel to resume/restore after being launched. Reported when hiberman flushes metrics at the completion of resume. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The time it takes to load the hibernate image from disk into the kernel. Reported when hiberman flushes metrics at the completion of resume. mka@chromium.org bgeffon@chromium.org chromeos-hibernate@google.com The time between when hiberman receives the request to resume, and when the hibernated image has been restored. This represents an approximation of how long the user had to wait for a hibernate resume to complete after logging in. Reported when hiberman flushes metrics at the completion of resume. fbarchard@chromium.org pwnall@chromium.org The maximum supported micro-architecture on an Intel platform. This value is logged at program start time. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org cros-telemetry@google.com Count of kernel crashes during the previous day, or the most recent day the device was in use. Reported at most once a day. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org cros-telemetry@google.com Count of kernel crashes since the last OS update, normalized as number of crashes per year of active use (active use = device is ON and not asleep). Reported daily. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org cros-telemetry@google.com Count of kernel crashes since the last OS update, normalized as number crashes per year of CPU time. Reported daily. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org cros-telemetry@google.com Count of kernel crashes since the last OS update, reported daily. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org cros-telemetry@google.com Count of kernel crashes during the previous epoch-week, or the most recent epoch-week the device was in use. Reported at most once a week. Epoch-weeks divide the time in 7-day intervals starting at the UNIX epoch. grundler@chromium.org groeck@chromium.org bgeffon@chromium.org cros-telemetry@google.com Time elapsed between the last two kernel crashes. Sent after every kernel crash. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a libhwsec operation issued through libhwsec that belongs to {Category}. Success is 0. For the other error codes, see src/platform2/libhwsec/error/tpm_retry_action.h. Recorded when the libhwsec operation finished in the middleware. Please list the metric's owners. Add more owner tags as needed. Chrome OS (ARM Chromebooks using Exynos 5250 only) indication about whether we're part of a special lot ID. Special lot IDs are groups of chips that have special case handling in the kernel for the Adaptive Support Voltage code (the normal logic doesn't work). See also Platform.AsvGroup. Note that fused devices are never part of a special lot (currently) and only some unfused lots are "special". hajimehoshi@chromium.org kouhei@chromium.org sonnyrao@chromium.org chromeos-memory@google.com Various memory usage % of total memory on Chrome OS devices (snapshotted every 30s). Warning: this histogram was expired from 2021-07-02 to 2022-01; data may be missing. hajimehoshi@chromium.org kouhei@chromium.org sonnyrao@chromium.org chromeos-memory@google.com Various memory usage amount on Chrome OS devices (snapshotted every 30s). bgeffon@chromium.org khmel@chromium.org chromeos-memory@google.com Memory usage of all ARC and ARCVM processes in Chrome OS, reported every 10 minutes. bgeffon@chromium.org chromeos-memory@google.com Memory usage of browser and helper processes (excluding GPU process and renderers) in Chrome OS, reported every 10 minutes. bgeffon@chromium.org chromeos-memory@google.com Memory usage of user-level daemons in Chrome OS, reported every 10 minutes. bgeffon@chromium.org chromeos-memory@google.com Memory usage of the GPU process in Chrome OS, reported every 10 minutes. bgeffon@chromium.org chromeos-memory@google.com Memory usage of renderer processes in Chrome OS, reported every 10 minutes. bgeffon@chromium.org chromeos-memory@google.com Memory usage of VMs (crostini and others, except for ARCVM) in Chrome OS, reported every 10 minutes. hajimehoshi@chromium.org kouhei@chromium.org Chrome OS total anonymous memory (active + inactive) as % of total memory 1 minute after boot. hajimehoshi@chromium.org kouhei@chromium.org Chrome OS total anonymous memory (active + inactive) as % of total memory 5 minutes after boot. hajimehoshi@chromium.org kouhei@chromium.org Chrome OS total anonymous memory (active + inactive) as % of total memory 30 minutes after boot. hajimehoshi@chromium.org kouhei@chromium.org Chrome OS total anonymous memory (active + inactive) as % of total memory 150 minutes after boot. hajimehoshi@chromium.org kouhei@chromium.org Chrome OS total anonymous memory (active + inactive) as % of total memory 750 minutes after boot. roccochen@chromium.org chromeos-minidiag-eng@google.com Total number of launches of the MiniDiag (pre-boot diagnostic tool) since the last upload. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. roccochen@chromium.org chromeos-minidiag-eng@google.com Records the duration that the MiniDiag (pre-boot diagnostic tool) is open. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. roccochen@chromium.org chromeos-minidiag-eng@google.com Test item-specific duration of the MiniDiag (pre-boot diagnostic tool) since the last upload. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. The TestType is the same as cros_diagnostics_diag_types listed in coreboot/util/cbfstool/eventlog.c since all the data are parsed from them. roccochen@chromium.org chromeos-minidiag-eng@google.com Test item-specific results of the MiniDiag (pre-boot diagnostic tool) since the last upload. This metrics is recorded right after booting into ChromeOS. This metrics leverages a coreboot command, elogtool, to retrieve the event log and count launch events. The TestType and MiniDiagResultType are the same as cros_diagnostics_diag_types and cros_diagnostics_diag_results listed in coreboot/util/cbfstool/eventlog.c since all the data are parsed from them. lbaraz@chromium.org xuhong@chromium.org cros-reporting-team@google.com Recorded when missive clientlib calls ReportQueue::Enqueue to post an event to ERP. It counts occurrences of the call returning success or each possible error Status. xuhong@chromium.org lbaraz@chromium.org cros-reporting-team@google.com The percentage of CPU time that the Missive daemon has been using. The CPU usage is not expected to be high and any usage beyond 100% is considered to be in the overflow bucket. This is reported once every 10 minutes and only if the Missive daemon is running. jrhilke@chromium.org cros-reporting-team@google.com Recorded when missive recieves a response to its request for an encryption key from the server. Counts the success/failures of key requests. xuhong@chromium.org lbaraz@chromium.org cros-reporting-team@google.com The amount of memory that the Missive daemon has been using. This is reported once every 10 minutes and only if the Missive daemon is running. lbaraz@chromium.org xuhong@chromium.org cros-reporting-team@google.com Recorded when Missive runs the storage directory migration function (called each time when Missive starts). It counts the status of the migration. xuhong@chromium.org lbaraz@chromium.org cros-reporting-team@google.com Counter of each case RESOURCE_EXHAUSTED error was returned by missive Storage to the caller. This is reported only when such error happens (rarely), and only if the Missive daemon is running. lbaraz@google.com cros-reporting-team@google.com Total amount of space freed by controlled degradation performed by Storage. vshenvi@google.com cros-reporting-team@google.com Would only be true. Recorded whenever the generation id is reset in the storage queue. The generation id is set up once during storage queue initialization using the metadata file that matches the last sequencing id used to track, deduplicate and confirm delivery by the server. The generation id is reset when this file is missing or corrupted and the sequencing is irreparably broken. xuhong@chromium.org lbaraz@chromium.org cros-reporting-team@google.com The amount of disk storage that the Missive daemon has been using for storing encrypted records. This is reported once every hour and only if the Missive daemon is running. lbaraz@chromium.org cros-reporting-team@google.com The amount of disk storage that the Missive daemon has been using for storing encrypted records on devices that have not uploaded any data for the last 24 hours (could have updated the encryption key). This is reported once every hour and only if the Missive daemon is running. xuhong@chromium.org lbaraz@chromium.org cros-reporting-team@google.com Would only be true. Recorded whenever an unusual timestamp is encountered when enqueuing a record, which will be rejected. lbaraz@chromium.org cros-reporting-team@google.com {Priority} upload size as a fraction of storage used. Recorded with every upload. andrewlassalle@google.com cros-connectivity@google.com Result of the |CheckForWedgedModem| function. The function checks the modem state after modemfwd starts, and tries to recover the modem if the modem is non responsive. This function is only called once after boot, so a single value is emitted per boot. andrewlassalle@google.com cros-connectivity@google.com Result of the DLC install action performed by modemfwd. Some device variants use a DLC to store their FW. When this DLC is installed, a metric is logged. andrewlassalle@google.com cros-connectivity@google.com Result of each DLC uninstall action performed by modemfwd. Modemfwd will remove any modem DLCs that are not for the device's variant. Each uninstall will log a metric. andrewlassalle@google.com cros-connectivity@google.com The result of each modem FW install attempt. ujjwalpande@google.com cros-connectivity@google.com Metric to track time taken by modemfwd helpers in seconds to flash the firmwares to modem. Values will be reported only for successful flashing cases as flashing times in case of failures could be misleading. andrewlassalle@google.com cros-connectivity@google.com The location that modemfwd uses for the FW install. After modemfwd determines if a DLC will be used or not, a metric is logged with the location used. ujjwalpande@google.com cros-connectivity@google.com Report state of modem recovery operation. apronin@chromium.org cros-hwsec+uma@google.com File system encryption key status for the encrypted stateful file system on Chrome OS. The encryption key is the one that is used by the kernel to protect actual file contents on disk. apronin@chromium.org cros-hwsec+uma@google.com Type/Origin of the system key used for the encrypted stateful file system on Chrome OS. This key is used to wrap the actual file system encryption key. gwendal@google.com chromeos-storage@google.com Number of disk sectors per second read by Chrome OS in a long interval (currently 30s) gwendal@google.com chromeos-storage@google.com Number of disk sectors per second read by Chrome OS in a short interval (currently 1s, sampled every 30s) vovoy@chromium.org chromeos-memory@google.com Memory notification count in 10 minutes, reported every 10 minutes. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The remaining reserved space (SMART 232). The value counts down typically from 100 to 0, sent at boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The total number of 512-byte sectors written during the lifetime of the device, sent at boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The total number of 512-byte sectors written during the lifetime of the device, sent at boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Percentage Used Endurance Indicator. A value of 0 indicates a new device, a value of 100 indicates the device is at the end of its lifespan as projected by the manufacturer. Values greater than 100 indicate the device is beyond the projected lifespan. Maximum value is 255, sent at boot. gwendal@chromium.org mutexlox@chromium.org iby@chromium.org cros-telemetry@google.com Records the feature level of the device. Recorded in every UMA upload. See libsegmentation in platform2 for context. gwendal@chromium.org mutexlox@chromium.org iby@chromium.org cros-telemetry@google.com Records the scope level of the device (Soft vs Hard Branded). Recorded in every UMA upload. See libsegmentation in platform2 for context. gwendal@google.com chromeos-storage@google.com Disk communication errors (SMART 199), sent at boot. gwendal@google.com chromeos-storage@google.com Uncorrectable disk errors (SMART 187), sent at boot. vpalatin@google.com USB device ID of the charger plugged into a Spring device (if any), sent once a minute. The Device ID is composed from the following 4 8-bit registers of the TSU6721 chip: ADC (07h), Device Type 3 (15h), Device Type 2 (0Bh), Device Type 1 (0Ah). Device Type 1/2/3 is a bitmap and most of bits are mutually exclusive (excepted VBUS debounce). ADC is the 5-bit value of the ID pin, but for most types (as in Device Type), there are only one or two possible ID pin connections/values. The datasheet can be found here: http://www.ti.com/lit/ds/symlink/tsu6721.pdf. Note that different brand/models of the charger can have the same ID. sarthakkukreti@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition format. Sampled once per boot. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition space free. Sampled once daily. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition lifetime writes. Sampled once daily. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The amount of time in hours since the last trim when chromeos-trim triggers a trim for the stateful partition. The chromeos-trim script is run daily, but a trim is only triggered if the previous run was interrupted, the amount of writes since the last trim is greater than X% of the remaining space in stateful or we have not trimmed in 7 days. Reported at most once a day. Warning: this histogram was expired from 2022-10-21 to 2023-08-10; data may be missing. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com The amount of data in the stateful partition that is erased when chromeos-trim triggers a trim. The chromeos-trim script is run daily, but a trim is only triggered if the previous run was interrupted, the amount of writes since the last trim is greater than X% of the remaining space in stateful or we have not trimmed in 7 days. Reported at most once a day. Warning: this histogram was expired from 2022-10-21 to 2023-08-10; data may be missing. achuith@chromium.org omrilio@chromium.org Chrome OS stateful partition usage level. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition space used. Sampled once daily. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Chrome OS stateful partition KiB writes per day. Sampled once daily. dehrenberg@chromium.org cast-analytics@google.com The number of blocks marked bad in an MTD partition. This is relevant for devices with raw NAND flash, such as Chromecast. Sampled once daily, if the Chromecast is on for any significant length of time in the day. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com Vendor specific estimate of the percentage of NVM subsystem life used based on the actual usage and the manufacturer's prediction of NVM life. A value of 100 indicates the estimated endurance has been consumed, but may not indicate a failure. Values can exceed 100, with percentages greater than 254 represented as 255. asavery@chromium.org gwendal@chromium.org chromeos-storage@google.com UFS Device life time estimation. This field provides an indication of the device life time based on the amount of performed program/erase cycles. The calculation is vendor specific. dlunev@chromium.org chromeos-storage@google.com Sparse histogram of internal storage device capabilities. Sampled once per boot. asavery@chromium.org chromeos-memory@google.com Number of pages swapped IN over a day, sampled daily. asavery@chromium.org chromeos-memory@google.com Number of pages swapped OUT over a day, sampled daily. granaghan@google.com cros-hwsec+uma@google.com Time in milliseconds AP RO verification took. Captured every cold boot. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a TPM authorized command issued through tcsd. Success is 0. For the other error codes, see /usr/include/tss/tpm_error.h. yich@google.com cros-hwsec-userland-eng+uma@google.com Reporting the TPM command ordinal that results in TPM_E_AUTH2FAIL code. Note that this is only applicable for TPM1.2. Warning: this histogram was expired from Oct 8, 2022 to June 26, 2023; data may be missing. yich@google.com cros-hwsec-userland-eng+uma@google.com Reporting the TPM command ordinal that results in TPM_E_AUTHFAIL code. Note that this is only applicable for TPM1.2. Warning: this histogram was expired from Oct 8, 2022 to June 26, 2023; data may be missing. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the value of the TPM dictionary attack counter reported at boot and hourly while running. Any non-zero value is unexpected. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the status of an hourly attempt to reset the TPM dictionary attack counter. yich@google.com cros-hwsec-userland-eng+uma@google.com Each sample is the result code of a TPM command issued through tcsd. Success is 0. For the other error codes, see /usr/include/tss/tpm_error.h. granaghan@google.com cros-hwsec+uma@google.com AP RO Verification status and detailed result. Captured every cold boot. granaghan@google.com cros-hwsec+uma@google.com Time in milliseconds filesystem initialization and scanning took. Captured every cold boot. granaghan@google.com cros-hwsec+uma@google.com Number of bytes used by the filesystem. Captured every cold boot. apronin@chromium.org cros-hwsec+uma@google.com Status of a complete TPM firmware update attempt. anatol@google.com cros-hwsec+uma@google.com Trusted Platform Module hardware alerts that signal about the chip abnormal situation. chenyian@google.com cros-hwsec-userland-eng+uma@google.com Report if TPM clear is success or not after a power wash. TPM should not be owned after the power wash. yich@google.com cros-hwsec-userland-eng+uma@google.com Report the TPM ownership can be take or not for each TPM initialization process. The process usually happen at the first boot of device. yich@google.com cros-hwsec+uma@google.com The amount of time for Chrome OS to take TPM ownership. Recorded when tpm_manager takes the ownership of TPM. yich@google.com cros-hwsec+uma@google.com The status of the secrets that tpm manager holds. Warning: this histogram was expired from 2021-09-01 to 2022-06-14; data may be missing. apronin@chromium.org cros-hwsec+uma@google.com Indicates a fingerprint of hardware + firmware versions for the TPM chip present in a Chrome OS device. chingkang@chromium.org cros-hwsec+uma@google.com The TPM1 command and response code send from {Client} to trousers. The value is the encoding of 2 bytes command code and 2 bytes response code. chingkang@chromium.org cros-hwsec+uma@google.com The TPM2 command and response code send from {Client} to trunks. The value is the encoding of 2 bytes command code and 2 bytes response code. chingkang@chromium.org cros-hwsec+uma@google.com Command code of the first timeout writing TPM command chingkang@chromium.org cros-hwsec+uma@google.com System uptime when first timeout writing TPM command occurs chingkang@chromium.org cros-hwsec+uma@google.com The write errno recovered after rebinding the TPM driver; recorded only once when trunks notices the write errno is gone after restart. yich@google.com cros-hwsec+uma@google.com Each sample is the result code of a TPM command issued through trunks. For the error codes, see src/platform2/trunks/tpm_generated.h. chingkang@chromium.org cros-hwsec+uma@google.com The write errno changed after rebinding the TPM driver; recorded only once when trunks notices the write errno has changed after restart. chingkang@chromium.org cros-hwsec+uma@google.com The sticky write errno after rebinding the TPM driver; recorded only once when trunks notices the write errno isn't changed after restart. hcyang@google.com cros-hwsec-userland-eng+uma@google.com Records occurrences of U2F commands sent to cr50. mutexlox@chromium.org iby@chromium.org cros-telemetry@google.com Use time (device ON and not asleep) in a particular period (approximately every five minutes). To compute usage time in a given period (e.g. a day), sum up all reported values of this metric for that period (day). As with other UMA metrics on CrOS, this will be uploaded roughly every half-hour. This will eventually supercede Platform.DailyUseTime, which has significant limitations (e.g. it may not report on the right day). mutexlox@chromium.org iby@chromium.org cros-telemetry@google.com Use time samples that would have gone to Platform.UnaggregatedUsageTime, but which are implausibly big. For example, we've seen individual samples of ~1 billion seconds, and many more of over 1 million seconds, which are both far too large to be valid data. metrics_daemon records this metric whenever an individual 5-minute usage sample exceeds 2 hours (defined by kMaxAcceptableUnaggregatedUsageTime, in metrics_daemon.cc, in platform2). semenzato@chromium.org bsimonnet@chromium.org iby@chromium.org mutexlox@chromium.org cros-telemetry@google.com Count of unclean OS shutdowns during the previous day, or the most recent day the device was in use. Specifically, the counter is incremented during boot if the OS did not shut down cleanly and the previous shutdown was not due to a kernel crash (kernel crashes are counted elsewere) and the previous shutdown did not occur while the device was suspended (failures while suspended are assumed to be the battery running down). Reported at most once a day. semenzato@chromium.org bsimonnet@chromium.org iby@chromium.org mutexlox@chromium.org cros-telemetry@google.com Count of crashes (user) during the previous day, or the most recent day the device was in use. Reported at most once a day. norvez@chromium.org cros-network-metrics@google.com Sample collected 10s after boot, showing how many WiFi interfaces are present. norvez@chromium.org cros-network-metrics@google.com Logged (with a constant value of 1) if a WiFi device experienced a PCI failure such that it is being removed from the system. Typically, Chrome OS will follow such a removal with an attempt to rescan the bus and recover device functionality. See also Platform.WiFiStatusAfterForcedPCIRescan for the result of such attempts. norvez@chromium.org cros-network-metrics@google.com Shows the WiFi status after the PCI bus is rescanned to recover WiFi. The UI depends on shill noticing that wlan0 is back up, so the only happy case is one where shill recognizes wlan0 after the rescan completes. gwendal@google.com chromeos-storage@google.com Number of disk sectors per second written by Chrome OS in a long interval (currently 30s) gwendal@google.com chromeos-storage@google.com Number of disk sectors per second written by Chrome OS in a short interval (currently 1s, sampled every 30s) bgeffon@chromium.org chromeos-memory@google.com Compressed swap size in megabytes. This is the actual amount of RAM used by the system to compress memory (i.e. after compression). Snapshot every 30s. bgeffon@chromium.org chromeos-memory@google.com The ratio of compressed memory (zram) before and after compression when the denominator at least 1 MB. Ratios of interest are between 1 and 6 (typically between 2 and 3), and we express them as a percentage (between 100% and 600%). The size of memory before compression includes zero-filled pages. Values close to 100% indicate low compression effectiveness. Snapshot every 30s. asavery@chromium.org gwendal@chromium.org Number of incompressible pages stored in zram. A large number suggests lower compression effectiveness. Snapshot every 30s. vbendeb@chromium.org ti50-core+uma@chromium.org A histogram of values representing AP RO verification state on ChromeOS devices in the field. The values are collected on each ChromeOS start up and are clustered in two ranges: 0..7 and 20..34, both ranges could grow. Cr50 and Ti50 are two generations of GSC (Google Security Chip), their AP RO verification states are named such that it is clear which particular chip version they refer to. apronin@chromium.org vbendeb@chromium.org cros-hwsec+uma@google.com A sparse histogram of values of Board ID flags programmed in GSC devices in the field. Board ID flags is a 32 bit field, and while there only are a few expected values, conceivably any bit combination could be encountered. vbendeb@chromium.org apronin@chromium.org cros-hwsec+uma@google.com A sparse histogram of values indexed by 4 byte Board ID code programmed in GSC reported by devices where there is a mismatch between the RLZ code and the Board ID value programmed in the GSC. apronin@chromium.org vbendeb@chromium.org cros-hwsec+uma@google.com A histogram of flash log event types collected from the GSC device. Log event type is an 8 bit value. This histogram does not allow to drill into particular log entries' contents, but allows to collect a general statistics of events. A script running on the Chrome OS device polls the GSC for new flash log events after every start up. vbendeb@chromium.org cros-hwsec+uma@google.com A sparse histogram of values indexed by 4 byte Board ID code programmed in GSC, reported by devices where there is no mismatch between the RLZ code and the Board ID value. vbendeb@chromium.org apronin@chromium.org cros-hwsec+uma@google.com A sparse histogram of values indexed by 4 byte RLZ code reported by devices where there is a mismatch between the RLZ code and the Board ID value programmed in the GSC. Since RLZ code could be misprogrammed, a sparse histogram is used to allow keeping track of outliers.