CN109560989B - Link monitoring system - Google Patents
Link monitoring system Download PDFInfo
- Publication number
- CN109560989B CN109560989B CN201811486884.0A CN201811486884A CN109560989B CN 109560989 B CN109560989 B CN 109560989B CN 201811486884 A CN201811486884 A CN 201811486884A CN 109560989 B CN109560989 B CN 109560989B
- Authority
- CN
- China
- Prior art keywords
- data
- link
- component
- time
- node
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/022—Capturing of monitoring data by sampling
- H04L43/024—Capturing of monitoring data by sampling by adaptive sampling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
- H04L43/045—Processing captured monitoring data, e.g. for logfile generation for graphical visualisation of monitoring data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/06—Generation of reports
- H04L43/067—Generation of reports using time frame reporting
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Mining & Analysis (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a link monitoring system, comprising: the system comprises a client, a server and a monitoring platform, wherein the client comprises a Sleuth component for acquiring link data from an application request; the server comprises a Spark component for analyzing link data to obtain measurement index data, a Zipkin component for integrating the link data into a complete link and storing the analyzed data into a database, a Cassandra component for storing the analyzed data, a Mysql component for storing the link data, and a RabbitMQ component for managing push information; the monitoring platform comprises an input component for setting processing rules and an output component for outputting data processing results. According to the invention, the Sleuth component acquires link data, the Spark component analyzes the link data, the Zipkin component integrates the link data, the data can be rapidly processed, and the RabbitMQ component manages the push information, so that the push of the information can be realized, and the control on the system condition can be realized.
Description
Technical Field
The invention relates to the technical field of internet system management, in particular to a link monitoring system.
Background
With the development of companies, more and more application programs are developed by the companies, and more calls are made among the application programs; meanwhile, the system construction of companies shifts to distributed deployment and micro-service, the deployment complexity is higher and higher, and then new problems come along, and typical problems are as follows: 1) calling a link to be lengthened; 2) the difficulty of locating the problematic nodes is increased; 3) increased difficulty in service availability monitoring; 4) increased difficulty in service performance monitoring; there is no suitable management tool and platform to connect all services through, so that the search for the problem source needs to be switched among a plurality of systems, and precious resources are largely consumed in the puddle for troubleshooting the problem.
Disclosure of Invention
The present invention is directed to solving, at least to some extent, one of the technical problems in the related art. To this end, it is an object of the present invention to provide a link monitoring system.
The technical scheme adopted by the invention is as follows:
in a first aspect, a link monitoring system includes: the system comprises a client, a server and a monitoring platform, wherein the client comprises a Sleuth component for acquiring link data from an application request; the server comprises a Spark component for analyzing link data to obtain measurement index data, a Zipkin component for integrating the link data into a complete link and storing the analyzed data into a database, a Cassandra component for storing the analyzed data, a Mysql component for storing the link data, and a RabbitMQ component for managing push information; the monitoring platform comprises an input component for setting processing rules and an output component for outputting data processing results.
Preferably, the specific step of the Sleuth component acquiring link data includes: the target application acquires an access request sent from the browser and records the receiving time of a recording point span A of a server end of the target application; the target application calls an interface of the third-party application to create a record point span B and record the request initiation time of a Client end of the third-party application; the third-party application records the receiving time of the Server end, executes the service code, records the response time of the Server end of the third-party application, returns response information and asynchronously pushes the response time of the Server end to the Server end; the target application acquires response information of the third-party application, records and asynchronously pushes the Client end response time of the third-party application to the server end; the target application completes the self service logic, records and asynchronously pushes the server end response time of the target application to the server end; and integrating the Server end response time of the third-party application, the Client end response time and the Server end response time of the target application as link data.
Preferably, the specific step of the server analyzing the link data includes: analyzing a data set of all root nodes in a certain time range under the condition that a father node is empty, and grouping root node names to obtain the name, ID and time-consuming result set of the longest node in a certain link; analyzing each link data in the result set in a child node passing mode to obtain code running time of the node, and collecting the link data and the code running time to obtain analyzed data; and when the total consumption time of the link exceeds a threshold value, triggering early warning and outputting information through the RabbitMQ component.
Preferably, the specific step of the server analyzing the link data includes: within a certain time range, subtracting the sum of the processing time of all the child nodes of each node from the processing time of each node to obtain the code running time of each node; analyzing the request times and average processing time of each node by taking the node name as a group; traversing each group of nodes to find a median value in each group; and judging whether the processing time of the node triggers early warning or not according to the processing time ranking of the nodes in the group.
Preferably, the server is based on Kafka technology, and is configured to process the link data and the parsed data according to a processing rule to generate a corresponding data list; an output component outputs the data list.
Preferably, the client further comprises a sampling component for implementing dynamic sampling, and the step of implementing dynamic sampling by the sampling component comprises: and obtaining a sampling list through a sampling rate and a reservoir sampling algorithm, marking the link data to be processed based on an AtomicInteger counter, and adopting the link data when the data of the counter belongs to the sampling list.
Preferably, the input component is further adapted to alter the sampling rate.
The invention has the beneficial effects that:
according to the invention, the Sleuth component acquires link data, the Spark component analyzes the link data, the Zipkin component integrates the link data, the data can be rapidly processed, and the RabbitMQ component manages the push information, so that the push of the information can be realized, and the control on the system condition can be realized.
Drawings
FIG. 1 is a schematic diagram of a link monitoring system of the present invention;
fig. 2 is a link data acquisition flow of the present invention.
Detailed Description
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
Example 1
The present embodiment provides a link monitoring system as shown in fig. 1, including: the system comprises a client 1, a server 2 and a monitoring platform 3, wherein the client 1 comprises a Sleuth component 11 for acquiring link data from an application request; the server 2 comprises a Spark component 21 for analyzing link data to obtain measurement index data, a Zipkin component 22 for integrating the link data into a complete link and storing the analyzed data into a database, a Cassandra component 23 for storing the analyzed data, a Mysql component 24 for storing the link data, and a RabbitMQ component 25 for managing push information; the monitoring platform comprises an input component 31 for setting processing rules, and an output component 32 for outputting data processing results.
The various components in the system:
sleuth (i.e., Spring Cloud Sleuth): the link data collection method is used as the core of the client and is used for collecting link information of various requests and collecting link data of Http requests, Dubbo requests, RabbitMQ requests and MySQL requests.
Kafka: as a message middleware (i.e., a server) for processing the collected link raw data to manage the production and consumption (i.e., analysis and utilization) of large batches of link data.
Consul (service discovery, configuration management center developed in go language for google open source): as a configuration center for sample rate, analysis interval, timeout threshold configuration, for storage and dynamic modification of the configuration.
Spark (i.e., Apache Spark): the big data flow type calculation component is used for analyzing and calculating the original data of the link to obtain measurement index data such as some longest links, the most time-consuming links and the like; acquiring original link data from Kafka, and storing the calculated data into MySQL; meanwhile, if the link time consumption exceeds the timeout threshold, the data is sent to the RabbitMQ.
Zipkin: is a data processing component of the distributed tracking system; the method obtains original data of the link from Kafka, integrates the data into a complete link, has the functions of link display and data analysis, and stores the analyzed data into Cassandra.
Cassandra: distributed NoSQL database, one of the Zipkin compatible databases, is used to store link data.
MySQL: and the relational database is used for storing the (link) data after Spark analysis.
RabbitMQ: and the message middleware is used for managing the production and consumption of the overtime early warning notification message.
The input component comprises input equipment such as a common keyboard and a common mouse and also comprises a data interface; the output component comprises a display, a data output interface and the like.
The design of the client is mainly divided into three parts: link data acquisition, sampling rate reset and data push.
(1) Collecting link data: the method comprises the steps of expanding an expansion packet for supporting Dubbo and MySQL acquisition in a user-defined mode through a Sleuth core packet, and introducing a corresponding expansion packet when a project needs to acquire link data of a certain component, so that the project is enabled to be minimally invasive and the most flexible support is provided.
(2) Resetting the sampling rate: starting a timing thread in the client to monitor the change of the sampling rate value in a component Consul of the server, and acquiring the sampling rate through api of the Consul; when the value changes, the configuration of the Sleuth sample rate class is reset without restarting the entry to modify the sample rate.
(3) Data push: when link data is collected, a dedicated topic is established by using api of Kafka, and the data is pushed to Kafka.
The application program integrates link data acquisition and transmission functions by introducing jar packets of the items; the project acquires link data of various requests through the Sleuth component and pushes the link data to Kafka for consumption; meanwhile, the collected configuration information can be obtained from Consul controlled by the server, and the collection rate is further adjusted.
The design of the monitoring platform mainly comprises the following steps of designing a project structure according to calculated results of all dimensions to be displayed in a project task book, and the design mainly comprises two parts of link management and monitoring management:
1) and link management: according to a project task book, measuring index requirements such as URL request frequency statistics in unit time, node time consumption median in unit time and the like are met, link management is divided into seven parts including a trace list, a trace early warning list, a service early warning list, an analysis interval list, an overtime threshold list and a sampling rate list, a database is designed, and then measuring indexes are displayed one by one.
2) Monitoring and controlling: the method mainly comprises the steps of displaying original link data, providing detailed information of links, displaying dependence management among nodes, providing by a Zipkin component, and only making one reference; calculating and acquiring data of various index types from Kafka consumption data through Spark service (components), and storing the calculated data into a Mysql database for a link monitoring platform to display; the link monitoring platform (i.e. the monitoring platform) can set three parameters of an analysis interval, a timeout threshold and a sampling rate, wherein the analysis interval and the timeout threshold are realized by restarting Spark service after being modified, and the sampling rate is realized by resetting client-related beans of link analysis. When the Spark finds a node overtime, an early warning is sent to the personnel related to the project.
Operation and maintenance monitoring system: the monitoring system is a developed monitoring system, and only the function of pushing overtime early warning messages to the nailing users is used in the monitoring system.
A link monitoring platform: and displaying the original link information and the analyzed link data, and modifying the configuration of Consul.
Regarding the beneficial effects of the present embodiment: a client: the invasion to the service system is very small, the collected data is asynchronous message, and the operation of the service system cannot be influenced even if the client has a problem; during the peak period of service system access, the sampling rate can be dynamically reduced through the management system, and the performance of a service system server is occupied as little as possible; the client side expands and supports link acquisition of middleware such as Mysql, RabbitMQ, Dubbo and the like on the basis of the original functions of the open source framework Sleuth, and meets the use scene of the existing popular technology.
A server side: useful data is stored forever for the data collected by the client through big data analysis, the running health condition of each node and each link is analyzed, and the real-time monitoring is carried out by adding early warning of the data. The collected data is made into a report and a trend chart, and the running conditions of all the systems can be intuitively analyzed and tracked for a long time.
Example 2
The present embodiment is directed to the problem that the problem is difficult to find and solve due to the fact that the link is long and complex, and the problem is difficult to find and analyze because the link is long and complex, and is across systems, there are more requested data, and a preferable scheme needs to be proposed and explained, for example, the link data acquisition flow shown in fig. 2:
s1, a user sends a request to access an application A (namely a target application) through a browser, and the application A records (recording point) SpanA Server end receiving time.
And S2. after the application A receives the request, calling an application B (namely a third party application) interface, creating a SpanB and recording the request initiation time of a Client.
And S3. after the application B receives the call request of the application A, the receiving time of the Server end of the SpanB is recorded, a service code is executed (namely the request for executing the call of the application A), the response time of the Server end of the SpanB is recorded, response information is returned, and finally the Server end data of the SpanB is asynchronously pushed to a message queue Kafka (Server end).
And S4. the application A receives the response data returned by the application interface B, records the response time of the Client end of the SpanB and asynchronously pushes the Client end data of the SpanB to the message queue Kafka.
And S5.A completes the self service logic, returns response information to the browser, records the response time of the Server end of the SpanA, and asynchronously pushes the Server end data of the SpanA to the message queue Kafka.
And S6, the browser completes the request, and the user acquires page data.
S7, the zipkin pulls the three pieces of data of the SpanA and the SpanB from the message queue Kafka, merges the Client end data of the SpanB and the Server end data, and calculates the time consumption between the two points, wherein the SpanA does not have the Client end, so the time between the reception and the response of the Server is eliminated.
And S8, storing the two merged Span data into a Cassandra (component) database, and displaying the just requested link information on a page by a Web end of Zipkin by reading Cassandra.
Example 3
This example serves to explain the preferred embodiment.
The server correspondingly analyzes and processes the data, and the specific steps comprise:
analyzing the link data: the analysis time interval can be dynamically adjusted, and the purpose of the method is to analyze the longest link data in the link from the link data in a certain time range, analyze the most time-consuming node in the link, and judge whether to trigger early warning. The main processing process comprises the steps of acquiring all link data into a memory, analyzing a data set of all root nodes under the condition that a father node is empty, and then grouping the root node names to obtain the name, id and a time-consuming result set of the longest node in a certain link; and respectively analyzing each link data in the result set, removing the processing time of the sub-node from the time of each node in the link to obtain the self code running time of each node, calculating the maximum time-consuming node according to the whole link data and the self code running time of each node, analyzing the whole link node in detail through the ID of the root node, comparing whether the total link time consumption exceeds an early warning threshold value, and triggering early warning to notify business personnel.
Analyzing node data: the analysis time interval of the task can be dynamically adjusted, and the task is to analyze the request times, median values and average values of each node from the link data in a certain time range and judge whether to trigger early warning or not. The main processing procedure is that all link data are acquired into a memory, and the processing time of each node is subtracted by the sum of the processing time of all child nodes of the node, so that the self code running time of each node is obtained; analyzing the request times and average processing time of each node by taking the node name as a group; and then, traversing each group of nodes to find a median value in each group, and analyzing the processing time of more than 30% of the nodes in the group to judge whether the early warning is triggered (namely judging whether the early warning should be triggered according to the sequence).
Listing treatment: the monitoring of service performance and availability is guaranteed, data must be analyzed and accumulated for a long time, and an intuitive trend graph is formed for analysis, for example:
ten-minute node data analysis: the task of the method is to analyze the request times, median values and average values of each node from the link data in a ten-minute range. The processing logic of the system is consistent with the analysis of node data, the time is fixed to be ten minutes, and the processed result set of the system is put into Kafka; because it is calculated once every ten minutes, ten minutes in forming a trend graph can depict one point, 1008 points can be depicted by each kind of measurement data accumulated in a week, and the interval trend graph every ten minutes in a week can be obtained by connecting the data.
One hour node data analysis: the task of the method is to analyze the request times, median values and average values of each node from the link data in an hour range. The main analysis data source is to analyze the request times and average processing time of each node by taking the node name as a group from a fixed ten-minute node data result set. Then, finding the median value in each group by traversing each group of nodes; because it is calculated once an hour, one hour in the formed trend graph can depict one point, 720 points can be depicted by each kind of measurement data accumulated in one month, and the interval trend graph of one month and one hour can be obtained by connecting the data.
Example 4
This example serves to illustrate the preferred embodiment.
The influence of the client-side collected data on the performance of the service system server can be dynamically adjusted: a sampled data list is obtained by the Reservoir Sampling Algorithm (e.g., Sampling rate 0.1, by which a random sample list value is obtained from 0,99, which may be {3,10,15,30,45,50,60,61,71,90 }).
By utilizing atomicity and isolation of AtomicInteger (counter), when data needs to be recorded each time, a counter (counter) is judged firstly (namely the counter gives a value to the data, and then whether the value belongs to a sampling list is judged), whether the value is in the sampling list is judged, if the value exists, the sampling is carried out, and otherwise, the sampling is not carried out.
And obtaining a consul value at regular time, refreshing a system sampling rate value, and refreshing the Bean of the sampling rate by using ContextRefresher. During the peak period of service system access, the sampling rate can be dynamically reduced through the management system, and the performance of the service system server is occupied as little as possible.
While the preferred embodiments of the present invention have been illustrated and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (6)
1. A link monitoring system, comprising: client, server and monitoring platform, wherein,
the client comprises a Sleuth component used for acquiring link data from the request of the application;
the server comprises a Spark component for analyzing link data to obtain measurement index data, a Zipkin component for integrating the link data into a complete link and storing the analyzed data into a database, a Cassandra component for storing the analyzed data, a Mysql component for storing the link data, and a RabbitMQ component for managing push information;
the monitoring platform comprises an input component for setting processing rules and an output component for outputting data processing results;
the concrete steps of the Sleuth component for acquiring link data comprise:
the target application acquires an access request sent from the browser and records the receiving time of a recording point span A of a server end of the target application;
the target application calls an interface of the third-party application to create a record point span B and record the request initiation time of a Client end of the third-party application;
the third-party application records the receiving time of the Server end, executes the service code, records the response time of the Server end of the third-party application, returns response information and asynchronously pushes the response time of the Server end to the Server end;
the target application acquires response information of the third-party application, records and asynchronously pushes the Client end response time of the third-party application to the server end;
the target application completes the self service logic, records and asynchronously pushes the server end response time of the target application to the server end;
and integrating the Server end response time of the third-party application, the Client end response time and the Server end response time of the target application as link data.
2. The link monitoring system according to claim 1, wherein the specific step of the server analyzing the link data includes:
analyzing a data set of all root nodes in a certain time range under the condition that a father node is empty, and grouping root node names to obtain the name, ID and time-consuming result set of the longest node in a certain link;
analyzing each link data in the result set in a child node passing mode to obtain code running time of the node, and collecting the link data and the code running time to obtain analyzed data;
and when the total consumption time of the link exceeds a threshold value, triggering early warning and outputting information through the RabbitMQ component.
3. The link monitoring system according to claim 1, wherein the specific step of the server analyzing the link data includes:
within a certain time range, subtracting the sum of the processing time of all the child nodes of each node from the processing time of each node to obtain the code running time of each node;
analyzing the request times and average processing time of each node by taking the node name as a group;
traversing each group of nodes to find a median value in each group;
and judging whether the processing time of the node triggers early warning or not according to the processing time ranking of the nodes in the group.
4. The link monitoring system according to claim 1, wherein the server is based on Kafka technology, and is configured to process the link data and the parsed data according to the processing rule to generate the corresponding data list;
an output component outputs the data list.
5. The link monitoring system according to claim 1, wherein the client further comprises a sampling component for implementing dynamic sampling, and the step of implementing dynamic sampling by the sampling component comprises:
and obtaining a sampling list through a sampling rate and a reservoir sampling algorithm, marking the link data to be processed based on an AtomicInteger counter, and adopting the link data when the data of the counter belongs to the sampling list.
6. A link monitoring system according to claim 5, wherein the input component is further adapted to vary the sampling rate.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811486884.0A CN109560989B (en) | 2018-12-06 | 2018-12-06 | Link monitoring system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811486884.0A CN109560989B (en) | 2018-12-06 | 2018-12-06 | Link monitoring system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109560989A CN109560989A (en) | 2019-04-02 |
| CN109560989B true CN109560989B (en) | 2020-12-22 |
Family
ID=65869377
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811486884.0A Active CN109560989B (en) | 2018-12-06 | 2018-12-06 | Link monitoring system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109560989B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110351131B (en) * | 2019-06-28 | 2022-04-05 | 北京奇才天下科技有限公司 | Monitoring method and device for distributed link and electronic equipment |
| CN110611715B (en) * | 2019-09-23 | 2023-11-28 | 国云科技股份有限公司 | System and method for collecting cloud monitoring information through service links |
| CN112350887B (en) * | 2020-10-19 | 2021-07-13 | 北京基调网络股份有限公司 | APM probe sampling rate determining method, computer equipment and storage medium |
| CN112416708B (en) * | 2020-11-17 | 2023-09-22 | 中国工商银行股份有限公司 | Asynchronous call link monitoring method and system |
| CN112732229A (en) * | 2020-12-31 | 2021-04-30 | 中山大学 | Multi-language learning system based on micro-service architecture |
| CN113064790B (en) * | 2021-03-15 | 2023-08-11 | 上海浦东发展银行股份有限公司 | Call chain data acquisition system, method and storage medium based on configuration center |
| CN113472850B (en) * | 2021-05-31 | 2023-05-09 | 北京达佳互联信息技术有限公司 | Link data acquisition method, device, system, electronic equipment and storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107404420A (en) * | 2017-09-11 | 2017-11-28 | 北京奇艺世纪科技有限公司 | One kind calls link method for monitoring performance and device |
| CN107493208A (en) * | 2017-08-30 | 2017-12-19 | 苏州朗动网络科技有限公司 | Full the link performance monitoring method and system of a kind of medium-and-large-sized operation system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104750741A (en) * | 2013-12-30 | 2015-07-01 | 中国移动通信集团湖南有限公司 | Invalid link processing method and invalid link processing device |
| CN108038201B (en) * | 2017-12-12 | 2019-05-21 | 无锡华云数据技术服务有限公司 | A kind of data integrated system and its distributed data integration system |
| CN108037973B (en) * | 2017-12-20 | 2021-11-16 | 苏州优圣美智能系统有限公司 | Data flow modeling and processing system interacting with data processing tool |
-
2018
- 2018-12-06 CN CN201811486884.0A patent/CN109560989B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107493208A (en) * | 2017-08-30 | 2017-12-19 | 苏州朗动网络科技有限公司 | Full the link performance monitoring method and system of a kind of medium-and-large-sized operation system |
| CN107404420A (en) * | 2017-09-11 | 2017-11-28 | 北京奇艺世纪科技有限公司 | One kind calls link method for monitoring performance and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109560989A (en) | 2019-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109560989B (en) | Link monitoring system | |
| CN108156006B (en) | Buried point data reporting method and device and electronic equipment | |
| CN107038162B (en) | Real-time data query method and system based on database log | |
| US10904112B2 (en) | Automatic capture of detailed analysis information based on remote server analysis | |
| CN110647512B (en) | Data storage and analysis method, device, equipment and readable medium | |
| CN110675194A (en) | Funnel analysis method, device, equipment and readable medium | |
| CN108471366A (en) | A kind of stereoscopic monitoring system of facing cloud native applications | |
| CN106815125A (en) | A kind of log audit method and platform | |
| CN111177165B (en) | Method, device and equipment for detecting data consistency | |
| US20160226736A1 (en) | Service call graphs for website performance | |
| US20160225042A1 (en) | Determining a cost of an application programming interface | |
| US10061678B2 (en) | Automated validation of database index creation | |
| CN111614483A (en) | Link monitoring method and device, storage medium and computer equipment | |
| CN103997662A (en) | Program pushing method and system | |
| CN102231673A (en) | System and method for monitoring business server | |
| CN110532428A (en) | Hot word configuration method, device, equipment and storage medium | |
| CN113762906A (en) | Method, device and equipment for alarming task period delay and storage medium | |
| WO2023109806A1 (en) | Method and apparatus for processing active data for internet of things device, and storage medium | |
| CN108564250A (en) | Forwarding record real time inspection system, method, computer equipment and storage medium | |
| CN110336889B (en) | Intelligent monitoring platform and monitoring method for operation in numerical weather forecast mode | |
| CN112764988A (en) | Data segmentation acquisition method and device | |
| CN108694107A (en) | Backlog monitoring method, device, readable medium and the electronic equipment of message queue | |
| CN104317820B (en) | Statistical method and device for report forms | |
| US10616306B2 (en) | System and method for large-scale capture and tracking of web-based application parameters | |
| Chhetri et al. | CL-SLAM: Cross-layer SLA monitoring framework for cloud service-based applications |
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 |