A method and system for edge-cloud collaborative log management in smart wearable devices

Abstract

This invention discloses a log management method and system for cloud-edge collaboration in smart wearable devices, belonging to the field of log management technology. The method includes: sending a log configuration request to the cloud; receiving a corresponding preset log level issued by the cloud according to a preset policy; synchronizing the preset log level to the smart wearable device; writing cached logs and normal logs; generating a unique link tracing identifier each time a business link starts, injecting the link tracing identifier into all network request headers and local logs, and synchronizing it to the smart wearable device; when a log feedback event is triggered, collecting local normal logs and cached logs and requesting the corresponding time period's smart wearable device logs from the smart wearable device; compressing the collected logs into log packets, uploading them to the storage terminal, and obtaining the log packet access address; and submitting a feedback request to the cloud. This invention can balance device resource consumption and problem location efficiency during log writing.

Description

Technical Field

[0001] This invention belongs to the field of log management technology, and in particular relates to a log management method and system for end-to-end cloud collaboration in smart wearable devices. Background Technology

[0002] With the rapid development of smart wearable technology, multi-terminal collaborative wearable devices, represented by smart glasses, have been widely used in consumer electronics, industrial inspection, and medical assistance. These devices typically employ a three-tier architecture: smart wearable hardware, a mobile control app, and cloud services. The wearable hardware is responsible for data collection and basic interaction, the mobile app handles business control, data transfer, and network communication, and the cloud provides AI computing, data storage, and service support. Because business processes span multiple terminals, failures can occur at any stage—the wearable hardware, the app, the Bluetooth communication link, network transmission, or the cloud services—posing significant challenges to log collection and problem localization.

[0003] Log level control is the most important technical means to balance device resource consumption and problem localization efficiency. Traditional logging solutions usually use a fixed log level. If high-level logging is enabled for a long time, it will significantly increase the CPU usage, storage consumption and battery consumption of wearable devices; if low-level logging is maintained, it is impossible to record the detailed context when the fault occurs, making it difficult to locate the problem.

[0004] Chinese invention patent with publication number CN122050008A discloses a method for actively modifying log levels. This solution is applied to an in-vehicle cloud system and includes: the cloud sending a log level adjustment instruction to the in-vehicle terminal, the in-vehicle terminal temporarily increasing the log granularity, guiding the user to reproduce the fault and upload the log, and automatically restoring the log level to the default value after the alarm is recovered.

[0005] This existing technology enables closed-loop cloud-based management of log levels, which to some extent resolves the contradiction between high resource consumption and insufficient location information associated with fixed log levels, providing a basic approach for dynamic log management.

[0006] However, this solution only raises the log level after a user triggers feedback, and can only record the reproduction process after feedback, unable to trace back the key operations and system state before the failure occurred. Since failures of smart wearable devices are mostly intermittent, users often cannot accurately reproduce them, resulting in many failures remaining untraceable due to a lack of context. Summary of the Invention

[0007] The purpose of this invention is to provide a log management method and system for smart wearable devices with end-to-cloud collaboration, which partially solves or alleviates the above-mentioned shortcomings in the prior art and can balance the consumption of device resources and the efficiency of problem location during the log writing process.

[0008] To solve the aforementioned technical problems, the present invention specifically adopts the following technical solution: A first aspect of the present invention is to provide a log management method for end-to-end cloud collaboration in smart wearable devices, comprising the following steps: The App sends a log configuration request to the cloud, receives the corresponding preset log level issued by the cloud according to the preset policy, and synchronizes the preset log level to the smart wearable device. The app writes all logs from the most recent preset time window to the cached log path as cached logs; and filters the logs according to the preset log level before writing them to the normal log path as normal logs. The App generates a unique link tracing identifier each time a business link is started, injects the link tracing identifier into all network request headers and local logs, and synchronizes it to the smart wearable device so that the logs on the smart wearable device carry the same link tracing identifier. When a log feedback event is triggered, the App collects local routine logs, cached logs, and crash logs generated when the system crashes; and requests the corresponding time period logs from the smart wearable device. The App merges and compresses the collected logs with the corresponding link tracing identifiers and metadata into a log package, uploads it to the storage terminal, and obtains the log package access address; The app submits a feedback request to the cloud, which includes the log packet access address, the link tracing identifier, and metadata. If the submission is successful, the temporary files generated by this feedback are cleaned up.

[0009] Furthermore, the preset strategy for distributing preset log levels in the cloud includes distributing logs based on at least one of the following: user identifier, smart wearable device model, App version, firmware version, application channel, or problem location requirements.

[0010] Furthermore, the business link includes at least one of AI dialogue request, automatic speech recognition (ASR) request, text-to-speech (TTS) request, translation request, and photo translation request; the link tracing identifier is written into the structured log file along with the log level, timestamp, module name, and extended fields when the log is output.

[0011] Furthermore, the log feedback events include user-initiated feedback events and automatic background exception feedback events; The triggering process for the user-initiated feedback event is that the user enters the feedback portal within the App and submits a problem description; The triggering conditions for the background abnormal automatic feedback event include at least one of the following: App crash, AI service abnormality, ASR / TTS link disconnection, cache abnormality reaching a preset threshold, device disconnection abnormality, and firmware upgrade failure.

[0012] Furthermore, if the log feedback event is a user-initiated feedback event, perform the following steps: Receive temporary log configurations from the cloud and set the current log level to a more detailed log level to collect logs of the user's operation process when reproducing the problem; After successfully submitting the feedback request, the log level will be restored to the preset log level.

[0013] Furthermore, if the log feedback event is a user-initiated feedback event, the following steps are also performed: Determine if the network is available; if not, display a network error message. Check if the description is empty; if it is empty, prompt the user to provide a more detailed description of the problem. Determine if there is enough remaining storage space; if not, display a message indicating insufficient storage space. If the system has floating window permission, a feedback floating window will be displayed; users can submit logs through the floating window after reproducing the problem; if the system does not have floating window permission, users will be guided to authorize it, or the submission method will remain the bottom pop-up.

[0014] Furthermore, if the log feedback event is an automatic background exception feedback event, perform the following steps: Using atomic variables as global commit locks, if a background commit task is already being executed, the current commit is skipped; Check if the network is available; if there is no network connection, retain the original log and wait for the next trigger. Verify the network type. If it is a cellular network, check the total number of cellular network log uploads for the day. If it exceeds the preset limit, skip this submission. Check if there is enough remaining storage space; if not, skip this commit. Check if the target log directory exists and is not empty; if it is empty, terminate the commit. After the log compression is complete, the size of the compressed package is checked. If it will cause the daily upload limit to be exceeded, the temporary compressed package is deleted and the original log is retained. After successful upload, the cloud feedback interface is invoked, and the upload size for the day is accumulated. If the upload or submission fails, release the submission lock and retain the original logs according to the exception type for subsequent retries.

