A background game log information tracing method, system and medium

Abstract

The present application relates to the technical field of game data processing, in particular to a background game log information tracing method and system and a medium. The method comprises: obtaining the problem category of the feedback opinions of game users and corresponding log data; obtaining the data skew jam degree of each log source set based on the difference in data occupancy of different log source shards of each log source set; determining the jump delay burden factor of each log information path according to the interaction of the service area in each log information path in each log source set and the data skew jam degree; obtaining the shard delay adjustment parameter of each log source shard according to the jump delay burden factor of the log information path of different game users involved in the log source shard of each log source set, re-dividing the memory of the log source shard, and then obtaining the source path of each problem category. The present application improves the tracing efficiency of game log information.

Description

Technical Field

[0001] This invention relates to the field of game data processing technology, specifically to a method, system, and medium for tracing background game log information. Background Technology

[0002] Background log traceability refers to the technical process of reconstructing the complete execution path and state of a specific event in a distributed system by analyzing the time-series logs generated during system runtime. In the online gaming industry, a single online game typically targets a large user base. To better attract users, game developers often divide the game into multiple game servers for users to choose from, achieving user segmentation and management. Each game server records a large amount of log information related to the game behavior of users within that server. When users report problems during gameplay to the feedback center, technical personnel can trace the game logs in the background to find the corresponding log information. By examining the recorded execution records within the log information, they can determine the cause of the problem and implement appropriate maintenance measures.

[0003] In online games, game users in different server areas can interact across servers, engaging in cross-server activities such as chatting and combat. This results in stored log information being distributed across different locations on different local disks, leading to a fragmented log information situation for cross-server interactions. To solve this problem, the current common approach is to use a global TraceID + log routing sharding (ZoneID) method. Through the collaboration of logical identifier concatenation and physical storage sharding, efficient tracing of massive logs is achieved. By leveraging the globally unique characteristic of the global TraceID in the log information, content belonging to the same log information distributed across different nodes is concatenated and identified by only retrieving the relevant shards, forming complete log information.

[0004] In real-world scenarios, online games are divided into game service areas, which may include popular service areas with high online activity and less popular service areas with relatively low online activity. Traditional methods of sharding the local disks of these two types of service areas do not take into account the cross-server interactions of game users. This leads to the risk of data skew between shards that actually store log information related to cross-server interactions of game users. Some routing shards may have too much log information waiting to be queued, causing the information that needs to be traced to be queued to be placed at the back, thus prolonging the tracing time. Summary of the Invention

[0005] To address the issue of data skew in existing methods when partitioning the local disk of the game server, resulting in long tracing times for game log information, the present invention aims to provide a method, system, and medium for tracing background game log information. The specific technical solution adopted is as follows:

[0006] In a first aspect, the present invention provides a method for tracing background game log information, the method comprising the following steps:

[0007] Obtain the issue categories and corresponding log data from game users' feedback;

[0008] Based on the differences in data occupancy between different log tracing fragments in each log tracing set, the data skew and congestion degree of each log tracing set is obtained. The log tracing set is obtained by dividing the log information path according to the problem category. Based on the interaction of the service area in each log information path within each log tracing set and the data skew and congestion degree, the jump delay burden factor of each log information path is determined.

[0009] Based on the jump latency burden factor of the log information paths of different game users involved in the log tracing fragments of each log tracing set, obtain the fragmentation latency adjustment parameter for each log tracing fragment; and re-partition the memory of the log tracing fragments according to the fragmentation latency adjustment parameter.

[0010] In the re-segmentation results, the tracing path for each issue category is obtained based on the jump delay burden factor of all log information paths in each log tracing set.

[0011] Preferably, the log tracing fragments of the log tracing set are the fragments occupied by the log information within the log tracing set.

[0012] Preferably, the step of obtaining the data skew and congestion degree of each log source set based on the difference in data occupancy between different log source shards of each log source set includes:

[0013] For any set of log sources:

[0014] Based on the overall difference between the data occupancy characteristic values ​​of the candidate shards of any log tracing set and other log tracing shards, a difference index corresponding to the candidate shard is obtained; the candidate shard is any log tracing shard of any log tracing set, and the data occupancy characteristic value is determined based on the number of stored log path points and the memory occupied;

[0015] The average value of the difference index corresponding to all log shards in any log tracing set is determined as the data skew and congestion degree of any log tracing set.

[0016] Preferably, determining the jump latency burden factor for each log information path based on the interaction status of the service area within each log information path in each log source set and the degree of data skew congestion includes:

[0017] For any set of log sources:

[0018] The service areas within the path to be analyzed that involve information interaction are denoted as the interaction service areas of the path to be analyzed.

[0019] Based on the number of logged-in users and the interaction duration in the interactive service area, the service area interaction pressure of the path to be analyzed is obtained. The number of logged-in users and the interaction duration are both positively correlated with the service area interaction pressure.

[0020] By combining the service area interaction pressure and the data skew congestion degree of any log source set, the jump delay burden factor of the path to be analyzed is obtained;

[0021] The path to be analyzed is any log information path in any log source set.

[0022] Preferably, obtaining the jump delay burden factor of the path to be analyzed by comprehensively considering the service area interaction pressure and the data skew congestion degree of any log source set includes: using the product of the service area interaction pressure and the data skew congestion degree of any log source set as the jump delay burden factor of the path to be analyzed.

[0023] Preferably, the step of obtaining the sharding latency adjustment parameter for each log tracing shard based on the jump latency burden factor of the log information paths of different game users involved in each log tracing shard of each log tracing set includes:

[0024] For any log sourcing set and any log sourcing shard:

[0025] The product of the sum of the jump delay burden factors of all log information paths of each game user involved in any log traceability segment and the number of log information paths of the same game user involved in any log traceability segment is determined as the urgency level of each game user corresponding to any log traceability segment.

[0026] The normalized result of the average urgency level of all game users corresponding to any log tracing shard is determined as the sharding delay adjustment parameter of any log tracing shard.

[0027] Preferably, the step of re-dividing the memory of the log tracing shards based on the sharding delay adjustment parameters includes:

[0028] For any log source tracing shard:

[0029] If the sharding delay adjustment parameter of any log tracing shard is less than or equal to the preset adjustment threshold, then the memory of any log tracing shard will not be adjusted.

[0030] If the sharding delay adjustment parameter of any log tracing shard is greater than the preset adjustment threshold, then the first difference between constant 1 and the sharding delay adjustment parameter of any log tracing shard is calculated; the product of the first difference and the initial memory size of any log tracing shard is rounded up and used as the adjusted memory of any log tracing shard, and then it is re-divided.

[0031] Preferably, obtaining the tracing path for each issue category based on the jump delay burden factor of all log information paths in each log tracing set includes:

[0032] The game users whose urgency level is maximized for all game users corresponding to the log source shards of each log source set are used as the source reference users for the problem category of each log source set.

[0033] Based on the jump delay burden factor in ascending order, sort all log information paths involved by the source reference user for each problem category to obtain a path sequence; use the first preset number of log information paths in the path sequence as the source path for each problem category.

[0034] Secondly, the present invention provides a background game log information tracing system, which is used to implement the above-mentioned method, the system comprising:

[0035] The acquisition module is used to acquire the problem categories and corresponding log data of game users' feedback.

[0036] The evaluation module is used to obtain the data skew and congestion degree of each log source set based on the differences in data occupancy between different log source fragments of each log source set. The log source set is obtained by dividing the log information path according to the problem category. Based on the interaction of the service area within each log information path in each log source set and the data skew and congestion degree, the jump delay burden factor of each log information path is determined.

[0037] The partitioning module is used to obtain the partitioning latency adjustment parameters for each log tracing partition based on the jump latency burden factor of the log information paths of different game users involved in the log tracing partitions of each log tracing set; and to repartition the memory of the log tracing partitions according to the partitioning latency adjustment parameters.

