Split device log storage and pulling method and system and storage medium

Abstract

The invention discloses a split device log storage and pulling method and system and a storage medium, and the method comprises the log storage step: when a preset condition is met, a log in a second log storage device of an auxiliary device is transferred to a first log storage device of a main device, and the split device log storage and pulling method and system and the storage medium are provided. A main device and auxiliary device collaborative storage and dynamic pulling mechanism comprehensively solves the log management problem of the split integrated terminal and solves the problem that the sleep log of the auxiliary device cannot be obtained: log transfer is triggered through a preset condition, the key log of the auxiliary device can be stored in the main device in advance, and the historical log of the auxiliary device can be pulled from the main device even if the auxiliary device is in sleep, so that the user experience is improved. The integrity of troubleshooting is guaranteed, the cloud storage pressure is relieved, logs are preferentially stored in the local of the main device, dependence on a cloud server is reduced, necessary logs are uploaded only through the main device when needed, and cloud storage space occupation and operation cost are reduced.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computers, and particularly relates to a split device log storage and pulling method and system and a storage medium. BACKGROUND

[0002] In the current field of intelligent hardware, integrated hardware such as a tablet plus a scanning pen, an ink bottle word processor plus a tablet, an ink bottle learning machine plus a tablet, and the like, constantly appear. These hardware can be actually split into two hardware carriers, and the two carriers can carry different software systems to independently run.

[0003] During the running of the device, if a dysfunction occurs, the device running log usually needs to be pulled to analyze the problem, and then the problem is solved. At present, for the two independent hardware carriers in the integrated terminal, each has a corresponding log system, and the log of which part is queried when the part is abnormal. However, this way has the following problems:

[0004] The integrated terminal generally has a main device and a secondary device, and the secondary device is usually in an unawakened state. Therefore, when the secondary device is in hibernation, its log cannot be pulled.

[0005] If the log is stored in a cloud server, over time, it will form a serious challenge to the storage space of the cloud server.

[0006] The storage space of the secondary device itself is limited, so the number of logs that can be stored is also limited. Therefore, we need to provide a split device log storage and pulling method, system, and storage medium. SUMMARY

[0007] The purpose of the present application is to provide a split device log storage and pulling method, system, and storage medium, a main-secondary device cooperative storage and dynamic pulling mechanism, which comprehensively solves the log management problem of the split integrated terminal, solves the problem that the log of the secondary device in hibernation cannot be obtained, and through preset condition triggering log transfer, the key log of the secondary device can be stored in the main device in advance. Even if the secondary device is in hibernation, its historical log can be pulled from the main device, ensuring the integrity of fault troubleshooting, relieving the pressure of cloud storage, storing the log in the local main device first, reducing the dependence on the cloud server, uploading the necessary log through the main device only when needed, reducing the occupation of cloud storage space and operating costs, to solve the problems in the above background technology that the integrated terminal generally has a main device and a secondary device, the secondary device is usually in an unawakened state, so when the secondary device is in hibernation, its log cannot be pulled, and if the log is stored in a cloud server, over time, it will form a serious challenge to the storage space of the cloud server, and the storage space of the secondary device itself is limited, so the number of logs that can be stored is also limited.

[0008] To achieve the above object, the application adopts the following technical scheme: a split device log storage and pulling method, comprising the following steps:

[0009] The log storage step comprises reaching a preset condition, and transferring logs in the second log storage device of the secondary device to the first log storage device of the primary device;

[0010] The preset condition comprises one or more of the following: the number of abnormal log levels generated by the secondary device reaching a preset threshold level exceeds a preset value, the time since the last transfer exceeds a preset transfer time, the abnormal log storage amount of the secondary device is greater than a preset transfer amount, and the secondary device reaches a preset transfer state.

[0011] The log pulling step comprises the server sending a log pulling request according to the unique identifier of the device, and the primary device and the secondary device uploading corresponding logs according to the request content and a preset log uploading strategy, wherein the request content includes the log type.

[0012] Preferably, the log storage step further comprises:

[0013] Data compression processing is performed on the logs in the second log storage device before the transfer, the first log storage device stores the primary device logs and the secondary device logs separately, and the logs that have been transferred in the second log storage device are deleted after the transfer.

[0014] Preferably, the preset log uploading strategy in the log pulling step comprises:

[0015] If the primary device logs are requested to be uploaded, the primary device logs in the first log storage device are directly uploaded.

[0016] If the secondary device logs are requested to be uploaded, the secondary device logs in the first log storage device are uploaded first, and then the state of the secondary device is detected: if the secondary device is in an awake state, the logs in the second log storage device are uploaded, and if the secondary device is in a sleep state, the logs are not uploaded temporarily.

[0017] If the primary and secondary device logs are requested to be uploaded, the primary and secondary device logs in the first log storage device are uploaded first, and then the state of the secondary device is detected: if the secondary device is in an awake state, the logs in the second log storage device are uploaded, and if the secondary device is in a sleep state, the logs are not uploaded temporarily.

[0018] Preferably, the log uploading mode of the second log storage device comprises:

[0019] The logs are directly uploaded by the secondary device, or the logs are transferred to the first log storage device by the secondary device and then uploaded by the primary device.

[0020] Preferably, the communication connection between the secondary device and the primary device is authenticated when established, and data transmission is performed after authentication; the authentication includes one or more of device ID matching and preset key verification.

[0021] Preferably, the first log storage device is used to store the primary device log and the secondary device log, and the second log storage device is used to store the log generated by the secondary device; the log type in the log pulling request issued by the server unit determines the range of uploaded logs, and the preset log uploading strategy is adapted to the wake-up or sleep state of the secondary device.

[0022] Preferably, the server end further includes the following steps when issuing the log pulling request:

[0023] The pulling period is determined according to a preset time strategy, and the time strategy is dynamically adjusted based on device usage frequency, log generation amount, or historical abnormal event occurrence frequency;

[0024] Different types of logs are assigned priority weights, and the priority weights are used to determine the order of log uploading in the case of limited network bandwidth;

[0025] The encryption parameters are carried in the pulling request, and the encryption parameters are used for end-to-end encryption processing of uploaded log data.

[0026] A split device log processing system, comprising:

[0027] The split device unit includes a primary device unit and a secondary device unit, and the secondary device unit can form an integrated device unit with the primary device unit;

[0028] The primary device unit is provided with a first log storage device, and the secondary device unit is provided with a second log storage device; the primary device unit and the secondary device unit are communicatively connected through any one or a combination of multiple of physical wired connection, wireless Bluetooth connection, and wifi wireless connection;

[0029] The server unit is used to issue a log pulling request and receive uploaded logs;

[0030] The secondary device unit is configured to perform a log transfer operation when a preset condition is met, and perform data compression and deleted transferred log operations before and after the transfer, respectively;

[0031] The primary device unit and the secondary device unit are configured to perform corresponding log uploading operations according to the pulling request and the log type of the server unit;

[0032] The system also includes an analysis unit for classified storage and analysis processing of the logs uploaded to the server unit, the analysis processing including one or more of log content keyword extraction, abnormal log level evaluation, log trend statistics.

[0033] A computer-readable storage medium comprising a stored computer program, wherein the computer program controls the computer program executed by the device where the computer-readable storage medium is located when the computer program is running.

[0034] The technical effects and advantages of the present application: the split device log storage and pulling method, system and storage medium provided by the present application have the following advantages compared with the prior art:

[0035] The present application solves the log management problem of the split body integrated terminal through the master and slave device cooperative storage and dynamic pulling mechanism, solves the problem that the sleep log of the slave device cannot be obtained: the key log of the slave device can be stored in the master device in advance through the preset condition triggering log transfer, even if the slave device is in sleep state, the historical log of the slave device can be pulled from the master device, the integrity of fault diagnosis is guaranteed, the cloud storage pressure is relieved, the log is stored in the local master device first, the dependence on the cloud server is reduced, only when necessary, the necessary log is uploaded through the master device, the cloud storage space occupation and operation cost are reduced, the storage limit of the slave device is broken: after the log of the slave device is regularly transferred to the master device, the local data can be deleted, the storage space of the slave device is released, so that it can continuously record new logs, avoid log loss due to insufficient storage, improve the efficiency of log management, and balance the device power consumption, storage resources and communication stability, providing reliable support for operation and maintenance and fault diagnosis of the split body device.

[0036] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. The objects and other advantages of the present application can be achieved and obtained by the structures indicated in the specification and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0037] Figure 1 The step flowchart of the present application. DETAILED DESCRIPTION

[0038] The technical solutions in the embodiments of the present application will be described clearly and completely in the following with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. The specific embodiments described herein are only used to explain the present application, and are not used to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0039] The application provides a method for storing and pulling device logs, which comprises the following steps: Figure 1

[0040] The log storage step comprises the following steps: reaching a preset condition, and transferring logs in a second log storage device of a secondary device to a first log storage device of a primary device.

[0041] The preset condition comprises one or more of the following: the number of abnormal log levels generated by the secondary device that reach a preset threshold level exceeds a preset value, the time since the last transfer exceeds a preset transfer time, the abnormal log storage amount of the secondary device is greater than a preset transfer amount, and the secondary device reaches a preset transfer state.

[0042] The log pulling step comprises the following steps: the server end issues a log pulling request according to the unique identification of the device, and the primary device and the secondary device upload corresponding logs according to the request content and a preset log uploading strategy, wherein the request content comprises a log type.

[0043] The logs in the second log storage device are subjected to data compression processing before the transfer; the first log storage device stores the primary device logs and the secondary device logs separately; and the logs that have been transferred in the second log storage device are deleted after the transfer.

[0044] Specifically, the log data is compressed (for example, using a ZIP, GZIP or other compression algorithm). This operation can significantly reduce the data transmission amount, reduce the occupation of the communication bandwidth between the primary and secondary devices, is particularly suitable for connection modes with limited bandwidth such as wireless Bluetooth and WiFi, and reduces the storage space occupation of the first log storage device of the primary device. The first log storage device of the primary device stores the logs generated by the primary device itself and the logs transferred from the secondary device separately by establishing independent storage partitions, folders or data tables. For example, the directory structure of a “primary device log folder” and a “secondary device transferred log folder” can be used, or the “device type” field can be used to distinguish in the database. This classification method can improve the log retrieval efficiency. When the server end issues a log pulling request of a specific device type, the corresponding storage area can be directly located, and full data traversal is avoided. After the logs of the secondary device are successfully transferred to the first log storage device of the primary device, the secondary device automatically deletes the log data that has been transferred in the second log storage device. This operation is aimed at the feature that the storage space of the secondary device is limited. By releasing the storage resources in a timely manner, it is ensured that the secondary device can continuously record new logs, and log loss caused by storage overflow is avoided. In addition, the storage read-write times of the secondary device are reduced, and the power consumption is indirectly reduced.

[0045] The preset log uploading strategy in the log pulling step comprises the following steps:

[0046] If the primary device logs are requested to be uploaded, the primary device logs in the first log storage device are directly uploaded. ​

[0047] If the request is to upload the secondary device log, the secondary device log in the first log storage device is uploaded first, and then the secondary device state is detected: if the secondary device is in the wake-up state, the log of the second log storage device is uploaded, and if it is in the sleep state, it is temporarily not uploaded;

[0048] If the request is to upload the primary and secondary device logs, the primary and secondary device logs in the first log storage device are uploaded first, and then the secondary device state is detected: if the secondary device is in the wake-up state, the log of the second log storage device is uploaded, and if it is in the sleep state, it is temporarily not uploaded;

[0049] Specifically, the primary device log upload: when the log type requested by the server side is the primary device log, the primary device directly extracts the corresponding data from the primary device log storage area of the first log storage device and uploads it. Since the primary device is usually in an active state and the log storage is locally controllable, this process does not need to rely on the secondary device, and the response speed is fast and the stability is high.

[0050] Secondary device log upload: when the pull request is the secondary device log, the two-step strategy of "first locally storing the log, and then supplementing the real-time log" is adopted:

[0051] First, the uploaded secondary device log in the first log storage device of the primary device is uploaded first to ensure that even if the secondary device is in the sleep state, its historical key log (such as abnormal records before sleep) can be obtained;

[0052] Second, the state of the secondary device is detected in real time: if the secondary device is in the wake-up state (which can be determined by the communication connection state), the newly added log in the second log storage device of the secondary device is triggered to be uploaded (the part that has not been stored in the primary device); if the secondary device is in the sleep state (communication is interrupted or unresponsive), its local log is temporarily not uploaded, and will be supplemented by a subsequent request after the secondary device wakes up.

[0053] Primary and secondary device joint log upload: when the pull request contains both the primary and secondary device logs, the above two strategies are integrated:

[0054] The primary device log and the stored secondary device log in the first log storage device of the primary device are uploaded first;

[0055] Then, it is determined whether to supplement the newly added log of the second log storage device according to the state of the secondary device (upload if in the wake-up state, and temporarily store if in the sleep state).

[0056] The log upload method of the second log storage device includes:

[0057] Directly uploaded by the secondary device, stored by the secondary device to the first log storage device, and then uploaded by the primary device;

[0058] Specifically, when the secondary device has independent networking capability (such as supporting WiFi or mobile data connection by itself) and is in an awake state, the logs in the second log storage device can be directly uploaded to the server side through the network of the secondary device. This method is suitable for the scenario where the secondary device is temporarily separated from the primary device and cannot establish local communication, ensuring the independence of log uploading.

[0059] If the secondary device has no independent networking capability (such as only supporting near-field communication with the primary device) or is a unified log uploading outlet (for easy management and permission control), the secondary device first transfers the logs in the second log storage device to the first log storage device of the primary device, and then the primary device uploads them to the server through its own network. This method is suitable for the scenario where the primary and secondary devices are integrated, and uses the network resources of the primary device to complete the uploading, reducing the network dependence and power consumption of the secondary device.

[0060] When the communication connection between the secondary device and the primary device is established, device identity verification is performed first, and then data transmission is performed after the verification is passed; the identity verification includes one or more of device ID matching and preset key verification;

[0061] Specifically, the primary device and the secondary device pre-store unique device identifiers (such as serial numbers, MAC addresses), and when the communication connection is established, the two devices send device IDs to each other. Only when the received ID matches the locally pre-stored legal ID list is the subsequent data transmission allowed. This method can prevent illegal devices from accessing and avoid log data from being stolen or tampered with.

[0062] The primary device and the secondary device pre-negotiate and store the same encryption key (such as a symmetric key), and when the connection is established, one party sends random verification information, and the other party returns it after encryption using the preset key. The sending party verifies that the decryption results are consistent to pass the verification. This mechanism further improves the security of identity verification, and even if the device ID is forged, the key verification can still intercept illegal connections.

[0063] The communication connection between the primary device and the secondary device transmits log data using a data verification mechanism, which includes calculating the hash value of the transmitted log data. The primary device recalculates the hash value after receiving the log data and compares it with the hash value sent by the secondary device. If they are consistent, it confirms that the log data transmission is complete, and if they are not consistent, it triggers retransmission.

[0064] Specifically, before the secondary device transmits log data from the second log storage device to the first log storage device of the primary device, the secondary device calculates the hash value of the log data to be transmitted and sends it to the primary device together with the log data. The primary device recalculates the hash value of the received log data using the same hash algorithm after receiving the log data, and then compares the recalculated hash value with the hash value sent by the secondary device.

[0065] The first log storage device is used for storing the main device log and the transferred secondary device log, the second log storage device is used for storing the log generated by the secondary device; the log type in the log pulling request issued by the server unit determines the range of uploaded log, and the preset log uploading strategy is adapted to the wake-up or sleep state of the secondary device;

[0066] Specifically, the first log storage device serves as a core storage node and has dual functions: one is to store various logs (such as system operation logs and application running logs) generated by the main device during operation; the other is to store the logs transferred from the secondary device (the transfer operation triggered by the preset condition). The second log storage device is only responsible for storing the logs generated by the secondary device itself, and serves as a temporary storage node, and the data thereof will be synchronized to the first log storage device at regular intervals according to the transfer mechanism.

[0067] The association between the log type and the uploading range: in the log pulling request issued by the server, the “log type” parameter directly determines the range of uploaded data: when the “main device log” is specified, only the main device log in the first log storage device is uploaded; when the “secondary device log” is specified, the uploading range includes the transferred secondary device log in the first log storage device and the newly added log in the local secondary device when the secondary device is woken up; when the “main and secondary device joint log” is specified, all the above ranges are covered.

[0068] The adaptation of the preset log uploading strategy to the device state: the strategy design fully considers the wake-up / sleep state of the secondary device: for the wake-up state, the newly added log in the second log storage device is supplemented by real-time communication to ensure data integrity; for the sleep state, only the historical log transferred in the first log storage device is relied on to avoid the pulling interruption caused by communication failure, and the subsequent request is used for retransmission after the secondary device is woken up, so that the real-time performance and reliability are balanced.

[0069] When the server issues the log pulling request, the following steps are further included:

[0070] The pulling period is determined according to the preset time strategy, and the time strategy is dynamically adjusted based on the device usage frequency, log generation amount or historical abnormal event frequency;

[0071] The priority weight is allocated to different types of logs, and the priority weight is used to determine the sequence of log uploading in the case of limited network bandwidth;

[0072] The encryption parameter is carried in the pulling request, and the encryption parameter is used for end-to-end encryption processing of the uploaded log data.

[0073] Specifically, the log pulling frequency is determined based on a preset time strategy, which is dynamically adapted according to the actual situation of the device: for devices that are used frequently (such as learning terminals in an educational environment) or devices that generate a large amount of logs (such as a scanning pen that is operated frequently), the pulling period is shortened (such as once an hour); for devices that are used infrequently or generate few logs, the pulling period is extended (such as once a day); if the device has recently experienced an abnormal event (such as frequent error reporting), the period is temporarily shortened to quickly obtain fault-related logs.

[0074] Different types of logs are set with priority weights (such as ERROR-level logs with the highest weight and INFO-level logs with a lower weight), and when the network bandwidth is limited (such as the primary and secondary devices being connected through Bluetooth with low bandwidth), high-priority logs are uploaded first to ensure that critical abnormal information reaches the server first, and secondary logs are uploaded to supplement when the bandwidth is sufficient, avoiding loss of critical information due to insufficient bandwidth.

[0075] The pulling request carries encryption parameters (such as encryption algorithm identification and random number seed), and the primary device or the secondary device uses the parameters to perform end-to-end encryption (such as using the AES algorithm) on the log data when uploading the logs, and the encrypted logs can only be decrypted by the server. This mechanism prevents logs from being eavesdropped or tampered with during transmission, ensuring the confidentiality and integrity of the log data, and is particularly suitable for logs containing sensitive device information (such as hardware status and user operation records).

[0076] A split device log processing system, comprising:

[0077] A split device unit, comprising a primary device unit and a secondary device unit, the secondary device unit can form an integrated device unit with the primary device unit;

[0078] The primary device unit is provided with a first log storage device, and the secondary device unit is provided with a second log storage device, the primary device unit and the secondary device unit are communicatively connected through any one or a combination of multiple of physical wired connection, wireless Bluetooth connection, and wifi wireless connection;

[0079] A server unit for issuing log pulling requests and receiving uploaded logs;

[0080] The secondary device unit is configured to perform a log transfer operation when a preset condition is met, and to perform data compression and deleted transferred log operations before and after the transfer, respectively;

[0081] The primary device unit and the secondary device unit are configured to perform corresponding log uploading operations according to the pulling request and the log type of the server unit;

[0082] The system further comprises an analysis unit for classified storage and analysis processing of the logs uploaded to the server unit, the analysis processing comprising one or more of log content keyword extraction, abnormal log level evaluation, log trend statistics.

