CN110673973B - Exception determination method and device for application programming interface API - Google Patents

Abstract

The present invention provides an application programming interface API exception determination method and device. The method includes: obtaining the current request data of each API of the cloud platform from the log system, the request data being used to represent the number of times the corresponding API has been requested to be called; obtaining the historical request data of each API from the database; according to the The current request data and the historical request data are used to determine whether the corresponding API is abnormal. Compared with the existing technology that directly uses the number of times each API is called as the basis for abnormal analysis, the accuracy is improved.

Description

Exception determination method and device for application programming interface API

Technical field

The present invention relates to cloud platform technology, and in particular to an application programming interface API exception determination method and device.

Background technique

With the development of cloud technology, cloud products are becoming increasingly diversified. Current cloud products include cloud computing, cloud space and cloud platform. Compared with traditional servers, cloud platforms have the advantages of higher stability, more security and reliability, more convenient storage, and easier collaboration and sharing. The availability of online services provided by cloud platforms is essentially reflected in the availability of each segmented Application Programming Interface (API). Therefore, API monitoring plays a very important role in determining whether online services are running normally. Function, API monitoring can quickly detect online business problems, thereby providing valuable time to solve online business problems.

At present, after obtaining the number of times each API of the cloud platform has been called within a period of time, most business personnel directly use the number of times each API is called as the basis for judging whether the corresponding API is abnormal. However, the results obtained by this method are not precise.

Contents of the invention

The present invention provides an API abnormality determination method and device to solve the problem of low accuracy of API abnormality determination in the prior art.

In a first aspect, the present invention provides an API exception determination method, including:

Obtain the current request data of each API of the cloud platform from the log system, where the request data is used to represent the number of times the corresponding API has been requested to be called;

Obtain the historical request data of each API from the database;

Determine whether the corresponding API is abnormal based on the current request data and the historical request data.

Optionally, the current request data is request data in the current acquisition cycle, and the historical request data includes: request data in the target acquisition cycle before the current acquisition cycle;

Determine whether the corresponding API is abnormal based on the current request data and the historical request data, including:

Determine the count value corresponding to the target acquisition cycle according to the request data in the current acquisition cycle and the request data in the target acquisition cycle;

According to the count value, it is determined whether the corresponding API is abnormal.

Optionally, the target acquisition cycle includes: the acquisition cycle before the current acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle the previous day, and the acquisition cycle corresponding to the current acquisition cycle one week ago;

Correspondingly, the request data within the target acquisition cycle includes: the first request data within the previous acquisition cycle, the second request data within the acquisition cycle corresponding to the current acquisition cycle the day before, and the The third request data in the acquisition cycle corresponding to the current acquisition cycle in the previous week;

Correspondingly, determining the count value corresponding to the target acquisition period based on the request data in the current acquisition period and the request data in the target acquisition period includes:

Determine the first count value corresponding to the previous acquisition cycle according to the request data in the current acquisition cycle and the first request data;

According to the request data in the current acquisition cycle and the second request data, determine the second count value corresponding to the acquisition cycle corresponding to the current acquisition cycle on the previous day;

According to the request data in the current acquisition cycle and the third request data, determine the third count value corresponding to the acquisition cycle corresponding to the current acquisition cycle in the previous week;

Correspondingly, determining whether the corresponding API is abnormal based on the count value includes:

Calculate the sum of the first count value, the second count value and the third count value;

Based on the sum value, determine whether the corresponding API is abnormal.

Optionally, the current request data is request data within a preset time period, and the historical request data includes: target request data within the preset time period on the target date;

Determining whether the corresponding API is abnormal based on the current request data and the historical request data includes:

Determine the current ranking of each API based on the request data within the preset time period;

Determine the historical ranking of each API based on the target request data;

Determine the ranking changes of each API based on the current ranking and the historical ranking;

Based on the ranking changes of each API, determine whether the corresponding API is abnormal.

Optionally, the above methods also include:

