CN110673973A - Application programming interface API (application programming interface) abnormity determining method and device - Google Patents
Application programming interface API (application programming interface) abnormity determining method and device Download PDFInfo
- Publication number
- CN110673973A CN110673973A CN201910927838.8A CN201910927838A CN110673973A CN 110673973 A CN110673973 A CN 110673973A CN 201910927838 A CN201910927838 A CN 201910927838A CN 110673973 A CN110673973 A CN 110673973A
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000002159 abnormal effect Effects 0.000 claims abstract description 53
- 230000005856 abnormality Effects 0.000 claims abstract description 16
- 230000008859 change Effects 0.000 claims description 19
- 238000004590 computer program Methods 0.000 claims description 7
- 238000004140 cleaning Methods 0.000 claims description 5
- 230000004931 aggregating effect Effects 0.000 claims description 4
- 230000002085 persistent effect Effects 0.000 claims description 3
- 238000004458 analytical method Methods 0.000 abstract description 5
- 238000012544 monitoring process Methods 0.000 description 27
- 238000010586 diagram Methods 0.000 description 7
- 239000008186 active pharmaceutical agent Substances 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000002547 anomalous effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
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 & Cheminformatics (AREA)
- Bioinformatics & Computational Biology (AREA)
- Evolutionary Biology (AREA)
- Probability & Statistics with Applications (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 or not according to the current request data and the historical request data. Compared with the prior art that the called times of each API are directly used as the basis of the anomaly analysis, the accuracy is improved.
Description
Technical Field
The invention relates to a cloud platform technology, in particular to an abnormality determination method and device for an Application Programming Interface (API).
Background
With the development of cloud technology, cloud products are becoming diversified day by day, and the types of cloud products related to the current cloud products are 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 cooperation and sharing and the like. The availability of the online service provided by the cloud platform is essentially reflected in the availability of each subdivided Application Programming Interface (API), so that API monitoring plays a very important role in judging whether the online service normally operates, and online service problems can be quickly discovered through API monitoring, thereby providing precious time for solving the online service problems.
At present, after the number of times of calling each API of a cloud platform within a period of time is obtained, most of business personnel directly use the number of times of calling each API as a basis for judging whether the corresponding API is abnormal, however, the result obtained by the method is not accurate.
Disclosure of Invention
The invention provides an API abnormity determining method and device, which are used for solving the problem that the API abnormity judging accuracy is not high in the prior art.
In a first aspect, the present invention provides an API anomaly determination method, 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 or not according to the current request data and the historical request data.
Optionally, the current request data is request data in a current obtaining 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, wherein the determining step comprises the following steps:
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 or not according to the counting value.
Optionally, the target obtaining period includes: the method comprises the steps of obtaining a previous obtaining period of a current obtaining period, obtaining periods corresponding to the current obtaining period in the previous day and obtaining periods corresponding to the current obtaining period in the previous week;
correspondingly, the request data in the target acquisition period includes: first request data in the previous acquisition period, second request data in an acquisition period corresponding to the current acquisition period of the previous day, and third request data in an acquisition period corresponding to the current acquisition period of the previous week;
correspondingly, the determining the count value corresponding to the target obtaining period according to the request data in the current obtaining period and the request data in the target obtaining 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 the acquisition period corresponding to the current acquisition period in the previous day according to the request data in the current acquisition period and the second request data;
determining a third counting value corresponding to the acquisition period corresponding to the current acquisition period in the previous week according to the request data in the current acquisition period and the third request data;
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 or not according to the sum value.
Optionally, the current request data is request data within 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 comprises:
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 the ranking change of each API according to the current ranking and the historical ranking;
and determining whether the corresponding API is abnormal or not according to the ranking change of each API.
Optionally, the method further includes:
and displaying the current ranking of each API and the ranking change of each API through a configuration center.
Optionally, the obtaining current request data of each API of the cloud platform from the log system includes:
acquiring original request data of each API of the 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 includes:
and persisting the current request data of each API into a corresponding database.
In a second aspect, the present invention provides an API abnormality determination device, 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 obtaining module is further configured to obtain historical request data of each API from a database;
and the determining module is used for determining whether the corresponding API is abnormal or not according to the current request data and the historical request data.
Optionally, the current request data is request data in a current obtaining 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 or not according to the counting value.
Optionally, the target obtaining period includes: the method comprises the steps of obtaining a previous obtaining period of a current obtaining period, obtaining periods corresponding to the current obtaining period in the previous day and obtaining periods corresponding to the current obtaining period in the previous week;
correspondingly, the request data in the target acquisition period includes: first request data in the previous acquisition period, second request data in an acquisition period corresponding to the current acquisition period of the previous day, and third request data in an acquisition period corresponding to the current acquisition period of 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 the acquisition period corresponding to the current acquisition period in the previous day according to the request data in the current acquisition period and the second request data;
determining a third counting value corresponding to the acquisition period corresponding to the current acquisition period in the previous week according to the request data in the current acquisition period and the third request data;
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 or not according to the sum value.
Optionally, the current request data is request data within 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 the ranking change of each API according to the current ranking and the historical ranking;
and determining whether the corresponding API is abnormal or not according to the ranking change of each API.
Optionally, the apparatus 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 obtaining module is specifically configured to:
acquiring original request data of each API of the 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 apparatus 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 above-described API anomaly determination method.
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 above API exception determination method via execution of the executable instructions.
According to the method and the device for determining the abnormality of the API, the current request data of each API of the cloud platform is obtained from a log system, and the request data is used for representing the number of times that the corresponding API is requested to be called; then, acquiring historical request data of each API from a database; and finally, determining whether the corresponding API is abnormal or not according to the current request data and the historical request data. Compared with the prior art that the called times of each API are directly used as the basis of the anomaly analysis, the accuracy is improved.
Drawings
Fig. 1 is an optional application scenario diagram of the API anomaly determination method provided in the present invention;
FIG. 2 is a flowchart illustrating a first embodiment of an API exception determination method according to the present invention;
fig. 3 is a flowchart illustrating a second embodiment of the API anomaly determination method according to the present invention;
fig. 4 is a schematic flowchart of a third embodiment of a method for locating an abnormal API provided by the present invention;
FIG. 5 is a schematic structural diagram of an API abnormality determination device provided in the present invention;
fig. 6 is a schematic diagram of a hardware structure of a server according to the present invention.
Detailed Description
In order to make the objects, 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 with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present 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 the online service provided by the cloud platform is essentially reflected in the availability of each subdivided API, and if an API on the cloud platform is abnormal, the related service may not be operated normally. In the prior art, after the number of times that each API of a cloud platform is called within 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 not accurate.
Based on the technical problems in the prior art, the invention provides an exception determination method and device for an Application Programming Interface (API). Firstly, current request data of each API of a cloud platform are obtained from a log system, wherein the request data are used for representing the number of times that the corresponding API is requested to be called; then, acquiring historical request data of each API from a database; and finally, determining whether the corresponding API is abnormal or not according to the current request data and the historical request data. Compared with the prior art that service personnel directly use the called times of each API as the basis of the abnormal analysis, the accuracy is improved.
Fig. 1 is an optional application scenario diagram of the API anomaly determination method provided in the present invention. The application scenario diagram shown in fig. 1 involves the following modules: the system comprises a log system, an interface monitoring module, a monitoring system and a database. Alternatively, the modules may be connected by wired or wireless technology, which is not limited by the present invention.
The interface monitoring module and the monitoring system may be used to execute the scheme of the present invention, the interface monitoring module may be an independent module or a module belonging to the monitoring system, and fig. 1 illustrates the monitoring module as an independent module. The following embodiments all describe the solution of the present invention in the case that the interface monitoring module is a separate module.
Wherein, the log system can be used for recording events which occur in the cloud platform. Each API, when called, generates an event record in the logging system. The interface monitoring module may obtain, from the log system, 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.
The database may include a time series database and a relational database management system, among others. The database stores historical request data of all the 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 solutions of the present invention and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present invention will be described below with reference to the accompanying drawings.
Fig. 2 is a flowchart illustrating a first embodiment of an API exception determining method according to the present invention. The API abnormality determination method provided in this embodiment may be executed by the interface monitoring module and the monitoring system shown in fig. 1. As shown in fig. 2, the method for determining an API exception provided in this embodiment includes:
s201, current request data of each API of the cloud platform are obtained from the log system, and the request data are used for representing the number of times that the corresponding API is requested to be called.
The meaning of the above-described currently requested data is explained in two scenarios:
in a first scenario, the interface monitoring module periodically obtains 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 that the corresponding API is requested to be called, and in the above example, the request data of each API in the past 10 minutes indicates the number of times that each API is requested to be called in the past 10 minutes.
And in a second scenario, the interface monitoring module can acquire the request data of each API from the log system at regular time. 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 cloud platform usage.
Such as: the interface monitoring module may obtain requested data for each API for the past 30 minutes from the logging system at a 20:00 time per day. In this scenario, the request data of each API in the past 30 minutes acquired by the interface monitoring module from the log system at 20:00 of the 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 of each API within 30 minutes from the day 20:00 indicates the number of times each API is requested to be called within the 30 minutes.
Optionally, after the original request data of each API of the cloud platform is acquired 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 aggregation operation is implemented by merging request data of APIs with the same function in all APIs of the cloud platform into one request data. The API with the same function is regarded as an API, and the merged request data is the request data of the API.
The cleaning is realized by discarding all APIs which cannot be successfully matched with the preset matching rule.
S202, obtaining the historical request data of each API from a database.
Referring to S101, in a scenario one, history request data that the interface monitoring module needs to obtain from the database is: request data in a target acquisition period prior to the current acquisition period. Such as: the target period may be an acquisition period previous to the current acquisition period, an acquisition period corresponding to the current acquisition period on the previous day, an acquisition period corresponding to the current acquisition period on the previous week, and the like.
Referring to the example corresponding to a101, assuming that the obtaining period is 10 minutes, the historical request data of each API obtained by the interface monitoring module from the database may be the previous 10 minutes, 10 minutes of the previous one-week-same-time period, or 10 minutes of the previous one-week-same-time period.
Referring to S101, in a case of the second scenario, the historical request data that the interface monitoring module needs to obtain from the database is the target request data in the preset time period in the target date. Such as: the data processing method comprises the steps of requesting data in the same preset time period of yesterday, requesting data in the same preset time period of previous week, requesting data in the same preset time period of previous two weeks, and the like.
Referring to the example corresponding to a101, assuming that the preset time period is 20:00 to begin within 30 minutes, the historical request data of each API obtained by the interface monitoring module from the database may be 20:00 to 20:30 yesterday, 20:00 to 20:30 last week, 20:00 to 20:30 last two weeks, and the like.
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 historical request data is acquired in S102, each API may be detected in an anomaly detection algorithm or the like to determine whether the corresponding API is abnormal, which is convenient for operation and maintenance personnel to maintain the interface flow control capability.
In the method for determining API exception provided in this embodiment, current request data of each API of a cloud platform is first obtained from a log system, where the request data is used to indicate the number of times that a corresponding API is requested to be called; then, acquiring historical request data of each API from a database; and finally, determining whether the corresponding API is abnormal or not according to the current request data and the historical request data. Compared with the prior art that the called times of each API are directly used as the basis of the anomaly analysis, the accuracy is improved.
Fig. 3 is a flowchart illustrating a second embodiment of the API anomaly determination method according to the present invention. In this embodiment, an implementation manner of determining whether a corresponding API is abnormal in the case of scenario one in the above embodiment will be described. As shown in fig. 3, the method for determining an API exception according to this embodiment includes:
s301, acquiring request data of each API of the cloud platform in the current acquisition period from the log system.
Optionally, the request data of each API in the current obtaining period may be obtained and persisted in the time sequence database.
S302, acquiring the request data of each API in the target acquisition period before the current acquisition period from the 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.
The following, with the target acquisition cycle, includes: the scheme of this embodiment is described by taking an acquisition cycle before a current acquisition cycle, an acquisition cycle corresponding to the current acquisition cycle on the previous day, and an acquisition cycle corresponding to the current acquisition cycle on the previous week as examples.
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 of the previous day, and the third request data in the acquisition period corresponding to the current acquisition period of the previous week.
For convenience of description, the request data of the CURRENT fetch cycle is denoted as QPS _ CURRENT, the first request data is denoted as QPS _ lastpost, the second request data is denoted as QPS _ LASTDAY, and the third request data is denoted as QPS _ lastbeam.
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 _ LASTSTEP)/QPS _ LASTSTEP >1 or < -1, it is indicated that the change amplitude of the CURRENT acquisition period compared with the previous acquisition period exceeds one time, and it is considered that there is an abnormality in the corresponding API when the CURRENT acquisition period is compared with the previous acquisition period, it may be determined that the first count value is 1.
And step B, determining a second counting value corresponding to the acquisition period corresponding to the current acquisition period in the previous day according to the request data in the current acquisition period and the second request data.
Specifically, if (QPS _ CURRENT-QPS _ LASTDAY)/QPS _ LASTDAY >1 or < -1, it is indicated that the change amplitude between the CURRENT acquisition period and the acquisition period corresponding to the CURRENT acquisition period in the previous day exceeds twice, and it is considered that there is an abnormality in the corresponding API between the CURRENT acquisition period and the acquisition period corresponding to the CURRENT acquisition period in the previous day, and the second count value may be determined to be 10.
And step C, determining a third counting value corresponding to the acquisition period corresponding to the current acquisition period in the previous week according to the request data in the current acquisition period and the third request data.
Specifically, if (QPS _ CURRENT-QPS _ last)/QPS _ last >1 or < -1 indicates that the change amplitude between the CURRENT acquisition cycle and the previous cycle is more than one time compared to the acquisition cycle corresponding to the CURRENT acquisition cycle, and it is considered that there is an abnormality in the corresponding API between the CURRENT acquisition cycle and the previous cycle compared to the acquisition cycle corresponding to the CURRENT acquisition cycle, it may be determined that the third count value is 100.
S304, determining whether the corresponding API is abnormal or not according to the counting value.
Specifically, in the case where the first count value, the second count value, and the third count value are obtained in the above steps a to C, whether the corresponding API is abnormal is determined by the following steps.
And D, calculating the sum of the first counting value, the second counting value and the third counting value.
And E, determining whether the corresponding API is abnormal or not according to the sum value.
Continuing with steps a-C above, whether the ones, tens, and hundreds of the sum of the first, second, and third count values are 1 characterizes whether the API is anomalous compared to the corresponding fetch cycle. For example, if the calculated sum is 0, it indicates that there is no exception for the corresponding API; if the calculated sum value is 111, it indicates that the corresponding API is abnormal compared with the previous acquisition cycle, the acquisition cycle corresponding to the current acquisition cycle on the previous day and the acquisition cycle corresponding to the current acquisition cycle on the previous week; if the calculated sum is 110, indicating that the acquisition period corresponding to the current acquisition period on the previous day is abnormal, and comparing the acquisition period corresponding to the current acquisition period on the previous week with the corresponding API, wherein the corresponding API is not abnormal when compared with the previous acquisition period; if the calculated sum is 101, it indicates that the corresponding API is abnormal compared with the previous acquisition cycle and the acquisition cycle corresponding to the current acquisition cycle in the previous week, and there is no abnormality compared with the acquisition cycle corresponding to the current acquisition cycle in the previous day.
Optionally, after the sum of the count values is obtained, the sum may be reported to a monitoring system, and the monitoring system further configures an alarm policy and sends alarm information to a terminal of a service worker.
In the method for determining API exception provided in this embodiment, it is described that the current request data is the request data in the current obtaining period, and when the historical request data includes the request data in the target obtaining period before the current obtaining period, a scheme for determining whether the corresponding API is abnormal is described, as compared with the prior art in which the number of times each API is called is directly used as a basis for determining whether the API is abnormal, the accuracy of the determination result is improved.
Fig. 4 is a flowchart illustrating a third embodiment of the method for locating an abnormal API provided by the present invention. In this embodiment, an implementation manner of determining whether a corresponding API is abnormal in the case of scenario two in the above embodiment will be described. As shown in fig. 4, the method for determining an API exception according to this embodiment includes:
s401, acquiring request data of each API of the cloud platform in a preset time period from the log system.
Optionally, the request data of each API within the preset time period may be obtained and persisted in 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.
And S403, determining the current ranking of each API according to the request data in the preset time period.
S404, determining the historical ranking of each API according to the target request data.
S405, determining ranking change of each API according to the current ranking and the historical ranking.
S406, determining whether the corresponding API is abnormal according to the ranking change of each API.
The preset time period in S401 is 20:00-20:30, the process of S403-S406 is explained by taking the target date including the previous day, week, and two weeks as examples:
according to the date of 20:00-20:30, determining the current ranking of each API, according to the request data of each API in the previous day 20:00-20:30, determining the ranking of each API on the previous day according to the request data of each API in the previous 20:00-20:30, determining the rank of each API before one week according to the request data of each API in the first 20:00-20:30, the request data for each API, determines the ranking of each API two weeks ago. Comparing the current ranking of each API with the ranking of the previous day, the previous week and the previous two weeks, if the variation amplitude of the ranking is within a preset range, considering that the corresponding API is not abnormal, and if the variation amplitude of the current ranking of each API is beyond the preset range compared with the ranking of the previous day, the previous week and the previous two weeks, considering that the corresponding API is abnormal.
It should be noted that: the analysis rule for determining whether the API is abnormal in the above example is only an example, and a person skilled in the art may set other rules according to actual situations, and the present invention is not limited to the above example.
Optionally, after obtaining the current rank and the rank change, the current rank and the rank change may be displayed through a configuration center for service staff to view. 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.
The method for determining API exception provided in this embodiment describes that the current request data is the request data in the preset time period, and when the historical request data includes the target request data in the preset time period in the target date, the scheme for determining whether the corresponding API is abnormal is described, as compared with the prior art in which the number of times each API is called is directly used as a basis for determining whether the API is abnormal, the accuracy of the determination result is improved.
Fig. 5 is a schematic structural diagram of an API abnormality determination device according to the present invention. As shown in fig. 5, the API abnormality determination device according to the present invention includes:
an obtaining module 501, configured to obtain current request data of each API of the cloud platform from the log system, where the request data is used to indicate the number of times that the corresponding API is requested to be called;
the obtaining module 501 is further configured to obtain historical request data of each API from a database;
a determining module 502, configured to determine whether a 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 obtaining period, and the historical request data includes: request data in a target acquisition period before the current acquisition period;
correspondingly, 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 or not according to the counting value.
Optionally, the target obtaining period includes: the method comprises the steps of obtaining a previous obtaining period of a current obtaining period, obtaining periods corresponding to the current obtaining period in the previous day and obtaining periods corresponding to the current obtaining period in the previous week;
correspondingly, the request data in the target acquisition period includes: first request data in the previous acquisition period, second request data in an acquisition period corresponding to the current acquisition period of the previous day, and third request data in an acquisition period corresponding to the current acquisition period of the previous week;
correspondingly, 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 the acquisition period corresponding to the current acquisition period in the previous day according to the request data in the current acquisition period and the second request data;
determining a third counting value corresponding to the acquisition period corresponding to the current acquisition period in the previous week according to the request data in the current acquisition period and the third request data;
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 or not according to the sum value.
Optionally, the current request data is request data within 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 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 the ranking change of each API according to the current ranking and the historical ranking;
and determining whether the corresponding API is abnormal or not according to the ranking change of each API.
Optionally, the apparatus further includes:
and a display module 503, configured to display the current ranking of each API and the change in the ranking of each API through the configuration center.
Optionally, the obtaining module 501 is specifically configured to:
acquiring original request data of each API of the 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 apparatus further includes:
and the persistence module 504 is configured to persist the current request data of each API into a corresponding database.
The API anomaly determination apparatus provided in this embodiment may be used to perform the steps in any of the above method embodiments, and the implementation principle and technical effect thereof are similar, and are not described herein again.
Fig. 6 is a schematic diagram of a 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 API exception determining method described in any of the above embodiments when the program instruction is executed, and specific implementation principles may refer to the above embodiments, which are not described herein again.
The present invention provides a computer-readable storage medium on which a computer program is stored, the computer program, when executed by a processor, implementing the API abnormality determining method described in any of the above embodiments.
The present invention also provides a program product including a computer program stored in a readable storage medium, the computer program being readable from the readable storage medium by at least one processor, the computer program being executable by the at least one processor to cause a server to implement the API abnormality determining method described in any of the above embodiments.
In the embodiments provided in the present invention, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed 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 can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.
The integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute some steps of the methods according to the embodiments of the present invention. And the aforementioned storage medium includes: a U disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It should be understood that the processor described herein may be a Central Processing Unit (CPU), other general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (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 the 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, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.
Claims (10)
1. An abnormality determination method for an Application Programming Interface (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;
and determining whether the corresponding API is abnormal or not according to the current request data and the historical request data.
2. The method of claim 1, wherein 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;
determining whether the corresponding API is abnormal according to the current request data and the historical request data, wherein the determining step comprises the following steps:
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 or not according to the counting value.
3. The method of claim 2,
the target acquisition period includes: the method comprises the steps of obtaining a previous obtaining period of a current obtaining period, obtaining periods corresponding to the current obtaining period in the previous day and obtaining periods corresponding to the current obtaining period in the previous week;
correspondingly, the request data in the target acquisition period includes: first request data in the previous acquisition period, second request data in an acquisition period corresponding to the current acquisition period of the previous day, and third request data in an acquisition period corresponding to the current acquisition period of the previous week;
correspondingly, the determining the count value corresponding to the target obtaining period according to the request data in the current obtaining period and the request data in the target obtaining 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 the acquisition period corresponding to the current acquisition period in the previous day according to the request data in the current acquisition period and the second request data;
determining a third counting value corresponding to the acquisition period corresponding to the current acquisition period in the previous week according to the request data in the current acquisition period and the third request data;
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 or not according to the sum value.
4. The method of claim 1,
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 whether the corresponding API is abnormal according to the current request data and the historical request data comprises:
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 the ranking change of each API according to the current ranking and the historical ranking;
and determining whether the corresponding API is abnormal or not according to the ranking change of each API.
5. The method of claim 4, further comprising:
and displaying the current ranking of each API and the ranking change of each API through a configuration center.
6. The method according to any one of claims 1 to 5, wherein the obtaining current request data of each API of the cloud platform from the log system comprises:
acquiring original request data of each API of the cloud platform from the log system;
and aggregating and cleaning the original request data to obtain the current request data of each API.
7. The method of claim 6, further comprising:
and persisting the current request data of each API into a corresponding database.
8. An API abnormality determination device 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 obtaining module is further configured to obtain historical request data of each API from a database;
and the determining module is used for determining whether the corresponding API is abnormal or not according to the current request data and the historical request data.
9. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the method of any one of claims 1 to 7.
10. 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-7 via execution of the executable instructions.
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 true CN110673973A (en) | 2020-01-10 |
| CN110673973B 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) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527601A (en) * | 2020-12-17 | 2021-03-19 | 航天信息股份有限公司 | Monitoring early warning method and device |
| CN113888311A (en) * | 2021-10-14 | 2022-01-04 | 中国工商银行股份有限公司 | Risk early warning method and device, computer equipment and computer readable storage medium |
| CN117519670A (en) * | 2023-12-25 | 2024-02-06 | 杭银消费金融股份有限公司 | Method and system for automatically generating RPC (remote procedure control) codes |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170262628A1 (en) * | 2016-03-10 | 2017-09-14 | Fujitsu Limited | Management device, management method, and computer-readable recording medium |
| CN109933508A (en) * | 2019-03-25 | 2019-06-25 | 北京百度网讯科技有限公司 | Method and apparatus for sending information |
-
2019
- 2019-09-27 CN CN201910927838.8A patent/CN110673973B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170262628A1 (en) * | 2016-03-10 | 2017-09-14 | Fujitsu Limited | Management device, management method, and computer-readable recording medium |
| CN109933508A (en) * | 2019-03-25 | 2019-06-25 | 北京百度网讯科技有限公司 | Method and apparatus for sending information |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527601A (en) * | 2020-12-17 | 2021-03-19 | 航天信息股份有限公司 | Monitoring early warning method and device |
| CN113888311A (en) * | 2021-10-14 | 2022-01-04 | 中国工商银行股份有限公司 | Risk early warning method and device, computer equipment and computer readable storage medium |
| CN117519670A (en) * | 2023-12-25 | 2024-02-06 | 杭银消费金融股份有限公司 | Method and system for automatically generating RPC (remote procedure control) codes |
| CN117519670B (en) * | 2023-12-25 | 2024-04-09 | 杭银消费金融股份有限公司 | Method and system for automatically generating RPC (remote procedure control) codes |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110673973B (en) | 2024-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110471821B (en) | Abnormality change detection method, server, and computer-readable storage medium | |
| CN106548402B (en) | Resource transfer monitoring method and device | |
| US8880946B2 (en) | Fault detection apparatus, a fault detection method and a program recording medium | |
| CN110673973B (en) | Abnormality determination method and device for application programming interface API | |
| US8352867B2 (en) | Predictive monitoring dashboard | |
| 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 | |
| CN108269189B (en) | Index data monitoring method and device, storage medium and computer equipment | |
| US11032627B2 (en) | Maintenance device, presentation system, and program | |
| CN114443429B (en) | Alarm event processing method and device and computer readable storage medium | |
| CN109976971B (en) | Hard disk state monitoring method and device | |
| CN109992473A (en) | Monitoring method, device, equipment and the storage medium of application system | |
| CN110727533A (en) | Alarm method, device, equipment and medium | |
| CN110990245A (en) | Micro-service operation state judgment method and device based on call chain data | |
| CN111130944B (en) | System monitoring method and system | |
| CN111143325A (en) | Data acquisition monitoring method, monitoring device and readable storage medium | |
| US11113364B2 (en) | Time series data analysis control method and analysis control device | |
| CN113159463A (en) | Traffic monitoring method and device | |
| CN110928748A (en) | Business system operation monitoring method and device | |
| CN108255710B (en) | Script abnormity detection method and terminal thereof | |
| EP4388468A1 (en) | Intelligent cloud service health communication to customers | |
| CN107562551A (en) | Monitoring method, device and the computer-readable recording medium of outside access system | |
| CN109508356B (en) | Data abnormality early warning method, device, computer equipment and storage medium | |
| CN114661562A (en) | Data warning method, device, equipment and 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 |