[0083] Specifically, the log pulling frequency is determined based on a preset time strategy, which is dynamically adapted according to the actual situation of the device: for devices used frequently (such as learning terminals in an educational environment) or devices with a large amount of log generation (such as a scanning pen operated frequently), the pulling period is shortened (such as once an hour); for devices with low usage frequency or few logs, the pulling period is extended (such as once a day); if the device has recently experienced an abnormal event (such as frequent error reporting), the period is temporarily shortened to quickly obtain fault-related logs.

[0084] Log upload priority allocation: different types of logs are set with priority weights (such as ERROR level logs with the highest weight and INFO level logs with lower weight), when the network bandwidth is limited (such as the main and secondary devices connected through Bluetooth low bandwidth), high priority logs are uploaded first to ensure that critical abnormal information reaches the server first, and secondary logs are uploaded when the bandwidth is sufficient, avoiding loss of critical information due to insufficient bandwidth.

[0085] Log data encryption processing: the pulling request carries encryption parameters (such as encryption algorithm identifier, random number seed), the main device or the secondary device uses the parameters to perform end-to-end encryption (such as using AES algorithm) on the log data when uploading the logs, and the encrypted logs can only be decrypted by the server. This mechanism prevents eavesdropping or tampering of logs during transmission, ensuring the confidentiality and integrity of log data, especially for logs containing sensitive device information (such as hardware status, user operation records).

[0086] A computer readable storage medium, the computer readable storage medium comprising a stored computer program, wherein the computer program controls the computer program executed by the device where the computer readable storage medium is located when the computer program is running.

[0087] In addition, the above-mentioned split device unit, server unit and analysis unit, when executed, are also used to realize the other functions of the above-mentioned split device log storage and pulling method, system and storage medium, which are not described here.

[0088] In addition, the present application also provides a terminal device, the split device log storage and pulling method involved in the present embodiment is mainly applied to a terminal device, which can be a PC, a portable computer, a mobile terminal and the like.

[0089] Specifically, the terminal device can include a processor (for example, a CPU), a communication bus, a user interface, a network interface, and a memory. The communication bus is used to realize the connection and communication between these components; the user interface can include a display screen (Display) and an input unit such as a keyboard (Keyboard); the network interface can optionally include a standard wired interface and a wireless interface (such as a WI-FI interface); the memory can be a high-speed RAM memory, or a stable memory (non-volatile memory) such as a disk memory, and the memory can also be a storage device independent of the aforementioned processor.

[0090] The memory stores a readable storage medium, and the readable storage medium stores a split device log storage and pulling method program. The processor can call the split device log storage and pulling method program stored in the memory, and execute the split device log storage and pulling method provided by the embodiment of the application.

[0091] It can be understood that the readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. More specific examples (a non-exhaustive list) of the computer readable storage medium include a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punched card or a concave-convex structure in a slot, and any suitable combination of the above. The computer readable storage medium used herein is not to be interpreted as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (for example, optical pulses through an optical fiber cable), or electrical signals transmitted through a wire.

[0092] The computer readable program instructions described herein can be downloaded from the computer readable storage medium to each computing / processing device, or to an external computer or an external storage device through a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber-optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions to the computer readable storage medium for storage in the computing / processing device.

[0093] Computer readable program instructions for carrying out operations of the present disclosure can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0094] Finally, it should be noted that the above-mentioned only is the preferred embodiment of the present application, and does not limit the present application, although the foregoing embodiments of the present application are described in detail, for those skilled in the art, it still can be modified to the technical solutions recorded in the foregoing embodiments, or equivalent replacement of part of the technical features, within the spirit and principles of the present application, any modification, equivalent replacement, improvement, etc., should be included in the protection scope of the present application.

Claims

1. A method for storing and retrieving logs from detachable devices, characterized in that, Includes the following steps: The log storage process includes transferring logs from the second log storage device of the secondary device to the first log storage device of the primary device when preset conditions are met. The preset conditions include one or more of the following: the number of abnormal logs generated by the secondary device that reach the preset threshold level exceeds the preset value; the time since the last transfer exceeds the preset transfer time; the storage amount of abnormal logs of the secondary device is greater than the preset transfer amount; and the secondary device reaches the preset transfer state. The log retrieval process includes the server sending a log retrieval request based on the device's unique identifier, and the primary and secondary devices uploading the corresponding logs according to the request content and the preset log upload strategy. The request content includes the log type.