[0015] Furthermore, when it is detected that the smart wearable device does not support log levels, the App will mark the current smart wearable device as an older version compatibility mode; When it is detected that the smart wearable device does not support log transmission, the App only collects local log files and marks the current smart wearable device as not supporting log transmission in the metadata of the feedback request. The cloud identifies the reason for the missing logs based on this mark.

[0016] Furthermore, the rules for cleaning up temporary files include: deleting the temporary log compressed package generated in this feedback; if it is an automatic feedback from the background and the submission is successful, then deleting the submitted crash log and the corresponding cached log; The app periodically performs local log cleanup, cleans up cached logs according to a preset short retention period, and cleans up normal logs according to a preset retention period and total storage size limit.

[0017] This invention also provides a cloud-based collaborative log management system for smart wearable devices, comprising an App installed on a smart device, a smart wearable device, and a cloud, wherein the App is configured with: The log configuration request module is used to send log configuration requests to the cloud, receive the corresponding preset log level issued by the cloud according to the preset policy, and synchronize the preset log level to the smart wearable device. The log writing module is used to write the full logs of the most recent preset time window to the cached log path as cached logs; and to filter the logs according to the preset log level and write them to the normal log path as normal logs. The Link Trace Identifier Management Module is used to generate a unique Link Trace Identifier each time a business link is started, inject the Link Trace Identifier into all network request headers and local logs, and synchronize it to the smart wearable device so that the logs on the smart wearable device carry the same Link Trace Identifier. The log collection module is used to collect local normal logs, cached logs, and crash logs generated when the system crashes when a log feedback event is triggered; and to request the corresponding time period of the smart wearable device's logs. The upload module is used to merge and compress the collected logs with the corresponding link tracing identifiers and metadata into a log package, upload it to the storage terminal, and obtain the log package access address; The feedback request submission module is used to submit feedback requests to the cloud. The feedback request includes the log packet access address, the link tracing identifier, and metadata. If the submission is successful, the temporary files generated by this feedback are cleaned up.

[0018] Beneficial effects:

[0019] This invention distinguishes between two storage paths: normal logs and cached logs. Normal logs rely on log filtering thresholds to select data for storage, filtering redundant detailed logs during daily operation to reduce long-term disk read / write overhead and storage space occupation. Cached logs are not constrained by level rules, retaining all operational data for short periods, balancing resource and power consumption control during daily device use with contextual tracing needs in case of sudden failures. This overcomes the shortcomings of traditional logs, which either store all data, consuming resources, or store only a few details, missing fault information. Simultaneously, log filtering specifications are synchronized across supported protocols, maintaining consistent log granularity across multiple terminals. For older firmware devices, a compatibility management mode is enabled, allowing independent control of log levels only on the App side, achieving full device compatibility.

[0020] A unique link tracing identifier is generated when a single business link is initiated. This identifier is automatically injected into various local logs and all network request headers in the App, and can also be simultaneously distributed to the bound smart wearable device, ensuring that business logs from the same source on the wearable device carry the same identifier. During subsequent troubleshooting, a single identifier can be used to connect all related logs from the App, smart hardware, and cloud services, breaking the problem of isolated and scattered log data from multiple terminals, significantly reducing the time required for fault location, and improving the efficiency of problem analysis.

[0021] For scenarios where users proactively provide feedback, the system performs multi-dimensional verification of network, input content, and storage space beforehand, and temporarily increases the granularity of log recording. It also offers two submission interaction methods: a floating window or a bottom pop-up, guiding users to reproduce the problem and submit logs conveniently. For automatic background feedback triggered by system crashes, link anomalies, etc., the system executes silently without pop-ups disturbing the user. It uses atomic variables to set a global commit lock to avoid conflicts in concurrent uploads from multiple tasks. It distinguishes between the two feedback modes at the interaction level, which not only facilitates users to report problems independently, but also automatically captures hidden system anomalies without the user's awareness.

[0022] The automatic upload process in the background incorporates multiple rounds of verification logic. It checks network connectivity, network type, the cumulative upload volume of mobile networks for the day, and the device's remaining storage space. After log compression, it verifies the size of the compressed package again. If continuing to upload would trigger a daily data limit violation, the original logs are retained, the temporary compressed package is deleted, and the upload is retried after connecting to a non-billed network or after the data limit is reset the following day. This multi-layered verification avoids the problem of bulk log uploads consuming users' mobile data from the source. The original log retention design prevents the loss of faulty data, striking a balance between data protection and faulty data retention.

[0023] The collected multi-terminal logs, along with device metadata, link information, and user problem descriptions, are uniformly packaged into a standard compressed file. This file is first uploaded to object storage to obtain resource access addresses and storage indexes, and then the metadata and storage information are submitted to the cloud through the business interface. This architecture separates large-capacity log files from business interface requests, avoiding the consumption of business interface transmission resources by large-volume binary data. It also leverages the transmission capabilities of object storage to improve the upload success rate in weak network environments. The cloud can quickly retrieve log packets using the storage index, and the structured metadata facilitates automatic classification, retrieval, and feedback of work orders by the cloud system, optimizing cloud data governance efficiency.

[0024] After successful log upload and cloud interface submission, promptly clean up all temporary files generated by the feedback and update the daily traffic statistics to free up device storage space. In the event of upload failure or interface submission anomaly, immediately release the global submission lock to prevent lock resources from lingering and blocking subsequent feedback tasks. Then, retain the original logs differently based on the cause of the anomaly, and automatically retry the submission when the subsequent environmental conditions are met. This effectively avoids permanent loss of log data due to anomalies and improves the stability and fault tolerance of the entire log feedback system. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. The elements or parts in the drawings are not necessarily drawn to scale. Obviously, the drawings described below are some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0026] Figure 1 This is a flowchart of the present invention; Figure 2 This is a schematic diagram of the structural principle of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0028] Definition of the noun: Smart glasses: Wearable devices with functions such as Bluetooth communication, voice interaction, shooting, recording, translation, and navigation.

[0029] App: An application installed on a mobile phone to connect to and control smart glasses.

[0030] Cloud: A server system used to receive logs, issue log levels, record user feedback, and assist in problem localization.

[0031] Log levels: Used to control the level of detail in log output, such as VERBOSE, DEBUG, INFO, WARN, ERROR.

[0032] TraceId: A tracing identifier in a business request or fault feedback chain, used to associate App, network request, AI service, and cloud records.

[0033] Cached logs: Temporary logs that retain highly detailed logs from the recent past period, used to capture the context before and after a failure occurs.

[0034] Regular log: A regular operation log that is written continuously according to the current log level.

[0035] OSS: Object Storage Service, used for uploading and saving compressed log files.

[0036] ACK: Acknowledgment message, used to indicate that the glasses or cloud have received the result of a file or log transmission.

[0037] Example 1:

[0038] like Figure 1 As shown, this embodiment uses smart glasses as an example to elaborate on the log management method for edge-cloud collaboration in smart wearable devices. It is understood that this method is also applicable to other smart wearable devices such as smart bracelets and smart rings, and its specific steps include: S1. The App sends a log configuration request to the cloud, receives the corresponding preset log level issued by the cloud according to the preset policy, and synchronizes the preset log level to the smart wearable device.

[0039] The cloud serves as the decision-making center for log levels, generating differentiated log level configurations based on dimensions such as user identifier, smart wearable device model, App version, firmware version, application channel, or problem localization requirements, thereby achieving refined hierarchical management.

[0040] In this embodiment, the log levels, from low to high, include five levels: VERBOSE, DEBUG, INFO, WARN, and ERROR.

[0041] Among them, VERBOSE is the most detailed, being the lowest-level execution detail log, used for in-depth debugging during the development phase. DEBUG is the debug level, a business process-level debug log, used to reconstruct the complete business execution path. INFO is the information level, a critical business milestone log, used to record core events for normal system operation. WARN is the warning level, a non-fatal exception log, recording potential risks that do not affect the main process but may cause subsequent problems. ERROR is the error level, a fatal exception log, recording serious errors that cause functionality to become unavailable or the program to crash.

[0042] The output volume of log levels varies exponentially. For example, the log volume of the VERBOSE level is dozens of times that of the WARN level. If all logs are stored, it will consume a huge amount of storage space. Therefore, it is necessary to formulate a log level storage strategy.

[0043] For example, for users who have reported difficult issues, a temporary DEBUG level is issued for 24-72 hours; for internal testers, a long-term DEBUG level is issued. For new, high-performance smart glasses, a temporary upgrade to the VERBOSE level is allowed; for older, lower-spec models, the highest level is limited to INFO. Newly released beta apps are upgraded to INFO level overall; for official apps, the default level is WARN. For newly pushed firmware versions, all users upgrading are temporarily upgraded to INFO level, with stability monitored for 7 days. For internal testing channels, the default level is DEBUG; for public app store channels, the default level is WARN. Additionally, engineers can manually push DEBUG / VERBOSE levels to specific devices in the background, remotely collecting logs without user intervention.

[0044] In this embodiment, the App initializes the log module after startup. The log module configuration items include: master log switch, file log switch, current file log level filtering threshold, cached log path and normal log path, maximum size of a single log file, log retention days and total storage size limit, JSON format output switch, global module name, TraceId and extended fields, etc.

[0045] The current file log level filtering threshold is determined based on the preset log level issued by the cloud. For example, if the preset log level is WARN, then logs at or above the WARN level and logs below the WARN level will be treated differently in subsequent operations.

[0046] When the app successfully connects to the smart glasses, it determines whether the glasses firmware supports the log level control protocol. If it does, the app sends the log level to the glasses via Bluetooth, allowing the glasses to synchronously switch the log detail level. If it does not support the protocol, the app maintains local log level control and marks the current device as an older version compatibility mode.

[0047] Specifically, for smart glasses that support log level control protocols, the app will synchronize the currently effective log level configuration to the glasses, ensuring that both ends output logs with the same level of detail, forming a complete cross-end fault evidence chain. For example, when the local filtering threshold is WARN, it is sent to the glasses via Bluetooth. The glasses will immediately update their own log filtering threshold, and all newly generated logs will be filtered and written according to the new level. After the update is complete, the glasses will return an ACK confirmation message to the app, indicating successful synchronization.

[0048] Whenever the local filtering threshold changes, the app immediately synchronizes the new level to the glasses, ensuring that the levels on both devices remain consistent. For example, when a user submits feedback about a problem, the app lowers the local filtering threshold from WARN to DEBUG and simultaneously sends the same level setting command to the glasses. The glasses then switch to the DEBUG level and record detailed logs of the user's process of reproducing the problem.

[0049] For older smart glasses firmware versions that do not support the log level control protocol, the app will not forcibly send any log level control commands. Instead, it will enter the old version compatibility mode to ensure that the feedback process can be executed normally and will not be interrupted due to the device not supporting the new protocol.

[0050] In compatibility mode, the app maintains independent control over the local log level and does not attempt to send any level synchronization commands to the glasses. Simultaneously, the app adds a clear marker to the local metadata and includes this marker in all subsequent feedback requests. Upon receiving this marker, the cloud automatically recognizes that the device does not support log level synchronization.

[0051] The log collection and feedback process in compatibility mode works perfectly. The app still collects local routine logs, cached logs, and crash logs, and also attempts to collect the default level logs from the glasses. Although older versions of the glasses cannot dynamically adjust the log level and can only output the default level logs preset by the firmware, these logs can still provide basic device operating status information and are still of great value for troubleshooting most common faults.

[0052] S2. The App writes the full logs of the most recent preset time window to the cached log path as cached logs; and filters the logs according to the preset log level before writing them to the normal log path as normal logs.

[0053] In this embodiment, the log module writes logs in two paths: one is the normal log path, which writes logs filtered according to log level thresholds; the other is the cached log path, which writes all logs within the most recent preset time window.

[0054] Cached logs are used to capture fault context, solving the problem of traditional logging schemes only recording detailed logs after a fault occurs, leading to a lack of context. They are fully written and retained for short periods, are not limited by any log level filtering thresholds, and always record all logs generated by the system within the most recent time period.

[0055] The preset time window is a control parameter for cached logs. This solution defaults to 3 minutes, which covers the entire process from triggering to manifesting most intermittent faults without excessively consuming device memory and storage resources. The cached logs operate using a sliding time window instead of a fixed time window. This means the system always retains only logs from the current moment backwards for 3 minutes. Each new log entry automatically removes the oldest entry outside the window, and the window continuously scrolls for 3 minutes. This ensures that regardless of when a fault occurs, the cached logs completely retain all execution details from the 3 minutes before the fault occurred to the instant immediately afterward, preventing log gaps.

[0056] Full logs refer to all levels of logs generated by the system, from the most detailed VERBOSE-level low-level execution logs to the most severe ERROR-level crash logs. All of these are written to the cached log path, completely unaffected by the current file log level filtering threshold. Even if the default filtering threshold for the official app is WARN, and normal logs only record warnings and errors, the cached logs will still silently retain all VERBOSE, DEBUG, and INFO-level low-level logs, including details of Bluetooth packet transmission and reception, function call parameters and return values, raw sensor sampling data, and complete network request header information. This information may seem useless during daily operation, but it is often crucial evidence for locating the root cause during troubleshooting.

[0057] To balance read / write performance and data reliability, the cached logs employ a storage architecture prioritizing memory queues and using file caching as a fallback. After logs are generated, they are first written to a fixed-size circular memory queue, the capacity of which corresponds to the log volume within a 3-minute time window. Read and write operations are completed entirely in memory, resulting in extremely high speed and no disk I / O overhead, thus not impacting the performance of the app or smart glasses. Simultaneously, the system starts a low-priority background thread to asynchronously write the logs from the memory queue to a file in the local cached log path, serving as a persistent backup of the memory queue. This ensures both the real-time nature and high performance of the cached logs while mitigating the issue of data loss in the memory queue during app crashes. The crash detection module forces all logs in the memory queue that have not yet been flushed to disk to be written to disk before process termination, ensuring that the last log entry before the crash is completely preserved.

[0058] Because cached logs only retain short-term data, their cleanup mechanism is very lightweight and efficient. The memory queue automatically removes old data through a sliding window, eliminating the need for additional cleanup threads. File caching employs a cleanup strategy that combines time-based retention with total size limits. By default, it retains cached log files from the most recent hour, with a total size not exceeding 10MB. When this limit is exceeded, the oldest files are automatically deleted, consuming almost no system resources while ensuring that cached logs do not excessively occupy device storage space.

[0059] The routine log is used to record the system's operational status and is the main log path of the logging system. It is used to record key events and abnormal information during the system's operation over a long period of time. It is written strictly according to preset log level filtering thresholds to minimize resource consumption during long-term operation.

[0060] The writing of normal log entries is controlled by the current file's log level filtering threshold. Each log entry generated is first verified by the level filter. Only log entries with a level value greater than or equal to the filtering threshold are eligible for normal log writing; log entries below the threshold are discarded without consuming any disk space. For example, when the filtering threshold is set to WARN, only WARN and ERROR level logs are written to the normal log; VERBOSE, DEBUG, and INFO level logs are all filtered and discarded. When the filtering threshold is temporarily lowered to DEBUG, all log entries with a level greater than or equal to DEBUG are written.

[0061] To further reduce disk I / O overhead and battery consumption, normal logs are written asynchronously in batches. Logs that meet the filtering criteria are not written to disk immediately, but instead enter a fixed-size write buffer. When the buffer is full or a preset refresh interval is reached, all logs in the buffer are written to the disk file at once, which significantly reduces the number of disk I / O operations. For smart glasses with limited battery capacity, this can effectively extend battery life.

[0062] Meanwhile, the routine log uses a file rotation mechanism. When the size of a single routine log file reaches the preset maximum value, the system will automatically close the current file and generate a new log file.

[0063] By default, normal logs are retained for 7 days, with a total storage size limit of 100MB. The system automatically performs a cleanup task every day at midnight, first deleting all log files that have exceeded the 7-day retention period; if the total size still exceeds 100MB after deletion, it deletes files in chronological order, starting with the oldest files, until the total size is below the limit.

[0064] During routine operation, the normal log records critical anomalies and milestone events of the system with extremely low resource consumption, while the cached log runs silently in the background, retaining the full context of the most recent 3 minutes. The combination of the two ensures the stable operation of the system and prepares data for sudden failures.

[0065] When a failure occurs, the cached logs immediately provide complete execution details for 3 minutes before and after the failure, including all underlying operations and parameter information; the normal logs provide the system running background for a period of time before the failure, such as whether there are potential risks such as frequent Bluetooth disconnections or network request failures, helping engineers quickly locate the root cause of the failure.

[0066] S3 and the App generate a unique link tracing identifier each time a business link is started. The link tracing identifier is injected into all network request headers and local logs and synchronized to the smart wearable device, so that the logs on the smart wearable device carry the same link tracing identifier.

[0067] In this embodiment, a business chain refers to a complete and independent functional operation initiated by the user, starting from the user's trigger action and ending with the completion of all related device operations, network requests, and cloud service calls. Different business chains are independent of each other, each with a unique link tracing identifier, and will not interfere with each other. Typical business chains include a user initiating an AI voice dialogue, triggering a photo translation, playing a TTS (text-to-speech) audio clip, and performing a firmware upgrade. It should be noted that a business chain may contain multiple network requests and device operations. For example, a complete AI dialogue chain may sequentially include multiple sub-steps such as voice acquisition, ASR (automatic speech recognition) request, semantic understanding request, TTS request, and audio playback. All these sub-steps will share the same link tracing identifier.

[0068] The tracing identifier is a unique string, ensuring no duplicates occur even with a large number of users and requests. It is generated at the very beginning of the business chain, the instant a user triggers an action, such as clicking the microphone button, typing text and clicking send, or pressing the photo translation button. At this point, the app immediately generates a new tracing identifier in the main thread and sets it as the global current tracing identifier for the log module until the current business chain completely ends.

[0069] To avoid confusion in link identifiers, only one active business link identifier can exist at a time. When a new business link starts, it automatically overwrites the identifier of the previous link. All subsequent operations of the previous link will still use the original identifier and will not be affected by the new identifier.

[0070] When the app starts and initializes the logging module, it registers the tracing identifier as a required field for log output. When the logging module outputs each log, it automatically reads the current tracing identifier and writes it as a top-level field into the structured JSON log.

[0071] Specifically, when business code calls the logging interface to output a log entry, the logging module first obtains the current global tracing identifier. Then, it assembles this identifier along with information such as the log level, timestamp, module name, log content, and extended fields into a standard JSON-formatted log object. Finally, it writes the object to the corresponding cached log or regular log path. Even in multi-threaded concurrent scenarios, the logging module ensures that each thread's log correctly carries the corresponding tracing identifier through thread-local variables, preventing identifier misalignment.

[0072] It is important to emphasize that the tracing identifier is injected into both cached logs and normal logs, and is not affected by the log level filtering threshold. In other words, regardless of the current log level, all logs written to disk will carry the corresponding tracing identifier, ensuring that all relevant logs can be accurately linked through the identifier during troubleshooting.

[0073] To transmit the tracing identifier to the cloud service, this embodiment injects the identifier into the header of all network requests sent to the cloud. Upon receiving a request, the cloud service automatically extracts the tracing identifier from the request header and passes it to all subsequent microservices, while also writing it to its own logs. In this way, from the App initiating the request to the cloud gateway, ASR service, semantic understanding service, and TTS service, all logs in the entire cloud-based distributed system will carry the same tracing identifier, forming a complete cloud-based tracing chain.

[0074] Once the app generates a new link tracing identifier, it immediately checks whether the smart glasses are currently connected and whether the glasses support the link tracing synchronization protocol. This protocol support status has already been obtained and cached during the previous firmware capability detection phase, so there is no need to detect it again. If the device supports the protocol, the app will send a link tracing identifier synchronization command to the glasses via Bluetooth. The command includes the current link tracing identifier and the type of service being used.

[0075] Upon receiving the synchronization command, the glasses will immediately set this identifier as the global current identifier in its own logging system. All logs generated by the glasses thereafter, including audio acquisition logs, sensor data logs, Bluetooth communication logs, and hardware operation status logs, will carry this same identifier. When the current service cycle ends, the app will send an identifier clearing command to the glasses again, and the glasses will revert to the default unidentified state.

[0076] S4. When the log feedback event is triggered, the App collects local normal logs, cached logs, and crash logs generated when the system crashes; and requests the corresponding time period logs from the smart wearable device.

[0077] The log collection process is initiated by log feedback events. In this embodiment, the log feedback events include user-initiated feedback events and background automatic feedback events. The user-initiated feedback event is triggered when the user enters the feedback portal in the App and submits a problem description. The background automatic feedback event is triggered under the following conditions: App crash, AI service anomaly, ASR / TTS link disconnection, cache anomaly reaching a preset threshold, device disconnection anomaly, or firmware upgrade failure.

[0078] Both types of events will enter a unified data collection process after being triggered, but there are slight differences in the collection time window and priority. User-initiated feedback events are triggered by users submitting problem descriptions within the app, and have the highest priority, immediately interrupting other low-priority background tasks to prioritize data collection; background exception automatic feedback events are triggered by the system detecting specific abnormal conditions, and have a lower priority, only executing data collection when the device is idle, the network is good, and the battery is sufficient, to avoid disturbing the user.

[0079] The following sections describe the collection process triggered by the two types of log feedback events.

[0080] I. User-initiated feedback process.

[0081] After a user accesses the log feedback section within the app, a feedback pop-up window is displayed. After the user enters a description of the problem, the app executes the following steps: S401 checks if the network is available; if it is not available, it displays a network error message.

[0082] If the verification reveals a network unavailability, the app will display a clear message informing the user that "the current network is abnormal, and log configuration and log upload cannot be obtained." It will also offer two options: "Retry later," allowing the user to re-enter the feedback process once the network is restored; and "Submit a problem description offline," where the user can enter a problem description and save it locally. The app will continuously monitor the network status in the background, and once the network is restored, it will automatically trigger the subsequent log collection and upload process without requiring further user intervention. This offline fallback design ensures that users can complete feedback even in weak or no network environments, preventing the loss of important fault clues.

[0083] S402 checks if the description is empty; if it is empty, it prompts the user to add more details to the problem description.

[0084] Problem descriptions are the first-hand information for engineers to quickly understand the fault phenomenon and locate the root cause of the problem. Vague or missing problem descriptions will prevent engineers from analyzing logs in a targeted manner, which will greatly reduce the efficiency of problem investigation.

[0085] The validation logic filters user input, checking for empty entries. When invalid input is detected, the app displays a prompt asking the user to "briefly describe the problem you encountered, such as 'the AI ​​conversation suddenly stopped midway' or 'the photo translation result is inaccurate,'" guiding the user to provide more valuable information about the problem. The app also provides a dropdown menu of selectable problem types in the feedback pop-up, allowing users to choose categories such as "AI conversation abnormality," "voice recognition problem," or "Bluetooth connection failure" before providing a more detailed description.

[0086] S403 determines whether the remaining storage space is sufficient; if not, it prompts that the storage space is insufficient.

[0087] Insufficient device storage space can lead to log writing failures, file corruption, and even affect the normal operation of the app and system. This solution sets a minimum storage space threshold. If the check finds insufficient remaining storage space, the app will pop up a prompt box informing the user that "Insufficient storage space, unable to record detailed logs," and provide three solutions: First, "Clean up storage space," which will redirect the user to the system's storage management page, guiding the user to delete unnecessary files; second, "Submit problem description only," allowing the user to skip the log collection step and submit only a text description, which, although lacking log data, still provides engineers with basic fault clues; and third, "Cancel feedback," allowing the user to resubmit feedback after cleaning up storage space. In addition, the app will clearly state the minimum space required in the prompt box, letting the user know how much content needs to be cleaned up to complete the feedback.

[0088] The S404 receives the temporary log configuration from the cloud and sets the current log level to a more detailed log level in order to collect the operation process logs of the user reproducing the problem.

[0089] Once all pre-verifications pass, the App will send a temporary log configuration request to the cloud. The request will include information such as user ID, smart glasses model, App version number, firmware version, problem description keywords, and problem type. The cloud will then dynamically distribute the most suitable temporary log configuration for this problem investigation based on this information and the preset strategy engine.

[0090] The cloud-based policy engine adjusts log levels based on the severity and type of the problem. For example, it issues DEBUG level logs for common functional anomalies, VERBOSE level logs for occasional, complex issues, and enables performance log collection for performance-related problems. Upon receiving the cloud configuration, the app immediately updates its local file log level filtering threshold, lowering it to the more detailed level specified by the cloud. Simultaneously, it synchronizes this level with all smart glasses that support the log level control protocol, ensuring that both the app and the glasses can record logs of the same level of detail.

[0091] The temporary log configuration also includes an expiration period parameter, which is calculated from the moment the level switch is successful. If the user does not complete the log submission within the expiration period, the app will automatically restore the log level to the default level to prevent the system from running in a high-resource-consumption mode for an extended period.

[0092] If the S405 has floating window permission, it will display a feedback floating window; after the user reproduces the problem, they can submit logs through the floating window; if it does not have floating window permission, it will guide the user to authorize it, or allow submission via the bottom pop-up window.

[0093] After switching log levels, the app will immediately determine whether it has floating window permission. This is to provide users with the most convenient way to submit logs, avoiding the need for users to frequently switch between different interfaces and interrupt the reproduction process when reproducing the problem. The floating window will not obstruct the user's normal operation. After reproducing the problem, the user only needs to click the "Submit Log" button on the floating window to immediately trigger the log collection and upload process.

[0094] If the app hasn't yet obtained floating window permission, a prompt will appear guiding you through the authorization process. It clearly explains that the floating window's purpose is to "allow you to submit logs with one click while using smart glasses, without switching back to the app," and provides two options: "Authorize Now" and "Do Not Authorize Now." If the user chooses to authorize now, they will be redirected to the system's floating window permission settings page. After authorization, the app will automatically return and the floating window will be displayed. If the user chooses not to authorize now, the app will automatically downgrade to a persistent bottom pop-up mode, displaying a fixed submit button at the bottom of the screen. The user can switch back to the app at any time to click submit.

[0095] 2. Automatic submission of background exception logs.

[0096] Background log submission can be triggered when the app crashes, experiences AI service anomalies, ASR / TTS connection failures, or cached error logs meet the submission criteria. Background submission does not display a user interface; the following steps are executed: S411 uses atomic variables as global commit locks. If a background commit task is already being executed, the current commit is skipped.

[0097] Global commit locks prevent concurrent conflicts between multiple tasks. Background commit tasks may be triggered simultaneously by multiple independent exception detection threads. For example, if the system detects both an app crash and an ASR service disconnection at the same time, without a mutual exclusion mechanism, two log compression and upload tasks will be started simultaneously, causing a surge in CPU and network bandwidth usage, and even serious problems such as log file read / write conflicts and data corruption.

[0098] S412 checks if the network is available. If there is no network connection, it retains the original log and waits for the next trigger.

[0099] Subsequent log collection and uploading operations will only be performed when network conditions are good. If the verification finds the network unavailable, the system will not display any prompts to disturb the user, but will silently retain all original log files and register a system network status listener. When the listener detects that the network connection has been restored, a new background commit attempt will be automatically triggered. At the same time, the system will also start a scheduled retry task to automatically check the network status. If the network has been restored, the commit will be executed to avoid logs being unable to be uploaded for a long time due to listener failure.

[0100] S413 verifies the network type. If it is a cellular network, it checks the total number of cellular network log uploads for the day. If it exceeds the preset limit, it skips this submission.

[0101] Cellular network traffic control effectively prevents background log uploads from consuming excessive paid data and causing user dissatisfaction. The system first determines the current network type. If it is a Wi-Fi network, no upload limit is set, and logs can be uploaded at full speed. If it is a cellular network, the system strictly checks the cumulative total of cellular network log uploads for the day.

[0102] The total upload volume for the day is persistently stored in a local database and automatically resets to zero at midnight every day. It will not be reset due to app restarts or device shutdowns. If the verification finds that the cumulative upload volume for the day has exceeded the preset limit, the system will immediately skip this submission, retain all original log files, and automatically upload again the next day when traffic is reset or the device is connected to a Wi-Fi network.

[0103] S414 checks if there is enough remaining storage space; if not, it skips the current commit.

[0104] If the verification finds that the device has insufficient remaining storage space, the system will immediately terminate the current submission process, retain all original log files, and record an exception flag indicating insufficient storage space. The system will periodically check the storage space status subsequently, and when it detects that the remaining space has recovered to above the threshold, it will automatically trigger the previously interrupted submission task. Simultaneously, the system will prioritize deleting old log files that have exceeded their retention period, freeing up storage space for storing new exception logs.

[0105] The app will collect three separate log files according to preset rules: normal logs, cached logs, and crash logs.

[0106] The collection scope of normal logs includes all historical logs that have not been cleaned up within the current log level filtering threshold. During collection, the app traverses the normal log directory, filters files that match the time range based on the timestamp in the filename, reads and verifies the integrity of each file, and skips corrupt or incomplete files. For user-initiated feedback events, the collection time window is automatically extended forward to before the user submitted feedback to ensure coverage of the time period when the fault occurred; for automatically reported background anomalies, the collection time window is limited to before and after the anomaly occurred to minimize the amount of data collected.

[0107] The scope of cached log collection is the full logs within the current sliding time window, with a default of collecting all cached logs from the last 3 minutes. Because the cached logs use a storage architecture of memory queues and file caching, during collection, the app first forces the logs in the memory queue that haven't yet been flushed to disk to be written to disk, and then reads the complete cached log file. This portion of the logs is not subject to any level of filtering restrictions and contains the most detailed underlying execution details before and after the failure, making it crucial data for locating intermittent failures. It's important to note that cached log collection is executed immediately, without waiting for the memory queue to be refreshed periodically, ensuring that the latest data is captured at the moment the failure occurs.

[0108] The scope of crash log collection includes all crash log files in the local crash log directory that were not successfully uploaded to the cloud. Crash logs are generated by a separate crash capture module, physically isolated from normal logs and cached logs, ensuring data integrity even if the app crashes. During collection, the app iterates through the crash log directory and records the timestamp of each crash file. For automatically reported background exceptions, if the trigger condition is an app crash, the corresponding crash log will be collected first and used as the core file of the log package. For user-reported events, regardless of whether the user reports a crash, all unuploaded crash logs will be collected to avoid missing potential crash issues.

[0109] Unlike reading local logs directly, logs from the glasses need to be transmitted via a Bluetooth link. After the collection process starts, the app first reads the previously cached glasses firmware capability information to determine if the device supports the log back protocol. If not, the collection of glasses logs is skipped, and the device is marked "Device does not support log back" in the subsequent feedback metadata. Upon receiving this mark, the cloud will notify engineers in the log analysis interface to avoid misjudgments due to missing logs. If the log back protocol is supported, the app will calculate the log time window to be collected based on the type and time of the feedback event, and then send a log request command to the glasses, specifying the start and end times of the log collection. After receiving the log request command, the glasses return the log files within the specified time window.

[0110] The S5 and App terminals merge and compress the collected logs with the corresponding link tracing identifiers and metadata into a log package, upload it to the storage terminal, and obtain the log package access address.

[0111] For automatic feedback of backend anomalies, the size of the compressed package will be checked again after the log is compressed. If it will cause the total upload limit to be exceeded for the day, the temporary compressed package will be deleted and the original log will be retained.

[0112] Once log compression is complete and a temporary compressed file is generated, the system immediately performs a secondary traffic check. First, the system reads the actual byte size of the temporary compressed file through the file system interface. Then, the system reads the total cumulative cellular network upload volume for the day from the local database, adds the actual compressed file size to the cumulative total, and obtains the estimated total traffic after this upload. This estimated total traffic is compared with the preset daily cellular network upload limit: if the estimated total traffic is less than or equal to the limit, it means this upload will not exceed the traffic limit, and the system will continue with subsequent upload operations, adding the compressed file size to the daily cumulative total after a successful upload; if the estimated total traffic exceeds the limit, it means this upload will exceed the user's traffic limit, and the system will immediately trigger the traffic over-limit processing logic.

[0113] In this embodiment, the log packets are not directly uploaded to the business server, but are uploaded to the cloud object storage service (OSS). This is because the object storage service is specifically optimized for large file uploads, supports advanced features such as resume upload, chunked upload, and signed URLs, and can provide a higher upload success rate and data reliability, while significantly reducing the load pressure on the business server.

[0114] Once all compressed files have been uploaded, the object storage service will return the permanent access address for each file.

[0115] S6. The App submits a feedback request to the cloud. The feedback request includes the log packet access address, the link tracing identifier, and metadata. If the submission is successful, the temporary files generated by this feedback are cleaned up.

[0116] Before submitting a feedback request, the app integrates all relevant information into a standardized request body that conforms to cloud interface specifications. The core content of the request body includes three types of fields. The first type is log package access information, the core of which is a list of permanent access addresses for the log packages and a list of corresponding object storage keys. The object storage keys adopt a hierarchical naming convention and include date, user identifier, and tracing identifier. The cloud can use this key to quickly locate and retrieve the corresponding log file directly from the object storage service without relying on access address resolution.

[0117] The second category is traceability identification information, which is the trace identifier generated during the user's problem reproduction process; the subsequent elements are the historical anomaly TraceIds automatically associated by the system, including the trace identifiers corresponding to all anomaly events that occurred before this feedback. After receiving the TraceId, the cloud automatically pulls all the server-side logs of the corresponding traces from the cloud log platform, and automatically associates and concatenates them with the logs uploaded by the terminal to form a complete chain of evidence of the entire fault.

[0118] The third category is metadata, which contains detailed data across multiple dimensions. Basic device information includes phone model, operating system version, app version number, unique device identifier, and anonymous user ID; smart glasses information includes glasses model, firmware version, Bluetooth connection status, and connection duration; environmental information includes network type, signal strength, battery level, remaining storage space, and system CPU and memory usage at the time of the feedback; protocol support information includes whether the glasses support log level control protocol, log return protocol, and link tracing synchronization protocol. All metadata fields are collected in real time during request construction to ensure accurate reflection of the actual environmental state at the time of the fault.

