Introduction

Telemetry 2.0(T2) is a reboot of the existing RDK Telemetry mechanism, inspired by the TR-069 bulk data specification, but with a simplified configuration mechanism.

This maintains backward compatibility with existing DCM and XConf mechanisms while adding expanded sources of telemetry data and multiple concurrent telemetry profiles. The original RDK telemetry mechanism, which involves grepping log files on a device, has been successful for triage and debugging. However, this success has led to high CPU utilization and large data uploads every 15 minutes when DCM runs. Telemetry 2.0 introduces a framework for smarter data collection and more targeted data sets, reducing the need for extensive log grepping.

The highlights of Telemetry 2.0 include configurable reporting intervals per telemetry profile, the definition of a T2.0 Common Library API for components to report telemetry data, support for multiple active telemetry profiles, telemetry sources from events, the system data model, and log grep, and configurable protocol and encoding for generated reports.

Architecture

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. Please note that TR-181 parameter support in legacy telemetry (DCM) is not supported for RDK-V.  

The sequence is as follows: 

1. The telemetry 2.0 component communicates with the XConf server and fetches the predefined markers.
2. Using the fetched configuration, the 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 component will collect <event> data received (via T2.0 Common Library APIs) for <event>s defined in the profile.
4. At the interval, the 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 multiprofile with report profile

A Telemetry 2.0 report profile is a report definition in JSON format. The report definition defines the 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.

T2 implements many of the concepts of the TR-069 Bulk Data specification but with some major variations in how those concepts are implemented.

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 “Report Profiles”.

Telemetry 2.0 report profiles are processed as follows: 

1. The Telemetry 2.0 component receives the payload of ReportProfiles and parses it
2. For each Profile received in the payload, T2 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, the 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, the 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. T2 will upload the generated report payload according to the profile’s protocol property details.

Telemetry 2.0 using community XConf server

XConf server configuration procedure:

1. XConf telemetry configuration starts with adding DCM settings as telemetry is a subset of log upload process in general, Below are the steps involved in DCM configuration:
   1. Add a Upload Repository – Tells Device about the server side file store where log files will be updated
   2. Add a Formula
   3. Map the configuration with a build condition (such as a MAC/IP/Model combination)
   4. Create Log Upload Settings (Tells devices when to upload the logs)
   5. Create Device settings (Tells when the device should reach XConf for a configuration polling)
2. Telemetry configuration can be done by adding a permanent profile which contains below objects
   1. Upload repository
   2. Profile options (Header, content, frequency etc.)
      1. The telemetry marker which is a combination of Header(For identification), Content(String to search in the log files), Type (Name of the log file), and Polling frequency (After which iteration to send). A new field Component is introduced and here we can specify the Component name from which telemetry data will be retrieved via T2 Common API. Telemetry profile entries can be set depending on the target platform. I.e..RDK-B and RDK-V.
         1. Eg: For RDK-V, header:WIFIV_ERR_HAL_SSIDChngd, content:WIFI_HAL_ERROR_SSID_CHANGED, type:CAPI, pollingfrequency:1
         2. Eg: For RDK-B, header:WIFI_INFO_CosaWifiinit, content:RDKB_SYSTEM_BOOT_UP_LOG : CosaWifiInit, type:WiFiLog.txt.0, pollingfrequency:1, component:ccsp-wifi-agent
3. Creating a targeting rule which is basically mapping the profile to a set of MAC/IP/Device etc.

Refer Xconf Server - User guide for configuration and feature validation for detailed steps.

Client(device) side verification

1. Client(device) side verification
   1. Configure the required details to dcm.properties and comment out the other details
   2. Client end Settings to enable T2 Feature
   3. Client side configuration which involves:
      1. SSH to RPI. Setup RFC parameters, reboot the device and check the running status of Telemetry 2.0
      2. Check profile obtained Inside /opt/.DCMSettings.conf from xconf
      3. After board boot up, disable log rotation, and monitor the log upload process

For detailed steps on configuring the XConf server and validating Telemetry 2.0 features on RDK-B and RDK-V platforms, including sample logs, please click here for RDK-B and here for RDK-V.