2. The method for storing and retrieving logs of a detachable device according to claim 1, characterized in that: The log storage step also includes: Before the transfer, the logs of the second log storage device are compressed; the first log storage device stores the main device logs and the secondary device logs separately; after the transfer, the transferred logs in the second log storage device are deleted.

3. The method for storing and retrieving logs of a detachable device according to claim 1, characterized in that: The preset log upload strategy in the log retrieval step includes: If a request is made to upload the master device log, upload the master device log from the first log storage device directly. If a request is made to upload logs from a secondary device, the logs from the secondary device in the first log storage device are uploaded first, and then the status of the secondary device is checked: if the secondary device is in a wake-up state, the logs from the second log storage device are uploaded; if it is in a sleep state, the logs are not uploaded for the time being. If a request is made to upload logs from the primary and secondary devices, the logs from the primary and secondary devices in the first log storage device are uploaded first, and then the status of the secondary device is checked: if the secondary device is in a wake-up state, the logs from the second log storage device are uploaded; if it is in a sleep state, the logs are not uploaded for the time being.

4. The method for storing and retrieving logs of a detachable device according to claim 3, characterized in that: The log upload methods of the second log storage device include: The logs are uploaded directly from the secondary device, then transferred to the first log storage device by the secondary device, and then uploaded by the primary device.

5. The method for storing and retrieving logs of a detachable device according to claim 1, characterized in that: When establishing a communication connection between the secondary device and the primary device, device authentication is performed first, and data transmission is only performed after successful authentication. The authentication includes one or more of device ID matching and preset key verification.

6. The method for storing and retrieving logs of a detachable device according to claim 1, characterized in that: The communication connection between the master device and the slave device transmits log data using a data verification mechanism. This mechanism includes calculating a hash value for the transmitted log data. After receiving the log data, the master device recalculates the hash value and compares it with the hash value sent by the slave device. If they match, the log data transmission is confirmed to be complete; otherwise, retransmission is triggered.

7. The method for storing and retrieving logs of a detachable device according to claim 1, characterized in that: The first log storage device is used to store the main device logs and the transferred secondary device logs, and the second log storage device is used to store the logs generated by the secondary device; the log type in the log retrieval request issued by the server unit determines the range of uploaded logs, and the preset log upload strategy is adapted to the wake-up or sleep state of the secondary device.

8. The method for storing and retrieving logs of a detachable device according to claim 1, characterized in that: When the server sends a log retrieval request, the following steps are also included: The fetching cycle is determined according to a preset time strategy, which is dynamically adjusted based on device usage frequency, log generation volume, or frequency of historical abnormal events. Priority weights are assigned to different types of logs, and these priority weights are used to determine the order in which logs are uploaded when network bandwidth is limited. The pull request includes encryption parameters, which are used to perform end-to-end encryption on the uploaded log data.

9. A detachable device log processing system, characterized in that, Based on any one of claims 1 to 8, comprising: A detachable device unit, comprising a main device unit and a secondary device unit, wherein the secondary device unit can form an integrated device unit with the main device unit; The main device unit is equipped with a first log storage device, and the secondary device unit is equipped with a second log storage device. The main device unit and the secondary device unit communicate with each other through any one or more combinations of physical wired connection, wireless Bluetooth connection, and Wi-Fi wireless connection. The server unit is used to issue log retrieval requests and receive uploaded logs; The auxiliary device unit is configured to perform a log transfer operation when a preset condition is met, and to perform data compression and log deletion operations before and after the transfer, respectively. The main device unit and the secondary device unit are configured to perform corresponding log upload operations based on the server unit's pull request and log type. The system also includes an analysis unit for classifying, storing, and analyzing logs uploaded to the server unit. The analysis includes one or more of the following: log content keyword extraction, abnormal log level assessment, and log trend statistics.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to execute the computer program according to any one of claims 1 to 8.

Images