[0038] The tracing module is used to obtain the tracing path for each issue category based on the jump delay burden factor of all log information paths in each log tracing set in the re-segmentation results.

[0039] Thirdly, the present invention provides a background game log information tracing medium for storing a computer program that causes a computer to execute the above-described method.

[0040] The present invention has at least the following beneficial effects:

[0041] This invention first evaluates the data skew congestion level of each log tracing set based on the differences in data occupancy between different log tracing shards within a single log tracing set. By analyzing the data skew generated when different shards of different sizes interact with local disks in different service areas during cross-server play, the delay effect of data skew on log tracing efficiency is made clearer. Furthermore, by combining the interaction of service areas within each log information path in each log tracing set, the jump latency burden of each log information path is quantified, obtaining a jump latency burden factor. Then, based on the jump latency burden factor of different game users' log information paths, the shard latency adjustment parameters for each log tracing shard are determined, and the memory of the log tracing shards is re-partitioned to determine the tracing path for each problem category. This invention, combined with log information generated by game users' own attempts when encountering problems, further clarifies the tracing optimization needed when each game user encounters the same problem, making the final shard memory adjustment more intelligent, improving the tracing efficiency of game log information, and reducing the interference of digital skew on tracing. Attached Figure Description

[0042] To more clearly illustrate the technical solutions and advantages in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 A flowchart illustrating a method for tracing background game log information provided in an embodiment of the present invention;

[0044] Figure 2 This is a structural block diagram of a background game log information tracing system provided in an embodiment of the present invention. Detailed Implementation

[0045] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following detailed description, in conjunction with the accompanying drawings and preferred embodiments, describes a background game log information tracing method, system, and medium proposed according to the present invention.

[0046] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0047] The following description, in conjunction with the accompanying drawings, details a specific solution for a background game log information tracing method, system, and medium provided by the present invention.

[0048] An embodiment of a method for tracing background game log information:

[0049] This embodiment proposes a method for tracing background game log information, such as... Figure 1 As shown, a method for tracing background game log information in this embodiment includes the following steps:

[0050] Step S1: Obtain the problem categories and corresponding log data of game users' feedback.

[0051] First, the feedback received from game users within a single day is extracted from the feedback center. Then, a trained neural network is used to categorize all the feedback from game users, resulting in several problem categories. In this embodiment, the neural network used is ResNet50, and the loss function used during training is the cross-entropy loss function. The specific training process of the neural network is a well-known technique and will not be described in detail here.

[0052] Then, the set of log information paths within the corresponding timestamp for each issue category is used as the log source set for each issue category. Each issue category contains feedback from multiple game users, and the log source set for each issue category contains multiple log information paths, with each log information path containing log path points.

[0053] Thus, this embodiment divides all the feedback from game users into multiple issue categories, with each issue category corresponding to a log source set.

[0054] Step S2: Based on the differences in data occupancy between different log tracing fragments in each log tracing set, the data skew and congestion degree of each log tracing set is obtained. The log tracing set is obtained by dividing the log information path according to the problem category. Based on the interaction of the service area in each log information path within each log tracing set and the data skew and congestion degree, the jump delay burden factor of each log information path is determined.

[0055] In online games, when game users in different server regions run independently within their respective server regions (such as in single-player battles), a corresponding service cluster responds and stores the logs generated by the game users in that server region on the local disk of the service cluster. However, during cross-server online interactions (online battles), these service clusters need to collaborate. But in this case, the (battle) logs belonging to the same cross-server interaction process are scattered and stored in different locations on different local disks, resulting in fragmented log information for cross-server interactions.

[0056] To address the issue of scattered log information, existing technologies typically utilize a global TraceID stored in the log information to mark the entire process path from the user's request to the system's response. Since the global TraceID is a globally unique string, such as a 128-bit or 64-bit hexadecimal value, log information scattered across different local disks can be linked together to form a complete log information path. Within each local disk, to facilitate information tracing, each local disk is usually manually divided into multiple partitions of different sizes. Then, a combination of global TraceID and log routing partitions (ZoneID) is used to improve the efficiency of game log information tracing through the logical identifier concatenation and the coordination of physical storage partitions.

[0057] In real-world scenarios, online games often divide their servers into highly active ("hot") and less active ("cold") servers. Traditionally, the local disk partitions for highly active servers are typically larger to store more log information, while those for less active servers are smaller. However, when users interact across servers, log tracing is performed across partitions on different local disks using a global TraceID and ZoneID. During this tracing process, especially when interacting between highly active and less active servers, significant differences in partition size occur, leading to data skew. This data skew causes congestion during tracing queries. Furthermore, user feedback and experimentation can further exacerbate this congestion, further delaying tracing efficiency.

[0058] While the existing global TraceID + log routing sharding (by ZoneID) approach solves the problem of scattered logs and connects corresponding log path points across servers, it does not address the query latency caused by data skew resulting from sharding. If multiple log information paths within the log tracing range exhibit data skew within their corresponding shards, tracing some log paths will be extremely slow. Therefore, this embodiment will analyze the data skew caused by uneven shard sizes within the log path range to determine the degree of data skew congestion for each log tracing set.

[0059] This embodiment will use a log tracing set as an example for illustration. Other log tracing sets can be processed using the method provided in this embodiment.

[0060] Specifically, for any set of log sources:

[0061] The product of the number of stored log path points in the log source set and the size of the memory occupied is used as the data occupancy characteristic value of the log source set. It should be noted that when calculating the product of the number of stored log path points and the size of the memory occupied, the two data values ​​are directly multiplied, and the units are not included in the calculation.

[0062] Any log shard in the log tracing set is designated as a candidate shard. Based on the overall difference in data occupancy characteristics between the candidate shards and other log tracing shards in the log tracing set, a difference index corresponding to the candidate shard is obtained. Using this method, the difference index corresponding to each log tracing shard in the log tracing set can be obtained. The average of the difference indices corresponding to all log tracing shards in the log tracing set is determined as the data skew and congestion level of the log tracing set.

[0063] In this embodiment, a specific formula for calculating the degree of data skew congestion is given. The degree of data skew congestion in this log source set can be expressed as:

[0064]

[0065] in, This indicates the degree of data skew and congestion in the log source set. This indicates the number of log sourcing fragments in the log sourcing set. This represents the data occupancy characteristic value of the i-th log sourcing fragment in the log sourcing set. This represents the data occupancy characteristic value of the k-th log occupancy fragment in the log occupancy set, excluding the i-th log occupancy fragment. This indicates the absolute value sign.

[0066] This represents the overall difference in data occupancy characteristics between the i-th log occupancy shard and other log occupancy shards in the log occupancy set. In other words, it is the difference index corresponding to the i-th log occupancy shard in the log occupancy set. The difference index is used to reflect the difference between data occupancy. The greater the difference between data occupancy, the greater the data skew. When the log occupancy set solves the log dispersion problem by using the existing global TraceID + log routing sharding (by ZoneID), the greater the difference in data content between shards on different local disks, the greater the data skew caused by their interaction, and the more severe the data congestion.

[0067] Data skew congestion can reflect, to some extent, the effect of data skew between initial shards and the delay in tracing the efficiency of log information paths involved. It primarily characterizes the overall delay impact on data tracing caused by similar issues reported by different game users to the feedback center. In real-world scenarios, factors affecting log tracing efficiency extend beyond the macro level to include detailed aspects: for the same log information path, the time taken is mainly determined by the interaction between the involved shards. This is because individual service processes, being non-cross-server, significantly reduce tracing difficulty and typically result in faster tracing times. Furthermore, when game users discover a problem, they often try multiple possibilities, generating multiple similar or identical log information paths. These paths further complicate tracing and reduce efficiency. Therefore, by analyzing the log generation operations of game users reporting the same problem category and considering the data skew congestion level, we can assess the delay effect of different internal problems on subsequent log tracing, and analyze the user problem latency for individual users across different internal issues.

[0068] When users report issues, under normal online conditions, different service servers connect to each other for online gameplay, such as battles. The corresponding log information is recorded across servers, resulting in a complete log path that typically includes log information from different service servers. Furthermore, within the current service servers, there are overloaded and underloaded servers, each with different active user numbers, leading to varying amounts of log information to be stored and consequently, different levels of difficulty in log tracing. When service servers with different levels of activity connect, varying degrees of data processing skew can occur. Therefore, based on the degree of data skew congestion, the interaction between shards involved in the same log information path can be analyzed, and the impact on the log information processing capacity of each service server can be considered to calculate the jump latency burden factor for the same log information path.

[0069] The following explanation will use a log tracing collection as an example.

[0070] Specifically, for any set of log sources:

[0071] Any log information path in the log source set is recorded as the path to be analyzed, and the service areas involved in information interaction within the path to be analyzed are recorded as the interaction service areas of the path to be analyzed. The interaction pressure of the service areas of the path to be analyzed is obtained based on the number of logged-in users and the interaction duration of the interaction service areas. The number of logged-in users and the interaction duration are both positively correlated with the interaction pressure of the service areas.

[0072] Among them, a positive correlation means that the dependent variable increases as the independent variable increases, and the dependent variable decreases as the independent variable decreases. It can be an additive relationship, a multiplicative relationship, etc., which is determined by the actual application.

[0073] In this embodiment, a specific formula for calculating service area interaction pressure is given. The service area interaction pressure of the path to be analyzed in the log source set can be expressed as:

[0074]

[0075] in, This indicates the service area interaction pressure of the path to be analyzed in this log source set. This indicates the number of interactive service areas in the path to be analyzed. This represents the number of logged-in users in the s-th interactive service area of ​​the path to be analyzed. This represents the total interaction time between the s-th interactive service area and all other interactive service areas of the path to be analyzed. This represents the normalization function.

[0076] The more logged-in users in the s-th interactive service area of ​​the path to be analyzed, and the longer the total interaction time between the s-th interactive service area and all other interactive service areas of the path to be analyzed, the more obvious the delay effect of log information tracing between different service areas is when the log information path is originally online and interacting, and the greater the service area interaction pressure of the path to be analyzed in the log tracing set.

[0077] Furthermore, the product of the service area interaction pressure of the path to be analyzed in the log tracing set and the data skew congestion degree of the log tracing set is used as the jump delay burden factor of the path to be analyzed. The larger the jump delay burden factor, the more data skew and different activity levels of the service areas require for online interaction when the log information path is conducting cross-server online interaction, and the more time is needed for tracing. This reflects that when the log information path is conducting cross-server online interaction, the longer it takes to jump from one shard corresponding to a service area to another shard corresponding to a service area.

[0078] Using the above method, the jump delay burden factor for each log information path can be obtained.

[0079] Step S3: Based on the jump delay burden factor of the log information path of different game users involved in the log tracing shards of each log tracing set, obtain the sharding delay adjustment parameter of each log tracing shard; and re-divide the memory of the log tracing shards according to the sharding delay adjustment parameter.

[0080] In step S2 of this embodiment, the jump latency burden factor of each log information path is obtained. The jump latency burden factor is used to reflect the latency of cross-server interaction within a single log information path due to data skew. During the tracing process, to improve the latency effect, it is necessary to classify the paths more accurately and plan as few paths as possible for tracing. This way, even if there is data skew, it will not have a significant impact on the current tracing. That is, further filtering is performed based on the jump latency burden factor to determine a smaller log retrieval range. Within the log information paths of the same problem category in the log tracing set, these log information paths have relatively dispersed timestamps due to differences in game user information, etc. In actual scenarios, problems reported by game users usually fall into two categories: one is that due to network factors, problems occur uniformly within a certain time period; the other is that the game itself has problems in a certain process, causing different users to encounter errors when executing the same process. This type of problem usually does not have strong temporal clustering. However, regardless of the situation, users usually try multiple times, thus generating more unnecessary data and affecting tracing efficiency.

[0081] The following example uses a log tracing fragment of a log tracing set as an example for illustration.

[0082] Specifically, for any log sourcing set and any log sourcing shard:

[0083] If the sharding delay adjustment parameter of the log tracing shard is less than or equal to the preset adjustment threshold, then the memory of the log tracing shard will not be adjusted.

[0084] If the sharding latency adjustment parameter of the log source tracing shard is greater than the preset adjustment threshold, then the sum of the jump latency burden factors of all log information paths for each game user involved in the log source tracing shard is calculated. This sum is then multiplied by the number of log information paths for the same game user within the log source tracing shard. This product is determined as the urgency level for each game user corresponding to the log source tracing shard. The higher the urgency level, the worse the game user's experience, and the more urgent the game user's need for optimization of this problem category. It should be noted that the game user corresponding to the log source tracing shard is the game user involved in the log source tracing shard, and each game user involved in the log source tracing shard has a corresponding urgency level. Then, the average urgency level of all game users corresponding to the log source tracing shard is calculated. The normalized result of this average is determined as the shard latency adjustment parameter for the log source tracing shard. The larger the shard latency adjustment parameter, the more significant the latency effect caused by the original source tracing within the log source shard, and the more urgent the game users' need to optimize and resolve the latency interference caused by the log source tracing shard. Therefore, the log source tracing shard needs to be resized. There are many data normalization methods. In this embodiment, the maximum-minimum value normalization method is used to normalize the average value. Other existing data normalization methods can also be used as alternative implementations, which will not be elaborated upon here. In this embodiment, the preset adjustment threshold is 0.4. In specific applications, the implementer can set it according to the specific circumstances. After obtaining the sharding delay adjustment parameters for the log source shard, the initial memory size of the log source shard is adjusted using these parameters. Specifically, the difference between the constant 1 and the sharding delay adjustment parameters for the log source shard is calculated and recorded as the first difference. The product of the first difference and the initial memory size of the log source shard is rounded up and used as the adjusted memory size for the log source shard, which means the memory size of the log source shard is reduced. Then, the reduced memory size of the log source shard is allocated to the shard with the smallest remaining memory among all the other shards on the local disk where the log source shard resides, whose sharding delay adjustment parameters are less than or equal to the preset adjustment threshold.

[0085] For example, if the log source shard is adjusted from 80MB to 70MB, then the 10MB reduction in memory of the log source shard relative to the initial memory needs to be allocated to other shards on the local disk where this shard is located. In this case, this 10MB of memory space is preferably allocated to the shard on the local disk whose shard delay adjustment parameter is less than or equal to the preset adjustment threshold and has the smallest remaining memory.

[0086] The initial memory size of the log tracing shard is a manually set value. In specific applications, the implementer sets it according to the specific situation, which will not be elaborated on here.

[0087] Using the above method, the memory of all log tracing shards can be repartitioned.

[0088] Step S4: In the re-segmentation results, based on the jump delay burden factor of all log information paths in each log source set, obtain the source path for each issue category.

[0089] Considering that while the same problem category may exhibit multiple similar behaviors, they are all essentially caused by the same problem category. Programmers need to address the root cause of the problem category when resolving it; once the root cause is addressed, the various behaviors will disappear, greatly reducing subsequent maintenance workload. Therefore, when tracing the source, it is best to select logs with significantly different problem behaviors for final tracing, providing a reference for future maintainers.

[0090] For any log source tracing set, there exists a corresponding problem category. The game user whose urgency level is maximized across all game users corresponding to the log source tracing shards of that log source tracing set is used as the source tracing reference user for that problem category. Then, all log information paths involved by the source tracing reference user for that problem category are sorted in ascending order of jump latency burden factor to obtain a path sequence. The first preset number of log information paths in this path sequence are used as the source tracing path for each problem category. In this embodiment, the preset number is 5; in specific applications, the implementer can set it according to specific circumstances.

[0091] Using the above method, the tracing path for each problem category can be determined for maintenance personnel to refer to, helping them to find the problem more quickly and achieve rapid problem tracing.

[0092] This embodiment first evaluates the data skew congestion level of each log tracing set based on the differences in data occupancy between different log tracing shards within a single log tracing set. By analyzing the data skew generated when different shards of different sizes interact with local disks in different service areas during cross-server play, the delay effect of data skew on log tracing efficiency is made clearer. Furthermore, combining the interaction of service areas within each log information path in each log tracing set, the jump latency burden of each log information path is quantified, obtaining a jump latency burden factor. Next, based on the jump latency burden factor of different game users' log information paths, the shard latency adjustment parameters for each log tracing shard are determined, and the memory of the log tracing shards is re-partitioned to determine the tracing path for each problem category. This embodiment, combined with the log information generated by game users' own attempts when encountering problems, further clarifies the tracing optimization needed when each game user encounters the same problem, making the final shard memory adjustment more intelligent, improving tracing efficiency, and reducing the interference of digital skew on tracing.

[0093] An embodiment of a background game log information tracing system:

[0094] See Figure 2 The diagram illustrates a structural block diagram of a background game log information tracing system provided in an embodiment of the present invention. The device may include an acquisition module, an evaluation module, a division module, and a tracing module.

[0095] The acquisition module is used to acquire the problem categories and corresponding log data of game users' feedback.

[0096] The evaluation module is used to obtain the data skew and congestion degree of each log source set based on the differences in data occupancy between different log source fragments of each log source set. The log source set is obtained by dividing the log information path according to the problem category. Based on the interaction of the service area within each log information path in each log source set and the data skew and congestion degree, the jump delay burden factor of each log information path is determined.

[0097] The partitioning module is used to obtain the partitioning latency adjustment parameters for each log tracing partition based on the jump latency burden factor of the log information paths of different game users involved in the log tracing partitions of each log tracing set; and to repartition the memory of the log tracing partitions according to the partitioning latency adjustment parameters.

[0098] The tracing module is used to obtain the tracing path for each issue category based on the jump delay burden factor of all log information paths in each log tracing set in the re-segmentation results.

[0099] It should be understood that Figure 2The structural block diagram and modules of the background game log information tracing system shown can be implemented in various ways. For example, in some embodiments, the system and its modules can be implemented by hardware, software, or a combination of software and hardware. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated hardware. Those skilled in the art will understand that the above-described methods and apparatus can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., but also by software, for example, executed by various types of processors, or by a combination of the above-described hardware circuits and software (e.g., firmware).

[0100] For more details about the above modules, please refer to other parts of this manual; they will not be repeated here.

[0101] Based on the same inventive concept as the above method, this embodiment of the invention also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-mentioned related method steps to realize the background game log information tracing method provided in the above embodiment.

[0102] It should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for tracing background game log information, characterized in that, The method includes the following steps: Obtain the issue categories and corresponding log data from game users' feedback; Based on the differences in data occupancy between different log tracing fragments in each log tracing set, the data skew and congestion degree of each log tracing set is obtained. The log tracing set is obtained by dividing the log information path according to the problem category. Based on the interaction of the service area in each log information path within each log tracing set and the data skew and congestion degree, the jump delay burden factor of each log information path is determined. Based on the jump latency burden factor of the log information paths of different game users involved in the log tracing fragments of each log tracing set, obtain the fragmentation latency adjustment parameter for each log tracing fragment; and re-partition the memory of the log tracing fragments according to the fragmentation latency adjustment parameter. In the re-segmentation results, the tracing path for each issue category is obtained based on the jump delay burden factor of all log information paths in each log tracing set; The data skew and congestion levels obtained for each log source set include: For any set of log sources: Based on the overall difference between the data occupancy characteristic values ​​of the candidate shards of any log tracing set and other log tracing shards, a difference index corresponding to the candidate shard is obtained; the candidate shard is any log tracing shard of any log tracing set, and the data occupancy characteristic value is determined based on the number of stored log path points and the memory occupied; The average value of the difference index corresponding to all log shards in any log tracing set is determined as the data skew and congestion degree of any log tracing set. The determination of the jump latency burden factor for each log information path includes: For any set of log sources: The service areas within the path to be analyzed that involve information interaction are denoted as the interaction service areas of the path to be analyzed. Based on the number of logged-in users and the interaction duration in the interactive service area, the service area interaction pressure of the path to be analyzed is obtained. The number of logged-in users and the interaction duration are both positively correlated with the service area interaction pressure. By combining the service area interaction pressure and the data skew congestion degree of any log source set, the jump delay burden factor of the path to be analyzed is obtained; The path to be analyzed is any log information path in any log source set.