[0119] After receiving the request, the cloud will retrieve the corresponding log compressed package from the object storage service based on the object storage key in the request body, and then decompress and verify its integrity.

[0120] To clean up storage space, a tiered strategy is used for the cleanup operation after a successful commit.

[0121] The first files to be cleaned up are all temporary files generated during this feedback process. These files were only used for this upload service and have no value after successful submission. Specifically, this includes: temporary ZIP archives and split files generated during log compression, temporary storage files generated when collecting logs from the glasses, intermediate log files generated during preprocessing, and temporary metadata files. The cleanup operation will iterate through all temporary file directories, delete files one by one, and verify the deletion results to ensure that no residual files occupy storage space. For files that fail to be deleted, the app will record the exception information and automatically perform a residual file cleanup task on the next startup as a fallback mechanism.

[0122] The cleanup strategy for raw log files varies depending on the type of feedback. For scenarios with automatic backend feedback, successfully uploaded crash log files and cached log files related to the incident are immediately deleted upon successful submission. Crash logs are one-time fault data and do not need to be retained locally after successful upload; cached logs only retain short-term context and have fulfilled their purpose after upload. Regular log files are retained until a preset retention period or total storage size limit is reached, at which point they are automatically cleaned up. For scenarios with user-initiated feedback, no raw log files are immediately deleted upon successful submission; all raw logs are retained for 7 days. This is because user-initiated issues are usually more complex, and cloud engineers may need to request users to upload more log data during subsequent analysis. Retaining raw logs avoids the need for users to reproduce the problem. After 7 days, the system automatically cleans up these raw log files to free up storage space.

[0123] Every cleanup operation generates an audit log, recording the cleanup time, the list of deleted files, and the amount of storage space released, facilitating subsequent traceability and troubleshooting. If an exception occurs during the cleanup process, the app will not interrupt the entire process but will record the exception information and continue cleaning other files to ensure that as much storage space as possible is released.

[0124] After cleaning up temporary files, the app performs a series of resource release and state restoration operations to restore the system to its normal operating state before the feedback. First, it releases the global atomic commit lock, resets atomic variables, and allows subsequent background commit tasks to execute normally. Then, it restores the log level to the default security level issued by the cloud, and sends a level restoration command to the smart glasses that support the protocol, ensuring that both ends exit the temporary high-level log mode to avoid long-term consumption of device resources.

[0125] For user-initiated feedback scenarios, the app will display a successful submission notification and the generated feedback number on the interface, informing the user that the issue has been successfully submitted and that engineers will process it as soon as possible. Simultaneously, the feedback floating window or bottom pop-up will close, restoring the app's normal interface. For automated background feedback scenarios, there will be no interface prompts throughout the process, and the user will be completely unaware of the background operations.

[0126] Finally, the app will update the local feedback record database, recording information such as the feedback number, submission time, feedback type, and exception type of this feedback, so that users can check the feedback progress later, and the system can also count and analyze the frequency of device failures.

[0127] The invention will be demonstrated through several scenario examples below.

[0128] Scenario Example 1: Users encounter issues such as "no response," "disconnection," and "recognition anomalies" when using the AI ​​dialogue or translation functions of smart glasses. Users proactively submit feedback within the app. The implementation process is as follows: 1. Users can access the log feedback portal in the app, enter a description of the problem, such as "suddenly there was no sound during the AI ​​dialogue".

[0129] 2. The app checks whether the network is available, whether the problem description is empty, and whether there is enough remaining local storage space.

[0130] 3. The App reads the log configuration from the cloud or uses the local default configuration to temporarily increase the log level during this feedback period, for example, from WARN to DEBUG.

[0131] 4. The App generates or reads the current TraceId and writes the same TraceId into subsequent network requests, AI requests, TTS requests, and log files.

[0132] 5. If the current smart glasses firmware supports the glasses-side log feedback protocol, the App sends a log retrieval command to the glasses via Bluetooth. The command includes the log retrieval switch, log level, and TraceId.

[0133] 6. After receiving the command, the glasses will send the corresponding time period's log back to the App. The App receives the log data and saves it as a local glasses log file.

[0134] 7. The App simultaneously collects mobile device routine logs, cache logs, crash logs, glasses logs, user problem descriptions, App version, system version, device serial number, firmware version, and TraceId.

[0135] 8. The App compresses the above files and metadata into a ZIP archive and uploads it to OSS.

[0136] 9. After obtaining the file address or object key returned by OSS, the App calls the cloud feedback interface to submit the user description, device information, TraceId, and log file address.

[0137] 10. After the feedback form is recorded in the cloud, the App deletes the temporary ZIP compressed file generated by this submission; if the policy allows, it also deletes the temporary glasses logs that have been successfully submitted.

[0138] 11. After the feedback process is completed, the App will restore the log level to the online security level to avoid recording too many detailed logs for a long time.

[0139] Scenario Example 2: The app captures crashes, AI service anomalies, ASR / TTS link anomalies, or cached log trigger conditions in the background and submits exception logs without user intervention. The implementation process is as follows: 1. Abnormal log submission conditions are detected during App startup or operation, such as the existence of crash log files or continuous failures of AI requests.

[0140] 2. The App uses a submission lock to determine if there is already a background log submission task; if there is already a task being executed, the current submission is skipped to avoid concurrent uploads.

[0141] 3. The app checks if there is a network connection; if there is no network, it retains the log and waits for the next trigger.

[0142] 4. The app determines whether it is on a Wi-Fi network; if not, it continues to determine whether the total daily upload limit for cellular networks has been exceeded.

[0143] 5. The App determines whether the remaining local storage space and the target log directory meet the compression requirements.

[0144] 6. The App compresses the target log directory into a background exception log ZIP archive file.

[0145] 7. After compression, check again whether the size of the ZIP archive file will cause the daily upload limit to be exceeded; if it exceeds the limit, delete the temporary ZIP archive file and retain the original log.

[0146] 8. After successful upload, the App calls the cloud feedback interface to submit the exception type, device information, TraceId, and log file address.

[0147] 9. After the cloud API returns a successful response, update the App with the uploaded size for the day and delete any submitted crash logs or temporary ZIP archive files.

[0148] 10. If the upload fails or the submission to the cloud fails, the App releases the submission lock and retains the original logs for subsequent retries.

[0149] Example 2:

[0150] like Figure 2 As shown, a smart wearable device-cloud collaborative log management system includes an App installed on the smart device, a smart wearable device, and a cloud. The App is configured with: The log configuration request module is used to send log configuration requests to the cloud, receive the corresponding preset log level issued by the cloud according to the preset policy, and synchronize the preset log level to the smart wearable device. The log writing module is used to write the full logs of the most recent preset time window to the cached log path as cached logs; and to filter the logs according to the preset log level and write them to the normal log path as normal logs. The Link Trace Identifier Management Module is used to generate a unique Link Trace Identifier each time a business link is started, inject the Link Trace Identifier into all network request headers and local logs, and synchronize it to the smart wearable device, so that the logs on the smart wearable device carry the same Link Trace Identifier. The log collection module is used to collect local normal logs, cached logs, and crash logs generated when the system crashes when a log feedback event is triggered; and to request the corresponding time period of the smart wearable device's logs. The upload module is used to merge and compress the collected logs with the corresponding link tracing identifiers and metadata into a log package, upload it to the storage terminal, and obtain the log package access address; The feedback request submission module is used to submit feedback requests to the cloud. The feedback request includes the log packet access address, the link tracing identifier, and metadata. If the submission is successful, the temporary files generated by this feedback are cleaned up.

[0151] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0152] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a computer terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0153] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A log management method for edge-cloud collaboration in smart wearable devices, characterized in that, Includes the following steps: The App sends a log configuration request to the cloud, receives the corresponding preset log level issued by the cloud according to the preset policy, and synchronizes the preset log level to the smart wearable device. The App writes all logs from the most recent preset time window to the cached log path as cached logs; The logs are filtered according to the preset log level and then written to the normal log path as normal logs; The App generates a unique link tracing identifier each time a business link is started, injects the link tracing identifier into all network request headers and local logs, and synchronizes it to the smart wearable device so that the logs on the smart wearable device carry the same link tracing identifier. When the log feedback event is triggered, the App collects local routine logs, cached logs, and crash logs generated when the system crashes. And request the smart wearable device logs for the corresponding time period from the smart wearable device. The App merges and compresses the collected logs with the corresponding link tracing identifiers and metadata into a log package, uploads it to the storage terminal, and obtains the log package access address; The App submits a feedback request to the cloud, which includes the log packet access address, the link tracing identifier, and metadata. If the submission is successful, clean up the temporary files generated by this feedback.

2. The log management method for edge-cloud collaboration in a smart wearable device according to claim 1, characterized in that, The preset strategies for cloud-based log distribution at preset levels include distribution based on at least one of the following: user identifier, smart wearable device model, App version, firmware version, application channel, or problem localization requirements.

3. The log management method for edge-cloud collaboration in a smart wearable device according to claim 1, characterized in that, The business link includes at least one of the following: AI dialogue request, Automatic Speech Recognition (ASR) request, Text-to-Speech (TTS) request, translation request, and photo translation request; the link tracking identifier is written to the structured log file along with the log level, timestamp, module name, and extended fields when the log is output.

4. The log management method for edge-cloud collaboration in a smart wearable device according to claim 1, characterized in that, The log feedback events include user-initiated feedback events and automatic background error feedback events; The triggering process for the user-initiated feedback event is that the user enters the feedback portal within the App and submits a problem description; The triggering conditions for the background abnormal automatic feedback event include at least one of the following: App crash, AI service abnormality, ASR / TTS link disconnection, cache abnormality reaching a preset threshold, device disconnection abnormality, and firmware upgrade failure.

5. The log management method for edge-cloud collaboration in a smart wearable device according to claim 4, characterized in that, If the log feedback event is a user-initiated feedback event, perform the following steps: Receive temporary log configurations from the cloud and set the current log level to a more detailed log level in order to collect logs of the user's operation process when reproducing the problem; After successfully submitting the feedback request, the log level will be restored to the preset log level.

6. The log management method for edge-cloud collaboration in a smart wearable device according to claim 5, characterized in that, If the log feedback event is a user-initiated feedback event, the following steps are also performed: Determine if the network is available; if not, display a network error message. Check if the description is empty; if it is empty, prompt the user to provide a more detailed description of the problem. Determine if there is enough remaining storage space; If insufficient, a message will be displayed indicating that storage space is insufficient; If the system has floating window permission, a feedback floating window will be displayed; users can submit logs through the floating window after reproducing the problem; if the system does not have floating window permission, users will be guided to authorize it, or the submission method will remain at the bottom pop-up.

7. The log management method for edge-cloud collaboration in a smart wearable device according to claim 4, characterized in that, If the log feedback event is an automatic feedback event from the backend for an exception, perform the following steps: Using atomic variables as global commit locks, if a background commit task is already being executed, the current commit is skipped; Check if the network is available; if there is no network connection, retain the original log and wait for the next trigger. Verify the network type. If it is a cellular network, check the total number of cellular network log uploads for the day. If it exceeds the preset limit, skip this submission. Check if there is enough remaining storage space; if not, skip this commit. Check if the target log directory exists and is not empty; if it is empty, terminate the commit. After the log compression is complete, the size of the compressed package is checked. If it will cause the daily upload limit to be exceeded, the temporary compressed package is deleted and the original log is retained. After successful upload, the cloud feedback interface is invoked, and the upload size for the day is accumulated. If the upload or submission fails, release the submission lock and retain the original logs according to the exception type for subsequent retries.

8. The log management method for end-to-cloud collaboration in a smart wearable device according to claim 1, characterized in that, When the app detects that the smart wearable device does not support log levels, it will mark the current smart wearable device as an older version compatibility mode. When it is detected that the smart wearable device does not support log back, the App only collects local log files and marks the current smart wearable device as not supporting log back in the metadata of the feedback request. The feedback request also includes the version information of the smart wearable device, so that the cloud can identify the reason for the missing logs based on this mark.

9. A log management method for end-to-cloud collaboration in a smart wearable device according to claim 1, characterized in that, The rules for cleaning up temporary files include: deleting the temporary log archive generated in this feedback; if it is an automatic feedback from the background and the submission is successful, then deleting the submitted crash log and the corresponding cache log; The app periodically performs local log cleanup, cleans up cached logs according to a preset short retention period, and cleans up normal logs according to a preset retention period and total storage size limit.

10. A log management system for smart wearable devices with edge-cloud collaboration, characterized in that, This includes an app installed on a smart device, a smart wearable device, and the cloud. The app is configured with: The log configuration request module is used to send log configuration requests to the cloud, receive the corresponding preset log level issued by the cloud according to the preset policy, and synchronize the preset log level to the smart wearable device. The log writing module is used to write the full logs of the most recent preset time window to the cached log path as cached logs; The logs are filtered according to the preset log level and then written to the normal log path as normal logs; The Link Trace Identifier Management Module is used to generate a unique Link Trace Identifier each time a business link is started, inject the Link Trace Identifier into all network request headers and local logs, and synchronize it to the smart wearable device, so that the logs on the smart wearable device carry the same Link Trace Identifier. The log collection module is used to collect local normal logs, cached logs, and crash logs generated when the system crashes when a log feedback event is triggered. And request the smart wearable device logs for the corresponding time period from the smart wearable device. The upload module is used to merge and compress the collected logs with the corresponding link tracing identifiers and metadata into a log package, upload it to the storage terminal, and obtain the log package access address; The feedback request submission module is used to submit feedback requests to the cloud. The feedback request includes the log packet access address, the link tracing identifier, and metadata. If the submission is successful, clean up the temporary files generated by this feedback.

Images