You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

While migrating to Telemetry2.0 from  DCA telemetry, the traditional log grepping is targetted to reduce as much as possible by instrumenting the  markers coming from RDKB components.To achieve this, RDKB components are supposed make required changes with the use of APIs from Telemetry 2.0 shared library (commonlib - https://code.rdkcentral.com/r/plugins/gitiles/rdk/components/generic/telemetry/+/refs/heads/rdk-next/source/commonlib/ )

Brief Background:

In DCA telemetry, the markers fetched from xconf are grepped in log files and reported in json format to splunk server.

The markers are of 3 types .

  1. Split based markers. 
  2. Count based markers
  3. TR-181 based markers.
Marker TypeSample configuration from xconfDescription with respect to sample configuration
Split based markers
{"header":"WIFI_ACS_1_split","content":"WIFI_ACS_1:","type":"wifihealth.txt","pollingFrequency":"0"}
Expects the value after content "WIFI_ACS_1:"
Count based markers 
{"header":"RF_ERROR_IPV6PingFailed","content":"Ping to IPv6 Gateway Address are failed","type":"SelfHeal.txt.0","pollingFrequency":"0"}
Expects the occurance count of content "Ping to IPv6 Gateway Address are failed"
TR-181 based markers{"header" : "XDNS_split","content" : "Device.DeviceInfo.X_RDKCENTRAL-COM_EnableXDNS","type" : "<message_bus>","pollingFrequency":"48"}Markers whose type is configured as "<message_bus>"


In T2.0,  the aim is to instrument possible number of split and count based markers from component side. These are termed as event markers. Can be classified as one more type under the classification of  markers. Once a marker is instrumented from component side, its configuration on xconf will be changed  from the configured file name to "<event>" in   'type:' section.

Example: {"header":"WIFI_ACS_1_split","content":"WIFI_ACS_1:","type":<event>","pollingFrequency":"0"}


Overview of Instrumenting RDKB components with T2 shared library (commonlib) APIs:

Component A
Reporting String type split Marker
Component B
Reporting Double type split Marker
Component C
Reporting Integer type split Marker
Component D
Reporting Count Marker
Script A 
Reporting split Marker
Script B 
Reporting Count marker
T2 Shared library (commonlib)
send_data_
via_
telemetrysignal
(char* telemetry_data) 
t2_event_s(char* marker, char* value)
t2_event_f(char* marker, double value)
t2_event_d(char* marker, int value)
t2_event_d(char* marker, 1 )
t2ValNotify "Marker" "Value"
 t2CountNotify "Marker"
 send_data_via_telemetrysignal(char* telemetry_data)
C
C
S
P

B
U
S

CcspBaseIf_SendTelemetry
DataSignal
(bus_handle, telemetry_data)
T2.0 Component

Steps to instrument split based and count based markers from RDKB components side.

  1. Check if that particular device Build have the Telemtry2.0 building capability
  2. Include required headers 
  3. Compile the component with telemetry 2.0 support
  4. Initialize the module with telemetry
  5. Find the correct place to report a marker
  6. Use appropriate APIs to report markers and values.
  7. Must check notes
  1. To Check if a particular device build have the Telemtry2.0 building capability
    1. Should have an entry in device based.xml file
    2. "telemetry2_0" should be appeneded to DISTRO_FEATURES in machine configuration file. NOTE: Distro feature will be removed soon, and this page will be updated to reflect that.
  2. Include required headers / declare enough sized telemetry buffer and send events to T2 with t2_event_s() api
    1. NOTE: Now that T2.0 is present on all RDK-B platforms, there is no need to use the #if defined for the header or T2.0 API calls






  • No labels