The current ranking of each API and the ranking changes of each API are displayed through the configuration center.

Optionally, obtaining the current request data of each API of the cloud platform from the log system includes:

Obtain the original request data of each API of the cloud platform from the log system;

The original request data is aggregated and cleaned to obtain the current request data of each API.

Optionally, the above methods also include:

Persist the current request data of each API to the corresponding database.

In a second aspect, the present invention provides an API exception determination device, including:

The acquisition module is used to obtain the current request data of each API of the cloud platform from the log system, and the request data is used to represent the number of times the corresponding API has been requested to be called;

The acquisition module is also used to obtain the historical request data of each API from the database;

A determination module, configured to determine whether the corresponding API is abnormal based on the current request data and the historical request data.

Optionally, the current request data is request data in the current acquisition cycle, and the historical request data includes: request data in the target acquisition cycle before the current acquisition cycle;

Correspondingly, the determination module is specifically used for:

Determine the count value corresponding to the target acquisition cycle according to the request data in the current acquisition cycle and the request data in the target acquisition cycle;

According to the count value, it is determined whether the corresponding API is abnormal.

Optionally, the target acquisition cycle includes: the acquisition cycle before the current acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle the previous day, and the acquisition cycle corresponding to the current acquisition cycle one week ago;

Correspondingly, the request data within the target acquisition cycle includes: the first request data within the previous acquisition cycle, the second request data within the acquisition cycle corresponding to the current acquisition cycle the day before, and the The third request data in the acquisition cycle corresponding to the current acquisition cycle in the previous week;

Correspondingly, the determination module is specifically used for:

Determine the first count value corresponding to the previous acquisition cycle according to the request data in the current acquisition cycle and the first request data;

According to the request data in the current acquisition cycle and the second request data, determine the second count value corresponding to the acquisition cycle corresponding to the current acquisition cycle on the previous day;

According to the request data in the current acquisition cycle and the third request data, determine the third count value corresponding to the acquisition cycle corresponding to the current acquisition cycle in the previous week;

Calculate the sum of the first count value, the second count value and the third count value;

Based on the sum value, determine whether the corresponding API is abnormal.

Optionally, the current request data is request data within a preset time period, and the historical request data includes: target request data within the preset time period on the target date;

Correspondingly, the determination module is specifically used for:

Determine the current ranking of each API based on the request data within the preset time period;

Determine the historical ranking of each API based on the target request data;

Determine the ranking changes of each API based on the current ranking and the historical ranking;

Based on the ranking changes of each API, determine whether the corresponding API is abnormal.

Optional, the above devices also include:

The display module is used to display the current ranking of each API and the ranking changes of each API through the configuration center.

Optionally, the acquisition module is specifically used for:

Obtain the original request data of each API of the cloud platform from the log system;

The original request data is aggregated and cleaned to obtain the current request data of each API.

Optional, the above devices also include:

The persistence module is used to persist the current request data of each API to the corresponding database.

In a third aspect, the present invention provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned API exception determination method is implemented.

In a fourth aspect, the present invention provides a server, including:

processor; and

memory for storing executable instructions for the processor;

Wherein, the processor is configured to implement the exception determination method of the above-mentioned API by executing the executable instructions.

The API exception determination method and device provided by the present invention first obtain the current request data of each API of the cloud platform from the log system. The request data is used to represent the number of times the corresponding API has been requested to be called; then, obtain all the request data from the database. The historical request data of each API is described; finally, based on the current request data and the historical request data, it is determined whether the corresponding API is abnormal. Compared with the existing technology that directly uses the number of times each API is called as the basis for abnormal analysis, the accuracy is improved.

Description of the drawings

Figure 1 is an optional application scenario diagram of the API exception determination method provided by the present invention;

Figure 2 is a schematic flow chart of Embodiment 1 of the API exception determination method provided by the present invention;

Figure 3 is a schematic flow chart of Embodiment 2 of the API exception determination method provided by the present invention;

Figure 4 is a schematic flow chart of Embodiment 3 of the abnormal API locating method provided by the present invention;

Figure 5 is a schematic structural diagram of an API exception determination device provided by the present invention;

Figure 6 is a schematic diagram of the hardware structure of the server provided by the present invention.

Detailed ways

In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments These are some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present invention.

In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus that encompasses a series of steps or units and need not be limited to those explicitly listed. Those steps or elements may instead include other steps or elements not expressly listed or inherent to the process, method, product or apparatus.

The availability of online services provided by the cloud platform is essentially reflected in the availability of each segmented API. If an API on the cloud platform is abnormal, it may cause the related business to fail to operate normally. In the existing technology, after obtaining the number of times each API of the cloud platform is called within a period of time through API monitoring, the number of times each API is called is directly used as a basis for judging whether the corresponding API is abnormal. However, the results obtained in this way are not accurate.

Based on the above technical problems existing in the prior art, the present invention provides an application programming interface API exception determination method and device. First, the current request data of each API of the cloud platform is obtained from the log system. The request data is used to represent the number of times the corresponding API has been requested to be called; then, the historical request data of each API is obtained from the database; finally, according to the requested Describe the current request data and the historical request data to determine whether the corresponding API is abnormal. Compared with the existing technology where business personnel directly use the number of times each API is called as the basis for abnormal analysis, the accuracy is improved.

Figure 1 is an optional application scenario diagram of the API exception determination method provided by the present invention. The application scenario diagram shown in Figure 1 involves modules: log system, interface monitoring module, monitoring system and database. Optionally, these modules can be connected through wired or wireless technology, which is not limited by the present invention.

Among them, the interface monitoring module and the monitoring system can be used to implement the solution of the present invention. The interface monitoring module can be an independent module or a module belonging to the monitoring system. Figure 1 illustrates the monitoring module as an independent module. The following embodiments describe the solution of the present invention with the interface monitoring module being an independent module.

Among them, the log system can be used to record events that occur on the cloud platform. When each API is called, an event will be generated and recorded in the log system. The interface monitoring module can obtain the number of times each API is called within a certain period of time from the log system, that is, the request data of each API during this period of time.

Among them, the database can include time series database and relational database management system. The database stores historical request data for each API of the cloud platform. The interface monitoring module can obtain historical request data of each API from the database.

The technical solution of the present invention and how the technical solution of the present application solves the above technical problems will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will be described below with reference to the accompanying drawings.

FIG. 2 is a schematic flowchart of Embodiment 1 of the API exception determination method provided by the present invention. The API exception determination method provided in this embodiment can be executed by the interface monitoring module and monitoring system shown in Figure 1 . As shown in Figure 2, the API exception determination method provided by this embodiment includes:

S201. Obtain the current request data of each API of the cloud platform from the log system. The request data is used to represent the number of times the corresponding API is requested to be called.

The following are two scenarios to illustrate the meaning of the above current request data:

Scenario 1: The interface monitoring module periodically obtains the request data of each API from the log system. In this scenario, the request data within the current acquisition cycle is the current request data mentioned above.

For example: the interface monitoring module can obtain the request data of each API from the log system every 10 minutes. In this scenario, the request data of each API in the past 10 minutes obtained by the interface monitoring module from the log system is the current Request data.

Among them, the meaning of the request data is the number of times the corresponding API has been requested and called. In the above example, the request data of each API in the past 10 minutes represents the number of times each API has been requested and called in the past 10 minutes.

Scenario 2: The interface monitoring module can regularly obtain the request data of each API from the log system. In this scenario, the request data within the preset time period is the current request data mentioned above. The preset time period may be a time period corresponding to the peak usage period of the cloud platform.

For example: the interface monitoring module can regularly obtain the request data of each API in the past 30 minutes from the log system at 20:00 every day. In this scenario, the request data of each API in the past 30 minutes obtained by the interface monitoring module from the log system at 20:00 today is the current request data of each API.

As above, the meaning of the request data is the number of times the corresponding API has been requested and called. In the above example, the request data for each API within 30 minutes starting from 20:00 today represents the number of times each API has been requested and called within the 30 minutes.

Optionally, after obtaining the original request data of each API of the cloud platform from the log system, the original request data can be aggregated and cleaned to obtain the current request data of each API.

The above aggregation operation is implemented by merging the request data of APIs with the same function among all APIs of the cloud platform into one request data. The above APIs with the same functions are regarded as one API, and the combined request data is the request data of the API.

The above cleaning is implemented by discarding all APIs that cannot successfully match the preset matching rules.

S202. Obtain the historical request data of each API from the database.

Refer to S101. In scenario 1, the historical request data that the interface monitoring module needs to obtain from the database is: the request data in the target acquisition cycle before the current acquisition cycle. For example, the target cycle may be the acquisition cycle before the current acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle the previous day, the acquisition cycle corresponding to the current acquisition cycle one week ago, etc.

See the example corresponding to A101. Assume that the acquisition cycle is 10 minutes. Then the historical request data of each API obtained by the interface monitoring module from the database can be the previous 10 minutes, the 10 minutes of the same time period yesterday, or the 10 minutes of the same time period last week. Minutes to wait.

Referring to S101, in scenario two, the historical request data that the interface monitoring module needs to obtain from the database is the target request data within the preset time period in the target date. For example: request data in the same preset time period yesterday, request data in the same preset time period in the previous week, request data in the same preset time period in the previous two weeks, etc.

See the example corresponding to A101. Assume that the preset time period is within 30 minutes starting from 20:00, then the historical request data of each API obtained by the interface monitoring module from the database can be 20:00-20:30 yesterday, and 20:00 the previous week. 00-20:30 and 20:00-20:30 in the first two weeks, etc.

S203. Determine whether the corresponding API is abnormal based on the current request data and the historical request data.

Optionally, based on the current request data obtained by S101 and the historical request data obtained by S102, each API can be detected through anomaly detection algorithms and other methods to determine whether the corresponding API is abnormal, which facilitates operation and maintenance personnel to understand the interface flow. Ability to maintain control.

The API exception determination method provided in this embodiment first obtains the current request data of each API of the cloud platform from the log system. The request data is used to represent the number of times the corresponding API has been requested to be called; then, the request data is obtained from the database. Historical request data of each API; finally, determine whether the corresponding API is abnormal based on the current request data and the historical request data. Compared with the existing technology that directly uses the number of times each API is called as the basis for abnormal analysis, the accuracy is improved.

FIG. 3 is a schematic flowchart of Embodiment 2 of the API exception determination method provided by the present invention. This embodiment will describe the implementation method of determining whether the corresponding API is abnormal in the case of scenario 1 in the above embodiment. As shown in Figure 3, the API exception determination method provided by this embodiment includes:

S301. Obtain the request data of each API of the cloud platform in the current acquisition cycle from the log system.

Optionally, after obtaining the request data of each API in the current acquisition cycle, it can be persisted to the time series database.

S302. Obtain the request data of each API in the target acquisition cycle before the current acquisition cycle from the database.

S303. Determine the count value corresponding to the target acquisition cycle based on the request data in the current acquisition cycle and the request data in the target acquisition cycle.

In the following, the solution of this embodiment will be described by taking the target acquisition cycle including: the acquisition cycle before the current acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle the previous day, and the acquisition cycle corresponding to the current acquisition cycle one week ago as an example. illustrate.

In the case where the target acquisition cycle includes the above three acquisition cycles, the request data within the target acquisition cycle includes: the first request data in the previous acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle on the previous day The second request data within the previous week and the third request data within the acquisition cycle corresponding to the current acquisition cycle.

For convenience of description, the request data of the current acquisition cycle is recorded as QPS_CURRENT, the first request data is recorded as QPS_LASTSTEP, the second request data is recorded as QPS_LASTDAY, and the third request data is recorded as QPS_LASTWEEK.

Then S303 specifically includes the following steps:

