CN115185710A - Transaction interface time consumption counting and early warning method - Google Patents
Transaction interface time consumption counting and early warning method Download PDFInfo
- Publication number
- CN115185710A CN115185710A CN202210881448.3A CN202210881448A CN115185710A CN 115185710 A CN115185710 A CN 115185710A CN 202210881448 A CN202210881448 A CN 202210881448A CN 115185710 A CN115185710 A CN 115185710A
- Authority
- CN
- China
- Prior art keywords
- transaction
- interface
- time
- transaction interface
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- 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/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
- G06F40/186—Templates
-
- 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/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- 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)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- General Business, Economics & Management (AREA)
- Technology Law (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention relates to the field of early warning, and provides a transaction interface time consumption counting and early warning method. The main scheme comprises the steps of continuously reading kafka logs, and when a same transaction interface request message req is found: consumer _ id and response message resp: when consumer _ id is received, determining a complete transaction interface request, analyzing the output time of the two rows of logs as req _ time and resp _ time respectively, calculating the transaction interface consumed time of the transaction interface request, automatically matching a transaction scheduling party and a transaction service party of transaction interface scheduling according to the format of message configuration, and putting information into a new queue kafka for storage; and starting a daemon java thread fmoinitor, continuously reading the consumed time of the transaction interface in the new queue kafka, and informing related personnel when the consumed time of the transaction interface reaches a certain early warning value IMAX.
Description
Technical Field
The invention relates to the field of early warning, and provides a transaction interface time consumption counting and early warning method.
Background
In the existing transaction system, each system can only count the consumed time of the transaction interface thereof, which causes inconsistent statistical calibers of each system due to the inconsistency of factors such as server time and the like, and in addition, the consumed time of the interface counted by the system is generally scanned by a database timing task, which sends early warning information to a system administrator to inform the system administrator of inquiring the cause of failure in time.
The following problems are specifically present:
1. the existing bank IT system is basically designed according to a distributed mode, the system function division is simple, the function scheduling among the systems is carried out through the conversion scheduling processing of an enterprise bus system (ESB system), the transaction time consumption statistics of each system is not standardized, and the problems of inconsistent statistical data caliber, abnormal data and the like are caused;
2. in the existing distributed system, a database or a log is scanned regularly through a script, and the database or the log is confirmed according to the starting interval time of a timing task, so that the early warning processing cannot be performed in a quasi-real-time manner. When a problem occurs, the time for discovering the system interface is long, and the operation and maintenance personnel must inquire and process the system interface on site, so that the timeliness is not enough, and the client or supervision and issuance process is caused.
Disclosure of Invention
In view of the above research problems, the present invention aims to provide a method for time consumption statistics and early warning for a cross-system transaction interface.
In order to achieve the purpose, the invention adopts the following technical scheme:
a cross-system transaction interface time consumption counting and early warning method comprises the following steps:
step 1: based on the unified specification of a message header interface in upstream and downstream system scheduling in an inline enterprise bus (ESB system), when a transaction interface single request provided by a transaction service party is received, a transaction interface scheduling party generates a flow ID, the flow ID is filled into an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface;
step 2: because the existing intra-row enterprise bus (ESB system) system is provided with a function of automatically adding logs into the spurnk log tool (the logs of the ESB system are automatically added into the spurnk log tool, and the spurnk log tool is associated with the kafka message queue, so that the log information is read only by reading the messages in the kafka, because the spurnk log system adopts the kafka message queue to send and process the logs in real time, at the moment, a daemon thread monitor is started, the kafka logs are continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, and is determined as a complete transaction interface request, the output time of the two rows of logs is analyzed as req _ time and resp _ time respectively, the transaction interface time consumption of the transaction interface request is calculated, the transaction scheduling party and the transaction service party of the transaction interface scheduling are automatically matched through the format of message configuration, and the number of the transaction request system, the number of the request response system, the transaction interface time consumption and the number of the transaction interface are placed into a new queue kafka for storage;
and step 3: starting a daemon java thread fmoinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a list of a system administrator and a scientific and technological development manager in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to the system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can timely position the problem for analysis and processing, and finally realize the quick repair processing of the system;
and 4, step 4: in step 3, when the consumed time of the transaction interface in kafka is counted, if the consumed time of the transaction reaches the threshold IKUE (the threshold is less than the warning value), data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of the transaction request system, the number of the transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
and 5: starting java timing task montol, counting the average time consumption rate, critical value transaction proportion and early warning value transaction interface proportion information of each transaction interface through the table data interface _ time in the step 4 and through a report format template to form a pdf document, sending project group personnel recently to perform comparison analysis early warning, finding the condition that the transaction performance is reduced due to long-time operation of the system or system resources such as a database, a disk, a memory and the like, giving a solution in time, and early warning system performance bottleneck to a certain extent, thereby finding and solving the problem early.
The invention also provides a device for counting and early warning the time consumption of the cross-system transaction interface, which comprises the following components:
based on the unified specification of message header interfaces in upstream and downstream system scheduling in an inline enterprise bus, when a transaction interface single request provided by a transaction service party is received, a flow ID is generated by the transaction interface scheduling party and is filled into an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface in an original manner;
because the existing intra-row enterprise bus system is provided with a tool for automatically adding the logs into the splunk log, the splunk log system adopts a kafka message queue to send and process the logs in real time, at this time, a daemon java thread monitor is started, the kafka logs are continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, and is determined as a complete transaction interface request, the output time of the two rows of logs is analyzed as req _ time and resp _ time respectively, the transaction interface time consumption of the transaction interface request is calculated, the transaction scheduling party and the transaction service party of the transaction interface scheduling are automatically matched through the format of message configuration, and the number of the transaction request system, the number of the request response system, the transaction interface time consumption and the number of the transaction interface are placed into a new queue kafka for storage;
starting a daemon java thread fmoinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a list of a system administrator and a scientific and technological development manager in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to the system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can timely position the problem for analysis and processing, and finally realize the quick repair processing of the system;
when the consumed time of a transaction interface in kafka is counted, if the consumed time of the transaction reaches a critical value IKUE, data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of a transaction request system, the number of a transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
starting a java timing task montol, counting the average time consumption rate, the critical value transaction proportion and the early warning value transaction interface proportion information of each transaction interface through the table data interface _ time and the report format template to form a pdf document, and sending a project group person in the near term to perform comparison analysis and early warning.
In the above technical solution, the unified specification of the header interface specifically means: the message after being processed by the ESB system comprises a message header and a message body, wherein the message header comprises a teller number, an organization number, a transaction date, an accounting date, a system tracking number, a transaction serial number and transaction interface number information, a transaction requester must completely fill in the transaction information, and a transaction server must return the message header information in an original state.
In the above technical solution, the CONSUMER _ SEQ is a system tracking number after ESB management, the transaction requester fills the field in the ESB header, and after forwarding through the ESB system and processing by the transaction server, returns the field in the response header.
In the technical scheme, the transaction service party refers to a system for providing services specifically, the ESB system is mainly responsible for forwarding and managing messages, the transaction requester sends the messages to the ESB system, and the ESB system forwards the messages to the transaction service party system.
Compared with the prior art, the invention has the beneficial effects that:
1. the invention analyzes and counts the transaction interface information based on the enterprise service bus log, can count the caliber by the same transaction interface, and avoids the problems of inconsistent statistical dimensions and incomplete statistical information caused by the self-counting of each system.
2. The invention is based on the kafka log framework in the splunk, adopts a daemon thread mode, can accurately and highly timely find out system abnormality, and can timely alarm accurate contents through WeChat, short message and the like, quickly locate problems, solve problems, and reduce the influence on customers and the early warning risk of supervision departments;
3. the invention can analyze and count reports of interfaces with regular travel, and can carry out early warning analysis in advance when the pressure of certain interfaces of the system gradually rises, thereby solving the probability of the time-consuming problem of the system to a certain extent.
Drawings
FIG. 1 is a schematic flow chart of the present invention.
Detailed Description
The above are merely representative examples of the many specific applications of the present invention, and do not limit the scope of the invention in any way. All the technical solutions formed by the transformation or the equivalent substitution fall within the protection scope of the present invention.
A cross-system transaction interface time consumption counting and early warning method comprises the following steps:
step 1: based on the unified specification of a message header interface in upstream and downstream system scheduling in an inline enterprise bus (ESB system), when a transaction interface single request provided by a transaction service party is received, a transaction interface scheduling party generates a flow ID, the flow ID is filled into an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface;
step 2: because the existing intra-row enterprise bus (ESB system) system is provided with a function of automatically adding logs into the spurnk log tool (the logs of the ESB system are automatically added into the spurnk log tool, and the spurnk log tool is associated with the kafka message queue, so that the log information is read only by reading the messages in the kafka, because the spurnk log system adopts the kafka message queue to send and process the logs in real time, at the moment, a daemon thread monitor is started, the kafka logs are continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, deems that a complete transaction interface request is obtained, analyzes the output time of the two rows of logs as req _ time and resp _ time respectively, calculates the transaction interface consumed time of the transaction interface request, automatically matches a transaction scheduling party and a transaction service party of the transaction interface scheduling through the format of message configuration, and puts the number of the transaction request system, the number of the request response system, the consumed time of the transaction interface and the number of the transaction interface into a new queue kafka for storage;
and 3, step 3: starting a daemon java thread fmoinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a list of a system administrator and a scientific and technological development manager in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to the system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can timely position the problem for analysis and processing, and finally realize the quick repair processing of the system;
and 4, step 4: in step 3, when the consumed time of the transaction interface in kafka is counted, if the consumed time of the transaction reaches the threshold IKUE (the threshold is less than the warning value), data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of the transaction request system, the number of the transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
and 5: starting java timing task montol, counting the average time consumption rate, critical value transaction proportion and early warning value transaction interface proportion information of each transaction interface through the table data interface _ time in the step 4 and through a report format template to form a pdf document, sending project group personnel recently to perform comparison analysis early warning, finding the condition that the transaction performance is reduced due to long-time operation of the system or system resources such as a database, a disk, a memory and the like, giving a solution in time, and early warning system performance bottleneck to a certain extent, thereby finding and solving the problem early.
The invention also provides a device for counting and early warning the time consumption of the cross-system transaction interface, which comprises the following components:
based on the unified specification of message header interfaces in upstream and downstream system scheduling in an inline enterprise bus, when a transaction interface single request provided by a transaction service party is received, a flow ID is generated by the transaction interface scheduling party and is filled into an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface in an original manner;
because the existing intra-row enterprise bus system is provided with a means for automatically adding the logs into the spurnk log, the spurnk log system adopts a kafka message queue to send and process the log in real time, at the moment, a daemon java thread monitor is started, the kafka log is continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, and is determined as a complete transaction interface request, the output time of the two rows of logs is analyzed as req _ time and resp _ time respectively, the transaction interface time consumption of the transaction interface request is calculated, the transaction scheduling party and the transaction service party of the transaction interface scheduling are automatically matched through the format of message configuration, and the number of the transaction request system, the number of the request response system, the transaction interface time consumption and the number of the transaction interface are placed into a new queue kafka for storage;
starting a daemon java thread fmoinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a list of a system administrator and a scientific and technological development manager in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to the system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can timely position the problem for analysis and processing, and finally realize the quick repair processing of the system;
when the consumed time of a transaction interface in kafka is counted, if the consumed time of the transaction reaches a critical value IKUE, data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of a transaction request system, the number of a transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
starting a java timing task montol, counting the average time consumption rate, the critical value transaction proportion and the early warning value transaction interface proportion information of each transaction interface through the table data interface _ time and the report format template to form a pdf document, and sending a project group person in the near term to perform comparison analysis and early warning.
In the above technical solution, the unified specification of the header interface specifically means: the message after being processed by the ESB system comprises a message header and a message body, wherein the message header comprises a teller number, an organization number, a transaction date, an accounting date, a system tracking number, a transaction serial number and transaction interface number information, a transaction requester must completely fill in the transaction information, and a transaction server must return the message header information in an original state.
In the above technical solution, the CONSUMER _ SEQ is a system tracking number after ESB management, the transaction requester fills this field in the ESB header, and after forwarding through the ESB system and processing by the transaction server, returns this field in the response header.
In the technical scheme, the transaction service party refers to a system for providing services specifically, the ESB system is mainly responsible for forwarding and managing messages, the transaction requester sends the messages to the ESB system, and the ESB system forwards the messages to the transaction service party system.
Examples
A cross-system transaction interface time consumption counting and early warning method comprises the following steps:
step 1: based on the unified specification of message header interfaces in upstream and downstream system scheduling in an inline enterprise bus, when a transaction interface single request provided by a transaction service party is received, a flow ID is generated by the transaction interface scheduling party and is filled in an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface in an original state.
The method comprises the following specific steps:
step 1.1: the interface service party provides a transaction interface document according to the ESB message specification, the transaction interface document is treated by the ESB, then a message header interface unified specification for upstream and downstream system scheduling is added, and the transaction service party and the transaction scheduling party are required to use a CONSUMER _ SEQ field according to requirements, so that the ESB system can accurately track transactions through logs.
Step 2: because the existing intra-row enterprise bus (ESB system) system is provided with a function of automatically adding logs into the spurnk log tool (the logs of the ESB system are automatically added into the spurnk log tool, and the spurnk log tool is associated with the kafka message queue, so that the log information is read only by reading the messages in the kafka, because the spurnk log system adopts the kafka message queue to send and process the logs in real time, at the moment, a daemon thread monitor is started, the kafka logs are continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, and is determined as a complete transaction interface request, the output time of the two rows of logs is analyzed as req _ time and resp _ time respectively, the transaction interface time consumption of the transaction interface request is calculated, the transaction scheduling party and the transaction service party of the transaction interface scheduling are automatically matched through the format of message configuration, and the number of the transaction request system, the number of the request response system, the transaction interface time consumption and the number of the transaction interface are placed into a new queue kafka for storage;
the method comprises the following specific steps:
step 2.1: existing intra-row enterprise bus (ESB) systems are all configured with a sink log tool which automatically adds logs into the sink log tool, and the sink log tool is all associated with a kafka message queue, so that log records of the ESB systems can be obtained only by reading messages in the kafka;
step 2.2: starting a daemon java thread monitor, connecting a log kafka message queue, circularly reading the messages in the kafka message queue, and when the message records are req: consumer _ id or resp: when logs at the beginning of consumer _ id are recorded, the logs are effective logs for recording interface service request and response, the output time of the two lines of logs is analyzed to be req _ time and resp _ time respectively, the transaction interface time consumption time of the transaction interface request is calculated, a transaction scheduling party and a transaction service party of transaction interface scheduling are automatically matched through the format of message configuration, and the serial number of a transaction request system, the serial number of a request response system, the time consumption time of the transaction interface and the serial number of the transaction interface are placed in a new queue kafka to be stored;
step 2.3: step 2.2, if the message in the circular read kafka message queue is not a valid log, skipping abandoning processing;
and step 3: starting a daemon java thread fmoinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a list of a system administrator and a scientific and technological development manager in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to the system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can timely position the problem for analysis and processing, and finally realize the quick repair processing of the system;
the method comprises the following specific steps:
step 3.1: starting a daemon java thread fmoinitor, connecting the new queue kafka in the step 2, analyzing the interface time consumption by circularly reading the interface statistical message in the queue, and judging the interface time consumption to be compared with an early warning value IMAX (set to 800ms by a parameter) of the interface time consumption.
Step 3.2: step 3.1, if the time consumed by the transaction interface is more than or equal to the IMAX value, the transaction time is determined to exceed the early warning value, the early warning processing is required, at the moment, the data in the system configuration table system _ menu is read through the ID of a transaction request party and the ID of a transaction service party in the interface message, the WeChat IDs or the short message IDs in the system administrator and the scientific and technological development manager list are found, the content assembly is carried out through a short message template with a fixed format and is respectively sent to the system administrator, the upstream and downstream system development managers and the attendant WeChat or the short message, at the moment, after the short message is received, the system developer can find the information of the transaction interface with longer time consumption through the content of the short message, the analysis processing of the positioning problem can be carried out in time, and the quick repair processing of the system can be finally realized;
step 3.3: step 3.1, if the transaction interface time consumption is more than or equal to IKUE (the critical value is less than the early warning value, and the parameter is set to 500 ms) and less than the IMAX value, the subsequent processing is required, specifically see step 4;
step 3.4: and step 3.1, if the interface time consumption is less than the IKUE (the critical value is less than the early warning value, and the parameter is set to be 500 ms), the performance of the transaction interface is considered to meet the requirement, and the transaction interface is directly ignored.
And 4, step 4: when the consumed time of a transaction interface in kafka is counted, if the consumed time of the transaction reaches a critical value IKUE, data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of a transaction request system, the number of a transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
the method comprises the following specific steps:
step 4.1: step 3.3, when the transaction interface time consumption is greater than or equal to the IMAX value, analyzing the number of the transaction request system, the number of the transaction response system, the time consumption of the transaction interface and the number information of the transaction interface in the message, registering the data in an inter _ time table in a database table for storage, and providing basic data for the step 5;
and 5: starting java timing task montol, counting average time consumption rate, critical value transaction proportion and early warning value transaction interface proportion information of each transaction interface through table data interface _ time and report format template to form pdf document, sending project group personnel in the near term, comparing, analyzing and early warning
The method comprises the following specific steps:
step 5.1: and step 4, starting a java timing task montol through a timing task configuration interval period M (set to be 5 per week), counting the average time consumption rate of each transaction interface, the occupation ratio of critical value transaction, the occupation ratio of the early warning value transaction interface, and a related report format template by counting the data of the previous 7 days in the interface _ time table and taking the transaction interface id as a group index, generating a pdf document, and sending the pdf document to a corresponding system project worker through an inline mail system.
Step 5.2: and 5.2, when the personnel of the project group find that the average time consumption rate of the transaction interface is obviously improved compared with the previous period, paying attention to the performance of the system interface, evaluating the reason for the average time consumption of the interface, analyzing in advance according to a production log system, finding out the performance problem in time and solving the performance problem in an early stage.
Claims (8)
1. A cross-system transaction interface time consumption counting and early warning method is characterized by comprising the following steps:
step 1: based on the unified specification of message header interfaces in upstream and downstream system scheduling in an inline enterprise bus, when a transaction interface single request provided by a transaction service party is received, a flow ID is generated by the transaction interface scheduling party and is filled into an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface in an original manner;
step 2: because the existing intra-row enterprise bus system is already configured with a means for automatically adding the logs into the spurnk log, and because the spurnk log system adopts the kafka message queue to send and process the logs in real time, a daemon java thread monitor should be started at the moment, the kafka logs are continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, and is determined as a complete transaction interface request, the output time of the two rows of logs is analyzed as req _ time and resp _ time respectively, the transaction interface time consumption of the transaction interface request is calculated, the transaction scheduling party and the transaction service party of the transaction interface scheduling are automatically matched through the format of message configuration, and the number of the transaction request system, the number of the request response system, the transaction interface time consumption and the number of the transaction interface are placed into a new queue kafka for storage;
and step 3: starting a daemon java thread fmoinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a list of a system administrator and a scientific and technological development manager in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to the system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can timely position the problem for analysis and processing, and finally realize the quick repair processing of the system;
and 4, step 4: in step 3, when the consumed time of the transaction interface in kafka is counted, if the consumed time of the transaction reaches the critical value IKEUE, data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of a transaction request system, the number of a transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
and 5: and (4) starting java timing task montol, counting the average time consumption rate, critical value transaction proportion and early warning value transaction interface proportion information of each transaction interface through the table data interface _ time and the report format template in the step (4), forming a pdf document, and sending a project group personnel in the near term to perform comparison analysis and early warning.
2. The cross-system transaction interface time consumption statistics and early warning method according to claim 1, wherein the method comprises the following steps: the unified specification of the message header interface specifically means: the message after being processed by the ESB system comprises a message header and a message body, wherein the message header comprises a teller number, an organization number, a transaction date, an accounting date, a system tracking number, a transaction serial number and transaction interface number information, a transaction requester must completely fill in the transaction information, and a transaction server must return the message header information in an original state.
3. The cross-system transaction interface time consumption statistics and early warning method according to claim 1, wherein the method comprises the following steps: the CONSUMER _ SEQ is a system tracking number after ESB treatment, the field is filled in an ESB message header by a transaction request party, and after the ESB message header is forwarded by an ESB system and processed by a transaction service party, the field is returned in a response message header.
4. The cross-system transaction interface time consumption statistics and early warning method according to claim 1, wherein the method comprises the following steps: the transaction service side refers to a system for providing service specifically, the ESB system is mainly responsible for the forwarding and management work of messages, the transaction request side sends the messages to the ESB system, and the ESB system forwards the messages to the transaction service side system.
5. A cross-system transaction interface time consumption counting and early warning device is characterized by comprising:
based on the unified specification of message header interfaces in upstream and downstream system scheduling in an inline enterprise bus, when a transaction interface single request provided by a transaction service party is received, a flow ID is generated by the transaction interface scheduling party and is filled into an ESB message header CONSUMER _ SEQ, and the transaction service party returns the field message in a return message interface in an original manner;
because the existing intra-row enterprise bus system is provided with a tool for automatically adding the logs into the spurnk log, the spurnk log system adopts a kafka message queue to send and process the logs in real time, at the moment, a daemon java thread monitor is started, the kafka logs are continuously read, and when the same transaction interface request message req is found: consumer _ id and response message resp: consumer _ id, req: consumer _ id is the number of the transaction request system, resp: the consumer _ id is the number of the request response system, deems that a complete transaction interface request is obtained, analyzes the output time of the two rows of logs as req _ time and resp _ time respectively, calculates the transaction interface consumed time of the transaction interface request, automatically matches a transaction scheduling party and a transaction service party of the transaction interface scheduling through the format of message configuration, and puts the number of the transaction request system, the number of the request response system, the consumed time of the transaction interface and the number of the transaction interface into a new queue kafka for storage;
starting a daemon java thread fmcinitor, continuously reading the consumed time of a transaction interface in a new queue kafka, when the consumed time of the transaction interface reaches a certain early warning value IMAX, reading WeChat or short messages in a system administrator and a scientific and technological development manager list in time, assembling the content through a short message template with a fixed format, and respectively sending the WeChat or short messages to a system administrator, an upstream and downstream system development manager and an attendant, wherein after receiving the short messages, the system developer can find the information of the transaction interface with longer consumed time through the content of the short messages in time, can locate the problem in time for analysis and processing, and finally realize the quick repair processing of the system;
when the consumed time of a transaction interface in kafka is counted, if the consumed time of the transaction reaches a critical value IKUE, data is required to be refreshed into a database table interface _ time for storage, wherein the data comprises the number of a transaction request system, the number of a transaction response system, the consumed time of the transaction interface and the number of the transaction interface;
starting a java timing task montol, table data interface _ time and a report form format template, counting the average time consumption rate, critical value transaction proportion and early warning value transaction interface proportion information of each transaction interface to form a pdf document, and sending project group personnel for comparison, analysis and early warning in the near term.
6. The device for counting and warning the consumed time of the transaction interface of the cross-system according to claim 5, wherein the unified specification of the header interface is specifically as follows: the message after being processed by the ESB system comprises a message header and a message body, wherein the message header comprises a teller number, an organization number, a transaction date, an accounting date, a system tracking number, a transaction serial number and transaction interface number information, a transaction requester must completely fill in the transaction information, and a transaction server must return the message header information in an original state.
7. The cross-system transaction interface time consumption statistics and early warning device of claim 5, wherein: the CONSUMER _ SEQ is a system tracking number after being processed by ESB, the field is filled in an ESB message header by a transaction request party, and the field is returned in a response message header after being forwarded by the ESB system and processed by a transaction service party.
8. The cross-system transaction interface time consumption statistics and early warning device of claim 5, wherein: the transaction service side refers to a system for providing service specifically, the ESB system is mainly responsible for the forwarding and management work of messages, the transaction request side sends the messages to the ESB system, and the ESB system forwards the messages to the transaction service side system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210881448.3A CN115185710A (en) | 2022-07-21 | 2022-07-21 | Transaction interface time consumption counting and early warning method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210881448.3A CN115185710A (en) | 2022-07-21 | 2022-07-21 | Transaction interface time consumption counting and early warning method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115185710A true CN115185710A (en) | 2022-10-14 |
Family
ID=83522220
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210881448.3A Pending CN115185710A (en) | 2022-07-21 | 2022-07-21 | Transaction interface time consumption counting and early warning method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115185710A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116627486A (en) * | 2023-07-25 | 2023-08-22 | 中博信息技术研究院有限公司 | Compact configuration type rest interface management and message conversion method and device |
-
2022
- 2022-07-21 CN CN202210881448.3A patent/CN115185710A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116627486A (en) * | 2023-07-25 | 2023-08-22 | 中博信息技术研究院有限公司 | Compact configuration type rest interface management and message conversion method and device |
| CN116627486B (en) * | 2023-07-25 | 2023-10-20 | 中博信息技术研究院有限公司 | Compact configuration type rest interface management and message conversion method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8156172B2 (en) | Monitoring and reporting enterprise data using a message-based data exchange | |
| CN110740103A (en) | Service request processing method and device, computer equipment and storage medium | |
| US11322013B2 (en) | Monitoring method of MES, monitoring device, and readable storage medium | |
| CN102801785B (en) | System and method for monitoring advertisement putting engine | |
| CN114257636B (en) | Unified message publishing method | |
| CN110147470B (en) | Cross-machine-room data comparison system and method | |
| CN112508486A (en) | Secondary spare part inventory management system for power system enterprise | |
| CN115185710A (en) | Transaction interface time consumption counting and early warning method | |
| CN112269727A (en) | Monitoring and alarming method and system based on log information | |
| CN116010190A (en) | ESB service monitoring management system and method | |
| CN114090529A (en) | Log management method, device, system and storage medium | |
| US7769651B2 (en) | Method and system of processing billing data | |
| CN109858807A (en) | A kind of method and system of enterprise operation monitoring | |
| CN112214459A (en) | Resource processing flow log collection system based on event mechanism | |
| CN112801623A (en) | Patent process management system and method | |
| CN113472881B (en) | Statistical method and device for online terminal equipment | |
| CN112965793B (en) | Identification analysis data-oriented data warehouse task scheduling method and system | |
| CN114580898A (en) | Efficient collection system and method, electronic device and readable storage medium | |
| CN114218045A (en) | Method and system for monitoring transaction amount based on nginx log flow analysis | |
| CN113986656A (en) | Power grid data safety monitoring system based on data center | |
| CN113760669A (en) | Problem data warning method and device, electronic equipment and storage medium | |
| CN111061609A (en) | Log monitoring method and system | |
| CN111983960A (en) | Monitoring system and method | |
| CN111767283B (en) | Data system monitoring method and system | |
| TWI789576B (en) | Centralized Online Monitoring System |
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 |