CN114020631A

CN114020631A - Method, apparatus and machine-readable storage medium for link testing

Info

Publication number: CN114020631A
Application number: CN202111327800.0A
Authority: CN
Inventors: 黄坤; 谭硕
Original assignee: China Construction Bank Corp
Current assignee: China Construction Bank Corp
Priority date: 2021-11-10
Filing date: 2021-11-10
Publication date: 2022-02-08
Anticipated expiration: 2041-11-10
Also published as: CN114020631B

Abstract

The embodiment of the application provides a method and a device for link test and a machine-readable storage medium. The method comprises the following steps: determining a time subinterval where a user submits a code moment; acquiring state data of a request response message of the nginx server in a time subinterval; acquiring the submission frequency of codes submitted by a user in a time subinterval; acquiring quality data of a code submitted by a user; obtaining a utility function value according to the state data, the quality data, the submission frequency and a preset test trigger utility function; comparing the utility function value with a preset threshold value; and triggering a link test when the utility function value is greater than or equal to the preset threshold value. The method determines whether the automatic link test is required to be triggered or not by comprehensively utilizing the multi-dimensional characteristics such as the quality data of the codes submitted by the user, the submitting frequency, the real-time link request state of the system and the like, thereby avoiding frequent link test and reducing the consumption of system resources.

Description

Method, apparatus and machine-readable storage medium for link testing

Technical Field

The present application relates to the field of full link testing technologies, and in particular, to a method and an apparatus for link testing and a machine-readable storage medium.

Background

With the development of the internet, more and more application service nodes are accessed in a distributed system, and in order to obtain information of all application service nodes on a call chain, full-link tracking is required.

The existing link tracing technology focuses on generating a trace mark on an application service node for full link tracing when a call request passes through the application service node, and the scheme causes a large amount of consumption of system resources due to the need of frequently tracing links.

Disclosure of Invention

An object of the embodiments of the present application is to provide a method, an apparatus, and a machine-readable storage medium for link testing, which aim to solve the problem in the prior art that link tracing is frequently performed, which results in a large consumption of system resources.

In order to achieve the above object, a first aspect of the present application provides a method for link testing, comprising:

determining a time subinterval where a user submits a code moment;

acquiring state data of a request response message of the nginx server in a time subinterval;

acquiring the submission frequency of the codes submitted by the user in the time subinterval;

acquiring quality data of a code submitted by a user;

obtaining a utility function value according to the state data, the quality data, the submission frequency and a preset test trigger utility function;

comparing the utility function value with a preset threshold value;

and triggering a link test under the condition that the utility function value is greater than or equal to a preset threshold value.

In this embodiment of the present application, the status data includes a request failure rate of the sensitive transaction in the preset sensitive transaction list, and the method for link testing further includes:

acquiring log data of the nginx server in a time subinterval;

cutting the log data to obtain a state code of the sensitive transaction in a preset sensitive transaction list;

and obtaining the request failure rate according to the status code.

In the embodiment of the present application, obtaining the request failure rate according to the status code includes:

counting the state codes to obtain a first number of state codes with failed requests and a second number of all the state codes;

the quotient of the first number and the second number is determined as a request failure rate.

In this embodiment, the quality data includes a coefficient of success weight submitted and compiled, and the method for link testing further includes:

acquiring a sub-time period of a code submitting moment of a user;

acquiring first submission and compiling power of codes submitted by a user in a sub-time period;

acquiring the average value of second submission and compiling success rates of codes submitted by all users in a sub-time period;

and determining the quotient of the first submission and compilation success rate and the mean value as a submission and compilation success weight value coefficient.

In an embodiment of the present application, the method for link testing further includes:

acquiring the triggering times of triggering Jenkins pipeline compilation by submitting codes by a user in a time subinterval;

the number of triggers is determined as the commit frequency.

In the embodiment of the present application, the preset test trigger utility function is:

w1 is a first preset weight, k _ submit (p) is quality data of a code submitted by a user p, num _ submit (time _ duration (t)) is the submission frequency of a time sub-interval of the time when the user p submits the code, w2 is a second preset weight, and fail _ ratio (time _ duration (t)) is the request failure rate of sensitive transactions in a preset sensitive transaction list of the time sub-interval of the time when the user p submits the code.

In the embodiment of the present application, triggering a link test includes:

acquiring preset link topology information and a version packet constructed by a Jenkins pipeline according to codes;

and taking the version packet and the preset link topology information as a target version, and pushing the target version to all application service nodes on a call chain corresponding to the request of the nginx server so that all application service nodes execute a preset link test script according to the target version.

In the embodiment of the present application, executing a preset link test script according to a target version includes:

acquiring preset link topology information from a target version;

acquiring link test information of a current application service node from preset link topology information;

and executing a preset link test script based on the link test information to obtain a link test result of the current application service node.

In this embodiment of the present application, executing a preset link test script based on link test information to obtain a link test result of a current application service node includes:

determining a next application service node according to the link test information;

sending an http request from the current application service node to the next application service node through a curl command to obtain response message information of an http response from the current application service node to the next application service node;

and determining whether the service state from the current application service node to the next application service node is normal or not according to the response message information.

In this embodiment of the present application, executing a preset link test script based on the link test information to obtain a link test result of the current application service node, further includes:

determining a port of a next application service node according to the link test information;

and testing the connectivity of the port through a telnet command to determine the link connectivity of the current application service node to the next application service node.

acquiring a frontmost service node on a call chain corresponding to a request of the nginx server;

controlling the foremost service node to obtain link test results of all application service nodes of the call chain;

controlling the foremost service node to perform aggregate analysis on the link test results of all the application service nodes to obtain full-link abnormal data;

and controlling the foremost service node to output full-link abnormal data.

A second aspect of the present application provides an apparatus for link testing, comprising:

a memory configured to store instructions; and

a processor configured to call instructions from the memory and when executing the instructions is capable of implementing the method for link testing described above.

A third aspect of the application provides a machine-readable storage medium having stored thereon instructions for causing a machine to perform the above-described method for link testing.

By the technical scheme, whether the automatic link test is required to be triggered or not is determined by comprehensively utilizing the multidimensional characteristics of quality data of codes submitted by users, submitting frequency, system real-time link request state and the like, so that frequent link test is avoided, and consumption of system resources is reduced.

Additional features and advantages of embodiments of the present application will be described in detail in the detailed description which follows.

Drawings

The accompanying drawings, which are included to provide a further understanding of the embodiments of the disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the embodiments of the disclosure, but are not intended to limit the embodiments of the disclosure. In the drawings:

FIG. 1 schematically illustrates an application environment of a method for link testing according to an embodiment of the present application;

FIG. 2 schematically illustrates a flow diagram of a method for link testing according to the present application;

FIG. 3 schematically illustrates a flow chart of the triggered link test of FIG. 2;

FIG. 4 schematically shows a block diagram of an apparatus for link testing according to an embodiment of the present application;

fig. 5 schematically shows an internal structure diagram of a computer device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it should be understood that the specific embodiments described herein are only used for illustrating and explaining the embodiments of the present application and are not used for limiting the embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that if directional indications (such as up, down, left, right, front, and back … …) are referred to in the embodiments of the present application, the directional indications are only used to explain the relative positional relationship between the components, the movement situation, and the like in a specific posture (as shown in the drawings), and if the specific posture is changed, the directional indications are changed accordingly.

In addition, if there is a description of "first", "second", etc. in the embodiments of the present application, the description of "first", "second", etc. is for descriptive purposes only and is not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In addition, technical solutions between various embodiments may be combined with each other, but must be realized by a person skilled in the art, and when the technical solutions are contradictory or cannot be realized, such a combination should not be considered to exist, and is not within the protection scope of the present application.

The method for testing the link provided by the application can be applied to the application environment shown in fig. 1. Wherein, the gitlab server is a code server used for storing git code warehouse in the research and development process. The Jenkins server is a continuous integration tool developed based on Java and is used for providing a continuous integrated research and development pipeline environment. The nginx server is used as a request inlet to obtain an original request from a page, and forwards the original request to a server of a downstream application service node according to a configuration forwarding rule of the nginx. There may be a plurality of application service nodes, in the example shown in fig. 1, there are three downstream application service nodes, which are node a, node B, and node C; the three nodes are respectively and correspondingly deployed with application service A, service B and service C. The nginx server, the server of the application service node, the gitlab server and the Jenkins server are all mounted with network storage modules, and the servers can share data and disk information through the network storage modules.

Fig. 2 schematically shows a flow diagram of a method for link testing according to an embodiment of the application. As shown in fig. 2, in the embodiment of the present application, a method for link test is provided, which may include the following steps:

step 202, determining a time subinterval at which the user submits the code.

It should be understood that, after an administrator first starts each core service of all the machines such as the application service node, nginx, gitlab, and the like, link topology information may be preset through a preset interface, and the link topology information may include a partition rule of a time sub-interval.

When a user submits a code in a gitlab server, a time subinterval at the moment of submitting the code t can be determined according to a time subinterval division rule in preset link topology information, and the time subinterval time _ duration (t) can be flexibly designed and processed according to specific engineering requirements. In one example, the time sub-interval may be cut and divided by hours, e.g., the time sub-interval at time 9:45 is [9:00-10:00 ]; in another example, the time sub-intervals may be divided and divided by day, for example, the day is 2021 year 4 month 16 day at time sub-intervals of 0 min 0 s at 2021 year 4 month 16 day 0 to 59 min 59 s at 2021 year 4 month 16 day 23.

Step 204, acquiring the state data of the request response message of the nginx server in the time subinterval;

the nginx server is a high-performance HTTP and reverse proxy server, has less occupied memory and strong concurrency capability, is widely applied, and can obtain the state data of the request response message of the nginx server in a time subinterval by cutting and analyzing the log data of the nginx.

In one example, the status data of the request response message includes a request failure rate of the sensitive transaction in a preset sensitive transaction list, and log data of the nginx server in a time subinterval can be acquired; cutting the log data to obtain a state code of the sensitive transaction in a preset sensitive transaction list; and obtaining the request failure rate according to the status code.

In a specific implementation, N sensitive transactions can be defined to exist in an observation set, and the sensitive transactions are added into an interest list in a preset mode; the sensitive transactions can represent the request relationship of a call chain among a plurality of nodes, for example, the call relationship of service A → service B → service C exists; defining the sensitive transaction list as the object _ request _ list.

For the method for cutting and analyzing the log data of the nginx server, technologies such as request-log-analyzer, goacs, nginx-log-analysis, linux-carried awk tool and the like can be adopted, and the statistical convenience, visualization and operability of log analysis are continuously improved by the technologies.

Taking the case of splitting the log and subsequent analysis by the aid of an awk tool of linux, assuming that the state code in the log data of the nginx server is at the 9 th position of the separator, the state code at the 9 th position of the separator in the log data can be obtained by the aid of the awk tool, and therefore common different types of state codes and the number of the state codes are obtained.

For the request failure rate index, the transaction result of the sensitive transaction list object _ request _ list can be observed in the log data of nginx, the distinction is performed through http status codes, a successful request is performed if the status code is 200, a failed request is performed if the status code is 401, 403, and the like, statistics is performed on the status codes with failed requests to obtain a first quantity, statistics is performed on all the status codes to obtain a second quantity, and the quotient of the first quantity and the second quantity is determined as the request failure rate.

In one example, at the time sub-interval time _ duration (t) of time t, the sensitive transaction list object _ request _ list has a request failure rate fail _ ratio (time _ duration (t)) calculated as follows:

fail_ratio(time_duration(t))＝num_failed(time_duration(t))/num_total(time_duration(t))；

wherein num _ failed (time _ duration (t)) is the first number of status codes for which the request failed at time t; num _ total (time _ duration (t)) is the second number of status codes for all of time t.

The linux system has a timed task crontab, the timed task can be set through the crontab, the log cutting and analyzing method is executed at a timed time, state data of a request response message of the nginx server is obtained, and the state data is stored in a network storage module, so that the server or an application service node can conveniently obtain the state data.

Step 206, obtaining the submission frequency of the code submitted by the user in the time subinterval.

It should be understood that, each time a user submits a code, the Jenkins server is triggered to be constructed in a pipelined manner, the triggering times of the code submitted by the user in the time sub-interval time _ duration (t) to trigger Jenkins pipeline compilation can be counted, the triggering times are taken as submission frequencies, and the submission frequencies are defined as num _ submit (time _ duration (t)).

The statistics of the submission frequency can be realized by recording the triggering frequency to the network storage module when triggering and compiling, so that the server or the application service node can acquire the submission frequency from the network storage module.

And step 208, acquiring quality data of the code submitted by the user.

After the code is submitted, Jenkins construction is triggered to possibly cause compiling failure, a sub-time period where a user p submits the code at a time t is defined as submit _ duration, and the first submission and compiling of the code submitted by the user p are defined as submit (p, submit _ duration); defining the average value of the second submission and compiling success rate of all the user submitted codes as submit _ average (submit _ duration); and determining the quotient of the first submission and compilation success rate and the mean value as a submission and compilation success weight value coefficient.

The sub-period sub _ duration at time t may be divided and divided by day, for example, the day is 2021 year 4 month 16 day, and the sub-period at time by day is [ 0 min 0 s at 4 month 16 day 0 at 2021 year 0 to 59 min 59 s at 4 month 16 day 23 at 2021 year 59 ]. The sub-period submit _ duration at time t may be the same as or different from the time sub-interval at time t.

The calculation formula of the coefficient of the successful weight submitted and compiled by the user p is as follows:

k_submit(p)＝submit(p,sumit_duration)/sumbit_average(sumit_duration)。

by the above definition, the submission and compilation power of a user is compared with the average of the submission and compilation success rates of all persons, so that the code quality of the user can be determined and whether the compilation introduces code problems and link connectivity problems can be predicted.

After determining the quality data of the user submitted code, it may be stored to a network storage module to facilitate the server or application service node to obtain the quality data.

And step 210, obtaining a utility function value according to the state data, the quality data, the submission frequency and a preset test trigger utility function.

In one example, the preset test trigger utility function is:

when k _ submit (P) is lower, the user P is indicated to submit the code frequently, the interface call may fail due to the code quality in the submission, and the link is not passed; when k _ submit (p) is higher, the user submitting the code trigger is compiled to be higher in power, which shows that the user code is higher in quality in a certain level.

By passing

Mapping is carried out, the smaller the k _ submit (p), the worse the user code quality is, the higher the probability of triggering a subsequent link test is, wherein the lower the k _ submit (p) is; the larger k _ submit (p) is, the higher the quality of the user code is, the higher the code is submitted, and the probability of triggering the subsequent link test is correspondingly lower.

num _ submittal (time _ duration (t)) is the submission frequency of the time subinterval where the user p submits the code moment, frequent code submission or new system functions addition can cause uncontrollable system and increase of error probability, and the new code itself can cause the change of a link call chain, and the probability of the need of the link test is naturally increased.

A fail _ ratio (time _ duration (t)) is a request failure rate of the sensitive transaction in a preset sensitive transaction list of a time sub-interval of a time when the user p submits the code, and if the request failure rate is low, the probability that the link has an anomaly is higher, and the probability that the subsequent link test is needed is increased.

w1 is a first preset weight, which represents the subjective ability of the user and the weight submitted by all users, and represents the contribution value influence weight of the user behavior on the link test.

w2 is a second preset weight, which represents the weight of the contribution factor of the current system link state, and characterizes the current user link, and the abnormal request influences the weight of the contribution value of the link test.

The first preset weight and the second preset weight may be optimized step by step in a way of actually tuning parameters in engineering to obtain a reasonable optimized value, in an example, w 1-w 2-1 may be set when the link topology information is preset, and of course, the values of the first preset weight and the second preset weight may also be flexibly adjusted according to the project.

The preset test trigger utility function linktest _ utility _ function (p) is used for further indicating and predicting whether the current system needs to perform link test or not by comprehensively analyzing the quality data of codes submitted by a user history, the submission frequency of the codes and the condition of whether the current system link is abnormal or not.

Step 212, the utility function value is compared with a preset threshold.

It should be understood that, after an administrator starts each core service of all the machines such as the application service node, nginx, gitlab, etc. for the first time, link topology information may be preset through a preset interface, and the link topology information configuration may refer to the following:

the number of core nodes N for observation and diagnosis is 3;

configuring the object _ request _ list as [ http:// ip _ nginx: port _ nginx/path _ nginx ];

configuring time _ duration (t) to divide the sub-periods by hours;

w1＝1；

w2＝1；

fulllink_test_threshold＝20。

wherein, the fullllink _ test _ threshold is a preset threshold.

Step 214, triggering a link test when the utility function value is greater than or equal to a preset threshold value.

If the utility function value is larger than or equal to a preset threshold value, the possibility that the current link is abnormal is indicated, and a diagnosis test needs to be carried out on the link; if the utility function value is smaller than the preset threshold value, the current link is less abnormal, the link is in a healthy and controllable state, and the diagnostic test is not needed. By intelligently triggering the link test, the consumption of system resources is avoided, and the influence on the normal operation of production and research and development caused by frequent link test is avoided.

The method comprises the steps that a time subinterval where a user submits a code is determined; acquiring state data of a request response message of the nginx server in a time subinterval; acquiring the submission frequency of codes submitted by a user in a time subinterval; acquiring quality data of a code submitted by a user; obtaining a utility function value according to the state data, the quality data, the submission frequency and a preset test trigger utility function; comparing the utility function value with a preset threshold value; and triggering a link test under the condition that the utility function value is greater than or equal to a preset threshold value. The method determines whether the automatic link test is required to be triggered or not by comprehensively utilizing the multi-dimensional characteristics such as the quality data of the codes submitted by the user, the submitting frequency, the real-time link request state of the system and the like, thereby avoiding frequent link test and reducing the consumption of system resources.

Fig. 3 schematically shows a flow diagram of the triggered link test in fig. 2. As shown in fig. 3, in the embodiment of the present application, the process of triggering the link test may include the following steps:

step 2142, obtaining preset link topology information and a version packet constructed by the Jenkins pipeline according to the codes.

The following describes specific steps of triggering a link test by taking three nodes as an example of an application service node. Firstly, presetting three nodes as a node A, a node B and a node C respectively; the three nodes respectively deploy application services a, B, and C, corresponding Uniform Resource Locators (URLs), ports, and internet protocol (ip) addresses. For example, there is a request _ origin _ web initiated by a page, if the system has no failure, the call chain is as follows, URL is converted into http in nginx server,// ip _ nginx: port _ nginx/path _ nginx; forwarding to node A node, wherein URL is http:// ip _ node A: port _ node A/path _ node A; forwarding to node B node, wherein URL is http:// ip _ node B: port _ node B/path _ node B; finally forwarding to node C node, wherein URL is http:// ip _ node C, port _ node C/path _ node C; and presetting the URL, the port and the ip address parameters aiming at the current topological structure.

Step 2144, the version packet and the preset link topology information are used as a target version, and the target version is pushed to all application service nodes on a call chain corresponding to the request of the nginx server, so that all application service nodes execute a preset link test script according to the target version.

When a user submits the code, jenkins is triggered to carry out code warehouse pipeline construction and compiling. And acquiring a version packet constructed by the pipeline and preset link topology information, and pushing the version packet and the preset link topology information to the application service nodes node A, node B and node C as target versions. After pushing is finished, the preset instruction of jenkins can execute the link test script of the target node at the application service nodes node A, node B and node C.

The step of pushing the target version to the application service nodes node A, node B and node C can be realized by a Publish Over SSH plug-in of a Jenkins tool; the specific implementation method comprises the steps of configuring a sshPusher rule in a Jenkins file, connecting a node A, a node B or a node C through a Secure Shell (SSH) protocol, remotely transmitting a target version object to a certain directory of the node A, the node B or the node C, and executing a corresponding Shell command. Taking node a as an example, node a may be connected through an SSH protocol, and a target version object a.tgz is transmitted to a certain directory $ { cargoname }/version _ releases of node a, and a corresponding shell command source.bash _ profile is executed; sh ci _ for _ jenkins.sh $ { cargoname }. The implementation manner of pushing the target version to the application service nodes B and C may refer to the implementation manner of node a, and is not described herein again.

The configuration rule indicates that after compilation is successful, the object A.tgz to object C.tgz files are pushed to the machine designated by the ip strings node A to node C, and ci _ for _ jenkins.sh scripts are executed at the application service nodes node A to node C, respectively.

After receiving the target version, the application service node acquires preset link topology information from the target version; acquiring link test information of a current application service node from preset link topology information; and executing a preset link test script based on the link test information to obtain a link test result of the current application service node.

Specifically, the link test information may include URL, ip address, and port information. The link test result of the current application service node may be measured by a plurality of indexes, for example, link connectivity from the current application service node to the next application service node, and/or whether the traffic status from the current application service node to the next application service node is normal.

When testing whether the service state from the current application service node to the next application service node is normal, the test can be realized by a curl command in a Linux language, a programming language such as Go language, Python language or Java language, or a Postman tool.

In one example, the next application service node may be determined from the link test information; sending an http request from the current application service node to the next application service node through a curl command to obtain response message information of an http response from the current application service node to the next application service node; and determining whether the service state from the current application service node to the next application service node is normal or not according to the response message information.

The http request may include a set of field parameters related to a test request parameter, a minimum request of the test request parameter, and a legal request, which are necessary for testing the link, and the embodiment of the present application is not limited thereto.

The link connectivity from the current application service node to the next application service node can be tested in various ways. In one example, a port of a next application service node may be determined from the link test information; and testing the connectivity of the port through a telnet command to determine the link connectivity of the current application service node to the next application service node.

Taking the current application service node a as an example, the test request URL of the node is: and http:// ip _ node B: port _ node B/path _ node B, wherein the link test information comprises URL and port _ node B for accessing the next application service node from the current application service node. One method for performing link testing at node a is that the ci _ for _ jenkins.sh script at the node a contains: the http request is sent via a curl command, for example: curl-X POST http:// ip _ nodeB: port _ nodeB/path _ nodeB.

Sh script may also contain a connectivity test command for a port at node a, for example: telnet ip _ node B port _ node B. And storing the link test result to a network storage module.

It should be noted that, if the call chain relationship of node a → node B is tested, if the call fails, it is impossible to specifically locate which node a → node B → node C has an exception;

by analogy, a preset instruction ci _ for _ jenkins.sh script of jenkins can be similarly executed on the next application service node B, and the node B tests the call chain relation of node B → node C; if the calling fails, which node is node B → node C has abnormality cannot be specifically located;

by analogy, the preset instruction ci _ for _ jenkins.sh script of jenkins can be similarly executed in the next application service node C; this time node C tests node C as the last node in the request chain to execute the request to the last business logic associated with that node. If the call fails, a microservice exception on node C may be located.

For a call chain call interface with N application service nodes, link abnormal information can be completely acquired. For example, when it is diagnosed that a request URL http:// ip _ node B: port _ node B/path _ node B corresponding to an application service node a is abnormal, it can be obtained that a problem exists in a call link from node a to node B, but it cannot be located which node, specifically, node a- > node B- > node C, has an abnormality.

Further, after each application service node executes a preset link test script, the frontmost service node on the call chain corresponding to the request of the nginx server can be obtained; controlling the foremost service node to obtain link test results of all application service nodes of the call chain; controlling the foremost service node to perform aggregate analysis on the link test results of all the application service nodes to obtain full-link abnormal data; and controlling the foremost service node to output full-link abnormal data.

It should be understood that, the frontmost service node refers to the most upstream node of the call chain, taking the call chain corresponding to the request of the nginx server with four application service nodes, node a, node B, node C, and node D, the link delivery is node a → node B → node C → node D in sequence, the frontmost service node is node a, and the link test results of all application service nodes are four in total, which are: a link test result initiated by node D for application serving node D, a link test result initiated by node C for next application serving node D, a link test result initiated by node B for next application serving node C, and a link test result initiated by node a for next application serving node B. And the foremost service node A of the control link performs aggregation analysis on all the four link test results to obtain link abnormal data of the four links, and outputs the link abnormal data.

In specific implementation, the node a may aggregate the link abnormal data into a report and feed the report back to a manager, or may remind a research and development staff to perform diagnosis, positioning and analysis in a short message or email manner. Of course, the steps of aggregating and analyzing the link abnormal data and aggregating the link abnormal data into a report may also be completed in other application service nodes, and are not described herein again.

It should be noted that the link testing scheme in the embodiment of the present application has obvious advantages compared to the zipkin and skywalking link tracing scheme in the prior art. In the two schemes in the prior art, for the call chain with N application service nodes, the network state can be tested only at the front node of the N trace chains, and the states of the remaining N-1 chains cannot be determined. In the embodiment of the application, all link tests are performed on all the N nodes, that is, all links and all sub-links included in the links are counted into N links, exhaustive tracking and automatic link tests are performed, so that accurate all-link and sub-link tracking and summarizing reports can be obtained, and the link test efficiency is expanded and enhanced functionally.

According to the method and the device, complete link topology information is preset on the distributed N application service nodes, a full-automatic link test flow is triggered when a code is submitted, exhaustive tracing and automatic link testing are all performed on a full link and all contained sub-links through the preset link topology information to obtain an accurate full link and sub-link tracing summary report, and manual link test debugging and repeated verification work are greatly reduced; the link fault node is accurately and efficiently positioned in the exhaustive link state, the problem positioning of research personnel is facilitated, the usability of one-click type automatic diagnosis and testing of the abnormal link is greatly improved, and the link fault node is high in expandability, modular capability and convenience in large-scale commercial implementation.

Fig. 2 and 3 are flow diagrams of embodiments of methods for link testing. It should be understood that although the steps in the flowcharts of fig. 2 and 3 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2 and 3 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performing the sub-steps or stages is not necessarily sequential, but may be performed alternately or alternately with other steps or at least some of the sub-steps or stages of other steps.

Fig. 4 schematically shows a block diagram of an apparatus for link testing according to an embodiment of the present application. As shown in fig. 4, an embodiment of the present application provides an apparatus for link testing, which may include:

a memory 510 configured to store instructions; and

a processor 520 configured to call instructions from the memory 510 and when executing the instructions is capable of implementing the method for link testing described above.

Specifically, in the present embodiment, the processor 510 may be configured to:

determining a time subinterval where a user submits a code moment;

acquiring quality data of a code submitted by a user; obtaining a utility function value according to the state data, the quality data, the submission frequency and a preset test trigger utility function;

comparing the utility function value with a preset threshold value;

Further, processor 510 may also be configured to:

acquiring log data of the nginx server in a time subinterval;

and obtaining the request failure rate according to the status code.

Further, processor 510 may also be configured to:

acquiring a sub-time period of a code submitting moment of a user;

Further, processor 510 may also be configured to:

the number of triggers is determined as the commit frequency.

Further, processor 510 may also be configured to:

acquiring preset link topology information from a target version;

Further, processor 510 may also be configured to:

and controlling the foremost service node to output full-link abnormal data.

The embodiment of the application provides a machine-readable storage medium, wherein the machine-readable storage medium is stored with instructions for causing a machine to execute the method for the link test.

The embodiment of the application provides a processor, wherein the processor is used for running a program, and the method for testing the link is executed when the program runs.

Fig. 5 schematically shows an internal structure diagram of a computer device according to an embodiment of the present application. As shown in fig. 5, in the embodiment of the present application, a computer device is provided, and the computer device may be a server, and its internal structure diagram may be as shown in fig. 5. The computer apparatus includes a processor a01, a network interface a02, a display screen a04, an input device a05, and a memory (not shown in the figure) connected through a system bus. Wherein processor a01 of the computer device is used to provide computing and control capabilities. The memory of the computer device comprises an internal memory a03 and a non-volatile storage medium a 06. The nonvolatile storage medium a06 stores an operating system B01 and a computer program B02. The internal memory a03 provides an environment for the operation of the operating system B01 and the computer program B02 in the nonvolatile storage medium a 06. The network interface a02 of the computer device is used for communication with an external terminal through a network connection. The computer program when executed by the processor a01 is operative to implement a method for link testing. The display screen a04 of the computer device may be a liquid crystal display screen or an electronic ink display screen, and the input device a05 of the computer device may be a touch layer covered on the display screen, a button, a trackball or a touch pad arranged on a casing of the computer device, or an external keyboard, a touch pad or a mouse.

Those skilled in the art will appreciate that the architecture shown in fig. 5 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.

Computer-readable media, which include both non-transitory and non-transitory, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in the process, method, article, or apparatus that comprises the element.

The above are merely examples of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for link testing, comprising:

determining a time subinterval where a user submits a code moment;

acquiring state data of a request response message of the nginx server in the time subinterval;

acquiring quality data of the code submitted by the user;

comparing the utility function value with a preset threshold value;

and triggering a link test when the utility function value is greater than or equal to the preset threshold value.

2. The method of claim 1, wherein the status data comprises a request failure rate for sensitive transactions in a preset list of sensitive transactions, the method further comprising:

acquiring log data of the nginx server in the time subinterval;

cutting the log data to obtain a state code of the sensitive transaction in the preset sensitive transaction list;

and obtaining the request failure rate according to the state code.

3. The method of claim 2, wherein obtaining the request failure rate according to the status code comprises:

determining a quotient of the first number and the second number as the request failure rate.

4. The method of claim 1, wherein the quality data comprises submission and compilation of a successful weight coefficient, the method further comprising:

acquiring a sub-time period of a code submitting moment of a user;

obtaining a first submission and a compilation success rate of codes submitted by the user in the sub-time period;

acquiring the average value of the second submission and compiling success rate of the codes submitted by all users in the sub time period;

determining a quotient of the first commit and compile success rate and the mean as the commit and compile success weight coefficient.

5. The method of claim 1, further comprising:

acquiring the triggering times of triggering Jenkins pipeline compilation by the user submitting codes in the time subinterval;

and determining the triggering times as the submission frequencies.

6. The method of claim 2, wherein the predetermined test trigger utility function is:

7. The method of claim 1, wherein triggering the link test comprises:

acquiring preset link topology information and a version packet constructed by a Jenkins pipeline according to the codes;

8. The method of claim 7, wherein executing the predetermined link test script according to the target version comprises:

acquiring the preset link topology information from the target version;

acquiring link test information of the current application service node from the preset link topology information;

9. The method according to claim 8, wherein the executing a preset link test script based on the link test information to obtain a link test result of the current application service node comprises:

10. The method of claim 8, wherein the executing a preset link test script based on the link test information to obtain a link test result of the current application service node further comprises:

11. The method of claim 8, further comprising:

acquiring a frontmost service node on a call chain corresponding to the request of the nginx server;

and controlling the foremost service node to output the full link abnormal data.

12. An apparatus for link testing, comprising:

a memory configured to store instructions; and

a processor configured to invoke the instructions from the memory and to enable the method for link testing according to any one of claims 1 to 11 to be implemented when executing the instructions.

13. A machine-readable storage medium having stored thereon instructions for causing a machine to perform the method for link testing according to any one of claims 1 to 11.