Log file collection method and apparatus, electronic device, and readable storage medium

Abstract

The application provides a log file collection method and device, electronic equipment and a readable storage medium. The first characteristic information of a to-be-collected server is compared with second characteristic information in a preset database, target servers belonging to the same category as the to-be-collected server in the preset database are determined, and the probability of the same type of server appearing the same type of fault is relatively large. After the target servers are determined, a target fault category with a larger first weight value is determined according to the first weight value of the fault category corresponding to the target server, the weight value of the screening rule and the index data corresponding to the target fault category is further determined according to the target fault category, and when the log file of the server is collected, the weight value of the log file can be calculated according to the index data included in the server, so that when the log file is collected, the log file associated with the diagnosis of the server fault can be accurately collected, the time for collecting the log is saved, and the storage resource of the server is also saved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a log file collection method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Server log data is an important basis for server fault diagnosis or analysis, and accurate server log data can improve the efficiency of server fault diagnosis.

[0003] In related technologies, server log collection tools are used to collect log files from various server models, and server log diagnostic platforms are used to analyze these log files.

[0004] The above method collects the full log file of the server. However, due to the differences between servers, the possible causes of failures on different servers may also be different. The above method of collecting the full log file consumes a lot of storage resources and does not distinguish between the differences between servers, resulting in log file redundancy and reducing the efficiency of fault diagnosis. Summary of the Invention

[0005] In view of the above problems, embodiments of the present invention are proposed to provide a log file collection method, apparatus, electronic device and readable storage medium that overcomes or at least partially solves the above problems.

[0006] In a first aspect, embodiments of this application disclose a log file collection method, the method comprising:

[0007] Obtain the first feature information of the server to be collected;

[0008] The first feature information is compared with the second feature information of the servers contained in the preset database to determine the target servers in the preset database that belong to the same category as the server to be collected.

[0009] Based on the first weight value of the fault category corresponding to the target server, the target fault category in which the first weight value is within a first preset range is determined;

[0010] The third weight value of the indicator data is determined based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule.

[0011] Based on the third weight value of the indicator data, the fourth weight value corresponding to each log file contained in the server to be collected is determined, and log files whose fourth weight values ​​belong to the second preset range are collected.

[0012] Secondly, embodiments of this application disclose a log file collection device, the device comprising:

[0013] The acquisition module is used to acquire the first feature information of the server to be collected;

[0014] The first determining module is used to compare the first feature information with the second feature information of the server contained in the preset database, and determine the target server in the preset database that belongs to the same category as the server to be collected;

[0015] The second determining module is used to determine the target fault category whose first weight value is within a first preset range based on the first weight value of the fault category corresponding to the target server.

[0016] The third determining module is used to determine the third weight value of the indicator data based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule.

[0017] The acquisition module is used to determine the fourth weight value corresponding to each log file contained in the server to be acquired based on the third weight value of the indicator data, and to acquire log files whose fourth weight values ​​belong to a second preset range.

[0018] Thirdly, embodiments of this application also disclose an electronic device, including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0019] Fourthly, embodiments of this application also disclose a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0020] In this embodiment, the first feature information of the server to be collected is compared with the second feature information in a preset database to determine the target servers in the preset database that belong to the same category as the server to be collected. Servers of the same type have a higher probability of experiencing the same type of fault. After determining the target server, the target fault category with the larger first weight value is determined according to the first weight value of the fault category corresponding to the target server. Based on the target fault category, the weight values ​​of the filtering rules and indicator data corresponding to the target fault category are further determined. When collecting log files from the server, the weight value of the log files can be calculated based on the indicator data included in the server. By sorting the weight values ​​of the log files, the log files associated with diagnosing server faults can be accurately collected, saving log collection time and improving the efficiency of server diagnosis. At the same time, a smaller number of log files also saves server storage resources. Attached Figure Description

[0021] Figure 1 This is a flowchart of the steps of a log file collection method provided in an embodiment of the present invention;

[0022] Figure 2 This is a flowchart of another log file collection method provided in an embodiment of the present invention;

[0023] Figure 3 This is a block diagram of a log file collection device provided in an embodiment of the present invention;

[0024] Figure 4 This is a block diagram of a terminal according to another embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of the terminal structure according to another embodiment of the present invention. Detailed Implementation

[0026] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0027] refer to Figure 1 It illustrates a flowchart of the log file collection method provided in an embodiment of this application, the method including:

[0028] Step 101: Obtain the first feature information of the server to be collected.

[0029] In this embodiment of the invention, the server to be collected can be a server for which log files need to be collected in order to analyze fault information based on the log files. The first feature information corresponding to the server to be collected can be server asset information indicators, such as: machine height, number of power supplies, server platform, and other feature information of the server to be collected. The k server asset information indicators of the server to be collected constitute the first feature information to be collected, represented as {r1, r2, ... r... k The first characteristic information differs for different servers.

[0030] Step 102: Compare the first feature information with the second feature information of the servers contained in the preset database to determine that the target servers in the preset database belong to the same category as the server to be collected.

[0031] In this embodiment of the invention, the preset database can be a database established based on existing server historical information. The servers in the preset database and their corresponding log files can serve as sample data. By analyzing the sample data, the differences in fault types among different types of servers can be determined. For example, if the preset database contains *a* servers, and the database also stores second characteristic information corresponding to each of the *a* servers, the second characteristic information can be server asset information indicators corresponding to each server in the database, which can be represented as {A1, A2, ... A...}. k}

[0032] Furthermore, the k server asset information indicators in the first feature information of the server to be collected are compared with the corresponding server asset information indicators of each server in the preset database. For example, A1 can be compared with r1, A2 with r2, etc. By comparing the features contained in the first feature information and the second feature information, it is possible to determine the target servers in the preset database that belong to the same category as the server to be collected. Servers of the same category have similar hardware or other configurations, and the target servers can be used as reference data when diagnosing server faults.

[0033] Step 103: Determine the target fault category whose first weight value is within a first preset range based on the first weight value of the fault category corresponding to the target server.

[0034] In this embodiment of the invention, the target servers determined from a preset database can be represented by a set T. If there are c target servers, then the set T = {T1, T2, ..., T}. cEach target server in set T has a corresponding fault category, which is used to classify different types of faults corresponding to the server. By statistically analyzing the fault categories corresponding to each target server and the fault categories corresponding to each server in a preset database, a first weight value can be determined for each fault category corresponding to the target server. The first weight value can represent the frequency of occurrence of the fault category. The larger the first weight value, the more frequently the fault category occurs. Therefore, by sorting the first weight values ​​of all fault categories corresponding to the target server, the fault categories with first weight values ​​within a first preset range are selected as the target fault categories. The first preset range can be fault categories that are in the top 10% or top 20% of the sorted first weight values, etc. The first preset range can be set according to the actual situation, and this embodiment of the invention does not limit it. The determined target fault category is the fault category of the target server that is most likely to occur.

[0035] Step 104: Determine the third weight value of the indicator data based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule.

[0036] In this embodiment of the invention, each fault category corresponds to multiple filtering rules. For example, the filtering rules corresponding to fault category A are rule 1, rule 2, and rule 3. Then, according to rule 1, rule 2, and rule 3, the fault corresponding to the server can be determined to be fault category A.

[0037] Furthermore, a single rule can correspond to multiple fault categories. For example, rule 1 can diagnose the server's fault category as fault category A, and rule 1 can also diagnose the server's fault category as fault category B. In other words, the filtering rule corresponding to each fault category can be repeated. By statistically analyzing the frequency of occurrence of the filtering rule corresponding to each target fault category, the second weight value corresponding to each filtering rule can be determined.

[0038] Furthermore, each filtering rule can correspond to multiple indicator data. These indicator data are used to numerically measure whether various server indicators meet the corresponding filtering rule. For example, rule 1 can correspond to indicator 1, indicator 2, and indicator 3; rule 2 can correspond to indicator 2, indicator 3, and indicator 4; and rule 3 can correspond to indicator 3, indicator 4, and indicator 5. By statistically analyzing the frequency of occurrence of indicator data corresponding to all filtering rules, and using the second weight value of the filtering rule containing that indicator, a third weight value can be determined for each indicator data. The third weight value of the indicator data reflects its importance in diagnosing fault categories.

[0039] Step 105: Determine the fourth weight value corresponding to each log file contained in the server to be collected based on the third weight value of the indicator data, and collect log files whose fourth weight values ​​belong to the second preset range.

[0040] In this embodiment of the invention, after determining the third weight value of the indicator data, the weight values ​​corresponding to all log files of the server to be collected can be further determined. For each log file, the number of indicator data it contains is analyzed. Based on the third weight value of each indicator data, the fourth weight value of each log file is calculated. All log files are sorted according to the size of the fourth weight value, and log files with fourth weight values ​​within a second preset range are determined as the log files to be collected. The second preset range can be the fault categories that are in the top 10% or top 20% of the sorted fourth weight values. The second preset range can be set according to the actual situation, and this embodiment of the invention does not limit it.

[0041] In summary, in this embodiment, the first feature information of the server to be collected is compared with the second feature information in a preset database to determine the target servers in the preset database that belong to the same category as the server to be collected. Servers of the same type have a higher probability of experiencing the same type of fault. After determining the target server, the target fault category with the larger first weight value is determined based on the first weight value of the fault category corresponding to the target server. Based on the target fault category, the weight values ​​of the filtering rules and indicator data corresponding to the target fault category are further determined. When collecting log files from the server, the weight value of the log files can be calculated based on the indicator data included in the server. By sorting the weight values ​​of the log files, the log files associated with diagnosing server faults can be accurately collected, saving log collection time and improving the efficiency of server diagnosis. At the same time, a smaller number of log files also saves server storage resources.

[0042] refer to Figure 2 It illustrates a flowchart of another log file collection method provided in this application embodiment, the method including:

[0043] Step 201: Obtain the first feature information of the server to be collected.

[0044] This step can be referred to in step 101, and will not be repeated here.

[0045] Step 202: Determine the Euclidean distance between the first feature information and the second feature information of the server contained in the preset database.

[0046] In this embodiment of the invention, the method for determining whether servers in a preset database and servers to be collected are of the same type can be: calculating the Euclidean distance between the first feature information of the server to be collected and the second feature information corresponding to each server in the preset database. Euclidean distance is a distance-based discrimination and classification method. Discrimination and classification refers to distinguishing things based on their different points, determining the category to which things belong, grouping things with more similarities into one category, and enabling rapid identification of the category of each thing among a large number of things according to certain rules. The basic idea of ​​distance discrimination is to classify samples that are closer together into one category, and samples that are farther apart into different categories. Here, distance can be the similarity between samples; the smaller the distance between samples, the more similar they are, and vice versa. During classification, the distance from each new sample point (category unknown) to a historical sample point (category known) can be calculated, and then the category of the new sample can be predicted as the category of its most similar historical sample point. Alternatively, the category of the new sample can be predicted as the category with the most similarity among the k (k = 1, 2, ...) historical sample points.

[0047] Furthermore, in this application, taking the Euclidean distance discriminant analysis method as an example, the similarity between each asset information indicator in the first feature information and the second feature information is calculated, thereby determining the target server that belongs to the same class as the server to be collected. The first feature information {r1, r2, ... r...} can be calculated using the following expression. k The Euclidean distance between the second feature information of the i-th server in the preset database and the second feature information of the i-th server.

[0048]

[0049] Where k represents the k asset information indicators included in the first or second feature information, j indicates the j-th asset information indicator in the first or second feature information, and D i This represents the calculated Euclidean distance value. Based on the order of the calculated Euclidean distance values, servers with smaller Euclidean distances are more similar to the server to be collected, while servers with larger Euclidean distances are dissimilar. The Euclidean distance is used to determine which target servers belong to the same category as the server to be collected.

[0050] Step 203: Servers in the preset database whose Euclidean distance to the first feature information is less than a preset threshold are identified as target servers belonging to the same category as the server to be collected.

[0051] In this embodiment of the invention, based on the calculated Euclidean distance, servers whose Euclidean distance to the server to be collected is less than the preset threshold are identified as target servers belonging to the same category as the server to be collected. The size of the preset threshold can be set according to the actual situation, and this embodiment of the invention does not limit it.

[0052] Step 204: Determine the target fault category whose first weight value is within a first preset range based on the first weight value of the fault category corresponding to the target server.

[0053] This step can be referred to in step 103, and will not be repeated here.

[0054] Optionally, step 204 specifically includes:

[0055] Sub-step 2041: For each fault category in the preset database, determine a first ratio of the number of servers included in the fault category to the total number of servers in the preset database.

[0056] In this embodiment of the invention, the first ratio can represent the prior probability, denoted as the ratio of the number of servers included in each fault category to the total number of servers. If the total number of servers included in the preset database is 'a', and there are a total of 'c' fault categories, the prior probability of each fault category can be expressed by the following expression.

[0057]

[0058] Where P is the set of prior probabilities corresponding to each fault category among all fault categories, P1, P2...P C This represents the prior probability corresponding to each fault category. N1 represents the total number of servers included in the first fault category, and so on, N... C This represents the total number of servers included in the c-th fault category.

[0059] Sub-step 2042: For each fault category corresponding to the target server, determine the second ratio of the number of target servers included in the fault category to the number of servers included in the fault category in a preset database.

[0060] Sub-step 2043: Determine the first weight value of the fault category corresponding to the target server based on the first ratio and the second ratio, and determine the fault category whose first weight value is within a first preset range as the target fault category.

[0061] In this embodiment of the invention, after determining the prior probability corresponding to each fault category calculated based on a preset database, a second ratio for each fault category corresponding to the target server is further determined based on the target server set. A first weight value corresponding to each fault category is determined by combining the first ratio and the second ratio.

[0062] Furthermore, the larger the first weight value, the more frequently the fault category occurs. Therefore, by sorting the first weight values ​​of all fault categories corresponding to the target server, the fault category with the first weight value within the first preset range is selected as the target fault category. The fault category determined in this way is the fault category with the highest probability of occurrence on the server to be collected.

[0063] Optionally, sub-step 2043 specifically includes:

[0064] Sub-step 2044: The product of the first ratio corresponding to the fault category of the target server and the second ratio corresponding to the fault category of the target server is used as the first weight value of the fault category of the target server.

[0065] In this embodiment of the invention, if there are c target servers, then the set T = {T1, T2, ..., Tc}, where Tj represents the number of servers in the classification set that have appeared in the j-th fault category. The first weight value of the j-th fault category is denoted as...

[0066]

[0067] Step 205: Determine the third weight value of the indicator data based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule.

[0068] This step can be referred to in step 104, and will not be repeated here.

[0069] Optionally, step 205 specifically includes:

[0070] Sub-step 2051: Determine the second weight value of the filtering rule corresponding to the target fault category based on the first weight value corresponding to the target fault category.

[0071] In this embodiment of the invention, c fault categories are sorted according to the first weight value calculated above. If the first preset range is the top 10%, then the target fault categories with larger first weight values ​​in the top 10% can be selected. Each target fault category can correspond to multiple filtering rules, and filtering rules that can diagnose the same fault category are considered as one category. A filtering rule may diagnose multiple fault categories simultaneously, so a filtering rule may exist in multiple fault categories. For example, the first fault category contains {rule 1, rule 2, rule 3}, the second fault category contains {rule 1, rule 3, rule 4}, and the third fault category contains {rule 2, rule 5}. After determining the target fault category, it can be further determined which specific filtering rules are included in the target fault category.

[0072] Furthermore, by combining the frequency of occurrence of each filtering rule with the first weight value of the target fault category it can diagnose, the second weight value corresponding to each filtering rule can be determined.

[0073] Optionally, sub-step 2051 specifically includes:

[0074] Sub-step 20511: If the filtering rule appears only in one target fault category, then the first weight value corresponding to the target fault category is used as the second weight value corresponding to the filtering rule.

[0075] Sub-step 20512: If the filtering rule appears in multiple target fault categories, then the first weight values ​​corresponding to the multiple target fault categories are summed as the second weight value corresponding to the filtering rule.

[0076] In this embodiment of the invention, for a filtering rule that appears only in one target fault category, the second weight value of the filtering rule is equal to the first weight value of the corresponding target fault category; for a filtering rule that appears in multiple target fault categories, the second weight value of the filtering rule is equal to the sum of the first weight values ​​of the target fault categories in which it appears.

[0077] Referring to sub-step 2051 and Table 1, which is an example table of the second weight value corresponding to each filtering rule, for example: if rule 1 appears in the first fault category and the second fault category, then the second weight value WR corresponding to rule 1 is the sum of the first weight value W1 of the first fault category and the first weight value W2 of the second fault category, and the number of times rule 1 appears is CR 2; if rule 2 appears in the first fault category and the third fault category, then the second weight value WR corresponding to rule 2 is the sum of the first weight value W1 of the first fault category and the first weight value W3 of the third fault category, and the number of times rule 2 appears is CR 2; if rule 3 appears in the first fault category and the second fault category, then the second weight value WR corresponding to rule 3 is the sum of the first weight value W1 of the first fault category and the first weight value W2 of the second fault category, and the number of times rule 3 appears is CR 2; if rule 4 appears in the second fault category, then the second weight value WR corresponding to rule 4 is the first weight value W2 of the second fault category, and the number of times rule 4 appears is CR 1; if rule 5 appears in the third fault category, then the second weight value WR corresponding to rule 5 is the first weight value W3 of the third fault category, and the number of times rule 5 appears is CR 1. Similarly, when there are multiple filtering rules, a second weight value can be calculated for each filtering rule.

[0078] Table 1

[0079] Weight WR <![CDATA[W1+W2]]> <![CDATA[W1+W3]]> <![CDATA[W1+W2]]> <![CDATA[W2]]> <![CDATA[W3]]> …… Number of CR <![CDATA[C1=2]]> <![CDATA[C2=2]]> <![CDATA[C3=2]]> <![CDATA[C4=1]]> <![CDATA[C5=1]]> ……

[0080] Sub-step 2052: For each indicator data, determine the third weight value corresponding to the indicator data based on the number of times the indicator data appears in different filtering rules and the second weight value corresponding to the filtering rule in which the indicator data appears.

[0081] In this embodiment of the invention, each filtering rule can correspond to multiple indicator data, and each indicator data can also appear in multiple filtering rules. Therefore, for each indicator data, the third weight value corresponding to the indicator data can be determined by the number of times the indicator data appears in different filtering rules and the second weight value corresponding to the filtering rule in which the indicator data appears.

[0082] Referring to Table 2, which is a statistical table of rule-based indicator data, in which... This indicates that the current filter rule contains the data for that metric. It can be seen that the number of metrics included in each filter rule can be different, and each metric can appear in multiple filter rules. The metric data can be used to determine whether a log file meets the filter rule.

[0083] Furthermore, in Table 2, Rule 1 includes Indicator 1, Indicator 2, Indicator 3, and Indicator 5; Rule 2 includes Indicator 2, Indicator 3, and Indicator 7; Rule 3 includes Indicator 4 and Indicator 5; Rule 4 includes Indicator 1, Indicator 6, Indicator 7, and Indicator 8; and Rule 5 includes Indicator 1, Indicator 4, Indicator 7, and Indicator 8. The third weight value corresponding to each indicator data can be the sum of the products of the number of times the indicator data appears in different filtering rules and the second weight values ​​corresponding to the filtering rules that contain the indicator data. The number of times the indicator data appears is recorded as the number of filtering rules that include that indicator data. For example, if Indicator 1 appears in both Rule 1 and Rule 4, with a frequency of 2, the third weight value corresponding to Indicator 1 can be: WT1 = CR1 × WR1 + CR4 × WR4. Similarly, the third weight value corresponding to each indicator data can be determined.

[0084] Table 2 - Examples of Statistical Data for Rule Indicators

[0085]

[0086]

[0087] Step 206: Determine the fourth weight value corresponding to each log file contained in the server to be collected based on the third weight value of the indicator data, and collect log files whose fourth weight values ​​belong to the second preset range.

[0088] This step can be referred to in step 105, and will not be repeated here.

[0089] Optionally, step 206 specifically includes:

[0090] Sub-step 2061: Determine a third ratio between the total number of indicator data contained in the log file and the total number of indicator data corresponding to the filtering rule.

[0091] Sub-step 2062: Determine the fourth weight value corresponding to each log file based on the sum of the third weight values ​​corresponding to all the indicator data contained in the log file and the third ratio.

[0092] In this embodiment of the invention, after determining the third weight value corresponding to each indicator data, the fourth weight value corresponding to each log file of the server to be collected can be determined based on the number of indicator data contained in each log file of the server to be collected and the third weight value corresponding to each indicator data.

[0093] For example, if the log file information contains content related to the metric data, then the log file is considered to contain the metric data. The number of metric data contained in the log file is denoted as CF. The fourth weight value corresponding to the log file is the product of the proportion of the metric data contained and the sum of the third weight values ​​of the contained metric data. The weight WF of the i-th log file can be calculated using the following expression:

[0094]

[0095] In this context, the number of indicator data points contained in the log file is denoted as CF, and N is the total number of indicator data points. Based on the above expression, the log files can be sorted according to the fourth weight value. Log files with the fourth weight value within a second preset range are selected as the log files to be collected. The second preset range can be the top 100%, the top 20%, etc. The second preset range can be set according to actual conditions, and this embodiment of the invention does not limit it. The log files within the determined second preset range are the log files that the server needs to collect. This reduces the number of log files that need to be collected from the server, accurately collects log files associated with diagnosing server faults, saves log collection time, improves the efficiency of server diagnosis, and also saves server storage resources due to the smaller number of log files.

[0096] In summary, in this embodiment, the first feature information of the server to be collected is compared with the second feature information in a preset database to determine the target servers in the preset database that belong to the same category as the server to be collected. Servers of the same type have a higher probability of experiencing the same type of fault. After determining the target server, the target fault category with the larger first weight value is determined based on the first weight value of the fault category corresponding to the target server. Based on the target fault category, the weight values ​​of the filtering rules and indicator data corresponding to the target fault category are further determined. When collecting log files from the server, the weight value of the log files can be calculated based on the indicator data included in the server. By sorting the weight values ​​of the log files, the log files associated with diagnosing server faults can be accurately collected, saving log collection time and improving the efficiency of server diagnosis. At the same time, a smaller number of log files also saves server storage resources.

[0097] refer to Figure 3 It illustrates a log file collection device 30 provided in an embodiment of this application, the device comprising:

[0098] Acquisition module 301 is used to acquire the first feature information of the server to be collected;

[0099] The first determining module 302 is used to compare the first feature information with the second feature information of the server contained in the preset database, and determine the target server in the preset database that belongs to the same category as the server to be collected.

[0100] The second determining module 303 is used to determine the target fault category whose first weight value is within a first preset range based on the first weight value of the fault category corresponding to the target server.

[0101] The third determining module 304 is used to determine the third weight value of the indicator data based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule.

[0102] The acquisition module 305 is used to determine the fourth weight value corresponding to each log file contained in the server to be acquired based on the third weight value of the indicator data, and to acquire the log files whose fourth weight value belongs to a second preset range.

[0103] Optionally, the first determining module includes:

[0104] The first calculation submodule is used to determine the Euclidean distance between the first feature information and the second feature information of the server contained in the preset database;

[0105] The first determining submodule is used to determine servers in the preset database whose Euclidean distance from the first feature information is less than a preset threshold as target servers belonging to the same category as the server to be collected.

[0106] Optionally, the second determining module includes:

[0107] The second calculation submodule is used to determine a first ratio of the number of servers included in each fault category to the total number of servers in the preset database for each fault category in the preset database.

[0108] The third calculation submodule is used to determine, for each fault category corresponding to the target server, a second ratio between the number of target servers included in the fault category and the number of servers included in the fault category in a preset database.

[0109] The second determining submodule is used to determine a first weight value of the fault category corresponding to the target server based on the first ratio and the second ratio, and to determine the fault category whose first weight value is within a first preset range as the target fault category.

[0110] Optionally, the second determining submodule is further used for

[0111] The product of the first ratio corresponding to the fault category of the target server and the second ratio corresponding to the fault category of the target server is used as the first weight value of the fault category of the target server.

[0112] Optionally, the third determining module includes:

[0113] The third determining submodule is used to determine the second weight value of the filtering rule corresponding to the target fault category based on the first weight value corresponding to the target fault category.

[0114] The fourth determination submodule is used to determine the third weight value corresponding to each indicator data based on the number of times the indicator data appears in different filtering rules and the second weight value corresponding to the filtering rule in which the indicator data appears.

[0115] Optionally, the third determining submodule is further configured to:

[0116] If the filtering rule appears in only one target fault category, then the first weight value corresponding to the target fault category is used as the second weight value corresponding to the filtering rule;

[0117] If the filtering rule appears in multiple target fault categories, the first weight values ​​corresponding to the multiple target fault categories are summed as the second weight value corresponding to the filtering rule.

[0118] Optionally, the acquisition module includes:

[0119] The fourth calculation submodule is used to determine a third ratio between the total number of indicator data contained in the log file and the total number of indicator data corresponding to the filtering rule;

[0120] The fifth determining submodule is used to determine the fourth weight value corresponding to each log file based on the sum of the third weight values ​​corresponding to all indicator data contained in the log file and the third ratio.

[0121] In summary, in this embodiment, the first feature information of the server to be collected is compared with the second feature information in a preset database to determine the target servers in the preset database that belong to the same category as the server to be collected. Servers of the same type have a higher probability of experiencing the same type of fault. After determining the target server, the target fault category with the larger first weight value is determined based on the first weight value of the fault category corresponding to the target server. Based on the target fault category, the weight values ​​of the filtering rules and indicator data corresponding to the target fault category are further determined. When collecting log files from the server, the weight value of the log files can be calculated based on the indicator data included in the server. By sorting the weight values ​​of the log files, the log files associated with diagnosing server faults can be accurately collected, saving log collection time and improving the efficiency of server diagnosis. At the same time, a smaller number of log files also saves server storage resources.

[0122] Figure 4 A block diagram of an electronic device 600 is shown according to an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0123] Reference Figure 4 The electronic device 600 may include one or more of the following components: a processing component 602, a memory 604, a power supply component 606, a multimedia component 608, an audio component 610, an input / output (I / O) interface 612, a sensor component 614, and a communication component 616.

[0124] Processing component 602 typically controls the overall operation of electronic device 600, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 602 may include one or more processors 620 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 602 may include one or more modules to facilitate interaction between processing component 602 and other components. For example, processing component 602 may include a multimedia module to facilitate interaction between multimedia component 608 and processing component 602.

[0125] Memory 604 is used to store various types of data to support the operation of electronic device 600. Examples of such data include instructions for any application or method operating on electronic device 600, contact data, phonebook data, messages, pictures, multimedia, etc. Memory 604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0126] Power supply component 606 provides power to various components of electronic device 600. Power supply component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 600.

[0127] Multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 608 includes a front-facing camera and / or a rear-facing camera. When the electronic device 600 is in an operating mode, such as a shooting mode or a multimedia mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0128] Audio component 610 is used to output and / or input audio signals. For example, audio component 610 includes a microphone (MIC) used to receive external audio signals when electronic device 600 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 604 or transmitted via communication component 616. In some embodiments, audio component 610 also includes a speaker for outputting audio signals.

[0129] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0130] Sensor assembly 614 includes one or more sensors for providing state assessments of various aspects of electronic device 600. For example, sensor assembly 614 can detect the on / off state of electronic device 600, the relative positioning of components such as the display and keypad of electronic device 600, changes in position of electronic device 600 or a component of electronic device 600, the presence or absence of user contact with electronic device 600, orientation or acceleration / deceleration of electronic device 600, and temperature changes of electronic device 600. Sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 614 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 614 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0131] Communication component 616 facilitates wired or wireless communication between electronic device 600 and other devices. Electronic device 600 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 616 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 616 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0132] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement a log file acquisition method provided in the embodiments of this application.

[0133] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions, which can be executed by a processor 620 of an electronic device 600 to perform the above-described method. For example, the non-transitory storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0134] Figure 5A block diagram of an electronic device 700 is shown according to an exemplary embodiment. For example, the electronic device 700 may be provided as a server. (Refer to...) Figure 5 The electronic device 700 includes a processing component 722, which further includes one or more processors, and memory resources represented by a memory 732 for storing instructions, such as application programs, that can be executed by the processing component 722. The application programs stored in the memory 732 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 722 is configured to execute instructions to perform a log file acquisition method provided in embodiments of this application.

[0135] Electronic device 700 may also include a power supply component 726 configured to perform power management of electronic device 700, a wired or wireless network interface 750 configured to connect electronic device 700 to a network, and an input / output (I / O) interface 758. Electronic device 700 may operate on an operating system stored in memory 732, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0136] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0137] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for collecting log files, characterized in that, The method includes: Obtain the first feature information of the server to be collected; The first feature information is compared with the second feature information of the servers contained in the preset database to determine the target servers in the preset database that belong to the same category as the server to be collected. Based on the first weight value of the fault category corresponding to the target server, the target fault category in which the first weight value is within a first preset range is determined; The third weight value of the indicator data is determined based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule. Based on the third weight value of the indicator data, the fourth weight value corresponding to each log file contained in the server to be collected is determined, and log files whose fourth weight values ​​belong to the second preset range are collected.

2. The method according to claim 1, characterized in that, The step of comparing the first feature information with the second feature information of servers contained in a preset database to determine that the target servers in the preset database belong to the same category as the server to be collected includes: Determine the Euclidean distance between the first feature information and the second feature information of the server contained in the preset database; Servers in the preset database whose Euclidean distance from the first feature information is less than a preset threshold are identified as target servers belonging to the same category as the server to be collected.

3. The method according to claim 1, characterized in that, Based on the first weight value of the fault category corresponding to the target server, the target fault category whose first weight value falls within a first preset range is determined, including: For each fault category in the preset database, a first ratio is determined between the number of servers included in the fault category and the total number of servers in the preset database. For each fault category corresponding to the target server, determine a second ratio between the number of target servers included in the fault category and the number of servers included in the fault category in a preset database; Based on the first ratio and the second ratio, a first weight value for the fault category corresponding to the target server is determined, and the fault category whose first weight value is within a first preset range is determined as the target fault category.

4. The method according to claim 3, characterized in that, The step of determining the first weight value of the fault category corresponding to the target server based on the first ratio and the second ratio includes: The product of the first ratio corresponding to the fault category of the target server and the second ratio corresponding to the fault category of the target server is used as the first weight value of the fault category of the target server.

5. The method according to claim 1, characterized in that, The step of determining the third weight value of the indicator data based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears includes: Based on the first weight value corresponding to the target fault category, determine the second weight value of the filtering rule corresponding to the target fault category; For each indicator data, a third weight value is determined based on the number of times the indicator data appears in different filtering rules and the second weight value corresponding to the filtering rule in which the indicator data appears.

6. The method according to claim 5, characterized in that, The step of determining the second weight value of the filtering rule corresponding to the target fault category based on the first weight value corresponding to the target fault category includes: If the filtering rule appears in only one target fault category, then the first weight value corresponding to the target fault category is used as the second weight value corresponding to the filtering rule; If the filtering rule appears in multiple target fault categories, the first weight values ​​corresponding to the multiple target fault categories are summed as the second weight value corresponding to the filtering rule.

7. The method according to claim 1, characterized in that, The step of determining the fourth weight value corresponding to each log file contained in the server to be collected based on the third weight value of the indicator data includes: Determine a third ratio between the total number of indicator data contained in the log file and the total number of indicator data corresponding to the filtering rule; The fourth weight value for each log file is determined by the sum of the third weight values ​​corresponding to all the indicator data contained in the log file, and by the third ratio.

8. A log file collection device, characterized in that, The device includes: The acquisition module is used to acquire the first feature information of the server to be collected; The first determining module is used to compare the first feature information with the second feature information of the server contained in the preset database, and determine the target server in the preset database that belongs to the same category as the server to be collected; The second determining module is used to determine the target fault category whose first weight value is within a first preset range based on the first weight value of the fault category corresponding to the target server. The third determining module is used to determine the third weight value of the indicator data based on the second weight value of the filtering rule corresponding to the target fault category and the number of times the filtering rule containing the indicator data appears; the indicator data is used to determine whether the log file meets the filtering rule. The acquisition module is used to determine the fourth weight value corresponding to each log file contained in the server to be acquired based on the third weight value of the indicator data, and to acquire log files whose fourth weight values ​​belong to a second preset range.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 7.

Images