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

Abnormality determination method and device for application programming interface API Download PDF

Info

Publication number
CN110673973B
CN110673973B CN201910927838.8A CN201910927838A CN110673973B CN 110673973 B CN110673973 B CN 110673973B CN 201910927838 A CN201910927838 A CN 201910927838A CN 110673973 B CN110673973 B CN 110673973B
Authority
CN
China
Prior art keywords
request data
api
current
acquisition period
period
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910927838.8A
Other languages
Chinese (zh)
Other versions
CN110673973A (en
Inventor
颜文
王鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Juhaokan Technology Co Ltd
Original Assignee
Juhaokan Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Juhaokan Technology Co Ltd filed Critical Juhaokan Technology Co Ltd
Priority to CN201910927838.8A priority Critical patent/CN110673973B/en
Publication of CN110673973A publication Critical patent/CN110673973A/en
Application granted granted Critical
Publication of CN110673973B publication Critical patent/CN110673973B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/008—Reliability or availability analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention provides an abnormality determination method and device for an Application Programming Interface (API). The method comprises the following steps: 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; and determining whether the corresponding API is abnormal according to the current request data and the historical request data. Compared with the prior art, the method has the advantages that the number of times that each API is called is directly used as the basis of exception analysis, and accuracy is improved.

Description

Abnormality determination method and device for application programming interface API
Technical Field
The present invention relates to cloud platform technologies, and in particular, to a method and apparatus for determining abnormality of an API.
Background
With development of cloud technology, cloud products are becoming diversified, and the types of the current cloud products include cloud computing, cloud space and cloud platforms. Compared with the traditional server, the cloud platform has the advantages of higher stability, higher safety and reliability, more convenient storage, easier collaboration and sharing and the like. The availability of the online service provided by the cloud platform is essentially reflected on the availability of each subdivided application programming interface (Application Programming Interface, abbreviated as API), so that the API monitoring plays a very important role in judging whether the online service operates normally or not, and online service problems can be rapidly discovered through the API monitoring, so that precious time is provided for solving the online service problems.
At present, after obtaining the number of times that each API of the cloud platform is called in a period of time, most business personnel directly use the number of times that each API is called as a basis for judging whether the corresponding API is abnormal, however, the result obtained by the method is inaccurate.
Disclosure of Invention
The invention provides an API abnormality determination method and device, which are used for solving the problem of low API abnormality judgment accuracy in the prior art.
In a first aspect, the present invention provides an abnormality determining method for an API, including:
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;
and determining whether the corresponding API is abnormal according to the current request data and the historical request data.
Optionally, the current request data is request data in a current acquisition period, and the historical request data includes: request data in a target acquisition period before the current acquisition period;
determining whether the corresponding API is abnormal according to the current request data and the historical request data, including:
determining a count value corresponding to the target acquisition period according to the request data in the current acquisition period and the request data in the target acquisition period;
and determining whether the corresponding API is abnormal according to the count value.
Optionally, 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;
correspondingly, the determining the count value corresponding to the target acquisition period according to the request data in the current acquisition period and the request data in the target acquisition period includes:
determining a first count value corresponding to the previous acquisition period according to the request data in the current acquisition period and the first request data;
determining a second count value corresponding to an acquisition period corresponding to the current acquisition period on the previous day according to the request data and the second request data in the current acquisition period;
according to the request data and the third request data in the current acquisition period, determining a third count value corresponding to the acquisition period corresponding to the current acquisition period in the previous week;
correspondingly, the determining whether the corresponding API is abnormal according to the count value includes:
calculating a sum of the first count value, the second count value, and the third count value;
and determining whether the corresponding API is abnormal according to the sum value.
Optionally, the current request data is request data in a preset time period, and the historical request data includes: target request data in the preset time period in the target date;
the determining whether the corresponding API is abnormal according to the current request data and the historical request data includes:
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.
Optionally, the method further comprises:
the current ranking of each API is displayed through the configuration center, and the ranking of each API changes.
Optionally, 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.
Optionally, the method further comprises:
the current request data of each API is persisted to the corresponding database.
In a second aspect, the present invention provides an abnormality determining apparatus of an API, including:
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;
and the determining module is used for determining whether the corresponding API is abnormal according to the current request data and the historical request data.
Optionally, the current request data is request data in a current acquisition period, and the historical request data includes: request data in a target acquisition period before the current acquisition period;
correspondingly, the determining module is specifically configured to:
determining a count value corresponding to the target acquisition period according to the request data in the current acquisition period and the request data in the target acquisition period;
and determining whether the corresponding API is abnormal according to the count value.
Optionally, 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;
correspondingly, the determining module is specifically configured to:
determining a first count value corresponding to the previous acquisition period according to the request data in the current acquisition period and the first request data;
determining a second count value corresponding to an acquisition period corresponding to the current acquisition period on the previous day according to the request data and the second request data in the current acquisition period;
according to the request data and the third request data in the current acquisition period, determining a third count value corresponding to the acquisition period corresponding to the current acquisition period in the previous week;
calculating a sum of the first count value, the second count value, and the third count value;
and determining whether the corresponding API is abnormal according to the sum value.
Optionally, the current request data is request data in a preset time period, and the historical request data includes: target request data in the preset time period in the target date;
correspondingly, the determining module is specifically configured to:
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.
Optionally, the device further includes:
and the display module is used for displaying the current ranking of each API and the ranking change of each API through the configuration center.
Optionally, the acquiring module is specifically configured to:
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.
Optionally, the device further includes:
and the persistence module is used for persisting the current request data of each API into the corresponding database.
In a third aspect, the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the abnormality determination method of the API described above.
In a fourth aspect, the present invention provides a server comprising:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to implement the exception determination method of the API described above via execution of the executable instructions.
According to the method and the device for determining the abnormality of the APIs, the current request data of each API of the cloud platform is firstly obtained from the log system, and the request data is used for representing the number of times that the corresponding API is requested to be called; then, historical request data of each API is obtained from a database; and finally, determining whether the corresponding API is abnormal according to the current request data and the historical request data. Compared with the prior art, the method has the advantages that the number of times that each API is called is directly used as the basis of exception analysis, and accuracy is improved.
Drawings
FIG. 1 is an optional application scenario diagram of an anomaly determination method for an API provided by the present invention;
FIG. 2 is a flowchart of a first embodiment of an abnormality determination method for an API according to the present invention;
FIG. 3 is a flowchart illustrating a second embodiment of an abnormality determination method for an API according to the present invention;
FIG. 4 is a flowchart illustrating a third embodiment of a method for locating an exception API according to the present invention;
FIG. 5 is a schematic diagram of an abnormality determining apparatus of an API provided by the present invention;
fig. 6 is a schematic hardware structure of a server according to the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
The availability of online services provided by the cloud platform is essentially reflected in the availability of each subdivided API, and if the cloud platform has an abnormality in the APIs, the related services may not operate normally. In the prior art, after the number of times that each API of the cloud platform is called in a period of time is obtained through API monitoring, the number of times that each API is called is directly used as a basis for judging whether the corresponding API is abnormal, however, the obtained result is inaccurate.
Based on the technical problems in the prior art, the invention provides an abnormality determination method and device for an API. Firstly, current request data of each API of a cloud platform is obtained 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; then, historical request data of each API is obtained from a database; and finally, determining whether the corresponding API is abnormal according to the current request data and the historical request data. Compared with the prior art, the method has the advantages that the service personnel directly uses the called times of all APIs as the basis of anomaly analysis, and the accuracy is improved.
Fig. 1 is an optional application scenario diagram of an abnormality determination method of an API provided by the present invention. The modules involved in the application scenario diagram shown in fig. 1 are: the system comprises a log system, an interface monitoring module, a monitoring system and a database. Alternatively, the several modules may be connected by wired or wireless technology, as the invention is not limited in this regard.
The interface monitoring module and the monitoring system can be used for executing the scheme of the invention, and the interface monitoring module can be an independent module or a module belonging to the monitoring system, and the monitoring module is shown as an independent module in fig. 1. The following embodiments describe the solution of the present invention with the interface monitoring module as a separate module.
The log system can be used for recording events occurring on the cloud platform. When each API is called, an event record is generated in the log system. The interface monitoring module may obtain the number of times each API is called in a certain period of time, that is, the request data of each API in the certain period of time, from the log system.
The database may include a time series database and a relational database management system, among others. The database stores historical request data of various APIs of the cloud platform. The interface monitoring module may obtain historical request data for each API from the database.
The following describes the technical scheme of the present invention and how the technical scheme of the present application solves the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present invention will be described below with reference to the accompanying drawings.
Fig. 2 is a flowchart of a first embodiment of an abnormality determining method of an API according to the present invention. The method for determining the abnormality of the API provided in this embodiment may be performed by the interface monitoring module and the monitoring system shown in fig. 1. As shown in fig. 2, the method for determining abnormality of an API provided in this embodiment includes:
s201, current request data of each API of the cloud platform is obtained 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 meaning of the above-described current request data is described in two scenarios:
in a first scenario, the interface monitoring module periodically obtains the request data of each API from the log system. In this scenario, the request data in the current acquisition period is the current request data.
Such as: the interface monitoring module can acquire the request data of each API from the log system every 10 minutes, and in this scenario, the request data of each API in the past 10 minutes acquired from the log system by the interface monitoring module is the current request data.
The meaning of the request data is the number of times the corresponding API is called, in the above example, the request data of each API in the past 10 minutes indicates the number of times each API is called in the past 10 minutes.
In a second scenario, the interface monitoring module may periodically obtain the request data of each API from the log system. In this scenario, the request data in the preset time period is the current request data. The preset time period may be a time period corresponding to a peak period of use of the cloud platform.
Such as: the interface monitor module may obtain the request data for each API from the log system at 20:00 times per day over the past 30 minutes. In this scenario, the request data of each API in the last 30 minutes acquired by the interface monitoring module from the log system at 20:00 this day is the current request data of each API.
As above, the meaning of the request data is the number of times the corresponding API is requested to be called, and in the above example, the request data within 30 minutes from 20:00 of the present day indicates the number of times the respective API is requested to be called within the 30 minutes.
Optionally, after the original request data of each API of the cloud platform is obtained from the log system, the original request data may be aggregated and cleaned, so as to obtain the current request data of each API.
The implementation mode of the aggregation operation is that the request data of the APIs with the same function in all APIs of the cloud platform are combined into one request data. The APIs with the same functions are regarded as one API, and the combined request data is the request data of the API.
The cleaning implementation mode is that the APIs which cannot be successfully matched with the preset matching rules in all APIs are discarded.
S202, acquiring historical request data of each API from a database.
Referring to S101, in the case of scenario one, the history request data that the interface monitoring module needs to acquire from the database is: the request data in the target acquisition period precedes the current acquisition period. Such as: the target period may be a previous acquisition period of the current acquisition period, an acquisition period of a previous day corresponding to the current acquisition period, an acquisition period of a previous week corresponding to the current acquisition period, or the like.
Referring to the example corresponding to a101, assuming that the acquisition period is 10 minutes, the history request data of each API acquired by the interface monitoring module from the database may be 10 minutes before, 10 minutes of the same time period of yesterday, 10 minutes of the same time period of the previous week, or the like.
Referring to S101, in the case of scenario two, the history request data to be acquired by the interface monitoring module from the database is target request data within the preset time period in the target date. Such as: request data in the same preset time period as yesterday, request data in the same preset time period as the previous week, request data in the same preset time period as the previous two weeks, and the like.
Referring to the example corresponding to a101, assuming that the preset time period is within 30 minutes from 20:00, the historical request data of each API obtained by the interface monitoring module from the database may be 20:00-20:30 yesterday, 20:00-20:30 in the previous week, 20:00-20:30 in the previous two weeks, and so on.
S203, determining whether the corresponding API is abnormal according to the current request data and the historical request data.
Optionally, on the basis that the current request data is acquired in S101 and the history request data is acquired in S102, each API can be detected by an anomaly detection algorithm or the like, so as to determine whether the corresponding API is anomalous, and maintenance of the interface flow control capability by operation and maintenance personnel is facilitated.
According to the method for determining the abnormality of the APIs, firstly, current request data of each API of the cloud platform is obtained 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; then, historical request data of each API is obtained from a database; and finally, determining whether the corresponding API is abnormal according to the current request data and the historical request data. Compared with the prior art, the method has the advantages that the number of times that each API is called is directly used as the basis of exception analysis, and accuracy is improved.
Fig. 3 is a flowchart illustrating a second embodiment of an abnormality determining method of an API according to the present invention. The present embodiment will explain an implementation manner of determining whether the corresponding API is abnormal in the case of scenario one in the above embodiment. As shown in fig. 3, the method for determining abnormality of an API provided in this embodiment includes:
s301, acquiring request data of each API of the cloud platform in a current acquisition period from a log system.
Alternatively, the request data of each API in the current acquisition period can be persisted to the time sequence database after being acquired.
S302, acquiring request data of each API in a target acquisition period before the current acquisition period from a database.
S303, determining a count value corresponding to the target acquisition period according to the request data in the current acquisition period and the request data in the target acquisition period.
Next, the target acquisition period includes: the scheme of the present embodiment is described by taking, as an example, an acquisition period immediately preceding the current acquisition period, and an acquisition period immediately preceding the week and corresponding to the current acquisition period.
In the case where the target acquisition period includes the above three acquisition periods, the request data in the target acquisition period includes: 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.
For convenience of description, the request data of the CURRENT acquisition cycle is denoted as qps_current, the first request data is denoted as qps_laststart, the second request data is denoted as qps_lastdata, and the third request data is denoted as qps_lastdata.
S303 specifically includes the following steps:
step A: and determining a first count value corresponding to the previous acquisition period according to the request data in the current acquisition period and the first request data.
Specifically, if (qps_current-qps_lastsetep)/qps_lastsetep >1 or < -1, which indicates that the change amplitude of the CURRENT acquisition period is more than doubled compared with the previous acquisition period, it is considered that the CURRENT acquisition period is abnormal compared with the previous acquisition period, and the first count value can be determined to be 1.
And B, determining a second count value corresponding to the acquisition period corresponding to the current acquisition period on the previous day according to the request data and the second request data in the current acquisition period.
Specifically, if (qps_current-qps_lastday)/qps_lastday >1 or < -1, which indicates that the change amplitude of the CURRENT acquisition period and the acquisition period corresponding to the CURRENT acquisition period on the previous day is more than doubled, it is considered that the corresponding API is abnormal in the CURRENT acquisition period and the acquisition period corresponding to the CURRENT acquisition period on the previous day, and the second count value may be determined to be 10.
And C, determining a third count value corresponding to the acquisition period corresponding to the current acquisition period in the previous week according to the request data and the third request data in the current acquisition period.
Specifically, if (qps_current-qps_lastspace)/qps_lastspace >1 or < -1, which indicates that the CURRENT acquisition period and the acquisition period corresponding to the CURRENT acquisition period have a more than doubled variation width than the previous week, it is considered that the CURRENT acquisition period and the previous week have an abnormality in the corresponding API than the acquisition period corresponding to the CURRENT acquisition period, the third count value may be determined to be 100.
S304, determining whether the corresponding API is abnormal according to the count value.
Specifically, in the case that the first count value, the second count value, and the third count value are obtained in the above steps a to C, it is determined whether the corresponding API is abnormal through the following steps.
And D, calculating the sum of the first count value, the second count value and the third count value.
And E, determining whether the corresponding API has abnormality according to the sum value.
With continued reference to steps a-C above, whether the bits, tens, and hundreds of the sum of the first count value, the second count value, and the third count value are 1 characterizes whether the API is anomalous as compared to the corresponding acquisition period. For example, if the calculated sum is 0, it is indicated that there is no exception to the corresponding API; if the calculated sum is 111, it is indicated that the corresponding API has an abnormality in comparison with the previous acquisition period, the acquisition period corresponding to the current acquisition period on the previous day, and the acquisition period corresponding to the current acquisition period on the previous week; if the calculated sum is 110, the acquisition period corresponding to the current acquisition period on the previous day is illustrated, the corresponding APIs have abnormality compared with the acquisition period corresponding to the current acquisition period on the previous week, and no abnormality exists compared with the previous acquisition period; if the calculated sum is 101, it is indicated that the corresponding API has an abnormality compared with the previous acquisition period and the acquisition period corresponding to the current acquisition period in the previous week, and no abnormality compared with the acquisition period corresponding to the current acquisition period in the previous day.
Optionally, after obtaining the sum of the count values, the sum may be reported to a monitoring system, and the monitoring system further configures an alarm policy and sends the alarm information to a terminal of a service person.
According to the API abnormality determination method provided by the embodiment, the description is given that the current request data is the request data in the current acquisition period, and when the history request data comprises the request data in the target acquisition period before the current acquisition period, the description is given on the scheme of determining whether the corresponding API is abnormal, and compared with the prior art that the number of times that each API is called is directly used as the basis for determining whether the API is abnormal, the accuracy of the judgment result is improved.
Fig. 4 is a flowchart of a third embodiment of a method for locating an abnormal API according to the present invention. The present embodiment will explain an implementation manner of determining whether the corresponding API is abnormal in the case of scenario two in the above embodiment. As shown in fig. 4, the method for determining abnormality of an API provided in this embodiment includes:
s401, acquiring request data of each API of the cloud platform in a preset time period from a log system.
Alternatively, after the request data of each API in the preset period is obtained, the request data may be persisted to the relational database management system.
S402, acquiring target request data of each API in the preset time period in the target date from a database.
S403, determining the current ranking of each API according to the request data in the preset time period.
S404, according to the target request data, determining the historical ranking of each API.
S405, determining ranking changes of all APIs according to the current ranking and the historical ranking.
S406, determining whether the corresponding API is abnormal according to ranking change of each API.
Next, taking the preset time period in S401 as the present day 20:00-20:30, the procedure of S403 to S406 will be described by taking the example that the target date includes the previous day, one week ago, and two weeks ago:
according to the current day 20:00-20:30, determining a current ranking of each API according to the previous day 20:00-20:30, determining the ranking of each API on the previous day according to the previous 20:00-20 of the week: 30, determining the ranking of each API before one week according to the 20:00-20 before two weeks: 30, determines the ranking of each API two weeks ago. Comparing the current ranking of each API with the previous day, the previous week and the previous two weeks, if the ranking change amplitude is within the preset range, the corresponding API is considered to be not abnormal, and if the current ranking of each API is compared with the previous day, the previous week and the previous two weeks, the change amplitude is more than the preset range, the corresponding API is considered to be abnormal.
It should be noted that: the analysis rule for whether the API is abnormal in the above example is merely an example, and a person skilled in the art may set other rules according to the actual situation, and the present invention is not limited to the above example.
Optionally, after the current ranking and the ranking change are obtained, the current ranking and the ranking change can be displayed through the configuration center for the service personnel to check. In addition, the configuration center can configure the interface operation of the flow control capability, so that service personnel can perform corresponding operation on the API with abnormal flow according to the flow control capability of the API, and the visual maintenance capability of fault management is provided for service operation and maintenance.
According to the API abnormality determination method provided by the embodiment, the description is made that the current request data is the request data in the preset time period, and when the history request data comprises the target request data in the preset time period in the target date, whether the corresponding API is abnormal or not is determined, and compared with the fact that the number of times that each API is called is directly used as the basis for determining whether the API is abnormal or not in the prior art, the accuracy of a judgment result is improved.
Fig. 5 is a schematic structural diagram of an abnormality determining apparatus for an API according to the present invention. As shown in fig. 5, the abnormality determining apparatus for an API provided by the present invention includes:
an obtaining module 501, configured to obtain, from a log system, current request data of each API of the cloud platform, where the request data is used to indicate a number of times that a corresponding API is requested to be called;
the obtaining module 501 is further configured to obtain, from a database, historical request data of each API;
a determining module 502, configured to determine whether the corresponding API is abnormal according to the current request data and the historical request data.
Optionally, the current request data is request data in a current acquisition period, and the historical request data includes: request data in a target acquisition period before the current acquisition period;
accordingly, the determining module 502 is specifically configured to:
determining a count value corresponding to the target acquisition period according to the request data in the current acquisition period and the request data in the target acquisition period;
and determining whether the corresponding API is abnormal according to the count value.
Optionally, 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;
accordingly, the determining module 502 is specifically configured to:
determining a first count value corresponding to the previous acquisition period according to the request data in the current acquisition period and the first request data;
determining a second count value corresponding to an acquisition period corresponding to the current acquisition period on the previous day according to the request data and the second request data in the current acquisition period;
according to the request data and the third request data in the current acquisition period, determining a third count value corresponding to the acquisition period corresponding to the current acquisition period in the previous week;
calculating a sum of the first count value, the second count value, and the third count value;
and determining whether the corresponding API is abnormal according to the sum value.
Optionally, the current request data is request data in a preset time period, and the historical request data includes: target request data in the preset time period in the target date;
accordingly, the determining module 502 is specifically configured to:
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.
Optionally, the device further includes:
a display module 503, configured to display, through a configuration center, a current ranking of each API and a ranking change of each API.
Optionally, the obtaining module 501 is specifically configured to:
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.
Optionally, the device further includes:
a persistence module 504, configured to persistence the current request data of each API into a corresponding database.
The abnormality determining device of the API provided in this embodiment may be used to execute the steps in any of the above method embodiments, and its implementation principle and technical effects are similar, and will not be described herein.
Fig. 6 is a schematic hardware structure of a server according to the present invention. As shown in fig. 6, the server of the present embodiment may include:
a memory 601 for storing program instructions.
The processor 602 is configured to implement the method for determining an abnormality of the API described in any of the foregoing embodiments when the program instructions are executed, and the specific implementation principle may be referred to the foregoing embodiments, which are not described herein again.
The present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the abnormality determination method of the API described in any of the above embodiments.
The present invention also provides a program product comprising a computer program stored in a readable storage medium, from which at least one processor can read, the at least one processor executing the computer program causing a server to implement the abnormality determination method of the API described in any one of the embodiments above.
In the several embodiments provided by the present invention, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in hardware plus software functional units.
The integrated units implemented in the form of software functional units described above may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (english: processor) to perform some of the steps of the methods according to the embodiments of the invention. And the aforementioned storage medium includes: u disk, mobile hard disk, read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk, etc.
It should be understood that the processor described in the present invention may be a central processing unit (english: central Processing Unit, abbreviated as CPU), other general purpose processors, digital signal processors (english: digital Signal Processor, abbreviated as DSP), application specific integrated circuits (english: application Specific Integrated Circuit, abbreviated as ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present application may be embodied directly in a hardware processor or in a combination of hardware and software modules within a processor.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the invention.

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.
CN201910927838.8A 2019-09-27 2019-09-27 Abnormality determination method and device for application programming interface API Active CN110673973B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910927838.8A CN110673973B (en) 2019-09-27 2019-09-27 Abnormality determination method and device for application programming interface API

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910927838.8A CN110673973B (en) 2019-09-27 2019-09-27 Abnormality determination method and device for application programming interface API

Publications (2)

Publication Number Publication Date
CN110673973A CN110673973A (en) 2020-01-10
CN110673973B true CN110673973B (en) 2024-02-13

Family

ID=69079886

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910927838.8A Active CN110673973B (en) 2019-09-27 2019-09-27 Abnormality determination method and device for application programming interface API

Country Status (1)

Country Link
CN (1) CN110673973B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112527601A (en) * 2020-12-17 2021-03-19 航天信息股份有限公司 Monitoring early warning method and device
CN117519670B (en) * 2023-12-25 2024-04-09 杭银消费金融股份有限公司 Method and system for automatically generating RPC (remote procedure control) codes

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109933508A (en) * 2019-03-25 2019-06-25 北京百度网讯科技有限公司 Method and apparatus for sending information

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6617617B2 (en) * 2016-03-10 2019-12-11 富士通株式会社 Management device, management program, and management method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109933508A (en) * 2019-03-25 2019-06-25 北京百度网讯科技有限公司 Method and apparatus for sending information

Also Published As

Publication number Publication date
CN110673973A (en) 2020-01-10

Similar Documents

Publication Publication Date Title
US10216560B2 (en) Integration based anomaly detection service
US8352867B2 (en) Predictive monitoring dashboard
CN111178760B (en) Risk monitoring method, risk monitoring device, terminal equipment and computer readable storage medium
CN106548402B (en) Resource transfer monitoring method and device
CN110471821B (en) Abnormality change detection method, server, and computer-readable storage medium
CN113824768B (en) Health check method and device in load balancing system and flow forwarding method
US8631280B2 (en) Method of measuring and diagnosing misbehaviors of software components and resources
WO2015136624A1 (en) Application performance monitoring method and device
CN108696368B (en) Network element health state detection method and equipment
US20160224400A1 (en) Automatic root cause analysis for distributed business transaction
CN110362455B (en) Data processing method and data processing device
CN110673973B (en) Abnormality determination method and device for application programming interface API
CN108492150B (en) Method and system for determining entity heat degree
CN109992473A (en) Monitoring method, device, equipment and the storage medium of application system
US11032627B2 (en) Maintenance device, presentation system, and program
CN109617750A (en) A kind of service method for early warning and gateway
US11113364B2 (en) Time series data analysis control method and analysis control device
CN113159463A (en) Traffic monitoring method and device
CN108255710B (en) Script abnormity detection method and terminal thereof
CN113835961B (en) Alarm information monitoring method, device, server and storage medium
CN109508356B (en) Data abnormality early warning method, device, computer equipment and storage medium
CN113132431B (en) Service monitoring method, service monitoring device, electronic device, and medium
CN110768904B (en) Service communication detection method, device, terminal and storage medium for power communication network
CN114816915A (en) Link tracking method and device
CN112134723A (en) Network anomaly monitoring method and device, computer equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant