CN112799920B - Program running state monitoring method based on program log - Google Patents
Program running state monitoring method based on program log Download PDFInfo
- Publication number
- CN112799920B CN112799920B CN202110394431.0A CN202110394431A CN112799920B CN 112799920 B CN112799920 B CN 112799920B CN 202110394431 A CN202110394431 A CN 202110394431A CN 112799920 B CN112799920 B CN 112799920B
- Authority
- CN
- China
- Prior art keywords
- log
- data
- alarm
- log data
- queue
- 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.)
- Active
Links
Images
Classifications
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/522—Barrier synchronisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Quality & Reliability (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a program running state monitoring method based on a program Log, which is characterized in that the method is used for realizing the instant alarm function on the basis of the Log4cxx basic Log function, and comprises the following steps: a client delivers a log; the client processes the log; and the server processes the log. The invention provides a program running state monitoring method based on a program log, which can immediately give corresponding alarm and process some error problems generated by a user on the basis of keeping the original log function. For example, when a large number of reports that the client fails to log in, the condition of the login service is immediately inquired, and the fault of the login service is solved. When a large number of orders fail to be placed, the condition of the transaction service can be immediately inquired. Both of these operations provide a better service experience for the user.
Description
Technical Field
The invention relates to a method for recording a program log of a financial transaction client and monitoring the running state of the program, which is suitable for the financial information service industry and belongs to the technical field of program log recording methods.
Background
The method of logging commonly used by most programs at present is generally to write files directly, a common Log library has Log4cxx, and a macro sink client uses Log4 cxx. Log4cxx is a Log framework maintained by the Apache software Foundation, corresponding to the famous open source project Apache Log4j in java in c + +. It is an open source project that can be ported on multiple platforms with the help of Apache Portable Runtime.
log4cxx has three main components: loggers, Appenders, and layout can be simply understood as log category, where to output, output form. The comprehensive use of the three components can record the categories and levels of information and can control the style and location of the log output at runtime.
In addition to the Appenders disabling and using the log4cxx base functionality of the log, log4cxx also provides more powerful functionality, such as: allowing logs to be exported to different locations, such as consoles, files, etc.; generating a new file according to the number of days or the size of the file; or may be streamed elsewhere, etc.
Layouts sometimes want to customize the log output format, and log4j. apppender. apppendername is followed by Layouts to complete.
The Log44cxx may Log in an asynchronous manner. The model of the producer and the consumer is adopted to asynchronously send the logs to be recorded to the corresponding appliers. There are the following 3 roles:
the producer: the real-time thread of a system with log4cxx is externally applied, and log information is transmitted into asynchronous appliers in real time;
transfer: buffer and discard summary;
the consumer: dispatcher (dispatch module) and applicators.
The logs enter an asynchronous appendix, which calls an appendix method, and fills the logs into a buffer (record buffer) in the appendix method. When the consumption capacity is not as good as the production capacity, the asynchronous appliers puts the log exceeding the buffer capacity into the discard buffer as a solution for transferring the overflow processing of the buffer when the consumption speed cannot keep up with the generation speed. Asynchronous appliers have a Dispatcher (dispatch module) that mainly accomplishes 3 tasks:
1) the Buffer is locked and other threads that are to operate on the Buffer are blocked.
2) See if Buffer is full: if the Buffer is full, all the log information in the Buffer is taken out, and the Buffer and the discard summary are emptied; if not, waiting for the Buffer to be filled with the log information, and then informing the sending thread.
3) And the sending thread gives all the taken log information to the corresponding applicators to carry out the subsequent log information push.
In various software systems, the logs play a very important role, and not only can be used as a basis for troubleshooting system faults when faults occur, but also can be used for analyzing software system behaviors, performances and the like. The service nodes of the software system typically need to log when processing service requests.
In the current log recording scheme, the log recording function of a software system is started through system configuration, and a detailed log of each service request processing process is recorded and comprises an error log. However, there is no way to report the error information to the outside when the error information is recorded, so that the operation and maintenance personnel can conveniently and timely perform targeted processing on the current error, and the experience of using the transaction program and the stability of the service can be improved.
Disclosure of Invention
The purpose of the invention is: the function of reporting the error information immediately is realized on the basis of meeting the original common log.
In order to achieve the above object, a technical solution of the present invention is to provide a method for monitoring a program running state based on a program Log, which is characterized in that the method is used for simultaneously realizing an instant alarm function on the basis of a Log4cxx basic Log function, and comprises the following steps:
step 1, delivering logs by a client, specifically comprising the following steps:
103, checking whether the submitted log data meets the input format requirement, and if so, entering the next step; if not, giving up the submitted log data, and ending the client delivery log process;
105, releasing a common queue lock by the log module, and releasing exclusive access to a common log data queue;
step 107, presetting corresponding alarm configuration in a configuration file, matching log data with the alarm configuration, judging whether an alarm condition is met, if so, entering step 108, and if not, entering step 111;
step 108, the log module acquires an alarm queue lock to monopolize access to the alarm data queue;
step 109, after the log module adds the log data to the alarm log data queue, releasing the alarm queue lock to release the exclusive access to the alarm log data queue;
step 110, after the alarm queue lock is released, the log module triggers a delivery event EventB of the alarm data queue to enable another subsequent working thread WorkB specially processing the alarm log data to receive the notification and then process the data, and then step 111 is carried out;
step 111, ending the client delivery log flow;
step 2, the client processes the log, and specifically comprises the following steps:
the working thread WorkB waits for the notification of the delivery event EventB of the alarm data queue, and if the working thread WorkB obtains the notification of the delivery event EventB, the step 205 is carried out;
2041, the worker thread WorkA obtains a common queue lock and exclusively accesses a common log data queue;
2042, after the working thread WorkA takes out the log data to be processed from the common log data queue, releasing a common queue lock;
2043, recording the taken log data by the working thread WorkA, and returning to 202 after the completion;
step 2051, the worker thread WorkB obtains an alarm queue lock and monopolizes access to the alarm data queue;
step 2052, after the worker thread WorkB takes out the log data to be processed from the alarm data queue, releasing the alarm queue lock;
step 2053, after the worker thread WorkB records the taken-out log data, encrypting the data to obtain encrypted alarm log data;
step 2054, the worker thread WorkB sends the encrypted alarm log data to the server in an HTTP POST mode, and returns to step 202 after completion;
step 3, the server side processes the log, and the method comprises the following steps:
step 301, after starting a server program, initializing a log data queue for storing log data reported by a user; and then starting a receiving working thread and a processing working thread, processing the data in the log data queue by the receiving working thread, and starting the HTTP service for receiving the data.
Step 302, the receiving working thread and the processing working thread enter a working cycle, whether a working end mark is True is judged, if True, the receiving working thread and the processing working thread are ended to enter the working, and if not, the step 303 is executed;
step 303, the receiving working thread waits for the HTTP service to receive the feedback notification reported by the client, and after the receiving working thread receives the feedback notification, the step 304 is performed;
the processing work thread waits for the notification of the delivery event EventC, and enters step 305 after obtaining the notification of the delivery event EventC;
step 304, receiving the encrypted alarm log data by the working thread, specifically comprising the following steps:
step 3041, after the interface that receives the working thread and calls the HTTP service obtains the encrypted alarm log data, it delivers the encrypted alarm log data to the log data queue;
step 3042, receiving a delivery event EventC that the working thread triggers the arrival of the log data, so that the processing working thread receives the notification of the delivery event EventC and processes the data;
step 3043, return to step 302 for cycle processing;
step 305, processing the encrypted alarm log data by the working thread, specifically comprising the following steps:
3051, the processing working thread takes out encrypted alarm log data to be processed from the log data queue and decrypts the data to obtain log data;
3052, processing the log data obtained by the record decryption of the working thread, sending an alarm notification to a target mailbox or a target mobile phone, and then returning to the step 302.
Preferably, the log data at least includes log level, generation module parameter, and log description, where the generation module parameter identifies a specific service module where the log occurs, then:
in step 107, setting a specific log level and a specific generation module parameter corresponding to the condition meeting the alarm through the alarm configuration;
the log module obtains the log grade of the current log in real time through the log parameters and obtains the generation module parameters of the current log in real time; the log module matches the log grade and the generation module parameter obtained in real time with the alarm configuration set in the configuration file, if the log grade obtained in real time is matched with the specific log grade in the configuration file and the generation module parameter obtained in real time is matched with the specific generation module parameter in the configuration file, the alarm condition is judged to be met, step 108 is entered, otherwise, the alarm condition is judged not to be met, and step 111 is entered.
Preferably, the log levels include detail, normal, warning, error, fatal, with sequentially increasing severity levels.
Preferably, in step 107, if the log level obtained in real time is greater than or equal to the specific log level in the configuration file, it is determined that the log level obtained in real time matches the specific log level in the configuration file.
Preferably, after the step 103 and before the step 104, the method further comprises:
and integrating the log, formatting a plurality of input log data into a system-agreed json format data block, and then entering step 104.
Preferably, in step 2053, the step of encrypting the data to obtain encrypted alarm log data includes the following steps:
firstly, a user account of a user who delivers the log data is spliced with the recorded log data and encrypted by an appointed password B to obtain log segment data; splicing the user account number, the separators and the log segment data, and encrypting the spliced user account number, the separators and the log segment data by using an agreed password A to finally obtain encrypted alarm log data for reporting;
then after step 3051, and before step 3052, the following steps are also included:
processing the working thread to judge whether the log data is a valid log, if so, entering step 3052, otherwise, returning to step 302;
the processing working thread adopts the following steps to judge whether the log data is a valid log:
and taking out the user account A at the head of the data obtained by decryption by using the agreed password A, taking out the user account B in the log section obtained by decryption by using the agreed password B, and judging whether the user account A is equal to the user account B, wherein if yes, the log data is a valid log, and otherwise, the log data is an invalid log.
Preferably, in step 3052, an alarm receiving mailbox corresponding to the user account is pre-configured as a target mailbox at the server, or an alarm receiving mobile phone number corresponding to the user account is configured as a target mobile phone.
The invention provides a program running state monitoring method based on a program log, which can immediately give corresponding alarm and process some error problems generated by a user on the basis of keeping the original log function. For example, when a large number of reports that the client fails to log in, the condition of the login service is immediately inquired, and the fault of the login service is solved. When a large number of orders fail to be placed, the condition of the transaction service can be immediately inquired. Both of these operations provide a better service experience for the user.
Drawings
FIG. 1 is a client drop log flow;
FIG. 2 is a client process log flow;
FIG. 3 illustrates an encryption format and manner of log data;
FIG. 4 is a server log receiving flow;
fig. 5 is a server log processing flow.
Detailed Description
The invention will be further illustrated with reference to the following specific examples. It should be understood that these examples are for illustrative purposes only and are not intended to limit the scope of the present invention. Further, it should be understood that various changes or modifications of the present invention may be made by those skilled in the art after reading the teaching of the present invention, and such equivalents may fall within the scope of the present invention as defined in the appended claims.
The method for monitoring the program running state based on the program Log is used for realizing the instant alarm function on the basis of the Log4cxx basic Log function. The invention is mainly divided into the following three processes:
1. a client delivers a log flow;
2. the client processes the log flow;
3. and the server side processes the log flow.
As shown in fig. 1, the client delivery log process specifically includes the following steps:
step 1, a user code calls a log interface, and relevant log parameters including log levels, generation module parameters, log description and the like are filled.
Step 2, judging whether the log module completes initialization or not, if the log module does not complete initialization, giving up the submitted log parameters, and ending the log delivery process of the client; if the log module has completed initialization, the log parameters are submitted via the log interface.
Step 3, checking whether the submitted log parameters meet the input format requirement, and if the submitted log parameters meet the format requirement, entering step 4; if not, the log submitting parameters are abandoned, and the client delivery log process is ended.
And 4, integrating the logs, formatting a plurality of input log parameters into a json format data block agreed by the system, and entering the step 5. In this embodiment, the json format is a lightweight data encoding exchange format.
And 5, the log module acquires a common queue lock for acquiring the permission of exclusively accessing the common log data queue.
And 6, adding the json format data block obtained in the step 4 into a common log data queue by the log module.
And 7, releasing the common queue lock by the log module, and releasing the exclusive access to the common log data queue.
And 8, after the common queue lock is released by the log module, triggering a delivery event EventA of the common data queue by the log module, so that another working thread WorkA specially processing the common log data in the following client side receives a notice of the delivery event EventA and processes the data.
And 9, presetting corresponding alarm configuration in the configuration file, and setting specific log levels and specific generation module parameters corresponding to the alarm conditions through the alarm configuration. In this embodiment, the log level includes: detail, normal, warning, error, fatal 5 levels, the severity level increasing in order. And recording the service module in which the log occurs through the generation module parameter.
The log module obtains the log level of the current log in real time through the log parameters and obtains the generation module parameters of the current log in real time. The log module matches the log level and the generation module parameter obtained in real time with the alarm configuration set in the configuration file, if the log level obtained in real time matches with the specific log level in the configuration file (in this embodiment, the log level obtained in real time is greater than or equal to the specific log level in the configuration file, namely the log level obtained in real time is determined to be matched), and the generation module parameter obtained in real time matches with the specific generation module parameter in the configuration file, the alarm condition is determined to be satisfied, step 10 is entered, otherwise, the alarm condition is determined not to be satisfied, and step 13 is entered.
And step 10, the log module acquires an alarm queue lock to exclusively access the alarm data queue.
And 11, after adding the json format data block obtained in the step 4 to an alarm log data queue, releasing an alarm queue lock by the log module so as to release exclusive access to the alarm log data queue.
Step 12, after the alarm queue lock is released, the log module triggers a delivery event eventB of the alarm data queue to enable another subsequent working thread WorkB specially processing the alarm log data to receive the notification and then process the data, and then step 13 is carried out.
And step 13, ending the client delivery log flow.
As shown in fig. 2, the client log processing flow is divided into a processing flow for normal log data and a processing flow for alarm log data.
The processing flow of the common log data comprises the following steps:
and 102, the working thread WorkA judges whether the working end mark of the log module is True, if so, the working thread WorkA is ended to run, the processing flow of the common log data is completed, and otherwise, the step 103 is carried out. In this embodiment, the work end flag of the log module is set by the external module calling the related function.
And step 104, the worker thread WorkA obtains a common queue lock and exclusively accesses the common log data queue.
And 105, releasing the common queue lock after the working thread WorkA takes out the log data to be processed from the common log data queue.
And step 106, recording the taken log data by the working thread WorkA, and returning to the step 102 after the log data is taken out.
The processing flow of the alarm log data comprises the following steps:
And step 204, the worker thread WorkB acquires an alarm queue lock and exclusively accesses the alarm data queue.
And step 206, after the working thread WorkB records the taken log data, encrypting the data to obtain encrypted alarm log data.
In this embodiment, the encryption mode and format refer to fig. 3:
firstly, a user account of a user delivering the log data is spliced with the recorded log data and encrypted by an appointed password B to obtain log segment data. And then, splicing the user account number, the separator and the log segment data, and encrypting by using an agreed password A to finally obtain encrypted alarm log data for reporting.
And step 207, the worker thread WorkB sends the encrypted alarm log data to the server side in an HTTP POST mode, and the step 202 is returned after the encrypted alarm log data are sent to the server side.
The server-side log processing flow further comprises a server-side log receiving flow and a server-side log processing flow.
As shown in fig. 4, the server log receiving process specifically includes the following steps:
And 102, receiving the working thread to enter a working cycle, judging whether the working end mark is True, if so, ending the operation of the receiving working thread, and otherwise, entering the step 103. The job completion flag is set by an external module calling the relevant function.
And 103, receiving a feedback notice reported by the client when the working thread waits for the HTTP service to receive. And after the receiving working thread receives the feedback notice, calling an HTTP service interface to acquire encrypted alarm log data.
And step 104, the receiving working thread delivers the encrypted alarm log data to a log data queue.
And 105, receiving a delivery event EventC of the working thread triggering log data arrival, so that the processing working thread receives notification of the delivery event EventC and processes the data.
And step 106, returning to the step 102 for circular processing.
As shown in fig. 5, the server log processing flow specifically includes the following steps:
And step 204, processing the working thread to judge whether the log data is a valid log, if so, entering step 205, and if not, returning to step 201.
In this embodiment, the processing work thread adopts the following steps to determine whether the log data is a valid log:
and taking out the user account A at the head of the data obtained by decryption by using the agreed password A, taking out the user account B in the log section obtained by decryption by using the agreed password B, and judging whether the user account A is equal to the user account B, wherein if yes, the log data is a valid log, and otherwise, the log data is an invalid log.
And step 205, processing the log data obtained by the record decryption of the working thread, sending an alarm notification to a target mailbox or a target mobile phone, and then returning to the step 201. In this embodiment, an alarm receiving mailbox corresponding to a user account is pre-configured as a target mailbox at the server, or an alarm receiving mobile phone number corresponding to the user account is configured as a target mobile phone.
Claims (7)
1. A method for monitoring program running state based on program Log is characterized in that the method is used for realizing instant alarm function on the basis of Log4cxx basic Log function, and comprises the following steps:
step 1, delivering logs by a client, specifically comprising the following steps:
step 101, calling a log interface by a user code, and filling related log data;
step 102, judging whether the log module completes initialization or not, if the log module does not complete initialization, giving up the submitted log data, and ending the client side log delivery process; if the log module is initialized, submitting log data through a log interface;
103, checking whether the submitted log data meets the input format requirement, and if so, entering the next step; if not, giving up the submitted log data, and ending the client delivery log process;
step 104, the log module acquires a common queue lock for acquiring the permission of exclusively accessing the common log data queue; then, the log module adds the log data obtained in the last step into a common log data queue;
105, releasing a common queue lock by the log module, and releasing exclusive access to a common log data queue;
step 106, after the common queue lock is released by the log module, the log module triggers a delivery event EventA of the common data queue, so that another working thread WorkA specially processing common log data in a subsequent client receives a notification of the delivery event EventA and processes data;
step 107, presetting corresponding alarm configuration in a configuration file, matching log data with the alarm configuration, judging whether an alarm condition is met, if so, entering step 108, and if not, entering step 111;
step 108, the log module acquires an alarm queue lock to monopolize access to the alarm data queue;
step 109, after the log module adds the log data to the alarm log data queue, releasing the alarm queue lock to release the exclusive access to the alarm log data queue;
step 110, after the alarm queue lock is released, the log module triggers a delivery event EventB of the alarm data queue to enable another subsequent working thread WorkB specially processing the alarm log data to receive the notification and then process the data, and then step 111 is carried out;
step 111, ending the client delivery log flow;
step 2, the client processes the log, and specifically comprises the following steps:
step 201, a log module initializes a common log data queue and an alarm log data queue, initializes and starts a working thread WorkA for processing common log data and a working thread WorkB for processing alarm log data;
step 202, the working thread WorkA and the working thread WorkB judge whether the working end mark of the log module is True, if True, the working thread WorkA and the working thread WorkB are ended, otherwise, the operation is performed in step 203;
step 203, the worker thread WorkA waits for the notification of the delivery event EventA of the common data queue, and if the worker thread WorkA obtains the notification of the delivery event EventA, the step 204 is carried out;
the working thread WorkB waits for the notification of the delivery event EventB of the alarm data queue, and if the working thread WorkB obtains the notification of the delivery event EventB, the step 205 is carried out;
step 204, the working thread WorkA processes the common log data, which comprises the following steps:
2041, the worker thread WorkA obtains a common queue lock and exclusively accesses a common log data queue;
2042, after the working thread WorkA takes out the log data to be processed from the common log data queue, releasing a common queue lock;
2043, recording the taken log data by the working thread WorkA, and returning to 202 after the completion;
step 205, the working thread WorkB processes the alarm log data, including the following steps:
step 2051, the worker thread WorkB obtains an alarm queue lock and monopolizes access to the alarm data queue;
step 2052, after the worker thread WorkB takes out the log data to be processed from the alarm data queue, releasing the alarm queue lock;
step 2053, after the worker thread WorkB records the taken-out log data, encrypting the data to obtain encrypted alarm log data;
step 2054, the worker thread WorkB sends the encrypted alarm log data to the server in an HTTP POST mode, and returns to step 202 after completion;
step 3, the server side processes the log, and the method comprises the following steps:
step 301, after starting a server program, initializing a log data queue for storing log data reported by a user; then starting a receiving working thread and a processing working thread, processing the data in the log data queue by the receiving working thread, and starting HTTP service for receiving the data;
step 302, the receiving working thread and the processing working thread enter a working cycle, whether a working end mark is True is judged, if True, the receiving working thread and the processing working thread are ended to enter the working, and if not, the step 303 is executed;
step 303, the receiving working thread waits for the HTTP service to receive the feedback notification reported by the client, and after the receiving working thread receives the feedback notification, the step 304 is performed;
the processing work thread waits for the notification of the delivery event EventC, and enters step 305 after obtaining the notification of the delivery event EventC;
step 304, receiving the encrypted alarm log data by the working thread, specifically comprising the following steps:
step 3041, after the interface that receives the working thread and calls the HTTP service obtains the encrypted alarm log data, it delivers the encrypted alarm log data to the log data queue;
step 3042, receiving a delivery event EventC that the working thread triggers the arrival of the log data, so that the processing working thread receives the notification of the delivery event EventC and processes the data;
step 3043, return to step 302 for cycle processing;
step 305, processing the encrypted alarm log data by the working thread, specifically comprising the following steps:
3051, the processing working thread takes out encrypted alarm log data to be processed from the log data queue and decrypts the data to obtain log data;
3052, processing the log data obtained by the record decryption of the working thread, sending an alarm notification to a target mailbox or a target mobile phone, and then returning to the step 302.
2. The method according to claim 1, wherein the log data at least includes log level, generation module parameter, and log description, and wherein if the generation module parameter identifies a specific service module where the log occurs, then:
in step 107, setting a specific log level and a specific generation module parameter corresponding to the condition meeting the alarm through the alarm configuration;
the log module obtains the log grade of the current log in real time through the log parameters and obtains the generation module parameters of the current log in real time; the log module matches the log grade and the generation module parameter obtained in real time with the alarm configuration set in the configuration file, if the log grade obtained in real time is matched with the specific log grade in the configuration file and the generation module parameter obtained in real time is matched with the specific generation module parameter in the configuration file, the alarm condition is judged to be met, step 108 is entered, otherwise, the alarm condition is judged not to be met, and step 111 is entered.
3. The method of claim 2, wherein the log level comprises detail, normal, warning, error, fatal, and the severity level is increased in sequence.
4. The method as claimed in claim 2, wherein in step 107, if the real-time obtained log level is greater than or equal to the specific log level in the configuration file, it is determined that the real-time obtained log level matches the specific log level in the configuration file.
5. The method for program log-based program running state monitoring according to claim 1, further comprising, after the step 103 and before the step 104:
and integrating the log, formatting a plurality of input log data into a system-agreed json format data block, and then entering step 104.
6. The method for monitoring the running state of the program based on the program log as claimed in claim 1, wherein the step 2053 of encrypting the data to obtain the encrypted alarm log data comprises the following steps:
firstly, a user account of a user who delivers the log data is spliced with the recorded log data and encrypted by an appointed password B to obtain log segment data; splicing the user account number, the separators and the log segment data, and encrypting the spliced user account number, the separators and the log segment data by using an agreed password A to finally obtain encrypted alarm log data for reporting;
then after step 3051, and before step 3052, the following steps are also included:
processing the working thread to judge whether the log data is a valid log, if so, entering step 3052, otherwise, returning to step 302;
the processing working thread adopts the following steps to judge whether the log data is a valid log:
and taking out the user account A at the head of the data obtained by decryption by using the agreed password A, taking out the user account B in the log section obtained by decryption by using the agreed password B, and judging whether the user account A is equal to the user account B, wherein if yes, the log data is a valid log, and otherwise, the log data is an invalid log.
7. The method for monitoring the program running state based on the program log according to claim 1, wherein in step 3052, an alarm receiving mailbox corresponding to the user account is configured in advance as a target mailbox at the server, or an alarm receiving mobile phone number corresponding to the user account is configured as a target mobile phone.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110394431.0A CN112799920B (en) | 2021-04-13 | 2021-04-13 | Program running state monitoring method based on program log |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110394431.0A CN112799920B (en) | 2021-04-13 | 2021-04-13 | Program running state monitoring method based on program log |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112799920A CN112799920A (en) | 2021-05-14 |
| CN112799920B true CN112799920B (en) | 2021-08-17 |
Family
ID=75816927
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110394431.0A Active CN112799920B (en) | 2021-04-13 | 2021-04-13 | Program running state monitoring method based on program log |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112799920B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8127357B1 (en) * | 2007-08-24 | 2012-02-28 | Louisiana Tech Research Foundation; A Division Of Louisiana Tech University Foundation, Inc. | Method to detect SYN flood attack |
| CN104462612A (en) * | 2015-01-05 | 2015-03-25 | 浪潮(北京)电子信息产业有限公司 | Method and device for monitoring database information |
| CN106055449A (en) * | 2016-05-12 | 2016-10-26 | 深圳市永兴元科技有限公司 | Method and device for cloud data monitoring based on resource dependence relations |
| CN112084048A (en) * | 2020-09-25 | 2020-12-15 | 中国建设银行股份有限公司 | Kafka synchronous disk refreshing method and device and message server |
| CN112506743A (en) * | 2020-12-09 | 2021-03-16 | 天津狮拓信息技术有限公司 | Log monitoring method and device and server |
-
2021
- 2021-04-13 CN CN202110394431.0A patent/CN112799920B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8127357B1 (en) * | 2007-08-24 | 2012-02-28 | Louisiana Tech Research Foundation; A Division Of Louisiana Tech University Foundation, Inc. | Method to detect SYN flood attack |
| CN104462612A (en) * | 2015-01-05 | 2015-03-25 | 浪潮(北京)电子信息产业有限公司 | Method and device for monitoring database information |
| CN106055449A (en) * | 2016-05-12 | 2016-10-26 | 深圳市永兴元科技有限公司 | Method and device for cloud data monitoring based on resource dependence relations |
| CN112084048A (en) * | 2020-09-25 | 2020-12-15 | 中国建设银行股份有限公司 | Kafka synchronous disk refreshing method and device and message server |
| CN112506743A (en) * | 2020-12-09 | 2021-03-16 | 天津狮拓信息技术有限公司 | Log monitoring method and device and server |
Non-Patent Citations (2)
| Title |
|---|
| PADLA: A Dynamic Log Level Adapter Using Online Phase Detection;Tsuyoshi Mizouchi、Kazumasa Shimari、Takashi Ishio等;《 2019 IEEE/ACM 27th International Conference on Program Comprehension (ICPC)》;20190829;全文 * |
| 分布式日志服务关键技术研究;李玉荣、杨树强、贾焰等;《计算机工程与应用》;20060331;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112799920A (en) | 2021-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3543866B1 (en) | Resource-efficient record processing in unified automation platforms for robotic process automation | |
| US8135827B2 (en) | Distributed capture and aggregation of dynamic application usage information | |
| EP3617961A1 (en) | Intelligent adaptor service in unified automation platforms for robotic process automation | |
| US20170048120A1 (en) | Systems and Methods for WebSphere MQ Performance Metrics Analysis | |
| CN105027108B (en) | Example host is configured | |
| US10911447B2 (en) | Application error fingerprinting | |
| CN113051019A (en) | Flow task execution control method, device and equipment | |
| US9015731B2 (en) | Event handling system and method | |
| CN112131002B (en) | Data management method and device | |
| US11169896B2 (en) | Information processing system | |
| US11531539B2 (en) | Automated compliance and testing framework for software development | |
| CN112395177A (en) | Interactive processing method, device and equipment of service data and storage medium | |
| KR20180037342A (en) | Application software error monitoring, statistics management service and solution method. | |
| CN109559089A (en) | Data processing method, device, equipment and the storage medium of main plateform system | |
| CN112882863A (en) | Method, device and system for recovering data and electronic equipment | |
| CN114564757A (en) | Data auditing method, device and equipment of block chain and readable storage medium | |
| CN111930489A (en) | Task scheduling method, device, equipment and storage medium | |
| CN113703997A (en) | Bidirectional asynchronous communication middleware system integrating multiple message agents and implementation method | |
| CN112799920B (en) | Program running state monitoring method based on program log | |
| CN113836237A (en) | Method and device for auditing data operation of database | |
| CN110908708A (en) | Code publishing method, device and system | |
| CN112015715A (en) | Industrial Internet data management service testing method and system | |
| CN115373886A (en) | Service group container shutdown method, device, computer equipment and storage medium | |
| US11016807B2 (en) | Intermediary system for data streams | |
| CN114387123A (en) | Data acquisition management method |
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 | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20210726 Address after: 200127 block a, 11th floor, no.1500, Puming Road, China (Shanghai) pilot Free Trade Zone, Pudong New Area, Shanghai Applicant after: Shanghai wandehonghui Information Technology Co.,Ltd. Address before: 210019 Wande building, 199 Taishan Road, Jianye District, Nanjing City, Jiangsu Province Applicant before: Nanjing Wande Information Technology Co.,Ltd. |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |