CN115729479A

CN115729479A - Method and electronic equipment for printing dynamic log

Info

Publication number: CN115729479A
Application number: CN202111003836.3A
Authority: CN
Inventors: 叶炜华; 郑叶剑; 徐阔海
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-08-30
Filing date: 2021-08-30
Publication date: 2023-03-03
Also published as: WO2023029955A1

Abstract

The application provides a method for printing dynamic logs and an electronic device, comprising the following steps: adding a dynamic log interface in a client; acquiring data of the dynamic log through the dynamic log interface; adding data of the dynamic log to a dynamic log section of the client, wherein the dynamic log section comprises the state of the dynamic log; and printing the dynamic log according to the state of the dynamic log. The technical scheme can inquire and print dynamic logs in a cross-address space mode, and can freely configure the state of a single log, so that the efficiency of log printing is improved.

Description

Method and electronic equipment for printing dynamic log

Technical Field

The present application relates to the field of computer operating system logging technology, and more particularly, to a method and an electronic device for printing a dynamic log.

Background

The logs can record related activity information at specific time in the system, and developers can perform positioning, debugging and the like of code bugs (bugs) according to the information provided by the logs, so that the developers want to record more useful logs, but the logs have the characteristics of difficulty in reading and understanding, large data volume, difficulty in obtaining and the like, and the analysis of the related logs by the developers is influenced by the existence of massive logs.

In general, the journal and the microkernel are in the same address space, the journal which is not in the address space cannot be operated, and the user cannot individually configure the printing state of each journal.

Disclosure of Invention

The application provides a method and electronic equipment for printing dynamic logs, and the technical scheme can realize cross-address space inquiry of the printed logs and can freely configure the state of a single log.

In a first aspect, a method for printing a dynamic log is provided, the method comprising: adding a dynamic log interface in a client; acquiring data of the dynamic log through the dynamic log interface; adding the data of the dynamic log to a dynamic log section of the client, wherein the dynamic log section also comprises state information of the dynamic log; and determining whether to print the dynamic log according to the state information of the dynamic log.

In one embodiment of the present application, a user may add a dynamic log interface in a client (process manager), through which all dynamic log point information may be collected, and then add the dynamic log point information to a dynamic log segment, and determine whether to print the dynamic log according to status information of the dynamic log in the dynamic log segment. In the technical scheme, the user can freely configure the state information of the dynamic log according to the requirement, so that the dynamic log can be freely printed according to the state information of the dynamic log in the dynamic log section, and the efficiency of printing the log is improved.

With reference to the first aspect, in certain implementations of the first aspect, the determining whether to print the dynamic log according to the state of the dynamic log includes: and determining whether to print the dynamic log according to the control state.

According to the embodiment of the application, the state information of the dynamic log may include a control state, and the control state may be on or off, so that whether to print the dynamic log may be determined according to the device state.

With reference to the first aspect, in certain implementations of the first aspect, the determining whether to print the dynamic log according to the state information of the dynamic log further includes: and when the control state is on, determining whether to print the dynamic log according to the frequency limiting state information.

It should be understood that the frequency-limited status information may be understood as whether the dynamic log is in a frequency-limited printing status, i.e. the number of times of printing within a preset time is less than or equal to a preset number of times of printing.

With reference to the first aspect, in some implementations of the first aspect, when the control state is on, determining whether to print the dynamic log according to the frequency-limited state information includes: and if the time interval between the current time and the starting time is greater than a first preset time, determining to print the dynamic log.

Thus, if the time interval between the current time and the starting time is greater than the first preset time, the current time is beyond the preset time, and a new printing cycle can be started continuously. According to the technical scheme, frequency-limited printing can be achieved, and therefore data redundancy caused by too much log printing can be avoided.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: and if the time interval between the current time and the starting time is less than or equal to the first preset time, determining whether to print the dynamic log according to the relation between the current printing times and the preset printing times.

In an embodiment of the application, if a time interval between the current time and the start time is less than or equal to a first preset time length, whether the dynamic log is printed or not is determined according to a relation between the current printing times and preset printing times.

Exemplarily, if the current printing times are less than the preset printing times, determining to print the dynamic log; and if the current printing times are larger than or equal to the preset printing times, determining not to print the log.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: inquiring a target log in the corresponding dynamic log section according to an inquiry parameter input by a user; presenting the target log to a user.

Based on the embodiment of the application, the system manager can query the target log in the dynamic log segment in the corresponding process according to the query parameter input by the user.

With reference to the first aspect, in some implementations of the first aspect, the querying a target log in a corresponding dynamic log segment includes: and querying a target log in the corresponding dynamic log section in a cross-process mode.

In the embodiment of the application, the system manager can be placed in a process with cross-process read-write capability, and the system manager can query the target log in the corresponding dynamic log segment in a cross-process manner. It should be understood that the system manager may reside in the processor.

With reference to the first aspect, in certain implementation manners of the first aspect, the pre-storing the target log in a control file, and the querying the target log in the corresponding dynamic log segment includes: and querying the target log from the control file.

It should be understood that the target log may be in a dynamic log segment belonging to a different process.

In the embodiment of the present application, the target log in the process manager is pre-stored in the control file, and the system manager may directly query the target log from the control file. The technical scheme can also realize cross-process query of the target log in the corresponding dynamic log segment.

With reference to the first aspect, in certain implementations of the first aspect, the querying a target log in a corresponding dynamic log segment includes: and querying the target log from the shared memory space, wherein the shared memory space is the shared memory space of a system manager and a process manager.

