CN113296993A - Client log recovery method and device, computer equipment and storage medium - Google Patents
Client log recovery method and device, computer equipment and storage medium Download PDFInfo
- Publication number
- CN113296993A CN113296993A CN202110479275.8A CN202110479275A CN113296993A CN 113296993 A CN113296993 A CN 113296993A CN 202110479275 A CN202110479275 A CN 202110479275A CN 113296993 A CN113296993 A CN 113296993A
- Authority
- CN
- China
- Prior art keywords
- log
- client
- information
- uploaded
- uploading
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0781—Error filtering or prioritizing based on a policy defined by the user or on a policy defined by a hardware/software module, e.g. according to a severity level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
Abstract
The application relates to the field of log collection, in particular to a method and a device for recovering a client log, computer equipment and a storage medium. The method comprises the following steps: when the client side SDK is started, the client side SDK sends verification information to the background server, wherein the verification information is information which is provided for the background server and used for distinguishing different client sides; receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client meets the log uploading condition or not; after determining that the client meets the log uploading condition based on the verification result, acquiring a client log needing to be uploaded from the local; and uploading the client log to a log server. The embodiment of the invention can accurately recycle the log of the client with problems, improve the recycling efficiency of the log of the client and further improve the speed of troubleshooting the problems by background personnel.
Description
Technical Field
The present application relates to the field of log collection, and in particular, to a method and an apparatus for recovering a client log, a computer device, and a storage medium.
Background
The following statements are merely provided to provide background information related to the present disclosure and may not necessarily constitute prior art.
The user may have problems in the process of using the client, for example, taking the game client as an example, problems such as failure in logging in the game, abnormal value-storing process, constant value-storing and list-losing interface popping up by the client, abnormal limited purchase of part of commodities, abnormal data reporting and the like may occur in the use process, and in order to find out the reason causing the problems more quickly and accurately, the log generated by the client needs to be recycled to be analyzed by background personnel for problem troubleshooting.
At present, a client log recovery method generally includes that a user actively contacts a client provider (such as a developer, a customer service person, and the like) after a problem occurs in a client and informs the client provider of a fault condition occurring, the client provider teaches the user how to submit the client log to a background, but the client log submission difficulty is high, not every user can operate, and the method for obtaining the client log by matching the user is low in efficiency and cannot achieve rapid troubleshooting. Another way is to inquire and record the user account of the user after the user actively feeds back the problem, and then subsequently detect each logged user account through the background server to determine whether the logged user account is the user account of the user, if so, the background server sends an instruction to the client of the relevant user account to instruct the client to upload the log thereof, however, in this way, the user account is used as a basis for determining whether the log of the client needs to be acquired, which may cause the acquired log of the client not to come from the client with the problem (for example, after the client in the a mobile phone is abnormal, the log of the client in the B mobile phone is logged on the normal client in the B mobile phone, the log acquired by the background server is the log of the client in the B mobile phone, which may reduce the recovery efficiency of the log of the client, thereby affecting the speed of the background personnel for troubleshooting problems.
Disclosure of Invention
The embodiment of the invention can accurately recover the logs of the client with problems, improve the recovery efficiency of the logs of the client and further improve the speed of troubleshooting of background personnel.
The present invention provides, according to a first aspect, a method for client log reclamation, which in one embodiment includes:
when the client side SDK is started, the client side SDK sends verification information to the background server, wherein the verification information is information which is provided for the background server and used for distinguishing different client sides;
receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client meets the log uploading condition or not;
and after determining that the client meets the log uploading condition based on the verification result, locally acquiring a client log needing to be uploaded, and uploading the client log to a log server.
In one embodiment, the step of obtaining the client log needing to be uploaded from the local and uploading the client log to the log server includes:
checking whether the client logs which are not uploaded completely exist locally; the client log which is not uploaded is the client log which is determined by the client SDK when the client is started last time and needs to be uploaded;
when determining that no client log which is not uploaded is available locally, determining a log corresponding to a locally stored client as a client log which needs to be uploaded, and uploading the log corresponding to the client to a log server;
when determining that the unfinished uploaded client logs exist locally, determining the unfinished uploaded client logs as client logs needing to be uploaded, acquiring breakpoint continuous transmission information corresponding to the unfinished uploaded client logs, and continuously uploading the unfinished uploaded client logs to a log server according to the breakpoint continuous transmission information; and the breakpoint continuous transmission information is used for recording the uploading progress of the client log which is not uploaded.
In one embodiment, the step of uploading the log corresponding to the client to the log server includes:
compressing the log corresponding to the client to obtain a log compression packet;
creating breakpoint continuous transmission information corresponding to the log compression packet;
and uploading the log compression packet fragments to a log server, wherein before the log compression packet is completely uploaded to the log server, the uploading progress of the log compression packet is recorded in breakpoint continuous transmission information corresponding to the log compression packet, and after the log compression packet is completely uploaded to the log server, the log compression packet and the breakpoint continuous transmission information corresponding to the log compression packet are deleted.
In one embodiment, the step of uploading the log compressed packet fragments to the log server comprises:
acquiring slice size requirement information from a background server from a local place;
dividing the log compressed packet into a plurality of log slices according to the slice size requirement information;
and uploading the plurality of log slices to a log server respectively, wherein after any log slice is uploaded, the uploading progress of the log compression packet recorded in the breakpoint continuous transmission information corresponding to the log compression packet is updated.
In one embodiment, the method further comprises: during the operation of the client, regularly detecting whether log information with the corresponding generation time length exceeding a preset time length threshold exists in a log corresponding to the locally stored client, and deleting the log information when the log information is determined to exist.
In one embodiment, the client-corresponding log includes a log generated by the client SDK and/or a log generated by the client program itself.
In one embodiment, the verification information includes a client program identifier of the client, an equipment identifier of the equipment where the client is located, and an operating system identifier; the white list information is a client program identifier, an equipment identifier and an operating system identifier configured on the background server by background personnel, or the client program identifier, the equipment identifier and the operating system identifier of the client corresponding to the abnormal login data, which are acquired by the background server after monitoring the abnormal login data.
The present invention provides according to a second aspect a client log reclamation apparatus, which in one embodiment comprises:
the system comprises a check information sending module, a background server and a client side SDK, wherein the check information sending module is used for sending check information to the background server when the client side is started through the client side SDK, and the check information is information which is provided for the background server and is used for distinguishing different client sides;
the check result receiving module is used for receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of white list information which is pre-configured; the verification result is used for representing whether the client meets the log uploading condition or not;
and the log uploading module is used for acquiring the client log needing to be uploaded from the local and uploading the client log to the log server after the client is determined to accord with the log uploading condition based on the verification result.
The invention provides a client log recovery method according to a third aspect, which is applied to a background server, and in one embodiment, the method comprises the following steps:
receiving verification information sent by a client side SDK, wherein the verification information is information which is sent by the client side SDK when the client side SDK is started and used for distinguishing different client sides;
matching the check information with at least one piece of pre-configured white list information, and generating a check result based on the matching result; the check result is used for representing whether the client side meets the log uploading condition or not;
and returning the check result to the client side SDK so that the client side SDK determines whether the client side meets the log uploading condition or not based on the check result, and after determining that the client side meets the log uploading condition based on the check result, acquiring a client side log needing to be uploaded from the local part of the client side and uploading the client side log to a log server.
The present invention provides a method for recovering a log at a client according to a fourth aspect, wherein the method is applied to a log server, and in one embodiment, the method comprises the following steps:
receiving a client log uploaded by a client SDK; the client log is a client log which is acquired from the local part of the client and needs to be uploaded after the client meets the log uploading condition on the basis of the verification result after the client receives the verification result returned by the background server and determines whether the client meets the log uploading condition on the basis of the verification result; the check information is provided for the background server and used for distinguishing different clients; the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the check result is used for representing whether the client side meets the log uploading condition or not;
and analyzing the client log to obtain a log analysis result.
The present invention provides according to a fifth aspect a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of any of the above-described embodiments of the method when executing the computer program.
The present invention provides according to a sixth aspect a computer readable storage medium having stored thereon a computer program which, when executed by a processor, carries out the steps of an embodiment of any of the methods described above.
The embodiment of the invention implants the SDK for recovering the log in the client, triggers the log recovery check logic of the SDK when the client is started (namely, sends check information to the background server, returns the check information based on the background server, matches the check information with at least one piece of pre-configured white list information, and judges whether the client meets the log uploading condition based on the check result generated by the matching result, wherein the check information is the information which is provided by the SDK to the background server and is used for distinguishing different clients, so that the background server can accurately judge whether the client where the SDK is located belongs to the client with problems or not), executes the log uploading logic (namely, locally acquires the log of the client which needs to be uploaded and uploads the log to the log server) after the SDK confirms that the client where the SDK is located meets the condition, therefore, the problem log of the client with the problem can be accurately recovered, the recovery efficiency of the client log is improved, and the problem troubleshooting speed of background personnel is further improved.
Drawings
FIG. 1 is a diagram of an application environment for a method for client log reclamation in one embodiment;
FIG. 2 is a flowchart illustrating a method for recovering logs at a client in one embodiment;
FIG. 3 is a schematic flow chart illustrating a process for determining a client log to be uploaded according to an embodiment;
FIG. 4 is a schematic flow chart illustrating uploading of a log corresponding to a client in one embodiment;
FIG. 5 is a block diagram of an embodiment of a client log reclamation apparatus;
FIG. 6 is a diagram illustrating an internal structure of a computer device according to an embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
Example one
The invention provides a method for recovering a client log. In one embodiment, the client log reclamation method may be applied in an application environment as shown in FIG. 1. In the application environment, a user terminal is installed with a client (program) in which an SDK (hereinafter referred to as a client SDK) for recovering logs is integrated (Software Development Kit), and when a user opens the client in the user terminal, the client SDK executes log recovery check logic, that is, sending check information to the background server, and based on the check result returned by the background server (the background server matches the check information received by the background server with at least one piece of white list information pre-configured and generates based on the matching result), judging whether the client side meets the log uploading condition, when the client SDK determines that the client where the client is located conforms to the condition, the log uploading logic is executed, that is, the client log to be uploaded is obtained locally (referring to the storage space of the user terminal), and is uploaded to the log server. The client side SDK transmits the verification information to the background server, and the background server can be used for judging whether the client side where the client side SDK is located belongs to a client side (or called an abnormal client side) with problems or not. The user terminal may include, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, desktop computers, and the like, and the background server and the log server may be deployed in the same physical server or may be deployed in different physical servers.
The method for recovering the client log provided by the embodiment includes the steps shown in fig. 2, that is, the method includes:
s110: and when the client side SDK is started, the client side SDK sends verification information to the background server.
The check information is information provided to the background server for distinguishing different clients, and may be a client program identifier of the client, a device identifier of a device where the client is located, and an operating system identifier. The client program identifier may refer to a package name of the client installation package, and may further include a program name (such as WeChat, Daoshike sword, etc.) and a program identifier (App ID) of the client; the Equipment Identity may be an MEID (Mobile Equipment Identifier) and/or an IMEI (International Mobile Equipment Identity) of the Equipment; the os identification may be the name of the os (e.g., iOS, Huawei LiteOS, etc.) installed by the user equipment, and may also include a system version number.
Specifically, the client SDK may submit the verification information to the background server through an API interface reserved in the background server, invoke the background server to verify the verification information, and return a verification result.
S120: and receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result.
The check result is used to characterize whether the client meets the log uploading condition, for example, 1 indicates that the log uploading condition is met, and 0 indicates that the log uploading condition is not met. After receiving the check information transmitted by the client SDK, the background server matches the check information with the preconfigured white list information one by one, wherein the number of the preconfigured white list information is at least one, if none of the preconfigured white list information is matched with the check information, the client is determined not to be in accordance with the log uploading condition, and information (such as 0) used for representing that the client is not in accordance with the log uploading condition is sent to the client SDK; otherwise, if one of the preconfigured white list information is matched with the check information, determining that the client meets the log uploading condition, and sending information (such as 1) for representing that the client meets the log uploading condition to the client SDK.
The white list information may be a client program identifier, a device identifier, and an operating system identifier. If the information items in a certain piece of white list information (namely the information items of the client program identification, the equipment identification and the operating system identification) and the information items in the verification information are the same, the white list information and the verification information are determined to be matched, otherwise, the white list information and the verification information are determined to be unmatched.
Further, the white list information may refer to information configured in a white list, and the white list may be implemented as a table.
For example, the white list may be as shown in table one, wherein two pieces of white list information, that is, information corresponding to sequence number 1 and sequence number 2, are configured:
table one:
| serial number | Client program identification | Device identification | Operating system identification |
| 1 | Jar_1 | IMEI_1 | iOS |
| 2 | Jar_2 | IMEI_2 | Huawei LiteOS |
Further, the white list information may be manually configured in the white list by background personnel, or may be automatically configured in the white list by a background server, for example, a processing logic may be developed for the background server, that is, the background server monitors login data of each user account, and if it is found that monitoring data of a certain user account is abnormal, a client program identifier, a device identifier, and an operating system identifier of a client corresponding to the monitoring data are collected, and then these items of information are configured in the white list as a piece of white list information.
S130: and after determining that the client meets the log uploading condition based on the verification result, acquiring the client log needing to be uploaded from the local, and uploading the client log needing to be uploaded to a log server.
A locally stored client log (i.e., a log corresponding to the client) may be a log file in a log format (certainly, the log may also be a file in another format, which is not limited in this embodiment), behavior information (or referred to as log information) of all behaviors or part of specified behaviors (for example, only abnormal behaviors are recorded) executed by the client during the operation period may be recorded in the log file, and the behavior information recorded each time includes generation time (i.e., time for recording the behavior information in the log file), so that a relevant person performs analysis after the log is recovered. Further, the longer the running period of the client is, the more behavior information recorded in the log file will be, which will occupy more and more storage space of the user terminal, so that the client SDK or the client itself can periodically detect whether log information whose corresponding generation duration (i.e. difference between current time and generation time corresponding to the log information) exceeds the preset duration threshold exists in a locally stored log corresponding to the client during the running period of the client, and delete the log information when determining that log information whose generation duration exceeds the preset duration threshold exists, so as to reduce the occupied storage space. The frequency of the timing detection and the preset time threshold can be flexibly adjusted according to the requirements of different scenes, and this embodiment does not limit this.
In particular, the client log may be a log generated by the client SDK and/or a log generated by the client program itself. In one possible scenario, the logs generated by the client SDK and the logs generated by the client program themselves are analyzed and processed by different teams after being recycled, so that if the client logs include the logs generated by the client SDK and the logs generated by the client program itself, the two types of logs can be recorded in different log files respectively.
In this embodiment, an SDK for recovering logs is implanted in a client, and when the client is started, a log recovery check logic of the SDK is triggered, that is, check information is sent to a background server, and based on a check result returned by the background server, the check information is matched with at least one piece of pre-configured white list information, and based on the check result generated by the matching result, whether the client in which the SDK is located meets a log uploading condition is determined, where the check information is information that the SDK is provided to the background server to distinguish different clients, which enables the background server to accurately determine whether the client in which the SDK is located belongs to a client having a problem, and when the SDK determines that the client in which the SDK is located meets the condition, the client log uploading logic is executed, that is to obtain a client log to be uploaded locally, and the client log is uploaded to a log server (if the client does not meet the log uploading condition based on the check result, and then the log uploading logic is skipped), so that the logs of the client with problems can be accurately recovered, the recovery efficiency of the logs of the client is improved, and the speed of troubleshooting of background personnel is further improved.
The following describes in detail the step of locally acquiring a client log to be uploaded in step S130, and uploading the client log to a log server, as shown in fig. 3, where the step includes:
s131: and checking whether the client logs which are not uploaded completely exist locally.
The client log which is not uploaded is the client log which is determined by the client SDK when the client is started last time and needs to be uploaded.
S132: when determining that no unfinished uploaded client log exists locally, determining a log corresponding to a locally stored client as a client log needing to be uploaded, and uploading the log corresponding to the locally stored client to a log server.
As shown in fig. 4, the step of uploading the log corresponding to the locally stored client to the log server in step S132 may include:
s1321: compressing the log corresponding to the client to obtain a log compression packet;
s1322: creating breakpoint continuous transmission information corresponding to the log compression packet;
s1323: and uploading the log compression packet fragments to a log server, wherein before the log compression packet is completely uploaded to the log server, the uploading progress of the log compression packet is recorded in breakpoint continuous transmission information corresponding to the log compression packet, and after the log compression packet is completely uploaded to the log server, the log compression packet and the breakpoint continuous transmission information corresponding to the log compression packet are deleted.
Before the logs are uploaded to the log server, the logs corresponding to the locally stored client side are compressed and packaged into a compressed packet (namely, the log compressed packet), so that the size of a file to be uploaded can be reduced, and the log recovery speed is further increased. The whole log compression packet can be uploaded during uploading, the log compression packet can also be uploaded in a fragmentation mode, the situation that the log compression packet needs to be uploaded again due to the fact that problems occur in the uploading process is avoided, furthermore, compared with the whole uploading process, the fragmentation uploading operation occupies more resources of a user terminal, such as computing resources, network resources and the like, therefore, logic can be developed for a client side SDK, namely after the log corresponding to the client side is compressed into the log compression packet, the file size of the log compression packet is obtained and compared with a preset threshold value (for example, the preset threshold value is called, and the file size can be adjusted flexibly according to the needs of specific scenes), if the file size of the log compression packet is larger than the preset threshold value, the fragmentation is uploaded, and if the file size of the log compression packet is not larger than the preset threshold value, the whole log compression packet is uploaded.
When the log compressed packet fragments are uploaded, information (called breakpoint resume information) for recording uploading progress needs to be created for the log compressed packet, so that after a problem occurs in the uploading process (for example, some fragments are uploaded in failure and need to be retransmitted, a client is shut down, and the like), the log compressed packet can be continuously uploaded at the break point of the previous uploading according to the information during the retransmission without retransmitting the log compressed packet. The breakpoint resume information can be implemented by a table or a text file.
Further, when the log compression packet is uploaded to the log server, the uploading requirement configuration information sent by the background server is obtained from the local, and the log compression packet is uploaded to the log server according to the uploading requirement configuration information. The configuration information of the uploading requirement can be configured to all the user terminals by background personnel through a background server, and the configuration information of the uploading requirement can be also realized by interaction between the background personnel and clients or client SDKs in all the user terminals through the background server when the configuration information of the uploading requirement is updated. The upload requirement configuration information may include slice size requirement information (for limiting the size of each slice, for example, if the slice is limited to 1MB, the size of each slice is 1MB after the log is compressed and packaged into a packet, etc.), an upload mode (such as synchronous upload or asynchronous upload, etc.), a log level (for example, logs generated by the client and the client SDK have different levels, and a log with a high level may be uploaded preferentially and then a log with a low level may be uploaded) and the like.
When the log compression packet is fragmented, slice size requirement information (for example, the size of each slice is required to be 1MB, which can be flexibly adjusted according to the scene requirement) from a background server is obtained locally, then the log compression packet is divided into a plurality of log slices according to the slice size requirement information, and then the plurality of log slices are uploaded to the log server respectively, wherein after any log slice is uploaded, the uploading progress of the log compression packet recorded in the breakpoint continuous transmission information corresponding to the log compression packet is updated. When the plurality of log slices are respectively uploaded to the log server, the log slices can be uploaded synchronously (that is, one log slice is uploaded and then the next log slice is uploaded) or asynchronously (that is, the plurality of log slices are uploaded simultaneously by multithreading). Each log slice has a corresponding unique sequence number, after all log slices are uploaded by the client side SDK, a file merging request is sent to the log server, the log server is instructed to merge all the received log slices in sequence to obtain a log compression packet, and the log compression packet is decompressed to obtain the client side log which needs to be uploaded, so that background personnel (such as developers, testers or operators and the like which need to analyze the log to troubleshoot problems) can troubleshoot the problems.
After the log compressed packet is completely uploaded to the log server, the log compressed packet and the breakpoint resume information corresponding to the log compressed packet are deleted, so that on one hand, the occupation of the storage space of the user terminal can be reduced, on the other hand, the client SDK is also convenient to check whether the client log which is not uploaded currently exists locally, for example, the checking process of the client SDK may be to scan a folder which is locally used for storing the log of the client, if the log compressed packet or the breakpoint resume information exists in the folder, it can be determined that the client log which is not uploaded currently exists locally, and if the log compressed packet and the breakpoint resume information thereof are not deleted after being uploaded, a plurality of log compressed packets and breakpoint resume information thereof may exist in the folder, and then more complex checking logic needs to be developed for the client SDK.
S133: when determining that the unfinished uploaded client logs exist locally, determining the unfinished uploaded client logs as the client logs needing to be uploaded, acquiring breakpoint continuous transmission information corresponding to the unfinished uploaded client logs, and continuously uploading the unfinished uploaded client logs to a log server according to the breakpoint continuous transmission information.
The breakpoint continuous transmission information is used to record an uploading progress of the unfinished uploaded client log, where the uploading progress may be a proportion (e.g., 60%) of a finished uploading portion in the client log (i.e., the unfinished uploaded client log), and may also be an uploading state (e.g., uploaded, not uploaded, etc.) of each log slice corresponding to the client log in more detail. After obtaining the breakpoint continuous transmission information corresponding to the client log, the client SDK may find an interruption point uploaded last time, and then continuously upload the non-uploaded part of the client log to the log server based on the interruption point, where, for example, there are 100 log slices, the serial numbers of the log slices are numbers 1-100, and the log slices from the 70 th to the 100 th are not yet uploaded, and then continuously upload from the 70 th slice as a starting point.
In a possible implementation manner, the client SDK may also check whether a local client log that is not completed to be uploaded exists before sending the check information to the background server, and send the check information to the background server when determining that the local client log that is not completed to be uploaded does not exist, and if a check result that represents that the client meets the log uploading condition and is returned by the background server is received, determine a log corresponding to the locally stored client as a client log that needs to be uploaded, and upload the log corresponding to the client to the log server; when determining that the unfinished uploaded client logs locally exist, the client logs are not sent to the background server, the unfinished uploaded client logs are directly determined to be the client logs needing to be uploaded, breakpoint continuous transmission information corresponding to the unfinished uploaded client logs is obtained, and the unfinished uploaded client logs are continuously uploaded to the log server according to the breakpoint continuous transmission information.
Fig. 2, fig. 3, and fig. 4 are schematic flow diagrams of a client log recovery method in an embodiment. It should be understood that although the steps in the flowcharts of fig. 2, 3 and 4 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2, 3, and 4 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performing the sub-steps or stages is not necessarily sequential, but may be performed alternately or alternatingly with other steps or at least some of the sub-steps or stages of other steps.
Example two
Based on the same inventive concept as the first embodiment, the invention further provides a client log recovery device, which can accurately recover the logs of the clients with problems, improve the recovery efficiency of the logs of the clients and further improve the speed of troubleshooting of background personnel.
As shown in fig. 5, the client log recycling apparatus provided in this embodiment includes the following modules:
the verification information sending module 110 is configured to send verification information to the background server when the client is started through the client SDK, where the verification information is information provided to the background server and used for distinguishing different clients;
the verification result receiving module 120 is configured to receive a verification result returned by the background server, where the verification result is generated by the background server matching the received verification information with at least one piece of white list information configured in advance, and based on the matching result; the verification result is used for representing whether the client meets the log uploading condition or not;
and the log uploading module 130 is configured to, after determining that the client meets the log uploading condition based on the verification result, obtain a client log to be uploaded from the local, and upload the client log to the log server.
The verification information comprises a client program identifier of the client, an equipment identifier of equipment where the client is located and an operating system identifier; the white list information is a client program identifier, an equipment identifier and an operating system identifier configured on the background server by background personnel, or the client program identifier, the equipment identifier and the operating system identifier of the client corresponding to the abnormal login data, which are acquired by the background server after monitoring the abnormal login data.
Wherein, the log uploading module includes:
the checking submodule is used for checking whether the client logs which are not uploaded exist locally; the client log which is not uploaded is the client log which is determined by the client SDK when the client is started last time and needs to be uploaded;
the first uploading submodule is used for determining a locally stored log corresponding to the client as a client log needing to be uploaded when the fact that the client log which is not uploaded exists locally is determined, and uploading the log corresponding to the client to a log server;
the second uploading submodule is used for determining the unfinished uploaded client logs as the client logs needing to be uploaded when the unfinished uploaded client logs are determined to be locally present, acquiring breakpoint continuous transmission information corresponding to the unfinished uploaded client logs, and continuously uploading the unfinished uploaded client logs to the log server according to the breakpoint continuous transmission information; and the breakpoint continuous transmission information is used for recording the uploading progress of the client log which is not uploaded.
Wherein, the first upload submodule includes:
the compression unit is used for compressing the log corresponding to the client to obtain a log compression packet;
the information creating unit is used for creating breakpoint continuous transmission information corresponding to the log compression packet;
and the uploading unit is used for uploading the log compression packet fragments to the log server, wherein before the log compression packet is completely uploaded to the log server, the uploading progress of the log compression packet is recorded in the breakpoint continuous transmission information corresponding to the log compression packet, and after the log compression packet is completely uploaded to the log server, the log compression packet and the breakpoint continuous transmission information corresponding to the log compression packet are deleted.
In an embodiment, when the uploading unit is configured to upload the log compressed packet fragments to the log server, the uploading unit is specifically configured to:
acquiring slice size requirement information from a background server from a local place;
dividing the log compressed packet into a plurality of log slices according to the slice size requirement information;
and uploading the plurality of log slices to a log server respectively, wherein after any log slice is uploaded, the uploading progress of the log compression packet recorded in the breakpoint continuous transmission information corresponding to the log compression packet is updated.
In one embodiment, the client log reclamation apparatus further comprises a timing detection module.
And the timing detection module is used for detecting whether log information with the corresponding generation time length exceeding a preset time length threshold exists in the locally stored log corresponding to the client in a timing mode during the operation period of the client, and deleting the log information when the log information exists.
The log corresponding to the client comprises a log generated by the client SDK and/or a log generated by the client program.
In an embodiment, before sending the check information to the background server through the client SDK, the check information sending module may first check whether there is a client log that is not finished uploading locally, and when determining that there is no client log that is not finished uploading locally, send the check information to the background server. If the verification result receiving module receives a verification result which is returned by the background server and represents that the client meets the log uploading condition, the log uploading module determines the locally stored log corresponding to the client as the client log needing to be uploaded, and uploads the log corresponding to the client to the log server; if the check information sending module determines that the unfinished uploaded client logs locally exist through the client SDK, the check information is not sent to the background server, the log uploading module can be indicated to directly determine the unfinished uploaded client logs as the client logs needing to be uploaded, then breakpoint continuous transmission information corresponding to the unfinished uploaded client logs is obtained, and the unfinished uploaded client logs are continuously uploaded to the log server according to the breakpoint continuous transmission information.
For specific limitations of the client log recovery apparatus and technical effects that can be generated by the client log recovery apparatus, reference may be made to limitations of the client log recovery method in the first embodiment, which is not described herein again. All or part of the modules in the client log recovery device can be realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
EXAMPLE III
The embodiment provides another client log recycling method, which can be applied to the background server shown in fig. 1, and the method includes the following steps:
receiving verification information sent by a client side SDK, wherein the verification information is information which is sent by the client side SDK when the client side SDK is started and used for distinguishing different client sides;
matching the check information with at least one piece of pre-configured white list information, and generating a check result based on the matching result; the check result is used for representing whether the client side meets the log uploading condition or not;
and returning the check result to the client side SDK so that the client side SDK determines whether the client side meets the log uploading condition or not based on the check result, and after determining that the client side meets the log uploading condition based on the check result, acquiring a client side log needing to be uploaded from the local part of the client side and uploading the client side log to a log server.
For specific limitations of the client log recovery method and technical effects that can be generated by the client log recovery method provided by this embodiment, reference may be made to limitations of the client log recovery method in the first embodiment, which is not described herein again.
Example four
The present embodiment provides another client log recycling method, which may be applied to the log server shown in fig. 1, and in one embodiment, the method includes:
receiving a client log uploaded by a client SDK; the client log is a client log which is acquired from the local part of the client and needs to be uploaded after the client meets the log uploading condition on the basis of the verification result after the client receives the verification result returned by the background server and determines whether the client meets the log uploading condition on the basis of the verification result; the check information is provided for the background server and used for distinguishing different clients; the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the check result is used for representing whether the client side meets the log uploading condition or not;
and analyzing the client log to obtain a log analysis result. After receiving the client log, the log server automatically analyzes the log, matches the preset keyword combination (the matching algorithm used for matching can be realized based on a double array AC automaton), generates a matching result and a link for accessing the log after matching is completed, and stores the matching result and the link in a preset database, so that relevant background personnel can download the corresponding client log and the matching result based on the link, analyze the client log and the matching result and troubleshoot problems. Furthermore, when the client log is received or the analysis of the log is completed, relevant background personnel can be asynchronously notified of the bailing condition or the analysis condition of the log, so that the relevant background personnel can further analyze the log.
In one embodiment, the client log is uploaded by the client SDK fragment, the log server stores each received log slice, and after receiving a file merge request of the client SDK, merges all log fragments corresponding to the file merge request in order (i.e., the order corresponding to each log fragment), so as to obtain a complete client log. Further, the merged file may be a compressed client log, so it needs to be decompressed before being analyzed.
For specific limitations of the client log recovery method and technical effects that can be generated by the client log recovery method provided by this embodiment, reference may be made to limitations of the client log recovery method in the first embodiment, which is not described herein again.
EXAMPLE five
In the present embodiment, a computer device is provided, and its internal structure diagram may be as shown in fig. 6. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing data such as client logs, configuration information, and the like, and the specific stored data may also refer to the limitations in the above method embodiments. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a client log reclamation method.
Those skilled in the art will appreciate that the architecture shown in fig. 6 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
The embodiment also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the following steps are implemented:
when the client side SDK is started, the client side SDK sends verification information to the background server, wherein the verification information is information which is provided for the background server and used for distinguishing different client sides; receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client meets the log uploading condition or not; and after determining that the client meets the log uploading condition based on the verification result, locally acquiring a client log needing to be uploaded, and uploading the client log to a log server.
In one embodiment, the processor executes the computer program to obtain the client log needing to be uploaded from the local, and when uploading the client log to the log server, the following steps are also implemented:
checking whether the client logs which are not uploaded completely exist locally; the client log which is not uploaded is the client log which is determined by the client SDK when the client is started last time and needs to be uploaded; when determining that no client log which is not uploaded is available locally, determining a log corresponding to a locally stored client as a client log which needs to be uploaded, and uploading the log corresponding to the client to a log server; when determining that the unfinished uploaded client logs exist locally, determining the unfinished uploaded client logs as client logs needing to be uploaded, acquiring breakpoint continuous transmission information corresponding to the unfinished uploaded client logs, and continuously uploading the unfinished uploaded client logs to a log server according to the breakpoint continuous transmission information; and the breakpoint continuous transmission information is used for recording the uploading progress of the client log which is not uploaded.
In one embodiment, when the processor executes the computer program to upload the log corresponding to the client to the log server, the following steps are further implemented:
compressing the log corresponding to the client to obtain a log compression packet; creating breakpoint continuous transmission information corresponding to the log compression packet; and uploading the log compression packet fragments to a log server, wherein before the log compression packet is completely uploaded to the log server, the uploading progress of the log compression packet is recorded in breakpoint continuous transmission information corresponding to the log compression packet, and after the log compression packet is completely uploaded to the log server, the log compression packet and the breakpoint continuous transmission information corresponding to the log compression packet are deleted.
In one embodiment, the processor executes the computer program to realize that when the log compressed packet fragments are uploaded to the log server, the following steps are further realized:
acquiring slice size requirement information from a background server from a local place; dividing the log compressed packet into a plurality of log slices according to the slice size requirement information; and uploading the plurality of log slices to a log server respectively, wherein after any log slice is uploaded, the uploading progress of the log compression packet recorded in the breakpoint continuous transmission information corresponding to the log compression packet is updated.
In one embodiment, the processor, when executing the computer program, further performs the steps of:
during the operation of the client, regularly detecting whether log information with the corresponding generation time length exceeding a preset time length threshold exists in a log corresponding to the locally stored client, and deleting the log information when the log information is determined to exist.
EXAMPLE six
In the present embodiment, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of:
when the client side SDK is started, the client side SDK sends verification information to the background server, wherein the verification information is information which is provided for the background server and used for distinguishing different client sides; receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client meets the log uploading condition or not; and after determining that the client meets the log uploading condition based on the verification result, locally acquiring a client log needing to be uploaded, and uploading the client log to a log server.
In one embodiment, the computer program is executed by a processor, and when the client log needing to be uploaded is obtained from the local and uploaded to a log server, the following steps are further implemented:
checking whether the client logs which are not uploaded completely exist locally; the client log which is not uploaded is the client log which is determined by the client SDK when the client is started last time and needs to be uploaded; when determining that no client log which is not uploaded is available locally, determining a log corresponding to a locally stored client as a client log which needs to be uploaded, and uploading the log corresponding to the client to a log server; when determining that the unfinished uploaded client logs exist locally, determining the unfinished uploaded client logs as client logs needing to be uploaded, acquiring breakpoint continuous transmission information corresponding to the unfinished uploaded client logs, and continuously uploading the unfinished uploaded client logs to a log server according to the breakpoint continuous transmission information; and the breakpoint continuous transmission information is used for recording the uploading progress of the client log which is not uploaded.
In one embodiment, when the computer program is executed by a processor and uploads a log corresponding to a client to a log server, the following steps are further implemented:
compressing the log corresponding to the client to obtain a log compression packet; creating breakpoint continuous transmission information corresponding to the log compression packet; and uploading the log compression packet fragments to a log server, wherein before the log compression packet is completely uploaded to the log server, the uploading progress of the log compression packet is recorded in breakpoint continuous transmission information corresponding to the log compression packet, and after the log compression packet is completely uploaded to the log server, the log compression packet and the breakpoint continuous transmission information corresponding to the log compression packet are deleted.
In one embodiment, the computer program is executed by a processor, and when uploading the log compressed packet fragments to a log server, further implements the following steps:
acquiring slice size requirement information from a background server from a local place; dividing the log compressed packet into a plurality of log slices according to the slice size requirement information; and uploading the plurality of log slices to a log server respectively, wherein after any log slice is uploaded, the uploading progress of the log compression packet recorded in the breakpoint continuous transmission information corresponding to the log compression packet is updated.
In one embodiment, the computer program, when executed by the processor, further implements the steps of:
during the operation of the client, regularly detecting whether log information with the corresponding generation time length exceeding a preset time length threshold exists in a log corresponding to the locally stored client, and deleting the log information when the log information is determined to exist.
It will be understood by those skilled in the art that all or part of the processes of the embodiments of the methods described above can be implemented by a computer program, which can be stored in a non-volatile computer-readable storage medium, and can include the processes of the embodiments of the methods described above when the computer program is executed. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (12)
1. A method for client log reclamation, the method comprising:
when a client side SDK is started, sending verification information to a background server, wherein the verification information is information which is provided for the background server and used for distinguishing different client sides;
receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client side meets the log uploading condition or not;
and after determining that the client meets the log uploading condition based on the verification result, locally acquiring a client log needing to be uploaded, and uploading the client log to a log server.
2. The method of claim 1, wherein the step of locally obtaining a client log to be uploaded, and uploading the client log to a log server, comprises:
checking whether the client logs which are not uploaded completely exist locally; the client log which is not uploaded is the client log which is determined by the client SDK when the client is started last time and needs to be uploaded;
when determining that no client log which is not uploaded is available locally, determining a log corresponding to a locally stored client as a client log which needs to be uploaded, and uploading the log corresponding to the client to a log server;
when determining that the unfinished uploaded client logs exist locally, determining the unfinished uploaded client logs as client logs needing to be uploaded, acquiring breakpoint continuous transmission information corresponding to the unfinished uploaded client logs, and continuously uploading the unfinished uploaded client logs to a log server according to the breakpoint continuous transmission information; and the breakpoint continuous transmission information is used for recording the uploading progress of the client log which is not uploaded.
3. The method of claim 2, wherein the step of uploading the log corresponding to the client to a log server comprises:
compressing the log corresponding to the client to obtain a log compression packet;
creating breakpoint continuous transmission information corresponding to the log compression packet;
uploading the log compression packet fragments to a log server, wherein before the log compression packet is completely uploaded to the log server, the uploading progress of the log compression packet is recorded in breakpoint continuous transmission information corresponding to the log compression packet, and after the log compression packet is completely uploaded to the log server, the log compression packet and the breakpoint continuous transmission information corresponding to the log compression packet are deleted.
4. The method of claim 3, wherein the uploading the log compressed packet fragments to a log server comprises:
acquiring slice size requirement information from the background server from the local;
dividing the log compressed packet into a plurality of log slices according to the slice size requirement information;
and uploading the plurality of log slices to a log server respectively, wherein after any log slice is uploaded, the uploading progress of the log compression packet recorded in the breakpoint continuous transmission information corresponding to the log compression packet is updated.
5. The method of claim 1, wherein the method further comprises:
and during the running period of the client, regularly detecting whether log information with the corresponding generation time length exceeding a preset time length threshold exists in a locally stored log corresponding to the client, and deleting the log information when the log information is determined to exist.
6. The method of claim 5, wherein the client-corresponding log comprises a log generated by the client SDK and/or a log generated by the client program itself.
7. The method of claim 1, wherein the verification information comprises a client program identifier of the client, a device identifier of a device on which the client is located, and an operating system identifier; the white list information is client program identification, equipment identification and operating system identification configured on the background server by background personnel, or the client program identification, the equipment identification and the operating system identification of the client corresponding to the abnormal login data are acquired by the background server after the abnormal login data are monitored.
8. An apparatus for client log reclamation, the apparatus comprising:
the system comprises a check information sending module, a background server and a client side SDK, wherein the check information sending module is used for sending check information to the background server when the client side is started through the client side SDK, and the check information is information which is provided for the background server and is used for distinguishing different client sides;
the check result receiving module is used for receiving a check result returned by the background server, wherein the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client side meets the log uploading condition or not;
and the log acquisition module is used for acquiring the client log needing to be uploaded from the local and uploading the client log to a log server after the client is determined to accord with the log uploading condition based on the verification result.
9. A method for client log reclamation, the method comprising:
receiving verification information sent by a client side SDK, wherein the verification information is information which is sent by the client side SDK when the client side SDK is started and used for distinguishing different client sides;
matching the check information with at least one piece of pre-configured white list information, and generating a check result based on the matching result; the verification result is used for representing whether the client side meets the log uploading condition or not;
and returning the check result to the client side SDK so that the client side SDK determines whether the client side meets the log uploading condition or not based on the check result, and after determining that the client side meets the log uploading condition based on the check result, acquiring the client side log needing to be uploaded from the local part of the client side and uploading the client side log to a log server.
10. A method for client log reclamation, the method comprising:
receiving a client log uploaded by a client SDK; the client side log is a client side log which is acquired from the local part of the client side and needs to be uploaded after the client side SDK is started at the client side and whether the client side meets the log uploading condition or not is determined based on the verification result after the client side SDK receives the verification result returned by the background server; the check information is provided for the background server and used for distinguishing different clients; the check result is generated by the background server matching the received check information with at least one piece of pre-configured white list information and based on the matching result; the verification result is used for representing whether the client side meets the log uploading condition or not;
and analyzing the client log to obtain a log analysis result.
11. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method of any of claims 1 to 9 are implemented when the computer program is executed by the processor.
12. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110479275.8A CN113296993A (en) | 2021-04-30 | 2021-04-30 | Client log recovery method and device, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110479275.8A CN113296993A (en) | 2021-04-30 | 2021-04-30 | Client log recovery method and device, computer equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113296993A true CN113296993A (en) | 2021-08-24 |
Family
ID=77320750
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110479275.8A Pending CN113296993A (en) | 2021-04-30 | 2021-04-30 | Client log recovery method and device, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113296993A (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113568884A (en) * | 2021-09-26 | 2021-10-29 | 武汉四通信息服务有限公司 | File management method and device, electronic equipment and storage medium |
| CN113687974A (en) * | 2021-10-22 | 2021-11-23 | 飞狐信息技术（天津）有限公司 | Client log processing method and device and computer equipment |
| CN115037736A (en) * | 2022-04-27 | 2022-09-09 | 浪潮通信技术有限公司 | Log collection method and log collection device |
| CN115344539A (en) * | 2022-10-12 | 2022-11-15 | 北京奥星贝斯科技有限公司 | Log space recovery method and device for distributed database |
| CN115550345A (en) * | 2022-08-18 | 2022-12-30 | 贵州多彩宝互联网服务有限公司 | Method for mobile equipment offline data acquisition and continuous transmission in disconnected network |
-
2021
- 2021-04-30 CN CN202110479275.8A patent/CN113296993A/en active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113568884A (en) * | 2021-09-26 | 2021-10-29 | 武汉四通信息服务有限公司 | File management method and device, electronic equipment and storage medium |
| CN113687974A (en) * | 2021-10-22 | 2021-11-23 | 飞狐信息技术（天津）有限公司 | Client log processing method and device and computer equipment |
| CN115037736A (en) * | 2022-04-27 | 2022-09-09 | 浪潮通信技术有限公司 | Log collection method and log collection device |
| CN115550345A (en) * | 2022-08-18 | 2022-12-30 | 贵州多彩宝互联网服务有限公司 | Method for mobile equipment offline data acquisition and continuous transmission in disconnected network |
| CN115344539A (en) * | 2022-10-12 | 2022-11-15 | 北京奥星贝斯科技有限公司 | Log space recovery method and device for distributed database |
| CN115344539B (en) * | 2022-10-12 | 2023-02-17 | 北京奥星贝斯科技有限公司 | Log space recovery method and device for distributed database |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113296993A (en) | Client log recovery method and device, computer equipment and storage medium | |
| CN110460571B (en) | Business system vulnerability processing method and device, computer equipment and storage medium | |
| CN110995468B (en) | System fault processing method, device, equipment and storage medium of system to be analyzed | |
| CN110647438B (en) | Event monitoring method and device, computer equipment and storage medium | |
| CN109788032B (en) | Method and device for acquiring mirror image file, computer equipment and storage medium | |
| CN108337296B (en) | Message push processing method and device, computer equipment and storage medium | |
| CN111835756B (en) | APP privacy compliance detection method and device, computer equipment and storage medium | |
| CN110716895A (en) | Target data archiving method and device, computer equipment and medium | |
| CN113505014B (en) | Fault diagnosis file acquisition method and device | |
| CN111143163A (en) | Data monitoring method and device, computer equipment and storage medium | |
| CN111611021A (en) | Log data transmission method and device, computer equipment and storage medium | |
| CN111061628A (en) | Data analysis method, system, device, computer equipment and storage medium | |
| CN109684155B (en) | Monitoring configuration method, device, equipment and readable storage medium | |
| CN108965383B (en) | File synchronization method and device, computer equipment and storage medium | |
| CN109325058B (en) | Rule batch comparison method, device, computer equipment and storage medium | |
| CN111475324A (en) | Log information analysis method and device, computer equipment and storage medium | |
| CN112559364A (en) | Test case generation method and device, computer equipment and storage medium | |
| CN108920357A (en) | Operation system detection method, device, computer equipment and storage medium | |
| CN109324961A (en) | System automatic test approach, device, computer equipment and storage medium | |
| CN110838940B (en) | Underground cable inspection task configuration method and device | |
| CN112256532A (en) | Test interface generation method and device, computer equipment and readable storage medium | |
| CN110555017A (en) | block chain data cleaning method and device, computer equipment and storage medium | |
| CN110598797B (en) | Fault detection method and device, storage medium and electronic device | |
| CN112115060A (en) | Audio test method and system based on terminal | |
| CN111723017A (en) | System capacity testing method and device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |