Introduction<\/span><\/h2>\n\n\nLogging and Log Upload are critical aspects when considering large-scale RDK deployment. CPE<\/span>s have a space constraint to store device logs for future use so either we store them for a limited number of days in CPE or in cloud servers.<\/span><\/span><\/span><\/p>\nLogs play a crucial role in RDK deployments by providing data for deriving field matrices and assessing the criticality of situations, such as determining whether an issue needs immediate attention or can wait until the next day. Controlled log uploads, ranging from 100% to very small numbers (2-3%) based on device maturity, help manage the volume of data. Configurable upload intervals, typically set to once a day, and the right level of abstraction ensure a balance between available storage space and the logs generated. Additionally, rotate-backup-upload policies are implemented to maintain efficient log management. <\/span><\/span>Log Upload uses XConf as the primary endpoint, allowing the configuration to enable or disable log upload for a device or group of devices. During bootup, the CPE retrieves configuration information from XConf, and based on rules defined in the XConf server, it can control whether a particular device needs to perform log uploads. This setup allows for the sampling of devices from a larger population. The configuration server is responsible for retrieving and delivering settings to any client, and it supports configurable upload methods such as HTTPS, HTTP, and TFTP.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\nArchitecture<\/h2>\n\n\n
RDK Log Upload Mechanism<\/strong><\/p>\n\n<\/div>\n![\"Log_Upload\"](\"https:\/\/developer.rdkcentral.com\/documentation\/wp-content\/uploads\/sites\/16\/2024\/10\/Log_Upload.png\" "\\"Log_Upload\\"")
<\/div>\n<\/div>\nLog uploader scripts are responsible for gathering local logs, packaging them, and uploading them to a remote URL. A client-side scheduler would control when it executes, but it could also be activated via immediate triggers from the log upload checker or other local actions.<\/p>\n
The Uploader is responsible for sending CPE log files to a remote file store. It performs the following:<\/p>\n
\n- Responds to triggers (i.e. from cron)<\/span><\/li>\n
- Checks local Device Settings for the URL of the file store, the logs it should send, and the repository it should use<\/span><\/li>\n
- Gets connection credentials<\/span><\/li>\n
- Makes a connection to the remote server and sends the files<\/span><\/li>\n<\/ul>\n
How CPEs Upload Logs and Metrics<\/span><\/h3>\nCPEs check with XConf for their logging and telemetry configuration through a query. Part of their query string includes several (about four) parameters of this particular CPE, such as the MAC address, model, current firmware version, and environment. The XConf server looks at these parameters and runs them through a rules engine that finds the closest targeting rule match to the CPE’s profile. Once it finds a match, it retrieves the configuration for that rule. The configuration includes things like an upload schedule, repository URL, upload protocol, path to the file server, protocol indicator, upload time smear, and more. Once the CPE gets the response, it parses it and sets the specified random schedule that delays uploading the files. At that time, the CPE packages up all of its log files, compresses the bundle and uploads the archive to the destination.<\/span><\/p>\nThe DCM service, which can be checked using the command $systemctl status dcm-log<\/strong>, is responsible for log upload in CPE. This service runs as a system service and invokes \/lib\/rdk\/StartDCM.sh<\/strong> on start-up. The StartDCM.sh script internally calls \/lib\/rdk\/DCMscript.sh<\/strong> for log upload. Once the logs are prepared, the script \/lib\/rdk\/uploadSTBLogs.sh<\/strong> takes over the actual uploading task. To monitor the log upload process, you can use the command $tail -f \/opt\/logs\/dcmscript.og.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
Logs play a crucial role in RDK deployments by providing data for deriving field matrices and assessing the criticality of situations, such as determining whether an issue needs immediate attention or can wait until the next day. Controlled log uploads, ranging from 100% to very small numbers (2-3%) based on device maturity, help manage the volume of data. Configurable upload intervals, typically set to once a day, and the right level of abstraction ensure a balance between available storage space and the logs generated. Additionally, rotate-backup-upload policies are implemented to maintain efficient log management. <\/span><\/span>Log Upload uses XConf as the primary endpoint, allowing the configuration to enable or disable log upload for a device or group of devices. During bootup, the CPE retrieves configuration information from XConf, and based on rules defined in the XConf server, it can control whether a particular device needs to perform log uploads. This setup allows for the sampling of devices from a larger population. The configuration server is responsible for retrieving and delivering settings to any client, and it supports configurable upload methods such as HTTPS, HTTP, and TFTP.<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n RDK Log Upload Mechanism<\/strong><\/p>\n Log uploader scripts are responsible for gathering local logs, packaging them, and uploading them to a remote URL. A client-side scheduler would control when it executes, but it could also be activated via immediate triggers from the log upload checker or other local actions.<\/p>\n The Uploader is responsible for sending CPE log files to a remote file store. It performs the following:<\/p>\n CPEs check with XConf for their logging and telemetry configuration through a query. Part of their query string includes several (about four) parameters of this particular CPE, such as the MAC address, model, current firmware version, and environment. The XConf server looks at these parameters and runs them through a rules engine that finds the closest targeting rule match to the CPE’s profile. Once it finds a match, it retrieves the configuration for that rule. The configuration includes things like an upload schedule, repository URL, upload protocol, path to the file server, protocol indicator, upload time smear, and more. Once the CPE gets the response, it parses it and sets the specified random schedule that delays uploading the files. At that time, the CPE packages up all of its log files, compresses the bundle and uploads the archive to the destination.<\/span><\/p>\n The DCM service, which can be checked using the command $systemctl status dcm-log<\/strong>, is responsible for log upload in CPE. This service runs as a system service and invokes \/lib\/rdk\/StartDCM.sh<\/strong> on start-up. The StartDCM.sh script internally calls \/lib\/rdk\/DCMscript.sh<\/strong> for log upload. Once the logs are prepared, the script \/lib\/rdk\/uploadSTBLogs.sh<\/strong> takes over the actual uploading task. To monitor the log upload process, you can use the command $tail -f \/opt\/logs\/dcmscript.og.<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n<\/div>\n<\/div>\nArchitecture<\/h2>\n\n\n
<\/div>\n<\/div>\n\n
How CPEs Upload Logs and Metrics<\/span><\/h3>\n