Versions Compared

Old Version 20

changes.mady.by.user Keerthana Pandurangan

Saved on

compared with

New Version Current

changes.mady.by.user Keerthana Pandurangan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

"telemetryProfile": [{ 
    "header": "SYSbootuptime_SHClientConnectComplete_WIFI_restartsplit", 

     "content": "WIFI_process is not runningClient_Connect_complete:", 
 
    "type": "SelfHealLM.txt.0log", 

     "pollingFrequency": "0" 
 },

Updated marker with event feed as the source; "type" and "content" field are changed:

"telemetryProfile": [{ 
  "header": "SYSbootuptime_SHClientConnectComplete_WIFI_restartsplit", 
   "content": ""com.cisco.spvtg.ccsp.wifiagent""ccsp-lm-lite", 
   "type": "<event>", 
   "pollingFrequency": "0" 
},

...

A shared library is used by components to send targeted marker occurrences through an event feed to the T2 component.Components using the shared library shall conditionally compile it in via #if defined(ENABLE_FEATURE_TELEMETRY2_0) in order to support platform-specific compilation.When the T2 component receives a marker event it processes the marker name and value according to the Use definition in the report profile. The T2 component will store absolute as received, accumulate, or aggregate values. Marker events are processed per report profile.
When a report is generated markers that were processed from the event feed are included in the report as specified by the report profile.
Architecture Overview
Telemetry 2.0
 Gliffy Diagram
macroId87fb0e2b-c598-43e3-978b-05f205fa4310
nameT2 overview
pagePin1
Overview of Instrumenting RDKB components with T2 shared library (commonlib) APIs:
Image Removed
T2.0 Common Library
...
.
Architecture Overview
Telemetry 2.0
 Gliffy Diagram
macroId87fb0e2b-c598-43e3-978b-05f205fa4310
nameT2 overview
pagePin1
Overview of Instrumenting RDKB components with T2 shared library (commonlib) APIs:

Image Added

T2.0 Common Library

•APIs for component metrics and events
t2_event_s(char*eventName, char* value)
t2_event_d(char*eventName, int value)
t2_event_f(char*eventName, double value)
TR-181 DataModel 
S.NODataModel DescriptionDataType
1Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.Telemetry.EnableEnable the T2 ProcessBoolean
2Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.Telemetry.Version
‘2.0’ : Operates only with legacy support
‘2.0.1’ : Operates with T2 report profile and legacy support
String
3Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.Telemetry.ConfigURLhttps://xconf.xcal.tv/loguploader/getT2SettingsString
T2 Report Profile
S.NODataModel
TR-181 DataModel 
S.NODataModel 
DescriptionDataType
1Device
.DeviceInfo
.X_RDKCENTRAL-COM_
RFC.Feature.Telemetry.EnableEnable the T2 ProcessBoolean
T2.ReportProfilesValue must be a JSON configuration blobString
2Device
.DeviceInfo
.X_RDKCENTRAL-COM_
RFC.Feature.Telemetry.Version
‘2.0’ : Operates only with legacy support
‘2.0.1’ : Operates with T2 report profile and legacy support
String3Device.DeviceInfo.X_RDKCENTRAL-COM_RFC.Feature.Telemetry.ConfigURLhttps://xconf.xcal.tv/loguploader/getT2SettingsString
T2 Report Profile
...
T2.ReportProfilesMsgPackValue must be a JSON configuration blob in base 64 encoded msgpack formatString
Types of Markers
The markers are of 3 types .
1.Split based markers. 
2. Count based markers
3. TR-181 based markers.
Marker Type
Sample configuration from xconf
Description with respect to sample configuration
Count based markers 
{"header":"RF_ERROR_IPV4PingFailed","content":"Ping to IPv4 Gateway Address are failed","type":"SelfHeal.txt.0","pollingFrequency":"0"}
Expects the occurrence count of content "Ping to IPv4 Gateway Address are failed"
Split based markers
{"header":"bootuptime_ClientConnectComplete_split","content":"Client_Connect_complete:
Types of Markers
The markers are of 3 types .
1.Split based markers. 
2. Count based markers
3. TR-181 based markers.
Marker Type
Sample configuration from xconf
Description with respect to sample configuration
Count based markers 
{"header":"RF_ERROR_IPV4PingFailed","content":"Ping to IPv4 Gateway Address are failed","type":"SelfHealLM.txt.0log","pollingFrequency":"0"}
Expects the occurrence count of content "Ping to IPv4 Gateway Address are failed"
Split based markers
{"header":"bootuptime_ClientConnectComplete_split","content":"Client_Connect_complete:","type":"LM.txt.log","pollingFrequency":"0"}
Expects the value after content "Client_Connect_complete:"
value after content "Client_Connect_complete:"
TR-181 based markers{"header" : "CMMAC_split","content" : "Device.DeviceInfo.X_COMCAST-COM_CM_MAC","type" : "<message_bus>","pollingFrequency":"48"}Markers whose type is configured as "<message_bus>"
...
{"header":"bootuptime_ClientConnectComplete_split","content":"ccsp-lm-lite","type":<event>","pollingFrequency":"0"}

Find the correct place to report a marker .
           Previously  in DCA telemetry, a marker is reported based on the xconf configured "content" string -  when the content string is found in corresponding configured filename configured under 'type:' section . 
           /* Refer :  {"header": "WIFI_INFO_Hotspot_client_connected", "content": "Added case, Client with:", "type": "Hotspotlog.txt.0","pollingFrequency":"0"} */
    • So, find the right place where the content string is being written to the corresponding log file in order to event a marker in T2.0.  
                                  In https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/hotspot/+/35833/3/source/hotspotfd/cosa_hotspot_dml.c (Line number 85 gives the idea)
                                   CcspTraceInfo(("Added case, Client with MAC:%s will be added\n", l_cMacAddr));
    • Once the place is decided, use the right API to report Marker and values.  
      • For markers without "_split" 
...
Example:  t2_event_d("WIFI_INFO_Hotspot_client_connected", 1); in https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/hotspot/+/35833/3/source/hotspotfd/cosa_hotspot_dml.c
  • For markers with "_split" suffix, the marker data is important, so use the API most appropriate to the marker data.  For instance, if the marker data is a string, use t2_event_s.  But if marker data is numeric, use one of t2_event_d or t2_event_f.  Also note that testing must ensure the string used for marker data matches the string expected by legacy telemetry.
...
      • suffix, the marker data is just a count of the number of times the marker is received.  In this case, the t2_event_d API can be used because the marker data passed to the API is not important.
Example:  t2_event_d("WIFI_INFO_Hotspot_client_connected", 1); in https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/hotspot/+/35833/3/source/hotspotfd/cosa_hotspot_dml.c
  • For markers with "_split" suffix, the marker data is important, so use the API most appropriate to the marker data.  For instance, if the marker data is a string, use t2_event_s.  But if marker data is numeric, use one of t2_event_d or t2_event_f.  Also note that testing must ensure the string used for marker data matches the string expected by legacy telemetry.
Example : t2_event_s("acs_split", pStr); in https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/CcspTr069Pa/+/35825/4/source-embedded/DslhManagementServer/ccsp_management_server_pa_api.c line 585

Use appropriate APIs to event markers and values.
           In RDKB we have logs coming from both scripts and component's code (code in C). From which markers are reported/grepped.
List of APIs :
    • To report markers from components 
      • t2_event_s(char* marker, char* value)                           - To send _split marker with string value to T2
 Usage: t2_event_s("xh_mac_3_split", "xh_MAC_value”);
             t2_event_s("xh_mac_3_split", strBuff); /* where strBuff contains the string value to be reported for this marker */
Sample Reviews: 
https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/CcspWifiAgent/+/30422/1/source/TR-181/sbapi/wifi_monitor.c where telemetryBuff is a an array of characters declared, reset and copied with string value to be reported.
https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/CcspTr069Pa/+/35825/4/source-embedded/DslhManagementServer/ccsp_management_server_pa_api.c where pStr is a buffer already used in the code.
NOTE: The instrumented component could use a static buffer or do a buffer malloc itself; but T2 common lib makes its own copy regardless, so instrumented component must clean up after itself.
      • t2_event_f(char* marker, double value)                           - To send marker with double value to T2
                  Usage: t2_event_d("HWREV_split", 2.2);


Must Check Notes
         1.While instrumenting components         
  2. While instrumenting  Scripts                    
       Source the utility script /lib/rdk/t2Shared_api.sh  
Invoke :
t2ValNotify "Marker" "Value"                 - To report split based markers
t2CountNotify  "Marker"                        - To report count based markers.

 Example: Refer https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/
...
sysint/+/
...
38359/
...
8/uploadRDKBLogs.sh
         
T2 Report Profiles
                        A Telemetry 2.0 Report Profile is a configuration, authored in JSON, that can be sent to any RDK device which supports Telemetry 2.0. A Report Profile contains properties that are interpreted by the CPE in order to generate and upload a telemetry report. These properties define the details of a generated report, including:
...