2. The method for tracing background game log information according to claim 1, characterized in that, The log tracing fragments of a log tracing set are the fragments occupied by the log information within the log tracing set.

3. The method for tracing background game log information according to claim 1, characterized in that, The step of obtaining the jump delay burden factor of the path to be analyzed by combining the service area interaction pressure and the data skew congestion degree of any log source set includes: using the product of the service area interaction pressure and the data skew congestion degree of any log source set as the jump delay burden factor of the path to be analyzed.

4. The method for tracing background game log information according to claim 1, characterized in that, The step of obtaining the sharding latency adjustment parameters for each log tracing shard based on the jump latency burden factor of the log information paths of different game users involved in each log tracing shard of each log tracing set includes: For any log sourcing set and any log sourcing shard: The product of the sum of the jump delay burden factors of all log information paths of each game user involved in any log traceability segment and the number of log information paths of the same game user involved in any log traceability segment is determined as the urgency level of each game user corresponding to any log traceability segment. The normalized result of the average urgency level of all game users corresponding to any log tracing shard is determined as the sharding delay adjustment parameter of any log tracing shard.

5. The method for tracing background game log information according to claim 1, characterized in that, The process of re-partitioning the memory of log tracing shards based on sharding delay adjustment parameters includes: For any log source tracing shard: If the sharding delay adjustment parameter of any log tracing shard is less than or equal to the preset adjustment threshold, then the memory of any log tracing shard will not be adjusted. If the sharding delay adjustment parameter of any log tracing shard is greater than the preset adjustment threshold, then the first difference between constant 1 and the sharding delay adjustment parameter of any log tracing shard is calculated; the product of the first difference and the initial memory size of any log tracing shard is rounded up and used as the adjusted memory of any log tracing shard, and then it is re-divided.

6. The method for tracing background game log information according to claim 4, characterized in that, The process of obtaining the tracing path for each issue category based on the jump delay burden factor of all log information paths in each log tracing set includes: The game users whose urgency level is maximized for all game users corresponding to the log source shards of each log source set are used as the source reference users for the problem category of each log source set. Based on the jump delay burden factor in ascending order, sort all log information paths involved by the source reference user for each problem category to obtain a path sequence; use the first preset number of log information paths in the path sequence as the source path for each problem category.

7. A background game log information tracing system, the system being used to implement the method of claim 1, characterized in that, The system includes: The acquisition module is used to acquire the problem categories and corresponding log data of game users' feedback. The evaluation module is used to obtain the data skew and congestion degree of each log source set based on the differences in data occupancy between different log source fragments of each log source set. The log source set is obtained by dividing the log information path according to the problem category. Based on the interaction of the service area within each log information path in each log source set and the data skew and congestion degree, the jump delay burden factor of each log information path is determined. The partitioning module is used to obtain the partitioning latency adjustment parameters for each log tracing partition based on the jump latency burden factor of the log information paths of different game users involved in the log tracing partitions of each log tracing set; and to repartition the memory of the log tracing partitions according to the partitioning latency adjustment parameters. The tracing module is used to obtain the tracing path for each issue category based on the jump delay burden factor of all log information paths in each log tracing set in the re-segmentation results.

8. A medium for tracing background game log information, characterized in that, Used to store a computer program that causes a computer to perform the method as described in claim 1.

Images