Step A: Determine the first count value corresponding to the previous acquisition cycle based on the request data in the current acquisition cycle and the first request data.

Specifically, if (QPS_CURRENT-QPS_LASTSTEP)/QPS_LASTSTEP>1 or <-1, it means that the current acquisition cycle has changed more than double compared with the previous acquisition cycle. It is considered that compared with the previous acquisition cycle, the corresponding API exists. Abnormal, it can be determined that the first count value is 1.

Step B: Determine the second count value corresponding to the acquisition cycle corresponding to the current acquisition cycle on the previous day based on the request data and the second request data in the current acquisition cycle.

Specifically, if (QPS_CURRENT-QPS_LASTDAY)/QPS_LASTDAY>1 or <-1, it means that the current acquisition period and the previous day have changed more than double compared to the acquisition period corresponding to the current acquisition period, and it is considered that the current acquisition period and the previous day have changed Compared with the acquisition cycle corresponding to the current acquisition cycle, there is an abnormality in the corresponding API, and it can be determined that the second count value is 10.

Step C: Determine the third count value corresponding to the acquisition cycle corresponding to the current acquisition cycle in the previous week based on the request data in the current acquisition cycle and the third request data.

Specifically, if (QPS_CURRENT-QPS_LASTWEEK)/QPS_LASTWEEK>1 or <-1, it means that the current acquisition period and the previous week have changed by more than double the acquisition period corresponding to the current acquisition period, and it is considered that the current acquisition period and the previous week have changed Compared with the acquisition cycle corresponding to the current acquisition cycle, if there is an abnormality in the corresponding API, it can be determined that the third count value is 100.

S304. Determine whether the corresponding API is abnormal according to the count value.

Specifically, when the first count value, the second count value and the third count value are obtained from the above steps A to C, the following steps are used to determine whether the corresponding API is abnormal.

Step D. Calculate the sum of the first count value, the second count value and the third count value.

Step E: Determine whether there is an exception in the corresponding API based on the sum value.

Continue to refer to the above steps A to C. Whether the ones, tens and hundreds digits of the sum of the first count value, the second count value and the third count value are 1 indicates whether there is an abnormality in the API compared with the corresponding acquisition cycle. . For example, if the calculated sum value is 0, it means that there is no exception in the corresponding API; if the calculated sum value is 111, it means that the acquisition cycle corresponds to the previous acquisition cycle, the previous day and the current acquisition cycle. And compared with the acquisition cycle corresponding to the current acquisition cycle in the previous week, the corresponding API has abnormalities; if the calculated sum value is 110, it means that the acquisition cycle corresponding to the current acquisition cycle in the previous day, the previous week Compared with the acquisition cycle corresponding to the current acquisition cycle, the corresponding API has abnormalities, and compared with the previous acquisition cycle, there is no exception; if the calculated sum value is 101, it means that the corresponding API is different from the previous acquisition cycle. Compared with the acquisition cycle corresponding to the current acquisition cycle and the previous week, there are abnormalities in the corresponding API. Compared with the acquisition cycle corresponding to the current acquisition cycle the previous day, there is no abnormality.

Optionally, after obtaining the above-mentioned count value sum, the above-mentioned sum value can be reported to the monitoring system. The monitoring system further configures the alarm policy and sends the alarm information to the terminal of the business personnel.

The API exception determination method provided by this embodiment describes that when the current request data is the request data in the current acquisition cycle, and the historical request data includes the request data in the target acquisition cycle before the current acquisition cycle, it is determined whether the corresponding API The abnormal solution is described. Compared with the existing technology that directly uses the number of times each API is called as the basis for determining whether the API is abnormal, the accuracy of the judgment result is improved.

Figure 4 is a schematic flowchart of Embodiment 3 of the abnormal API locating method provided by the present invention. This embodiment will describe the implementation method of determining whether the corresponding API is abnormal in the second scenario in the above embodiment. As shown in Figure 4, the API exception determination method provided by this embodiment includes:

S401. Obtain the request data of each API of the cloud platform within the preset time period from the log system.

Optionally, after obtaining the request data of each API within a preset time period, it can be persisted to the relational database management system.

S402. Obtain the target request data of each API within the preset time period in the target date from the database.

S403. Determine the current ranking of each API based on the request data within the preset time period.

S404. Determine the historical ranking of each API based on the target request data.

S405. Determine the ranking change of each API based on the current ranking and the historical ranking.

S406. Determine whether the corresponding API is abnormal based on the ranking changes of each API.

Next, take the preset time period in S401 as 20:00-20:30 today, and the target date includes the previous day, one week ago, and two weeks ago as an example to explain the process of S403-S406:

Based on the request data of each API between 20:00-20:30 today, determine the current ranking of each API. Based on the request data of each API between 20:00-20:30 the previous day, determine the ranking of each API on the previous day. The request data of each API between 20:00-20:30 a week ago is used to determine the ranking of each API one week ago. Based on the request data of each API between 20:00-20:30 two weeks ago, the ranking of each API two weeks ago is determined. ranking. Compare the current ranking of each API with the previous day, one week ago, and two weeks ago. If the ranking changes are within the preset range, the corresponding API is considered to be normal. If the current ranking of each API is the same as the previous day, one week ago, Compared with two weeks ago, the change range exceeds the preset range, and it is considered that there is an abnormality in the corresponding API.

It should be noted that the analysis rule for whether an API exception occurs in the above example is only an example. Those skilled in the art can set other rules according to actual conditions. The present invention is not limited to the above example.

Optionally, after obtaining the above-mentioned current ranking and ranking changes, the current ranking and ranking changes can be displayed through the configuration center for business personnel to view. In addition, the configuration center can configure interface operations for flow control capabilities, allowing business personnel to perform corresponding operations on APIs with abnormal traffic based on the API's flow control capabilities, providing visual maintenance capabilities for fault management for business operation and maintenance.

The API exception determination method provided by this embodiment describes that the current request data is the request data within the preset time period, and the historical request data includes the target request data within the preset time period in the target date, determine the corresponding A solution for determining whether an API is abnormal is described. Compared with the existing technology that directly uses the number of times each API is called as a basis for determining whether an API is abnormal, the accuracy of the judgment result is improved.

Figure 5 is a schematic structural diagram of an API exception determination device provided by the present invention. As shown in Figure 5, the API exception determination device provided by the present invention includes:

The acquisition module 501 is used to obtain the current request data of each API of the cloud platform from the log system, where the request data is used to represent the number of times the corresponding API has been requested to be called;

The acquisition module 501 is also used to obtain the historical request data of each API from the database;

The determination module 502 is used to determine whether the corresponding API is abnormal based on the current request data and the historical request data.

Optionally, the current request data is request data in the current acquisition cycle, and the historical request data includes: request data in the target acquisition cycle before the current acquisition cycle;

Correspondingly, the determination module 502 is specifically used to:

Determine the count value corresponding to the target acquisition cycle according to the request data in the current acquisition cycle and the request data in the target acquisition cycle;

According to the count value, it is determined whether the corresponding API is abnormal.

Optionally, the target acquisition cycle includes: the acquisition cycle before the current acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle the previous day, and the acquisition cycle corresponding to the current acquisition cycle one week ago;

Correspondingly, the request data within the target acquisition cycle includes: the first request data within the previous acquisition cycle, the second request data within the acquisition cycle corresponding to the current acquisition cycle the day before, and the The third request data in the acquisition cycle corresponding to the current acquisition cycle in the previous week;

Correspondingly, the determination module 502 is specifically used to:

Determine the first count value corresponding to the previous acquisition cycle according to the request data in the current acquisition cycle and the first request data;

According to the request data in the current acquisition cycle and the second request data, determine the second count value corresponding to the acquisition cycle corresponding to the current acquisition cycle on the previous day;

According to the request data in the current acquisition cycle and the third request data, determine the third count value corresponding to the acquisition cycle corresponding to the current acquisition cycle in the previous week;

Calculate the sum of the first count value, the second count value and the third count value;

Based on the sum value, determine whether the corresponding API is abnormal.

Optionally, the current request data is request data within a preset time period, and the historical request data includes: target request data within the preset time period on the target date;

Correspondingly, the determination module 502 is specifically used to:

Determine the current ranking of each API based on the request data within the preset time period;

Determine the historical ranking of each API based on the target request data;

Determine the ranking changes of each API based on the current ranking and the historical ranking;

Based on the ranking changes of each API, determine whether the corresponding API is abnormal.

Optional, the above devices also include:

The display module 503 is used to display the current ranking of each API and the ranking changes of each API through the configuration center.

Optionally, the acquisition module 501 is specifically used to:

Obtain the original request data of each API of the cloud platform from the log system;

The original request data is aggregated and cleaned to obtain the current request data of each API.

Optional, the above devices also include:

The persistence module 504 is used to persist the current request data of each API into the corresponding database.

The API exception determination device provided in this embodiment can be used to perform the steps in any of the above method embodiments. The implementation principles and technical effects are similar and will not be described again here.

Figure 6 is a schematic diagram of the hardware structure of the server provided by the present invention. As shown in Figure 6, the server in this embodiment may include:

Memory 601 is used to store program instructions.

The processor 602 is configured to implement the API exception determination method described in any of the above embodiments when the program instructions are executed. For specific implementation principles, please refer to the above embodiments, and this embodiment will not be described again here.

The present invention provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the API exception determination method described in any of the above embodiments is implemented.

The present invention also provides a program product. The program product includes a computer program. The computer program is stored in a readable storage medium. At least one processor can read the computer program from the readable storage medium. At least one processor executes the computer program to cause the server to implement the API exception determination method described in any of the above embodiments.

In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional units.

The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium and includes a number of instructions to cause a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to execute the various embodiments of the present invention. Some steps of the method. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (English: Read-Only Memory, abbreviation: ROM), random access memory (English: Random Access Memory, abbreviation: RAM), magnetic disk or optical disk, etc. Various media that can store program code.

It should be understood that the processor described in the present invention can be a central processing unit (English: Central Processing Unit, referred to as: CPU), or other general-purpose processor, digital signal processor (English: Digital SignalProcessor, referred to as: DSP), special-purpose processor Integrated circuit (English: Application Specific IntegratedCircuit, abbreviation: ASIC), etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. The steps of the method disclosed in this application can be directly implemented by a hardware processor, or executed by a combination of hardware and software modules in the processor.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention, but not to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions described in the foregoing embodiments can still be modified, or some or all of the technical features can be equivalently replaced; and these modifications or substitutions do not deviate from the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present invention. scope.

Claims (7)

1. An anomaly determination method for an API, comprising:

acquiring current request data of each API of the cloud platform from a log system, wherein the request data is used for representing the number of times that the corresponding API is requested to be called;

acquiring historical request data of each API from a database;

when the current request data is request data in a current acquisition period, the historical request data comprises: when the request data in the target acquisition period is before the current acquisition period, the target acquisition period comprises: the method comprises the steps of obtaining a previous obtaining period of a current obtaining period, obtaining a previous day of the obtaining period corresponding to the current obtaining period and obtaining a previous week of the obtaining period corresponding to the current obtaining period; correspondingly, the request data in the target acquisition period comprises: the first request data in the previous acquisition period, the second request data in the acquisition period corresponding to the current acquisition period on the previous day, and the third request data in the acquisition period corresponding to the current acquisition period on the previous week;

determining a first count value corresponding to the previous acquisition period according to the ratio of the difference value between the request data in the current acquisition period and the first request data to the first request data, wherein the first count value is used for representing the relation between the change amplitude of the request data in the current acquisition period compared with the first request data in the previous acquisition period;

determining a second count value corresponding to an acquisition period corresponding to the current acquisition period on the previous day according to the ratio of the difference value between the request data and the second request data in the current acquisition period to the second request data, wherein the second count value is used for representing the relation between the change amplitude of the request data of the current acquisition period compared with the change amplitude of the second request data;

determining a third count value corresponding to an acquisition period corresponding to the current acquisition period in the previous week according to the ratio of the difference value between the request data in the current acquisition period and the third request data to the third request data, wherein the third count value is used for representing the relation between the change amplitude of the request data of the current acquisition period compared with the third request data;

calculating a sum of the first count value, the second count value, and the third count value;

judging whether the units, tens and hundreds of bits of the sum are 1, and determining whether the corresponding API is abnormal;

when the current request data is the request data in a preset time period, the preset time period is a time period corresponding to a peak period of use of the cloud platform; the history request data includes: when the target request data in the preset time period in the target date is received;

determining the current ranking of each API according to the request data in the preset time period;

determining the historical ranking of each API according to the target request data;

determining ranking changes of all APIs according to the current ranking and the historical ranking;

and determining whether the corresponding API is abnormal according to the ranking change of each API.

2. The method as recited in claim 1, further comprising:

the current ranking of each API is displayed through the configuration center, and the ranking of each API changes.

3. The method according to claim 1 or 2, wherein the obtaining, from the log system, current request data of each API of the cloud platform includes:

acquiring original request data of each API of a cloud platform from the log system;

and aggregating and cleaning the original request data to obtain the current request data of each API.

4. A method according to claim 3, further comprising:

the current request data of each API is persisted to the corresponding database.

5. An abnormality determining apparatus for an API, comprising:

the acquisition module is used for acquiring current request data of each API of the cloud platform from the log system, wherein the request data is used for representing the number of times that the corresponding API is requested to be called;

the acquisition module is further used for acquiring historical request data of each API from a database;

the current request data is request data in a current acquisition period, and the historical request data comprises: request data in a target acquisition period before the current acquisition period; the target acquisition period includes: the method comprises the steps of obtaining a previous obtaining period of a current obtaining period, obtaining a previous day of the obtaining period corresponding to the current obtaining period and obtaining a previous week of the obtaining period corresponding to the current obtaining period; correspondingly, the request data in the target acquisition period comprises: the first request data in the previous acquisition period, the second request data in the acquisition period corresponding to the current acquisition period on the previous day, and the third request data in the acquisition period corresponding to the current acquisition period on the previous week;

a determining module, configured to determine a first count value corresponding to the previous acquisition period according to a ratio of a difference value between the request data in the current acquisition period and the first request data to the first request data, where the first count value is used to represent a relationship between a change amplitude of the request data in the current acquisition period compared with the first request data in the previous acquisition period;

determining a second count value corresponding to an acquisition period corresponding to the current acquisition period on the previous day according to the ratio of the difference value between the request data and the second request data in the current acquisition period to the second request data, wherein the second count value is used for representing the relation between the change amplitude of the request data of the current acquisition period compared with the change amplitude of the second request data;

determining a third count value corresponding to an acquisition period corresponding to the current acquisition period in the previous week according to the ratio of the difference value between the request data in the current acquisition period and the third request data to the third request data, wherein the third count value is used for representing the relation between the change amplitude of the request data of the current acquisition period compared with the third request data;

calculating a sum of the first count value, the second count value, and the third count value;

judging whether the units, tens and hundreds of bits of the sum are 1, and determining whether the corresponding API is abnormal;

the current request data is request data in a preset time period, and the historical request data comprises: target request data in the preset time period in the target date;

the determining module is used for determining the current ranking of each API according to the request data in the preset time period;

determining the historical ranking of each API according to the target request data;

determining ranking changes of all APIs according to the current ranking and the historical ranking;

and determining whether the corresponding API is abnormal according to the ranking change of each API.

6. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any of claims 1-4.

7. A server, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to implement the method of any of claims 1-4 via execution of the executable instructions.