Problem description
Developers usually use the log component to print necessary information on the console to help troubleshoot problems during the development process.
After an app is delivered to users, developers can record logs through the diagnostic log API provided by mPaaS client SDK and then pull diagnostic logs from the console. However, developers may fail to pull diagnostic logs due to improper access or usage.
Reproduction
Log on to the console, choose Products and Services > Mobile PaaS > Mobile Analysis Service > Log management > Pull real-time logs, and click Add to open the diagnostic task adding page. On the page that appears, enter the information of the diagnostic task.
Click OK to create the diagnostic task. Then click Trigger Push/Sync to trigger the diagnostic task. After the task is successfully delivered, the task status on the page is updated.
After the client receives the diagnostic task, it uploads the logs to the server. The task status changes to Task successfully processed. You can click View to open the sub-task status page, or click Download to download the logs.
Result analysis
The task statuses include:
Initialization completed
Calling Sync service succeeded (iOS, only calling Sync service, not sending to the client)
Calling Push service succeeded (Android, only calling Push service, not sending to the client)
Calling Sync service failed (iOS)
Calling Push service failed (Android)
Task successfully processed
Task failed
Partial tasks failed
The sub-task statuses are:
Expired or permission restricted
Completed
Normally, you can successfully pull diagnostic logs after you perform the previous steps. The task status is "Task successfully processed" and the sub-task status is "Completed". When an exception occurs, the most common situation is that the task status is "Completed" and the sub-task status is "Expired or permission restricted". The possible causes of pull failure include (but are not limited to):
Diagnostic logs expired or have been removed from the client.
The client has no write permission and therefore failed to generate local logs.
The client failed to generate logs due to other causes.
Troubleshooting
Check whether MSS is successfully registered
On the iOS platform, log pulling depends on the MSS service. Therefore, you must check whether the MSS service is running properly on the client. You can observe the output of Sync logs on the console. The following provides two log output examples for MSS connected and MSS disconnected, respectively.
If the MSS service fails to run properly, you must troubleshoot the MSS connection problem first.
MSS connected
2020-03-25 11:19:33.873603+0800 Demo[24958:6621533] [Sync] start sync ssl:cn-hangzhou-mss-link.cloud.alipay.com,settings:{
2020-03-25 11:19:33.873873+0800 Demo[24958:6621533] [Sync] LL socket connect SUCESS!MSS disconnected (the problem in the following example is caused by network error)
2020-03-25 11:16:53.624467+0800 Demo[24452:6612201] [Sync] LL connectToHost=cn-hangzhou-mss-link.cloud.alipay.com port:443
2020-03-25 11:16:53.627994+0800 Demo[24452:6612201] [Sync] LL onSocket:willDisconnectWithError:err Error Domain=NSPOSIXErrorDomain Code=50 "Network is down"Check whether local logs are written to the sandbox
We recommend that you perform this step when the network is disconnected.
Check that the codes contain the action of writing local logs. Then open the sandbox path Library/file/<date>/11.2nd of the app and check whether a file exists under the path, as shown in the following figure.
Check whether the creation time and modification time of the file are consistent with the testing time.
If no log file is found in the sandbox, check the access procedure of the diagnostic component on the client. If you fail to resolve the problem, please prepare a project that can reproduce the problem, and search for the group number 31591197 with DingTalk to join DingTalk group for help.
Check whether the pull instruction reaches the client
After you trigger a Sync action on the mPaaS console to pull logs, observe the output of the client on the console and check whether MSS receives the instruction. For example:
If MSS fails to receive the instruction, check the network tracing and make sure that the user ID is correct. If the problem persists, please prepare a project that can reproduce the problem, and search for the group number 31591197 with DingTalk to join DingTalk group for help.