In this embodiment, each process may share a piece of memory with the system manager, that is, have a shared memory space, so that the target log may be stored in the shared memory space in advance, and the system manager may directly query the target log from the shared memory space. The technical scheme can also realize cross-process query of the target log in the corresponding dynamic log segment.

With reference to the first aspect, in certain implementations of the first aspect, the querying a target log in a corresponding dynamic log segment includes: and querying the target log through a first thread, wherein the first thread is a thread for communicating a process manager and a system manager.

It should be understood that in this embodiment, the process manager may establish a connection with the system management through the first thread, and then the system manager may query the corresponding target log through the first thread. The technical scheme can also realize cross-process query of the target log in the corresponding dynamic log segment.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: updating the state of a target log in the corresponding dynamic log section according to a log state updating instruction input by a user; and presenting the update result of the target log to a user.

In the embodiment of the application, the user can freely change the log state, so that the state configuration can be carried out on each log, the printing on demand can be realized, and the printing efficiency is improved.

With reference to the first aspect, in some implementation manners of the first aspect, the state information of the dynamic log further includes a log space field, and the log space field is used to perform batch control on the dynamic log.

Illustratively, the user can perform batch control on the log through the log space field, such as batch printing or batch close printing.

The log space field may be a tree structure, such as with module a as a node and process a and process B as child nodes.

Illustratively, the user can print all functions under the B file in the module a, and the like, through the log space field.

In a second aspect, an electronic device is provided that includes one or more processors; one or more memories; the one or more memories store one or more computer programs comprising instructions which, when executed by the one or more processors, cause the method of printing dynamic logs as described in the first aspect and any one of its possible implementations to be performed.

In a third aspect, a computer-readable storage medium is provided, having stored thereon computer instructions, which, when executed on a computer, cause a method of printing dynamic logs as described in the first aspect and any one of its possible implementations to be performed.

In a fourth aspect, there is provided a computer program product comprising computer instructions which, when run on a computer, cause the method of printing a dynamic log as described in the first aspect and any one of its possible implementations to be performed.

Drawings

FIG. 1 is a system framework diagram of a dynamic call function.

FIG. 2 is a schematic flow diagram of a method of printing a journal under the system framework diagram of FIG. 1.

Fig. 3 is a system architecture diagram having a limited frequency log printing function.

FIG. 4 is a schematic flow chart diagram of a method of printing logs under the system architecture of FIG. 3.

Fig. 5 is a schematic flow chart of a method of printing logs that reduces the number of duplicate logs.

Fig. 6 is a system architecture diagram of a method for printing a log according to an embodiment of the present application.

Fig. 7 is a diagram illustrating components to which the method for printing a log according to the embodiment of the present disclosure may be applied.

Fig. 8 is a schematic flowchart of a method for adding a log point according to an embodiment of the present application.

Fig. 9 is a schematic flow chart of a method for querying a log according to an embodiment of the present application.

Fig. 10 is a schematic flow chart of a method for updating a log state according to an embodiment of the present application.

FIG. 11 is a schematic flow chart diagram illustrating a method for adding a dynamic log segment in a process manager according to an embodiment of the present application.

Fig. 12 is a schematic flowchart of a method for printing a log according to a log status according to an embodiment of the present application.

Fig. 13 is a schematic flowchart of viewing a dynamic log according to an embodiment of the present application.

Fig. 14 is a schematic flow chart of a method for modifying a log state according to an embodiment of the present application.

FIG. 15 is a schematic flowchart of a method for printing a dynamic log according to an embodiment of the present application.

Detailed Description

Before describing the technical solutions of the present application, some simple descriptions will be made on some terms of art that may be involved in the present application.

Computer system log: in order to maintain the operating status of the system resources, the computer system typically has corresponding date and time stamp information that logs the system's alarm about the daily time or malfunction. However, the computer log redundancy is very large, which makes it very difficult to find and analyze useful information.

A log (log) refers to a collection of certain operations of objects specified by the system and their results in time order. Each log file consists of log records, each describing a separate system event. Typically, the system log is a text file that the user can read directly, containing a timestamp and an information or other information specific to the subsystem.

Message transmission: the computer system is a general term for a type of data communication method between processes or software components. The data to be communicated is abstracted and packaged into 'message', and two or more parties participating in communication realize the transmission of the message between processes or components by calling primitives such as message sending and receiving, so that the data communication is completed.

Data flow graph: a schema data structure reflects the design principle of computational logic and the realization process by expressing the flow direction and the computational relationship of data in the computational logic.

Data flow graph parameters: in the data flow graph, the parameter refers to data carried by a connection edge of a computing node on the graph and used for processing by the computing node or fed back by the computing node.

Address space: representing the amount of memory occupied by any one computer entity.

Microkernel: is an operating system kernel which can provide necessary services; these necessary services include tasks, threads, inter-process communication (IPC), and memory management. All services (including device drivers) run in user mode and processing these services is the same as processing any other program. Since each service only runs in its own address space. These services are protected from each other.

Process (process): the method is a running activity of a program in a computer on a certain data set, is a basic unit for resource allocation and scheduling of a system, and is the basis of an operating system structure. In modern computer architectures designed for threads, a process is a container for a thread and is an entity of a program.

