Telemetry 2

Created on June 21, 2022

Page is under construction

Overview

Telemetry 2.0 is a reboot of the existing RDK Telemetry mechanism, inspired by the TR-069 Bulk Data specification, but with a simplified configuration mechanism.

See Comparison with Bulk Data for more details on how Telemetry 2.0 relates to the Bulk Data specification.

Telemetry 2.0 maintains backward compatibility with existing DCM and XConf mechanisms, but also adds new mechanisms, such as: 

  • expanded sources of telemetry data, even for the legacy telemetry profile
  • multiple telemetry profiles that can be concurrently active

The original RDK Telemetry mechanism (legacy telemetry) is simple in concept – grepping log files on a device – and has been hugely successful.  The resulting data and reports are a staple for Triage and Debugging.  However, over time, that success has also resulted in a cost.  The number of logs and strings being searched and reported for legacy telemetry can result in larger than desired CPU utilization every time DCM runs (typically every 15 minutes), and the resulting upload of data can grow very large.

Telemetry 2.0 establishes a framework that can be used to take a heuristic approach to data collection, as well as allowing for more targeted sets of data rather than collecting all the data, all the time.  It also allows for different collection mechanisms to reduce the need for expensive log grepping.

Key Features

  • Configurable reporting intervals per telemetry profile
  • Support for multiple active telemetry profiles
  • Telemetry sources from events, system data model, and log grep
  • Configurable protocol and encoding for generated reports

How It Works


Telemetry 2.0 (RDK-B) – Legacy Support for Telemetry 1.1 backward compatibility

When the Telemetry 2.0 component is enabled, it will download the legacy configuration and generate the legacy report in a way that is compatible with legacy telemetry.  When processing the legacy telemetry configuration, Telemetry 2.0 introduces one additional source for telemetry data:  <event>.  This allows the legacy configuration to begin to take advantage of the performance improvement of using component events rather than using only log grep.  See XConf TBD.  Please note that TR-181 parameter support in legacy telemetry (DCM) is not supported for RDK-V.  

The sequence is as follows: 

  1. Telemetry 2.0 component communicates with Xconf server and fetches the predefined markers
  2. Using the fetched configuration, Telemetry 2.0 Component will prepare a profile containing Vectors for log lookup search string markers, TR-181 parameters and event properties defined in the configuration.  Telemetry 2.0 will register interest for any <event> in the profile.  The profile will be set to run at the configured interval (typically 15 minutes).
  3. During the interval, the Telemetry 2.0 Component will collect <event> data received (via T2 Common Library APIs) for <event>s defined in the profile.
  4. At the interval, Telemetry 2.0 Component will retrieve the data from the device for log file search and TR-181 parameters.  From the retrieved data and the received <event> data, it will create a JSON formatted message (report).
  5. The JSON formatted message data will be uploaded to the server.



Telemetry 2.0 Report Profile Support



A Telemetry 2.0 Report Profile is a report definition in JSON format.  The report definition defines data to be included in the report, the frequency at or condition under which the report should be generated, and the upload protocol and endpoint to which the generated report should be sent.   See Telemetry 2.0: Report Profiles for more details.

Telemetry 2.0 implements many of the concepts of the TR-069 Bulk Data specification, but with some major variations in how those concepts are implemented.  See Comparison with Bulk Data for comparisons between Telemetry 2.0 and the TR-069 Bulk Data specification.

Telemetry 2.0 Report Profiles are set on the device via one of the following TR-181 parameters:  Device.X_RDKCENTRAL-COM_T2.ReportProfiles or Device.X_RDKCENTRAL-COM_T2.ReportProfilesMsgPack.  The value of the parameter is expected to be JSON or msgPacked JSON, respectively.

For simplicity of this documentation, we will refer to the payload for either of these TR-181 parameters as “ReportProfiles”.

Telemetry 2.0 ReportProfiles are processed as follows: 

    1. Telemetry 2.0 component receives the payload of ReportProfiles and parses it
    2. For each Profile received in the payload, Telemetry 2.0 will compare the Profile name and versionHash to determine whether this Profile is already present on the device or if needs an update.   For any Profile on the device that is not received in the ReportProfiles payload, that Profile will be deleted from the device.
    3. For each Profile received in the payload, Telemetry 2.0 component will parse the Parameters and handle each according to its type:  grep, event or dataModel.  See Telemetry 2.0: Report Profiles for more details.
    4. At the interval or condition configured in the Profile, Telemetry 2.0 component will gather data from the device based on the Parameter types and will generate a report formatted according to the Profile’s Encoding property details.
    5. Telemetry 2.0 will upload the generated report payload according to the Profile’s Protocol property details.



Go To Top