CN117149826A - Method, device, computer equipment and storage medium for storing service call log - Google Patents
Method, device, computer equipment and storage medium for storing service call log Download PDFInfo
- Publication number
- CN117149826A CN117149826A CN202311041933.0A CN202311041933A CN117149826A CN 117149826 A CN117149826 A CN 117149826A CN 202311041933 A CN202311041933 A CN 202311041933A CN 117149826 A CN117149826 A CN 117149826A
- Authority
- CN
- China
- Prior art keywords
- log data
- call log
- request
- storing
- time
- 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
- 238000000034 method Methods 0.000 title claims abstract description 57
- 239000000872 buffer Substances 0.000 claims abstract description 218
- 238000004590 computer program Methods 0.000 claims description 22
- 230000000875 corresponding effect Effects 0.000 description 43
- 238000010586 diagram Methods 0.000 description 15
- 230000001680 brushing effect Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- 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
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Telephonic Communication Services (AREA)
Abstract
The application relates to a method, a device, computer equipment and a storage medium for storing service call logs. The method comprises the following steps: acquiring call log data, and storing the call log data into a target buffer area corresponding to a request to which the call log data belongs; updating the request time corresponding to the request according to the calling time in the calling log data; and storing the call log data in the target buffer zone into a database under the condition that the request time meets the preset end condition. By adopting the method, the delay of storing the call log data in the database can be reduced.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and apparatus for storing service call logs, a computer device, and a storage medium.
Background
Distributed link tracking is a method for analyzing and monitoring applications, particularly those built using micro-service architecture. Distributed tracking helps to pinpoint where failures occur and why performance is low, and developers can use distributed tracking to help debug and optimize their code.
Each service generates a piece of call log data (Span, also called Span data) when calling other services, and the call log data has a corresponding relation with a request for generating the call log data. Therefore, a corresponding row is allocated in the data table for each request in the database, and the log data is stored in the database according to the request after the log data is generated, so that the log data belonging to the same request can be stored together. And after the request is finished, acquiring all data in the row corresponding to the request, and drawing a calling condition diagram of the request to help analyze the problem.
However, since log data is generated very fast, this method requires frequent read and write operations to the database. Due to the speed of writing to the database, log data is delayed from generation to storage into the database by tens of minutes to hours, resulting in inefficient generation of call case graphs.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a method, apparatus, computer device, and storage medium for storing a service call log.
In a first aspect, the present application provides a method for storing a service call log. The method comprises the following steps:
Acquiring call log data, and storing the call log data into a target buffer area corresponding to a request to which the call log data belongs;
updating the request time corresponding to the request according to the calling time in the calling log data;
and storing the call log data in the target buffer zone into a database under the condition that the request time meets the preset ending condition.
In one embodiment, the storing the call log data in the target buffer area corresponding to the request to which the call log data belongs includes:
acquiring a request identifier from the call log data, wherein the request identifier is used for representing a request to which the call log data belongs;
and storing the call log data into the target buffer area when the target buffer area matched with the request identification exists in each buffer area.
In one embodiment, the method further comprises:
and under the condition that a target buffer area matched with the request identification does not exist in each buffer area, creating a new buffer area according to the request identification, taking the new buffer area as the target buffer area, and storing the call log data into the target buffer area.
In one embodiment, the method further comprises:
acquiring current time and determining a time difference between the current time and the request time;
under the condition that the time difference is larger than a time threshold, determining that the request time meets a preset ending condition; or,
and under the condition that the time difference is smaller than or equal to the time threshold, determining that the request time does not meet the preset ending condition.
In one embodiment, the storing the call log data in the target buffer into a database includes:
storing each call log data in the target buffer zone into a clone buffer zone, and deleting the target buffer zone from each buffer zone;
and storing all call log data in the clone buffer into a database.
In one embodiment, storing each of the call log data in the target buffer into a clone buffer includes:
acquiring a father service identifier in each call log data;
sorting the call log data based on the parent service identifier so that the parent service identifier of the call log data arranged in the subsequent bit is the service identifier of the call log data arranged in the previous bit for any two adjacent call log data;
And storing the sequenced call log data into a clone buffer area in sequence.
In one embodiment, the storing all of the call log data in the clone buffer in a database includes:
and calling a sequential disk brusher, so that the sequential disk brusher sequentially stores all the call log data in the clone buffer into a continuous storage space in a database.
In one embodiment, the acquiring call log data includes:
and pulling the call log data from the message middleware under the condition that the message middleware for storing the call log data is pushed.
In a second aspect, the application further provides a device for storing the service call log. The device comprises:
the first acquisition module is used for acquiring call log data and storing the call log data into a target buffer area corresponding to a request to which the call log data belongs;
the updating module is used for updating the request time corresponding to the request according to the calling time in the calling log data;
and the storage module is used for storing the call log data in the target buffer zone into a database under the condition that the request time meets the preset end condition.
In one embodiment, the first obtaining module is further configured to:
acquiring a request identifier from the call log data, wherein the request identifier is used for representing a request to which the call log data belongs;
and storing the call log data into the target buffer area when the target buffer area matched with the request identification exists in each buffer area.
In one embodiment, the apparatus further comprises:
the creating module is used for creating a new buffer area according to the request identification when a target buffer area matched with the request identification does not exist in each buffer area, taking the new buffer area as the target buffer area and storing the call log data into the target buffer area.
In one embodiment, the apparatus further comprises:
the acquisition module is used for acquiring the current time and determining the time difference between the current time and the request time;
the processing module is used for determining that the request time meets a preset ending condition under the condition that the time difference is larger than a time threshold value; or,
and under the condition that the time difference is smaller than or equal to the time threshold, determining that the request time does not meet the preset ending condition.
In one embodiment, the storage module is further configured to:
storing each call log data in the target buffer zone into a clone buffer zone, and deleting the target buffer zone from each buffer zone;
and storing all call log data in the clone buffer into a database.
In one embodiment, the storage module is further configured to:
acquiring a father service identifier in each call log data;
sorting the call log data based on the parent service identifier so that the parent service identifier of the call log data arranged in the subsequent bit is the service identifier of the call log data arranged in the previous bit for any two adjacent call log data;
and storing the sequenced call log data into a clone buffer area in sequence.
In one embodiment, the storage module is further configured to:
and calling a sequential disk brusher, so that the sequential disk brusher sequentially stores all the call log data in the clone buffer into a continuous storage space in a database.
In one embodiment, the first obtaining module is further configured to:
And pulling the call log data from the message middleware under the condition that the message middleware for storing the call log data is pushed.
In a third aspect, the present application also provides a computer device. The computer device comprises a memory storing a computer program and a processor implementing any of the methods above when executing the computer program.
In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements any of the methods above.
In a fifth aspect, the present application also provides a computer program product. The computer program product comprising a computer program which, when executed by a processor, implements any of the methods above.
The method, the device, the computer equipment and the storage medium for storing the service call log set up a buffer zone for each request, store the call log data of the request into the buffer zone first, and continuously detect whether the request time of the request meets the preset end condition. And under the condition that the request time meets the preset end condition, the call log data is written into the database once. By setting the buffer area, the embodiment of the application can reduce the number of write operations performed on the database when the service call log is stored, and reduce the delay of storing the log data into the database.
Drawings
FIG. 1 is a flow diagram of a method of storing a service call log in one embodiment;
FIG. 2 is a flow chart of step 104 in one embodiment;
FIG. 3 is a flow diagram of a method of storing a service call log in one embodiment;
FIG. 4 is a flow chart of step 106 in one embodiment;
FIG. 5 is a flow chart illustrating step 402 in one embodiment;
FIG. 6 is a schematic diagram of a request to invoke a service in one embodiment;
FIG. 7 is a diagram of call log data in one embodiment;
FIG. 8 is a diagram of call log data obtained by message middleware in one embodiment;
FIG. 9 is a block diagram of the storage of service call logs in one embodiment;
fig. 10 is an internal structural view of a computer device in one embodiment.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
In one embodiment, as shown in fig. 1, a method for storing service call logs is provided, and this embodiment is described in that the method is applied to an Aggregator (aggreator) component, and includes the following steps:
Step 102, acquiring call log data, and storing the call log data in a target buffer area corresponding to a request to which the call log data belongs.
In the embodiment of the application, under the condition that the service is called and the call log data is generated, each service can push the call log data to the aggregator so that the aggregator can acquire the call log data. There is a correspondence between call log data and requests to call the service. The correspondence may be recorded in the call log data (for example, the call log data may record information such as a name or a request identifier of a request), or the aggregator may calculate, through time of generating the call log data and time of generating each request, a request to which the call log data belongs, which is not particularly limited in the embodiment of the present application.
The aggregator may internally set a plurality of buffers, the buffers having a correspondence with the requests. The aggregator may allocate a buffer to a request when call log data corresponding to the request is first acquired, and store the call log data in the buffer. And then, according to the buffer area corresponding to the request to which each call log data belongs, the call log data are respectively stored into the corresponding buffer areas, so that the call log data belonging to the same request are all located in the same buffer area.
Step 104, updating the request time corresponding to the request according to the call time in the call log data.
In the embodiment of the application, the aggregator can record the request time corresponding to each request, wherein the request time refers to the time when the request finally calls the service. The call log data records the time (call time) when the service that generated the call log data is called. Therefore, after receiving the call log data, the aggregator can update the request time according to the call time in the call log data, so that the aggregator can acquire the latest request time corresponding to each request.
In general, the call log data is pushed to the aggregator according to the order of generation, so the aggregator can update the request time of the request corresponding to the call log data directly according to the call time in the call log data after receiving the call log data. Or considering the situation that the call log data has delay when being pushed, the aggregator can also compare the call time with the currently recorded request time, update the request time when the call time is later than the request time, and not update the request time when the call time is earlier than or equal to the request time.
And step 106, storing the call log data in the target buffer zone into a database under the condition that the request time meets the preset end condition.
In the embodiment of the present application, the preset end condition is a preset condition for judging whether each log data in the buffer should be written into the database. The preset end condition may be related to the request time. For example, the preset ending condition may be set such that the difference between the request time and the current time is greater than a time threshold, that is, if the request does not generate call log data for a long time, each call log data in the target buffer may be stored in the database first, and the storage space in the aggregator is released; subsequently, if the request generates new call data, the aggregator may re-establish a buffer for the request. Alternatively, the preset end condition may be set such that, in a case where the number of call log data in the buffer does not exceed the number threshold, the difference between the request time and the current time is greater than a larger time threshold, and in a case where the number of call log data exceeds the number threshold, the difference between the request time and the current time is greater than another smaller time threshold: that is, if the number of call log data in the buffer area corresponding to a certain request is large, the time threshold corresponding to the buffer area is small, so that the aggregator can store all call log data in the buffer area into the database and quickly release the storage space of the aggregator under the condition that no new call log data is stored in the buffer area in a short time; if the number of call log data in the buffer area corresponding to a certain request is smaller, the time threshold corresponding to the buffer area can be larger because the memory space occupied by the buffer area is smaller.
The aggregator may detect a request time corresponding to each request every a period of time to determine whether the request time meets a preset end condition. Under the condition that the request time meets the preset end condition, the aggregator can write all call log data in the target buffer area into the database once, so that the number of times of writing into the database is reduced.
According to the method for storing the service call log, provided by the embodiment of the application, a buffer area is set for each request, call log data of the request is firstly stored in the buffer area, and whether the request time of the request meets the preset ending condition is continuously detected. And under the condition that the request time meets the preset end condition, the call log data is written into the database once. By setting the buffer area, the embodiment of the application can reduce the number of write operations performed on the database when the service call log is stored, and reduce the delay of storing the log data into the database.
In one embodiment, as shown in fig. 2, in step 104, storing call log data in a target buffer corresponding to a request to which the call log data belongs includes:
step 202, obtaining a request identifier from the call log data, where the request identifier is used to characterize a request to which the call log data belongs.
In step 204, in the case that there is a target buffer matching the request identifier in each buffer, the call log data is stored in the target buffer.
In the embodiment of the application, each request is allocated with a globally unique request identifier when being generated, and the request identifier of the request for calling the service can be stored in the call log data so as to indicate the request to which the call log data belongs.
The aggregator may store the existing correspondence between buffers and request identifiers. After receiving the call log data, the aggregator may obtain the request identifier from the call log data and match the request identifier with each buffer. And under the condition that the target buffer corresponding to the request identifier is matched, indicating that the target buffer is the buffer corresponding to the request to which the call log data belongs. The aggregator may in turn store call log data into the target buffer.
According to the method for storing the service call log, under the condition that the request identifier is stored in the call log data, the request identifier is obtained from the call log data, the call log data is stored in the target buffer area corresponding to the request identifier, so that the call log data corresponding to each request can be stored in one buffer area, and then the call log data is written into the database once under the condition that the request time of the request meets the preset ending condition, and the delay of storing the log data into the database is reduced.
In one embodiment, the method further comprises:
and under the condition that no target buffer area matched with the request identification exists in each buffer area, creating a new buffer area according to the request identification, taking the new buffer area as the target buffer area, and storing the call log data into the target buffer area.
In the embodiment of the application, under the condition that the aggregator cannot be matched with the corresponding target buffer area according to the request identifier, the aggregator can create a new buffer area and record the corresponding relation between the new buffer area and the request identifier, so that the new buffer area becomes the buffer area corresponding to the request identifier. The aggregator may then store the call log data in the target buffer with the new buffer as the target buffer to which the call log data corresponds.
According to the method for storing the service call log, when the buffer area corresponding to the request identifier does not exist, a new buffer area is created according to the request identifier, the new buffer area is used as a target buffer area, and call log data are stored in the target buffer area corresponding to the request identifier. A corresponding buffer may be created for a request if the aggregator first receives call log data corresponding to the request.
In one embodiment, as shown in fig. 3, the method further includes:
step 302, the current time is obtained, and a time difference between the current time and the requested time is determined.
Step 304, determining that the request time meets a preset ending condition under the condition that the time difference is larger than a time threshold; or,
in step 306, in the case that the time difference is less than or equal to the time threshold, it is determined that the request time does not satisfy the preset end condition.
In the embodiment of the application, whether the time difference between the current time and the request time is larger than the time threshold value can be used as a preset ending condition. The time threshold may be a predetermined fixed value or may be a dynamic value related to the amount of call log data in the buffer, the rate at which call log data enters the aggregator.
For example, a time threshold may be set for each buffer, so that the time threshold of each buffer is inversely related to the number of call log data in the buffer, that is, the more the number of call log data is, the shorter the time threshold of the buffer is, so that the aggregator can store call log data for the buffer with the larger number of call log data, and release the storage space of the aggregator under the condition that no new call log data enters in the buffer in a short time.
Alternatively, the same time threshold may be set for each buffer, and the time threshold and the speed at which call log data enters the aggregator are positively correlated. That is, if the speed of entering the aggregator by the call log data is high, it indicates that the call log data generated by each service is more at this time, and the call log data is easy to be blocked when entering the aggregator, and can be acquired by the aggregator only after a long time after the call log data is generated. In this case, the time threshold may be set to be relatively large (for example, several minutes), so that it is ensured that when the request does not generate call log data any more, that is, when the request has ended, each call log data in the buffer is stored in the database, so that call log data belonging to the same request are stored together, and call situation diagrams of subsequent drawing requests are facilitated. Under the condition that the call log data enters the aggregator at a low speed, the fact that the call log data generated by each service is less is indicated, and the call log data can be acquired by the aggregator quickly after the call log data are generated. The time threshold may be set smaller (e.g., a few seconds) at this time, reducing the delay in the call log data being stored in the database.
The aggregator may calculate the time difference between the current time and the request time of each request once every fixed time interval. And under the condition that the time difference corresponding to the buffer area is larger than the corresponding time threshold value, the aggregator can determine that the buffer area meets the preset ending condition, and store the call log data in the buffer area into the database. And under the condition that the time difference corresponding to the buffer area is smaller than or equal to the corresponding time threshold value, the aggregator can determine that the buffer area does not meet the preset ending condition, and continuously repeat the process of acquiring the call log data corresponding to the buffer area.
According to the method for storing the service call log, whether the request time meets the preset ending condition is judged according to whether the time difference between the current time and the request time is larger than the time threshold. And under the condition that the request time meets the preset end condition, the call log data is written into the database once. By setting the buffer area, the embodiment of the application can reduce the number of write operations performed on the database when the service call log is stored, improve the efficiency of storing log data into the database, and further improve the efficiency of generating the call situation diagram.
In one embodiment, as shown in FIG. 4, storing call log data in the target buffer into a database in step 106 includes:
step 402, store each call log data in the target buffer into the clone buffer, and delete the target buffer from each buffer.
Step 404, storing all call log data in the clone buffer into a database.
In the embodiment of the application, since the aggregator may need to call other components to store call log data, and each buffer area in the aggregator is changed at any time (when call log data corresponding to a new request appears, a new buffer area needs to be created, and when an old request ends, a buffer area of the old request needs to be deleted), a clone buffer area can be set for temporarily storing call log data which needs to be stored in a database, and other components are enabled to be fixedly bound with the clone buffer area to receive data pushed to the clone buffer area.
When the call log data in the target buffer area needs to be stored in the database, the aggregator can store the call log data in the target buffer area in the clone buffer area first, delete the original target buffer area and release the storage space of the aggregator. The aggregator can then call other components to store all call log data of the clone buffer into the database, and empty the clone buffer, prepare to receive the next request time and store the call log data therein.
It should be noted that, if there are multiple buffers with request time meeting the preset end condition, in order to ensure that call log data in each buffer can be sequentially stored in the same area in the database, call log data in one buffer may be stored in a clone buffer first, after all call log data in the to-be-cloned buffer are stored in the database, the clone buffer is emptied, and then each call log data in another buffer is stored in the clone buffer, so that the situation that call log data in two buffers are simultaneously stored in the clone buffer, and call log data confusion occurs when other components store call log data in the clone buffer in the database is avoided.
According to the method for storing the service call log, provided by the embodiment of the application, the clone buffer is set, when call log data in the target buffer is required to be stored in the database, each call log data is firstly stored in the clone buffer, then the call log data in the clone buffer is stored in the database, and the target buffer is deleted. Therefore, other components called by the aggregator can be fixed and bound with the clone buffer, the process of binding the buffer with other components called by the aggregator is not required to be repeated once after the aggregator creates a new buffer each time, and the efficiency of storing call log data into a database can be improved.
In one embodiment, as shown in FIG. 5, storing call log data in the target buffer into the clone buffer in step 402 includes:
step 502, obtaining a parent service identifier in each call log data.
Step 504, sorting the call log data based on the parent service identifier, so that the parent service identifier of the call log data arranged in the next bit is the service identifier of the call log data arranged in the previous bit for any two adjacent call log data.
Step 506, storing the sequenced call log data in the clone buffer in sequence.
In the embodiment of the application, the service identifier of the service and the service identifier of the service for calling the service, namely the father service identifier, are also recorded in the calling log data. When the call log data is stored in the clone buffer, the call log data may be ordered according to the parent service identifier and the service identifier, so that the order of the call log data in the clone buffer is the order in which the services are called.
Referring to fig. 6, a full process of requesting a call service is shown. After the user initiates a request to service a, service a needs to invoke service B, which in turn needs to invoke service C (database). The service C returns the data to the service B, the service B returns the data to the service A, and the service A sends the data back to the user. Referring to fig. 7, when the request arrives at service a, service a generates call log data 1 including the service identifier of service a (there is no parent service identifier in the call log data since there is no service calling service a). When service a calls service B, service B generates call log data 2 including the service identifier of service B and the parent service identifier of service B (i.e., the service identifier of service a). When service B calls service C, service C will generate call log data 3, which includes the service identifier of service C and the parent service identifier of service C (i.e., the service identifier of service B).
When the aggregator needs to store call log data 1, 2, 3 in the clone buffer, the aggregator can sort the call log data 1, 2, 3. For example, call log data of a service having no parent service identifier, that is, a service having received a request, may be first arranged in a first place, and then, call log data having the same parent service identifier as the service identifier X may be determined from the remaining call log data by repeating a service identifier (hereinafter referred to as service identifier X) in the call log data currently arranged in a last place (hereinafter referred to as call log data X), and the call log data may be arranged in call log data X to become new call log data X. If there are multiple call log data whose parent service identifier is the same as the service identifier X, it is possible to determine which call log data is generated by the service call corresponding to the call log data X according to the call time in the call log data.
Taking the above example as an example, the call log data 1 of the service a may be first arranged in the first bit. At this time, there is only one call log data 1 in the sorting queue, so the call log data arranged in the last bit is also call log data 1. At this time, the call log data X is call log data 1, and the service identifier X is service identifier 1. In the remaining call log data: in the call log data 2 and the call log data 3, the father service identifier of the call log data 2 is the service identifier 1, and the father service identifier of the call log data 3 is the service identifier 2, so that only the father service identifier of the call log data 2 is the same as the service identifier X, and the call log data 2 is arranged at the later position of the call log data 1. At this time, the call log data X becomes call log data 2, and the service identifier X is service identifier 2. In the rest of the call log data, the father service identifier of the call log data 3 is the same as the service identifier X, and the call log data 3 is arranged in the latter bit of the call log data 2. At this time, no other call log data exists, and the sorting is finished, so that the aggregator can store the call log data in the clone buffer according to the sequence of 1, 2 and 3, so that when the call log data in the clone buffer is stored in the database, the call log data can also be stored in the database according to the sequence in which the services are called, and the call situation diagram of the subsequent drawing request is facilitated.
According to the method for storing the service call log, when the call log data are stored in the clone buffer area, the call log data are ordered according to the father service identification and the service identification, so that the call log data are arranged in the clone buffer area according to the actual calling sequence of the service, the call log data can be arranged according to the actual calling sequence of the service when being stored in the database, and the call condition diagram of a subsequent drawing request can be drawn by sequentially reading the call log data in the database, so that the efficiency of generating the call condition diagram is improved.
In one embodiment, in step 404, storing all call log data in the clone buffer into a database includes:
the sequential disk brusher is invoked such that the sequential disk brusher sequentially stores all call log data in the clone buffer into contiguous memory space in the database.
In an embodiment of the present application, the sequential disk brush (Sequential Writer) is a Java component that allocates a contiguous block of memory space on disk for incoming data and sequentially writes the incoming data into the memory space. The sequential disk brusher can be connected to an aggregator and a database. After the aggregator stores the call log data in the clone buffer, the sequential disk brusher can be called, and the call log data in the clone buffer is pushed to the sequential disk brusher. The sequential disk brusher can allocate a continuous storage space in the database for each call log data in the clone buffer, and store each call log data in sequence into the continuous storage space.
According to the method for storing the service call log, the call sequence disk brushing device stores the call log data, and as the sequence disk brushing device distributes a continuous storage space for the call log data to be stored in the database, the sequence disk brushing device can sequentially read and write the database disk when the call log data are stored and a call condition diagram is generated by subsequently reading the call log data, and the speed of reading and writing the call log data is improved.
In one embodiment, in step 102, obtaining call log data includes:
in the event that a message middleware push is received that stores call log data, the call log data is pulled from the message middleware.
In the embodiment of the application, message middleware can be adopted to buffer among various services and aggregators. Referring to fig. 8, the message middleware may be Kafka. Each service stores data into Kafka as a producer (producer) of Kafka, and the aggregator subscribes to partitions (parts) of Kafka from which data is consumed as a consumer (consumer) of Kafka. So that in the case of a service logging call log data into Kafka, kafka may push call log data to the aggregator, which in turn may pull call log data from Kafka.
According to the method for storing the service call log, the call log data pushed by the service are stored through the message middleware, so that the aggregator can pull the call log data from the message middleware through subscribing the message middleware. The embodiment of the application adopts the message middleware to buffer between the service and the aggregator, so that the pressure on the aggregator can be avoided when the call log data generated at the same time is too much.
It should be understood that, although the steps in the flowcharts related to the embodiments described above are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.
Based on the same inventive concept, the embodiment of the application also provides a storage device for the service call log, which is used for realizing the storage method for the service call log. The implementation of the solution provided by the device is similar to the implementation described in the above method, so the specific limitation in the embodiments of the storage device for one or more service call logs provided below may be referred to the limitation of the storage method for the service call log hereinabove, and will not be repeated herein.
In one embodiment, as shown in fig. 9, there is provided a storage device 900 of a service call log, including: a first obtaining module 902, an updating module 904, a storing module 906, wherein:
a first obtaining module 902, configured to obtain call log data, and store the call log data in a target buffer corresponding to a request to which the call log data belongs;
an updating module 904, configured to update a request time corresponding to the request according to the call time in the call log data;
and a storage module 906, configured to store each call log data in the target buffer into a database when the request time meets a preset end condition.
The storage device of the service call log provided by the embodiment of the application sets a buffer area for each request, stores the call log data of the request into the buffer area, and continuously detects whether the request time of the request meets the preset end condition. And under the condition that the request time meets the preset end condition, the call log data is written into the database once. By setting the buffer area, the embodiment of the application can reduce the number of write operations performed on the database when the service call log is stored, improve the efficiency of storing log data into the database, and further improve the efficiency of generating the call situation diagram.
In one embodiment, the first obtaining module 902 is further configured to:
acquiring a request identifier from the call log data, wherein the request identifier is used for representing a request to which the call log data belongs;
and storing the call log data into the target buffer area when the target buffer area matched with the request identification exists in each buffer area.
In one embodiment, the apparatus further comprises:
the creating module is used for creating a new buffer area according to the request identification when a target buffer area matched with the request identification does not exist in each buffer area, taking the new buffer area as the target buffer area and storing the call log data into the target buffer area.
In one embodiment, the apparatus further comprises:
the acquisition module is used for acquiring the current time and determining the time difference between the current time and the request time;
the processing module is used for determining that the request time meets a preset ending condition under the condition that the time difference is larger than a time threshold value; or,
and under the condition that the time difference is smaller than or equal to the time threshold, determining that the request time does not meet the preset ending condition.
In one embodiment, the storage module 906 is further configured to:
storing each call log data in the target buffer zone into a clone buffer zone, and deleting the target buffer zone from each buffer zone;
and storing all call log data in the clone buffer into a database.
In one embodiment, the storage module 906 is further configured to:
acquiring a father service identifier in each call log data;
sorting the call log data based on the parent service identifier so that the parent service identifier of the call log data arranged in the subsequent bit is the service identifier of the call log data arranged in the previous bit for any two adjacent call log data;
And storing the sequenced call log data into a clone buffer area in sequence.
In one embodiment, the storage module 906 is further configured to:
and calling a sequential disk brusher, so that the sequential disk brusher sequentially stores all the call log data in the clone buffer into a continuous storage space in a database.
In one embodiment, the first obtaining module 902 is further configured to:
and pulling the call log data from the message middleware under the condition that the message middleware for storing the call log data is pushed.
The various modules in the storage of the service call log described above may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 10. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements a method of storing a service call log.
It will be appreciated by those skilled in the art that the structure shown in FIG. 10 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having stored therein a computer program, the processor implementing the steps of the method embodiments described above when the computer program is executed.
In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored which, when executed by a processor, carries out the steps of the method embodiments described above.
In an embodiment, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the steps of the method embodiments described above.
The user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or sufficiently authorized by each party.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magnetic random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (Phase Change Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in the form of a variety of forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), and the like. The databases referred to in the embodiments provided herein may include at least one of a relational database and a non-relational database. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processor referred to in the embodiments provided in the present application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, or the like, but is not limited thereto.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of the application should be assessed as that of the appended claims.
Claims (12)
1. A method for storing a service call log, the method comprising:
acquiring call log data, and storing the call log data into a target buffer area corresponding to a request to which the call log data belongs;
updating the request time corresponding to the request according to the calling time in the calling log data;
and storing the call log data in the target buffer zone into a database under the condition that the request time meets the preset ending condition.
2. The method of claim 1, wherein storing the call log data in a target buffer corresponding to a request to which the call log data pertains comprises:
acquiring a request identifier from the call log data, wherein the request identifier is used for representing a request to which the call log data belongs;
and storing the call log data into the target buffer area when the target buffer area matched with the request identification exists in each buffer area.
3. The method according to claim 2, wherein the method further comprises:
and under the condition that a target buffer area matched with the request identification does not exist in each buffer area, creating a new buffer area according to the request identification, taking the new buffer area as the target buffer area, and storing the call log data into the target buffer area.
4. The method according to claim 1, wherein the method further comprises:
acquiring current time and determining a time difference between the current time and the request time;
under the condition that the time difference is larger than a time threshold, determining that the request time meets a preset ending condition; or,
And under the condition that the time difference is smaller than or equal to the time threshold, determining that the request time does not meet the preset ending condition.
5. The method of claim 1, wherein storing call log data in the target buffer into a database comprises:
storing each call log data in the target buffer zone into a clone buffer zone, and deleting the target buffer zone from each buffer zone;
and storing all call log data in the clone buffer into a database.
6. The method of claim 5, wherein storing each of the call log data in the target buffer into a clone buffer comprises:
acquiring a father service identifier in each call log data;
sorting the call log data based on the parent service identifier so that the parent service identifier of the call log data arranged in the subsequent bit is the service identifier of the call log data arranged in the previous bit for any two adjacent call log data;
and storing the sequenced call log data into a clone buffer area in sequence.
7. The method of claim 5 or 6, wherein said storing all of said call log data in said clone buffer into a database comprises:
and calling a sequential disk brusher, so that the sequential disk brusher sequentially stores all the call log data in the clone buffer into a continuous storage space in a database.
8. The method of claim 1, wherein the obtaining call log data comprises:
and pulling the call log data from the message middleware under the condition that the message middleware for storing the call log data is pushed.
9. A storage device for service call logs, the device comprising:
the first acquisition module is used for acquiring call log data and storing the call log data into a target buffer area corresponding to a request to which the call log data belongs;
the updating module is used for updating the request time corresponding to the request according to the calling time in the calling log data;
and the storage module is used for storing the call log data in the target buffer zone into a database under the condition that the request time meets the preset end condition.
10. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any one of claims 1 to 8 when the computer program is executed.
11. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 8.
12. A computer program product comprising a computer program, characterized in that the computer program, when executed by a processor, implements the steps of the method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311041933.0A CN117149826A (en) | 2023-08-18 | 2023-08-18 | Method, device, computer equipment and storage medium for storing service call log |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311041933.0A CN117149826A (en) | 2023-08-18 | 2023-08-18 | Method, device, computer equipment and storage medium for storing service call log |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117149826A true CN117149826A (en) | 2023-12-01 |
Family
ID=88883459
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311041933.0A Pending CN117149826A (en) | 2023-08-18 | 2023-08-18 | Method, device, computer equipment and storage medium for storing service call log |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117149826A (en) |
-
2023
- 2023-08-18 CN CN202311041933.0A patent/CN117149826A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7698602B2 (en) | Systems, methods and computer products for trace capability per work unit | |
| CN111309720A (en) | Time sequence data storage method, time sequence data reading method, time sequence data storage device, time sequence data reading device, electronic equipment and storage medium | |
| CN110928851B (en) | Method, device and equipment for processing log information and storage medium | |
| CN109522273B (en) | Method and device for realizing data writing | |
| CN114741449A (en) | Object storage method and device based on distributed database | |
| CN117149826A (en) | Method, device, computer equipment and storage medium for storing service call log | |
| CN116204311A (en) | Pod cluster capacity expansion and contraction method and device, computer equipment and storage medium | |
| CN108073709B (en) | Data recording operation method, device, equipment and storage medium | |
| CN107632880B (en) | Method for exporting excel data, storage medium and electronic equipment | |
| CN116009985A (en) | Interface calling method, device, computer equipment and storage medium | |
| CN106844480B (en) | A kind of cleaning comparison storage method | |
| CN116048878A (en) | Business service recovery method, device and computer equipment | |
| CN115421856A (en) | Data recovery method and device | |
| CN113051301A (en) | Object storage method, system and equipment | |
| CN115730016B (en) | Data synchronization method, system, device, computer equipment and storage medium | |
| CN116932779B (en) | Knowledge graph data processing method and device | |
| CN115604290B (en) | Kafka message execution method, device, equipment and storage medium | |
| CN112433671B (en) | Data persistence method, system, device and medium | |
| CN117931825A (en) | Sequence number generation method, system, device, computer equipment and storage medium | |
| CN116541358A (en) | Invalid file cleaning method, device, computer equipment and storage medium | |
| CN110402436B (en) | Method and device for processing pre-written log | |
| CN117938514A (en) | Token processing method, device, server, storage medium and program product | |
| CN116541399A (en) | Database partition table management method and device | |
| CN117914751A (en) | Traffic playback method, apparatus, computer device, storage medium, and program product | |
| CN114297273A (en) | Data extraction method and device |
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 |