Thread (thread): is the smallest unit that the operating system can perform operation scheduling. It is included in the process and is the actual unit of operation in the process. A thread refers to a single sequential control flow in a process, multiple threads can be concurrently executed in a process, and each thread executes different tasks in parallel.

User mode: the program is not allowed to perform operations requiring privileged states in the processor to avoid operating system crashes. Each process runs in its own user space, while not allowing access to the user space of other programs.

Therefore, developers want to record some useful logs dynamically according to the wishes and discard irrelevant logs.

Generally, a log printing function can be embedded in a place where a log needs to be printed, and the log can be printed when a program runs to the log printing function. Meanwhile, in order to avoid log loss caused by sudden crash and restart of the computer, the log is backed up into the reserved memory, and the log can be taken out for analysis after the restart.

The technical scheme has the advantages of small occupied memory and high running speed, but the problems of more repeated logs and data redundancy can occur.

In response to the above problems, fig. 1 to 5 provide several methods of printing logs.

FIG. 1 is a system framework diagram of a dynamic call function. As shown in fig. 1, the dynamic debug (dynamic debug) function 110 may include a controller (controller) 111, a server (dynamic bg server) 121, and a plurality of clients (clients), such as client 1, client 2, and client 3. The controller 111, the server 121 and the plurality of clients are all located in the kernel address space, i.e. in the same address space.

The controller can be a file and can mainly store the positions used by all dynamic debugging interfaces. The file storage method comprises the information of the path, the code line number, the module name, the function name, the control bit, the log content and the like of the file, and the storage format can be as follows: filename Lineno [ module ] function flags format.

The control bit may include a print or a non-print, for example, a print of 1 and a non-print of 0. The user can achieve the effect of controlling a certain log by modifying the content of the control bit, for example, determining whether the certain log is printed or not, or determining the content included in the prefix printed by the certain log, and the like.

The server is mainly used for collecting information used by dynamic debugging interfaces called in the clients, storing the collected information in the controller, and modifying the control bits in the memory correspondingly after the controller is modified by a user.

The client side can be mainly responsible for using the dynamic debugging interface for printing the log, and can determine the log printing mode according to the control bit of the corresponding log point in the memory.

Referring to (a) of fig. 2, the method may include steps 210 to 230.

And 210, calling a dynamic debugging interface function by the client to generate log point information.

Illustratively, a client developer may add a call dynamic debug interface function in a client code, and when a program of the client runs to the dynamic debug interface function, log point information may be automatically generated, where the log point information may include a file path, a code line number, and the like.

220, the server collects log point information for all clients.

It should be appreciated that the server may collect log point information for all clients according to step 210, and may supplement the log point information with default control bit information, such as print or not, and then may save it in memory.

The server saves a copy of the collected log point information to the controller 230.

And the server backs up all the collected log point information to the controller.

Referring to (b) of fig. 2, the method of the user modifying the control bits may include steps 240 to 260.

The user modifies the control bits of the target log point on the controller 240.

Illustratively, the user modifies the control bit corresponding to the target journal point from "print" to "no print".

It should be understood that the target log point may correspond to one log, or may correspond to multiple logs, for example, multiple logs belonging to the same type, that is, a user may modify a control bit of a certain log individually, or modify control bits of multiple logs in batch.

The server synchronizes the modifications on the controller to memory 250.

The server synchronously modifies in the memory.

And 260, when the client runs to a log point, inquiring the control bit of the log point in the memory, and determining whether to print the log according to the control bit.

The technical scheme can effectively realize the function of dynamically debugging the log switch, can set the prefix of log printing according to the preference of a user, and can solve the problem of log redundancy, but the technical scheme still has some defects, for example, the log and the kernel are positioned in the same address space, the log which is not positioned in the address space cannot be operated, only the log at the debug level can be operated, and the logs at other levels cannot be operated.

Fig. 3 is a diagram of a system architecture with a limited frequency print log function. As shown in fig. 3, the system may include an interface module (printk _ ratelimit), a data module (data block), and a control module (controller).

The interface module is an external interface of the limited frequency printing function, and the interface can automatically generate control data required by the limited frequency printing function during compiling and store the control data in the data module.

The data module is mainly used for storing control data generated by the interface module, and may include information such as printing times, start time, time interval, and limit times, the start time and the printing times are set to 0 by default during initialization, and the interval time and the limit times may be set according to values set by a user in the proc interface.

The control module is mainly used for counting the printing times in the time interval and ensuring that the printing times in the time interval do not exceed the limit times.

FIG. 4 is a schematic flow chart diagram of a method of printing logs under the system architecture of FIG. 3. As shown in fig. 4, the method may include steps 401 to 404.

401, it is determined whether the interval between the current time and the start time is greater than a preset time interval.

It should be understood that the preset time interval may be 1s, 5s, etc., which is not limited in the embodiments of the present application.

If the interval between the current time and the starting time is greater than the preset time interval, step 404 is executed, the starting time is set as the current time, and the log printing times are cleared. If the interval between the current time and the start time is less than or equal to the preset time interval, step 402 is executed.

And 402, judging whether the current printing times are larger than the preset printing times.

It should be understood that the preset number of prints may be changed according to a setting of a user, for example, the preset number of prints is 50, 100, and the like, which is not limited in the embodiment of the present application.

It is to be understood that the initial value of the number of prints may be set to 0.

If the current printing times is greater than or equal to the preset printing times, step 405 is executed to end the printing process. If the current number of printing times is less than the preset number of printing times, step 403 is executed.

403, add 1 to the number of prints and print the log.

It is to be understood that, in the case where the current number of prints is less than the preset number of prints, the number of prints of the log is increased by 1 and the log is printed.

According to the technical scheme, the function of frequency-limited log printing can be effectively realized, the printing frequency can be set according to the requirements of users, and the problem of log redundancy is solved to a certain extent.

Fig. 5 is a schematic flow chart of a method of printing logs that reduces the number of duplicate logs. As shown in fig. 5, the method may include steps 510 through 530.

And 510, calling a log record and judging the type of the log.

The server can call the log record in the system and judge the type of the log according to the type field in the log record.

And 520, if the log is a log of a preset type, scanning whether a log matched with the log exists in the logs of the preset type stored in the local buffer area.

If the server judges that the type of the log belongs to the log of the preset type, whether the log matched with the log exists in the log of the preset type stored in the local buffer area or not can be scanned.

530, if yes, adding one to the repetition number field of the matched log in the buffer; if not, the log is added to the buffer and the number of repetitions field for the log is set to 1.

According to the technical scheme, the number of times of repeated printing of the logs can be effectively reduced, so that the number of the logs can be reduced, but the technical scheme still has some defects, for example, when two or more repeated logs exist, the precedence relationship of the logs can be completely lost, and a user cannot distinguish which log is in front of which log and which log is behind which log, so that the problem positioning and analysis are not facilitated.

In the above technical solutions, the log and the kernel are both in the same address space, and the log not in the address space cannot be operated, and the user cannot individually and freely configure the state of a single log.

In view of this, embodiments of the present application provide a method for printing a log, which may implement querying the print log across address spaces, and may freely configure the state of a single log.

Fig. 6 is a system architecture diagram of a method for printing a log according to an embodiment of the present application. As shown in fig. 6, the system architecture 600 may include a server 610, a controller 620, and a client 630.

The server 610 may mainly record a process calling a dynamic log interface and a segment head address and a segment tail address of a dynamic log segment (. Log) in the process, and when the controller 620 sends a signal for modifying a dynamic log state, the server may modify or notify that a state of a log point in a corresponding process is modified.

The controller 620 may interact with a user and provide a user interface through which the user can modify the state of the dynamic log individually or in batches.

The client 630 generates some dynamic log information when calling the dynamic log interface, and collects the dynamic log information in a dynamic log segment (. Log), and when the client program runs to the dynamic log, the client program can query the state of the local corresponding log and determine whether to print the log according to the state.

The client may include a dynamic log segment for storing information required by the dynamic log, for example, the dynamic log segment may include information such as a file name, a function name, a code line number, a module name, and a control bit, that is, the dynamic log may allow control of different levels, not only at the debug level. The dynamic log segment may include dynamic log 1 through dynamic log n.

In addition, the dynamic log segment can also include a log space field through which a user can perform batch control on the log, such as batch printing or batch close printing.

Illustratively, the user can print all functions under the B file in the module a, etc. through the log space field.

Some of the hardware associated with embodiments of the present application may include: an arithmetic unit, a controller, a Central Processing Unit (CPU), a memory, an input device, and an output device.

Wherein, the arithmetic unit: may consist of an arithmetic logic unit, an accumulator, a status register, a general purpose register set, etc.

A controller: the control center of the whole computer system can command all parts of the computer to work coordinately, and ensure that the computer can operate and process orderly according to the preset targets and steps.

A CPU: the CPU is composed of an arithmetic unit and a controller and is a necessary core component in a computer system. In the application, the CPU may provide a running program, call an output device to display a presentation log, and the like.

A memory: is a memory device in a computer system that can be used to store programs and data. In the present application, memory may provide the ability to store logs as well as dynamic log control information.

An input device: the devices that can input data and information to a computer are the bridges that the computer communicates with users or other devices. An input device is one of the primary means by which information is exchanged between a user and a computer system. In the present application, the input device may provide input capabilities for user control commands.

An output device: is a terminal device of a computer for receiving output display of computer data, printing, controlling peripheral device operations, and the like. Various calculation result data or information are also expressed in the form of numbers, characters, images, sounds, and the like. In the present application, the output device may be responsible for printing the log as requested by the CPU for presentation to the user.

Fig. 7 is a block diagram of components to which the method for printing a log according to the embodiment of the present application is applicable. As shown in fig. 7, the component structure may include a software portion and a hardware portion, wherein the software portion includes a system manager, a process manager, and a log controller, and the hardware portion may include a CPU memory portion.

The component structure can adopt a microkernel architecture, system services can run in a user mode, and processes of all the system services are isolated.

The system manager is used for managing all services of the whole system, and can comprise three submodules, namely a memory modifier, an instruction processor and an instruction parser.

It should be understood that the system manager in the present application may be one of the servers, and in some embodiments, the system manager may be replaced with a server.

The memory modifier can be used for managing the storage of the log in the storage block, and the like, such as writing the log into the memory, or modifying the log in the memory, and the like. The instruction parser may be used to parse query instructions, modification instructions, etc. input by the user. The instruction processor may be configured to process the instruction parsed by the instruction parser.

The process manager can be a module for managing the process, and comprises functions of creating the process, recovering the process and the like.

It should be understood that the process manager may be a type of client and, in some embodiments, the process manager may be replaced with a client.

The dynamic log segments may be used to collect dynamic logs. And the dynamic log interface can be used for calling the dynamic log by a user.

The log controller comprises an interactive module with a log grade modifying function and can comprise two sub-modules of result feedback and instruction receiver.

It should be understood that the log controller may be one type of controller, and in some embodiments, the log controller may be replaced with a controller.

The CPU memory portion may include two portions, a log storage block and an instruction storage block.

The instruction storage block may be used to store instructions related to querying the log, instructions related to modifying the log state, and the like. The log storage block may be used to store logs.

Fig. 8 is a schematic flowchart of a method for adding a log point according to an embodiment of the present application. As shown in fig. 8, the method may include steps 810 to 820.

The dynamic log interface is invoked 810.

<xnotran> , , , __ attribute __ ((section)) , . </xnotran>

When a client program runs to the code of the dynamic log interface, it can be considered to invoke the dynamic log interface.

And 820, adding the log point information into the dynamic log segment.

This step may be applied to the compilation stage, which may be performed by a compiler. <xnotran> __ attribute __ ((section)) , . </xnotran>

According to the technical scheme, the information of all log points can be added to the dynamic log section by calling a dynamic log interface.

Fig. 9 is a schematic flow chart of a method for querying a log according to an embodiment of the present application. As shown in fig. 9, the method may include steps 910 through 940.

The controller is called to input query parameters via the serial interface 910.

In this step, the user can call the controller through a serial interface (for short, a serial port), and can input some query parameters to query some log point information. The query parameters may include information such as a module of the query, a process number, etc., and may also query more detailed information through keywords.

The controller transmits a query command satisfying a preset condition to the server 920.

It should be understood that the preset condition may be a type, specification, etc. of the query parameter preset by the user, and only the query parameter satisfying the preset condition can be identified.

The controller can compile the query parameters meeting the preset conditions into a query instruction, and then transmit the query instruction to the server through the instruction call interface.

The server parses the instruction 930 and queries the corresponding log and transmits the log to the controller.

The server analyzes the received query instruction, identifies the range of the log to be queried and the like according to the analysis result, queries the corresponding log, and can transmit the log to the controller.

The method for querying the log corresponding to the query by the server may include, but is not limited to, the following methods:

the method I comprises the following steps:

the server is arranged under a process with cross-process read-write capability, and when the server needs to inquire logs, the server can directly read the information of the dynamic log segment in the process of the corresponding client.

The second method comprises the following steps:

the client can uniformly store all log point information in a file in advance, and when the server needs to inquire the log, the server reads the corresponding log from the file.

The third method comprises the following steps:

each client can share one memory space with the server, all log point information of the client can be stored in the shared memory, and when the server needs to inquire logs, the server can directly access the shared memory space and read corresponding logs.

The method four comprises the following steps:

when the client is initialized, a thread can be newly established to be responsible for communicating with the server, for example, socket connection is established, and when the server needs to query logs, a query requirement can be sent through the thread to query corresponding logs.

In the above several ways, the server can implement the cross-address space query of the corresponding log.

940, the controller presents the queried log to the user.

In this step, the controller may print the query result fed back by the server on the serial interface in a form of a table, and the user may obtain the query result through the serial interface information.

It should be understood that the query results may also be presented in other forms, such as bar records, text, and the like.

If the query fails, the controller also prints the failed result on the serial port, and can indicate the reason of the printing failure, such as the query parameter is wrong, the result is not queried, and the like.

In one embodiment of the present application, a user can query corresponding log point information in all clients (processes) by inputting query parameters.

Fig. 10 is a schematic flow chart of a method for updating a log state according to an embodiment of the present application. As shown in fig. 10, the method may include steps 1010 through 1040.

The controller is called via the serial interface and the parameters to update the log state are entered 1010.

1020, the controller transmits a query instruction satisfying a preset condition to the server.

And 1030, the server analyzes the instruction, updates the state of the corresponding log and transmits the updated log to the controller.

1040, the controller presents the updated log to the user.

For the steps 1010 to 1040, reference may be made to the related descriptions of the steps 910 to 940, and details are not repeated for brevity.

In one embodiment of the present application, the user can update the corresponding log point information in all clients (processes) by inputting the update query parameter.

FIG. 11 is a schematic flow chart diagram illustrating a method for adding a dynamic log segment in a process manager according to an embodiment of the present application. As shown in fig. 11, the method may include steps 1110 through 1130.

1110, add a dynamic log interface in the process manager.

Wherein, the client developer can add a dynamic log interface in the code of the process manager. Alternatively, the client developer may replace the native log interface with the dynamic log interface in the code in the process manager.

1120, scan for the presence of target data with a target field.

During the compilation stage, the compiler automatically scans the key fields to determine the target data with the target fields. The target field may be _ attribute _ ((". Log")).

If the target field is not scanned, the process is ended. If the target field is scanned, step 1130 is performed.

The target data is added 1130 to the dynamic log segment.

The scanned target data with the target field is added to the dynamic log segment and the size of the target data may be added in the _ log _ end field.

It should be understood that the dynamic log segment may also include fields of the status of the dynamic log, such as whether to print, whether to limit the frequency, the printing frequency, etc., and the dynamic log segment may also include fields of the dynamic log space, etc.

Fig. 12 is a schematic flowchart of a method for printing a log according to a log status according to an embodiment of the present application. As shown in fig. 12, the method may include steps 1210 through 1270.

1210, determining whether the log status is in an off state.

In a possible implementation manner, if the log state is in the closed state, the log printing process is ended.

In another possible implementation, if the log date status is not in the off status, step 1220 is performed.

It should be understood that a field indicating whether the status of the log is in the closed status may be included in the log, for example, if the value of the field is 0, the log is in the closed status, and if the value of the field is 1, the log is not in the closed status.

It should be understood that for each log, the user may set the closing or opening of their log state. Alternatively, the user may batch set the log status for each type, such as by the log space field of the dynamic log.

1220, determine if the log state is in a limited frequency state.

It should be understood that the frequency limited state herein means that the number of times the log performs printing within a preset time period is less than or equal to a preset number of times.

In one possible implementation, if the log status is not in the frequency limited status, step 1270 is executed to directly print the log.

In another possible implementation, if the log state is in the frequency limited state, step 1230 is performed.

It should be understood that for each log, the user can set whether it is in a frequency limited state or set whether it is in a frequency limited state for log batches through the log space field of the dynamic log. Further, the user can individually configure the print frequency of each log.

1230, judging whether the interval between the current time and the starting time is greater than a preset time length.

In one possible implementation, if the interval between the current time and the starting time is greater than the preset time, step 1260 is executed to refresh the printing time, that is, the current time is set as the starting time, and the number of printing times is set as 1. When the interval between the current time and the starting time is greater than the preset time, it indicates that the current time is out of the last preset time, and at this time, the current time may be set as the starting time.

In another possible implementation manner, if the interval between the current time and the starting time is less than or equal to the preset time length, step 1240 is executed.

1240, judging whether the current printing times is larger than the preset printing times.

It should be understood that the initial value of the number of prints may be set to 0.

In a possible implementation manner, when the current printing times are greater than the preset printing times, the log printing process is ended.

In another possible implementation manner, when the current number of prints is less than or equal to the preset number of prints, step 1250 is executed.

1250, the number of log prints is increased by one.

In this step, the number of times of log printing is increased by 1, and then an operation of printing the log may be performed.

1260, refresh the print time, and set the number of prints to 1.

It should be understood that the printing time is refreshed in this step, i.e., the current time is set as the starting time, so as to facilitate the timing of the next preset time period.

1270, printing a log.

It should be understood that the user can freely configure the way the log is printed.

In some embodiments, the user may configure the way that the logs are printed first, for example, within a preset time period, if the number of prints is set to 50, the first 50 logs may be printed.

In other embodiments, the user may configure the way of smoothly printing the journal, for example, within a preset time length, if the number of printing times is set to 50, the journal may be printed once every other journal until the journal is printed 50 times.

In other embodiments, the user may configure the log probability printing manner, for example, within a preset time length, if the number of printing times is set to 50, the log may be randomly printed 50 times.

Based on the embodiment of the application, the logs can be printed according to the state of the dynamic logs, the log printing in the frequency-limited state can be realized, the number of the printed logs is favorably reduced, in addition, the printing state of each log can be set by a user, and the user can realize the printing as required.

Fig. 13 is a schematic flowchart for viewing a dynamic log according to an embodiment of the present application. As shown in fig. 13, the method may include steps 1310 through 1350.

1310, call the log controller and enter parameters for the query log.

The user can call the controller through the serial interface and can input some query parameters, which may include a module to be queried, a process number, a query range, and the like.

1320, the log controller parses the parameters meeting the preset conditions and transmits to the system manager.

It should be understood that, in this step, the log controller may preliminarily parse the query parameter input by the user and identify whether the query parameter satisfies the preset condition.

For the query parameters which do not meet the preset conditions, the log controller cannot identify the query parameters, so that the user cannot query the log result.

For query parameters that satisfy the preset conditions, the log controller may compile the query parameters into a query instruction and transmit the query instruction to the system manager.

1330, the system manager queries the corresponding process data segment for a log.

It should be understood that, in this step, the system manager firstly parses the received query instruction, then identifies the log to be queried, the range of the log, and the like according to the parsing result, and then queries the corresponding process manager data segment to obtain the log.

The log query mode of the system manager may include, but is not limited to, the following:

the first method is as follows:

the system manager is arranged under a process with cross-process read-write capability, and when the system manager needs to inquire logs, the system manager can directly read the information of the dynamic log segments in the corresponding process manager in a cross-process mode.

The second method comprises the following steps:

the process manager can uniformly store all log point information in a file in advance, and when the system manager needs to query the log, the system manager reads the corresponding log from the file.

The third method comprises the following steps:

the process manager and the system manager can share one memory space, all log point information of the process manager can be stored in the shared memory, and when the system manager needs to query logs, the shared memory space can be directly accessed to read corresponding logs.

The method is as follows:

when the process manager needs to query the logs, a query requirement can be sent through the thread to query the corresponding logs.

In the above several ways, the system manager may query the corresponding log across the address space.

1340, the system manager copies the queried log to the log controller.

In this step, the system manager may copy the queried log to one and then send it to the log controller.

1350, the log controller presents the log to the user.

In this step, the log controller may print the query result in a form of a table on the serial interface, and the user may acquire the result of the query through the serial interface information.

If the query fails, the log controller also prints the failed result on the serial port, and can indicate the reason of the printing failure, such as an error of the query parameter, no query result, and the like.

In one embodiment of the present application, a user may query log point information corresponding to processes in all process managers by inputting a query parameter.

Fig. 14 is a schematic flow chart of a method for modifying a log state according to an embodiment of the present application. As shown in fig. 14, the method may include steps 1410 through 1450.

1410, call the log controller and enter instructions to modify the log state.

In this step, the user may call the controller through the serial interface and input an instruction for modifying the log status, which may include modified parameters, modified query scope, whether the log is printed, whether the log is frequency limited, and the like.

It should be understood that the user may modify the state of each log, or may modify the state in batches according to the type of the log, which is not limited in this embodiment of the application.

1420, the log controller parses the instructions and transmits to the system manager.

In this step, the log controller parses an instruction input by a user, and when the instruction satisfies a preset condition, the instruction may be compiled into a modification instruction and then transmitted to the system manager.

1430, the system manager queries for a corresponding process data segment.

This step 1430 may be referred to the related description of step 1330, and is not described again for brevity.

1440, the system manager modifies the status of the queried log and transmits the modification to the log controller.

In this step, the system manager may modify the state of the queried log according to the modification instruction, and then transmit the modification result of the log to the log controller.

It should be appreciated that the system manager can modify the state of the log across processes.

1450, the log controller presents the modification result of the log to the user.

Illustratively, if the modification instruction is to modify the non-printing log into the printing log, the log controller presents the result that the state modification of the log is successful to the user. Illustratively, a "1" may be returned if the state modification of the log is successful, and a value of "0" may be returned if the state modification of the log is not successful. For example, the return value may be printed on the serial interface in a tabular form, or may be presented in other forms, such as a bar record, text, and the like.

Based on the embodiment of the application, the user can pertinently modify the state of the log according to needs, and printing according to needs is achieved, so that the efficiency of log printing can be improved.

Fig. 15 is a schematic flowchart of a method for printing a dynamic log according to an embodiment of the present application. As shown in fig. 15, the method may include steps 1510 through 1540.

1510 add a dynamic log interface in the client.

For example, the client code personnel may add a dynamic log interface to the code that the process manager needs to generate the log. It should be appreciated that the process manager is one of the clients.

Alternatively, a dynamic log interface may be used instead of the native log interface.

1520, obtaining the data of the dynamic log through the dynamic log interface.

<xnotran> , , __ attribute __ ((section)) , , , . </xnotran>

1530 adding data of the dynamic log to a dynamic log segment, the dynamic log segment further comprising status information of the dynamic log.

In this step, the obtained data of the dynamic log may be added to the dynamic log segment, and the dynamic log segment may further include state information of the dynamic log.

It should be understood that the status information may include control status, frequency limited status, and the like.

1540, determining whether to print the dynamic log according to the status information of the dynamic log.

Illustratively, in this step, when the client program runs to the dynamic log interface, whether to print the dynamic log may be determined according to the status information in the dynamic log. In this way, the user can add a dynamic log interface in the process manager, collect all dynamic log point information through the dynamic log interface, add the dynamic log point information to the dynamic log segment, and determine whether to print the dynamic log according to the state information of the dynamic log in the dynamic log segment. In the technical scheme, the user can freely configure the state information of the dynamic log according to the requirement, so that the dynamic log can be freely printed according to the state information of the dynamic log in the dynamic log section, and the efficiency of printing the log is improved.

Optionally, the determining, according to the state of the dynamic log, whether to print the dynamic log includes: and determining whether to print the dynamic log according to the control state.

It should be understood that the control state may include on or off, when the control state is on, indicating that the dynamic log may be printed; when the control state is off, it means that the dynamic log is not printable.

For example, referring to step 1210 in fig. 12, before printing the log, it may be determined whether the log status is in a closed status.

Optionally, the status information of the dynamic log further includes frequency-limited status information of the dynamic log, and the determining whether to print the dynamic log according to the status information of the dynamic log includes: and when the control state is on, determining whether to print the dynamic log according to the frequency limiting state information.

Illustratively, referring to step 1220 in FIG. 12, a determination is made whether to print the log based on the log being in a frequency limited state.

When the log is not in the frequency limiting state, the log can be directly printed, and when the log is in the frequency limiting state, whether the log is printed or not is further judged.

Optionally, when the control state is on, determining whether to print the dynamic log according to the frequency limit state information includes: and if the time interval between the current time and the starting time is greater than a first preset time, determining to print the dynamic log.

Illustratively, referring to step 1230 in fig. 12, if the time interval between the current time and the starting time is greater than the first preset time period, which indicates that the current time is outside the preset time period, the new printing cycle may be started continuously. According to the technical scheme, frequency-limited printing can be achieved, and data redundancy caused by excessive log printing can be avoided.

Optionally, the method further comprises: and if the time interval between the current time and the starting time is less than or equal to the first preset time, determining whether to print the dynamic log according to the relation between the current printing times and the preset printing times.

Optionally, the method further comprises: inquiring a target log in the corresponding dynamic log section according to an inquiry parameter input by a user; presenting the target log to a user.

Illustratively, referring to fig. 13, the system manager queries the corresponding target log according to the query parameter input by the user, then copies the queried log to the log controller, and the log controller presents the log to the user.

Optionally, the querying a target log in the corresponding dynamic log segment includes: and querying a target log in the corresponding dynamic log section in a cross-process mode.

See, for example, way one of the system manager query logs in step 1330 in FIG. 13.

In the embodiment of the application, the system manager can be placed in a process with cross-process read-write capability, and the system manager can query the target log in the corresponding dynamic log segment in a cross-process mode.

Optionally, the querying the target log in the corresponding dynamic log segment includes: and querying the target log from the control file.

See, for example, way two for the system manager querying the log in step 1330 in fig. 13.

Optionally, the querying a target log in a corresponding dynamic log segment includes: and querying the target log from the shared memory space, wherein the shared memory space is the shared memory space of a system manager and a process manager.

See, for example, way three for the system manager to query the log in step 1330 in FIG. 13.

It should be understood that the system manager and process manager may reside on a single processor or may reside on different processors.

In this embodiment, each process may share one piece of memory with the system manager, that is, have a shared memory space, and the target log may be stored in the shared memory space in advance, and the system manager may directly query the target log from the shared memory space. The technical scheme can also realize cross-process query of the target log in the corresponding dynamic log segment.

Optionally, the querying a target log in a corresponding dynamic log segment includes: and querying the target log through a first thread, wherein the first thread is a thread for communicating a process manager and a system manager.

See, for example, system manager query log four in step 1330 in FIG. 13.

It should be understood that, in this embodiment, the process manager may establish a connection with the system management through the first thread, and then the system manager may query the corresponding target log through the first thread. The technical scheme can also realize cross-process query of the target log in the corresponding dynamic log segment.

Optionally, the method further comprises: updating the state of a target log in the corresponding dynamic log section according to a log state updating instruction input by a user; and presenting the update result of the target log to a user.

Illustratively, referring to fig. 14, the instruction to update the log state may be an instruction to modify the log state.

In one possible implementation, if the log status modification is successful, a value of "1" may be returned, i.e., the returned value of "1" may be presented to the user; if the log state is not successfully modified, a value of "0" may be returned, i.e., the returned value of "0" may be presented to the user.

In the embodiment of the application, the user can freely change the log state, so that the state configuration can be carried out on each log, the printing can be realized according to the requirement, and the printing efficiency is improved.

Optionally, the state information of the dynamic log further includes a log space field, and the log space field is used for performing batch control on the dynamic log.

An embodiment of the present application further provides an electronic device, including one or more processors; one or more memories; the one or more memories store one or more computer programs, the one or more computer programs comprising instructions, which when executed by the one or more processors, cause performance of the method of printing a dynamic log as any of the above embodiments.

The embodiment of the present application further provides a device for printing a dynamic log, where the device is used to implement the method for printing a dynamic log in any one of the possible implementation manners in the foregoing embodiments.

Embodiments of the present application further provide a computer-readable storage medium, in which computer instructions are stored, and when the computer instructions are executed on a computer, the method for printing a dynamic log as described in any one of the above possible implementation manners is executed.

Embodiments of the present application further provide a computer program product, which includes computer instructions, when the computer instructions are executed on a computer, the method for printing a dynamic log as described in any one of the possible implementations of the foregoing embodiments is executed.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of printing a dynamic log, comprising:

adding a dynamic log interface in a client;

acquiring data of the dynamic log through the dynamic log interface;

adding the data of the dynamic log into a dynamic log segment of the client, wherein the dynamic log segment also comprises the state information of the dynamic log;

and determining whether to print the dynamic log according to the state information of the dynamic log.

2. The method of claim 1, wherein the status information of the dynamic log comprises a control status of the dynamic log,

the determining whether to print the dynamic log according to the state of the dynamic log comprises:

and determining whether to print the dynamic log according to the control state.

3. The method of claim 2, wherein the status information of the dynamic log further comprises frequency limited status information of the dynamic log, and wherein the determining whether to print the dynamic log according to the status information of the dynamic log comprises:

and when the control state is on, determining whether to print the dynamic log according to the frequency limiting state information.

4. The method of claim 3, wherein determining whether to print the dynamic log according to the frequency limited state information when the control state is on comprises:

and if the time interval between the current time and the starting time is greater than a first preset time length, determining to print the dynamic log.

5. The method of claim 4, further comprising:

and if the time interval between the current time and the starting time is less than or equal to the first preset time, determining whether to print the dynamic log according to the relation between the current printing times and the preset printing times.

6. The method according to any one of claims 1-5, further comprising:

inquiring a target log in the corresponding dynamic log section according to an inquiry parameter input by a user;

presenting the target log to a user.

7. The method of claim 6, wherein querying the target log in the corresponding dynamic log segment comprises:

and querying a target log in the corresponding dynamic log segment in a cross-process mode.

8. The method of claim 6, wherein the target log is pre-stored in a control file, and the querying corresponds to the target log in the dynamic log segment, comprising:

and querying the target log from the control file.

9. The method of claim 6, wherein querying the target log in the corresponding dynamic log segment comprises:

and querying the target log from a shared memory space, wherein the shared memory space is a shared memory space of a system manager and a process manager.

10. The method of claim 6, wherein querying the target log in the corresponding dynamic log segment comprises:

and querying the target log through the first thread, wherein the first thread is a thread for communicating a process manager and a system manager.

11. The method according to any one of claims 6-10, further comprising:

updating the state of the target log in the corresponding dynamic log section according to a log state updating instruction input by a user;

and presenting the update result of the target log to a user.

12. The method according to any one of claims 1-11, wherein the state information of the dynamic log further comprises a log space field, and the log space field is used for performing batch control on the dynamic log.

13. An electronic device, comprising one or more processors; one or more memories; the one or more memories store one or more computer programs, the one or more computer programs comprising instructions, which when executed by one or more processors, cause performance of the method of printing a dynamic log of any of claims 1-12.

14. A computer-readable storage medium having stored thereon computer instructions which, when run on a computer, cause the method of printing a dynamic log according to any one of claims 1-12 to be performed.