WO2019051948A1 - 监控数据的处理方法、设备、服务器及存储介质 - Google Patents

监控数据的处理方法、设备、服务器及存储介质 Download PDF

Info

Publication number
WO2019051948A1
WO2019051948A1 PCT/CN2017/108457 CN2017108457W WO2019051948A1 WO 2019051948 A1 WO2019051948 A1 WO 2019051948A1 CN 2017108457 W CN2017108457 W CN 2017108457W WO 2019051948 A1 WO2019051948 A1 WO 2019051948A1
Authority
WO
WIPO (PCT)
Prior art keywords
monitoring data
application
request message
server
sent
Prior art date
Application number
PCT/CN2017/108457
Other languages
English (en)
French (fr)
Inventor
池红露
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019051948A1 publication Critical patent/WO2019051948A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents

Definitions

  • the present application relates to the field of network communication technologies, and in particular, to a method, a device, a server, and a storage medium for processing data.
  • the data source of the analysis is generally the data in the monitoring log, and the network data monitoring, device monitoring, etc. are achieved by analyzing the log data in the monitoring log. purpose.
  • a method, device, server, and storage medium for processing data are provided.
  • a method of processing monitoring data including:
  • the plug-in installed in the application is also run, and the plug-in is used to collect the request message sent by the application;
  • the monitoring data is sent to the server, and the server is instructed to monitor according to the monitoring data.
  • a method of processing monitoring data including:
  • Receiving monitoring data sent by at least two monitored devices including a device for processing a request message corresponding to the same universal unique identifier, the device running an application, obtained and organized by a plug-in in the application a request message sent by the application to obtain the monitoring data;
  • the monitored device is monitored according to the attribute parameter.
  • a first processing device for monitoring data comprising:
  • a plug-in running module for running an application, and simultaneously running a plug-in installed in the application, the plug-in is used to collect a request message sent by the application;
  • a request message obtaining module configured to acquire the request message when the request message is sent by the application
  • An organization module configured to reorganize the request message according to a preset rule to obtain monitoring data
  • the monitoring data sending module is configured to send the monitoring data to the server, and instruct the server to perform monitoring according to the monitoring data.
  • a second processing device for monitoring data comprising:
  • the monitoring data receiving module is configured to receive monitoring data sent by at least two monitored devices, where the at least two devices include a device that processes a request message corresponding to the same universal unique identifier, and the device runs an application through the application.
  • the plugin in the program gets and organizes the application to send Sending a request message to obtain the monitoring data;
  • a parsing module for parsing attribute parameters in the monitoring data
  • the monitoring module is configured to monitor the monitored device according to the attribute parameter.
  • a monitored device includes a memory and a processor having stored therein computer readable instructions that, when executed by the processor, cause the processor to perform the following steps:
  • the plug-in installed in the application is also run, and the plug-in is used to collect the request message sent by the application;
  • the monitoring data is sent to the server, and the server is instructed to monitor according to the monitoring data.
  • a server comprising a memory and a processor, the memory storing computer readable instructions, the computer readable instructions being executed by the processor such that the processor performs the following steps:
  • Receiving monitoring data sent by at least two monitored devices including a device for processing a request message corresponding to the same universal unique identifier, the device running an application, obtained and organized by a plug-in in the application a request message sent by the application to obtain the monitoring data;
  • the monitored device is monitored according to the attribute parameter.
  • One or more non-transitory readable storage mediums storing computer readable instructions, when executed by one or more processors, cause the one or more processors to perform the following steps:
  • the plug-in installed in the application is also run, and the plug-in is used to collect the request message sent by the application;
  • the monitoring data is sent to the server, and the server is instructed to monitor according to the monitoring data.
  • One or more non-transitory readable storage mediums storing computer readable instructions, when executed by one or more processors, cause the one or more processors to perform the following steps:
  • Receiving monitoring data sent by at least two monitored devices including a device for processing a request message corresponding to the same universal unique identifier, the device running an application, obtained and organized by a plug-in in the application a request message sent by the application to obtain the monitoring data;
  • the monitored device is monitored according to the attribute parameter.
  • FIG. 1 is a flow chart of a method for processing monitoring data according to an embodiment of the present application
  • FIG. 2 is a flowchart of a method for processing monitoring data according to another embodiment of the present application.
  • FIG. 3 is a flowchart of a method for processing monitoring data applied to a server according to an embodiment of the present application
  • FIG. 4 is a flowchart of a usage scenario of a method for processing monitoring data according to an embodiment of the present application
  • FIG. 5 is a flow chart of a usage scenario of a method for processing monitoring data according to another embodiment of the present application.
  • FIG. 6 is a block diagram showing an exemplary structure of a first processing device for monitoring data according to an embodiment of the present application
  • FIG. 7 is a block diagram showing an exemplary structure of a second processing device for monitoring data according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram showing the internal structure of a device to be monitored according to an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an internal structure of a server according to an embodiment of the present application.
  • FIG. 1 is a flowchart of a method for processing monitoring data according to an embodiment of the present application.
  • a method for processing monitoring data according to an embodiment of the present application is described in detail below with reference to FIG. 1, and the method is applied to a device to be monitored.
  • the device may be a terminal device or a server.
  • the processing method of the monitoring data includes the following steps S101 to S104.
  • the running application is an application installed on the local end (or the application end). Since the local end can be used as a monitored device, the application can also be understood as an application installed on the monitored device.
  • the plugin is used to obtain the request message sent by the application, and is used to reorganize the request message according to a preset rule to obtain monitoring data, and may also be used for
  • the monitoring data is sent to the server, and the server is instructed to perform monitoring according to the monitoring data.
  • the application can be an application installed on the monitored device, and a plug-in is installed in the application at the same time.
  • the device includes but not Limited to mobile phones, tablets, personal PCs, self-service devices, etc.
  • the application can be an APP (Application) application installed on the device.
  • the application installed with the plug-in may be one or several applications in the device, and when the application is running, the plug-ins installed in the corresponding application run simultaneously.
  • the step of simultaneously running the plug-in installed in the application includes: running the application by starting a new process, and opening a thread for running the plug-in in the process of the application.
  • a main process needs to be separately obtained to obtain the log data.
  • the traditional solution obtains the monitoring data in the log by using a separate process, which increases the resource loss and makes a main After the process crashes, it is more difficult to restart the main process, and the second is to increase the crash rate of the total main process.
  • the plugin is run by a thread in the process of the application, and the plugin is made on the one hand.
  • the running time matches the running time of the corresponding application, and the plugin will not run at the inappropriate time. On the other hand, it has no effect on the total main process crash rate.
  • the plugin's thread has an exception, restart the The thread can be used.
  • the restarting thread must be lower in difficulty and workload than the traditional scheme.
  • the request message is a normal data request of the application, for example, when the monitored first device sends a request message for the network resource to the monitored second device, the terminal request in the step
  • the message may be a request message that the first device normally sends to the second device requesting the network resource.
  • the preset rule in the step may be data in the extraction request message indicating that the request message is in each stage of a life cycle, and the preset rule is used to indicate that the system is in the request data.
  • the data is reorganized to form monitoring data, which is sent to the server where the monitoring platform is located, and the server monitors the local and other monitored devices according to the monitoring data.
  • the preset gauge The different monitoring tasks may be different according to the settings of the programmer. For example, when the monitoring task is set to monitor the network time between different devices to be monitored, the preset rule is a request message involved in the request message.
  • the transmission time, the reception time of the response message, the UUID, the source IP, and the destination IP are reorganized, and the above monitoring data is the data after reorganization.
  • One of the request messages can be uniquely determined by a UUID (Universally Unique Identifier).
  • the UUID is a software construction standard.
  • the sending of a request message and the response to the request message are all the same UUID, and its life cycle.
  • the attribute parameters carried in the request messages at different stages in the life cycle are different, and the preset rules here correspond to the attribute parameters carried in the respective stages.
  • the request message when the request message is in the sending phase, the request message includes parameters such as a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, and the like, wherein the request method is The name can be delete, get, trace, or ping, etc.; when the request message is in the response phase, the request message contains parameters such as UUID, time of receiving the request data, business parameters, response header, request method name, and returned Specific data and so on.
  • parameters such as a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, and the like, wherein the request method is The name can be delete, get, trace, or ping, etc.
  • the request message when the request message is in the response phase, the request message contains parameters such as UUID, time of receiving the request data, business parameters, response header, request
  • the reorganizing the request message may be extracting and integrating the attribute parameters in the phase of the life cycle of the request message.
  • S104 Send the monitoring data to the server, and instruct the server to perform monitoring according to the monitoring data.
  • the server receives monitoring data sent by at least two monitored devices.
  • the monitoring data received by the server is a request message.
  • the plug-in in the sender device is collected, and the other is collected by the plug-in in the receiving processor device of the request message.
  • the step of sending the monitoring data to the server in the foregoing step S104 includes:
  • the monitoring data is sent to the server;
  • the monitoring data is sent to the server when the interval is greater than the preset value.
  • This embodiment provides two timings for transmitting monitoring data, one is to judge the timing of sending the corresponding monitoring data according to the quantity of the monitoring data, and the other is the time of sending the monitoring data to the server last time according to the current time distance.
  • the time interval is used to determine the timing of transmission of the corresponding monitoring data.
  • a preset when the number of accumulated monitoring data is used as the timing for transmitting the monitoring data, a preset may be performed.
  • the preset value may be set to 500, that is, the number of accumulated monitoring data.
  • the preset may also be performed.
  • the preset value may be set to 1 minute, that is, when the current time is The accumulated monitoring data is transmitted to the server when the time interval between the times when the monitoring data was last transmitted exceeds 1 minute.
  • the monitoring data organized before the condition that the preset value is satisfied or the preset time interval may be stored in the cache, when the preset value is the condition or the preset When the condition of this interval is satisfied, the stored monitoring data is sent to the server together.
  • the cumulative transmission of the monitoring data is compared to the separate transmission of each monitoring data, which can reduce the number of network interactions.
  • the data processing pressure of the application end and the server end can be alleviated. It can reduce unnecessary data transmission in the network.
  • the method further includes the following steps: when receiving the upgrade instruction of the plug-in, performing an upgrade process on the plug-in installed in the application.
  • the original plug-in installed in the application can be replaced with the new plug-in to complete the upgrade of the plug-in.
  • the upgrade instruction corresponding to obtaining the new plug-in may be defaulted by the system, the default is upgrade or no upgrade, or may be upgraded by a user input, and when the user inputs an upgrade instruction, the new plug-in is downloaded. , where the user can download the new plugin by clicking the upgrade button on the terminal screen.
  • the above instructions for determining the upgrade can also be defaulted by the system. By default, the new plug-in is not installed or installed, and the user can also update the plug-in by clicking the upgrade button on the terminal screen.
  • the request message sent by the application is collected by the plug-in, and the request message is re-organized to generate monitoring data. And sending the monitoring data to the server, so that the server monitors each monitored device according to the monitoring data.
  • the present application collects and organizes the sent data into monitoring data when sending the request data, does not need to invade the system where the application is located, and does not need to decompile the requested data.
  • the monitoring data provided by the present application
  • the processing method, device, server and storage medium can make the original system of the device more stable and reduce the workload of the developer on the basis of the monitoring purpose.
  • FIG. 2 is a flowchart of a method for processing monitoring data applied to a server according to another embodiment of the present application.
  • a method for processing monitoring data according to another embodiment of the present application is described in detail below with reference to FIG. It is to be noted that the processing method of the monitoring data includes the above steps S101, S102, and S103, and the above step S103 includes the following steps S201 to S203.
  • the above-mentioned universal unique identification code is UUID (Universally Unique Identifier).
  • UUID Universalally Unique Identifier
  • the parsing the attribute parameter may be data in the extraction request message indicating that the request message is in each stage of a life cycle.
  • the attribute parameters carried in the request messages at different stages in the life cycle are different, and the preset rules here correspond to the attribute parameters carried in each stage.
  • the request message when the request message is in the sending phase, the request message includes parameters such as a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, and the like, wherein the request method is The name can be delete, get, trace, or ping, etc.; when the request message is in the response phase, the request message contains parameters such as UUID, time of receiving the request data, business parameters, response header, request method name, and returned Specific data and so on.
  • parameters such as a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, and the like, wherein the request method is The name can be delete, get, trace, or ping, etc.
  • the request message when the request message is in the response phase, the request message contains parameters such as UUID, time of receiving the request data, business parameters, response header, request
  • the organization is based on integrating and encapsulating the attributes of the request message belonging to the same UUID and the corresponding attribute parameters to form monitoring data.
  • FIG. 3 is a flowchart of a method for processing monitoring data applied to a server according to an embodiment of the present application.
  • a method for processing monitoring data applied to a server according to an embodiment of the present application is described in detail below with reference to FIG. 3, which As shown in FIG. 3, the processing method of the monitoring data includes the following steps S301 to S303.
  • S301 Receive monitoring data sent by at least two monitored devices, where the at least two devices include a device that processes a request message corresponding to the same universal unique identifier, where the application runs through an application.
  • the plugin acquires and organizes a request message sent by the application to obtain the monitoring data.
  • the server receives monitoring data sent by at least two monitored devices.
  • the monitoring data received by the server is one of the sender devices of the request message.
  • the plug-in is collected by the plug-in, and the other is the plug-in collected by the receiving device of the request message.
  • the server can only receive the monitoring data sent by the corresponding two monitored devices.
  • the server may Receiving the request message sent by all the servants and the consuming party, if the request message of all the servants or the consuming party is not received, it indicates that there is a problem in one of the data transmission links.
  • All of the methods for processing the monitoring data to which the present embodiment is applied need to be installed with a plug-in for collecting the request message in the corresponding application.
  • the parameter included in the monitoring data includes, but is not limited to, a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, etc., when the request message is in a sending phase.
  • the request method name may be delete, get, trace, or ping, etc., and the parsing operation in the step is to parse the UUID, the request sending time, and the service.
  • the request message includes parameters including but not limited to UUID, time when the request data is received, The service parameter, the response header, the request method name, the returned specific data, and the like.
  • the parsing operation in the step is to parse the UUID, the time when the request data is received, the service parameter, the response header, the request method name, and the return. Specific data and so on.
  • the local device may perform various forms of monitoring on each monitored device according to the attribute parameter.
  • the network delay may be monitored according to the corresponding sending time and receiving time, and the corresponding device may be monitored accordingly. and many more.
  • the method for processing the monitoring data applied to the server includes the steps S301 to S303, the attribute parameter includes a time T1 at which the first device sends the request message, and the second device receives the request.
  • the time T2 of the message, the time T3 when the second device sends the response message of the request message, and the time T4 when the first device receives the response message, the step of monitoring the monitored device according to the attribute parameter includes:
  • the value of (T4-T1)-(T3-T2) is calculated, and the calculated value is used as the network time between the first device and the second device.
  • This embodiment can avoid the misjudgment of the network quality when the time bases of the caller and the service party are inconsistent.
  • the local time of the service party is ten points and the local time of the caller is nine points, which is provided by this embodiment.
  • the time-consuming calculation method of the network does not cause misjudgment of the actual network quality.
  • the solution further includes setting a permission on the monitoring server to limit which data can be viewed or modified, wherein the setting object of the permission is monitoring data belonging to the same level on the device to be monitored, for example, Network layer data, application layer data, host operating status of the monitoring device, or the middleware data described above.
  • the setting object of the permission is monitoring data belonging to the same level on the device to be monitored, for example, Network layer data, application layer data, host operating status of the monitoring device, or the middleware data described above.
  • the user can obtain access/modification on the same level by applying only one authentication. Permission to monitor data.
  • different types of monitors responsible for monitoring each task may be installed on the server where the monitoring platform is located, and each monitor is responsible for a monitoring task for monitoring request data at different levels.
  • the network layer data, the application layer data, the host running status of the monitored device, or the middleware data described above are respectively configured with the monitor 1, the monitor 2, the monitor 3, and the monitor 4 for monitoring the request data of the corresponding layer.
  • the monitor 1 is for monitoring network layer data
  • the monitor 2 is for monitoring application layer data
  • the monitor 3 is for monitoring the host running state of the monitored device
  • the monitor 4 is for monitoring middleware data, wherein the middle of the above
  • the piece of data may be data other than network layer data, application layer data, and data representing the running state of the host of the monitored device.
  • FIG. 4 is a flow chart of a usage scenario of a method for processing monitoring data according to an embodiment of the present application.
  • the monitoring platform shown in FIG. 4 may be a server, and system A and system B in FIG. 4 may be differently monitored.
  • the device, wherein the monitored device may be a terminal device such as a mobile phone, a tablet, a PC, or a server, and different monitored devices corresponding to System A and System B send respective integrated monitoring data to the monitoring platform for monitoring.
  • the monitor, the Filter in Figure 4 represents the filter of the corresponding module itself, and the Esg-stub represents the plugin.
  • the monitoring function in the plug-in is mainly based on the filter mode in the servlet standard.
  • the Filter mode is for filtering the http requests of all processing services based on the servlet standard, and each request can be obtained in the filtering process. All data details, such as the source IP address of the service request, the time the service request enters the server, and the time the service is executed. If the information about the error of the service can also be captured and sent to the monitoring platform, the operation and maintenance personnel of the business system can analyze the error information. For example, the time of data transmission in the network can also be analyzed by the time data of the consumer and the service party.
  • FIG. 5 is a flow chart of a usage scenario of a method for processing monitoring data according to another embodiment of the present application, and FIG. 5 illustrates a flow of processing and processing of the same request message between different monitored devices.
  • the plug-in in the calling device obtains the request message
  • the attribute parameters such as the ID, the source IP, the request start time, and the request end time in the request message are extracted, and the parameter is integrated into the monitoring data.
  • the monitoring data is placed in the queue and the data in the queue is tracked.
  • a preset value for example, 500
  • the time interval between the current time and the time when the monitoring data is sent to the server last time is greater than a preset value (for example, 1 minute)
  • a preset value for example, 1 minute
  • the plug-in in the servant device obtains the request message
  • the tracking event of the same request message ID is created, and the attribute parameters such as the ID, the source IP, the request start time, and the request end time in the request message are extracted, and the attribute parameter is extracted.
  • the monitoring data is placed in the queue, and the data in the queue is tracked.
  • a preset value for example, 500
  • the current time distance is sent to the server last time.
  • the time interval between the times of the monitoring data is greater than a preset value (for example, when the time is 1 minute)
  • the corresponding monitoring data is sent to the server to ensure that the normal service of the service party is not affected by the monitoring.
  • the request message involved in this embodiment includes the original request message sent by the monitored device, and further includes an response response message that is processed by the monitored device according to the original request message.
  • the labels of the foregoing steps S101-S303 are not used to limit the sequence of the steps in the embodiment, and the numbers of the steps are only for the convenience of referring to the labels of the steps when describing the steps.
  • the above step S201 may be performed before the step of S202 or after the step of step S202, as long as the order of execution of the respective steps does not affect the logical relationship of the embodiment, which is within the scope of the claimed application.
  • FIG. 6 is a block diagram showing an exemplary structure of a first processing device for monitoring data according to an embodiment of the present application.
  • a first processing device for monitoring data according to an embodiment of the present application is described in detail below with reference to FIG. As shown, the first processing device 10 of the monitoring data includes:
  • the plug-in running module 11 is configured to simultaneously run a plug-in installed in the application when the application is running, and the plug-in is used to collect a request message sent by the application;
  • the request message obtaining module 12 is configured to acquire the request message when the request message is sent by the application;
  • the organization module 13 is configured to reorganize the request message according to a preset rule to obtain monitoring data.
  • the monitoring data sending module 14 is configured to send the monitoring data to the server, and instruct the server to perform monitoring according to the monitoring data.
  • the preset rule for example, extracts data in the request message indicating that the request message is in each stage of a life cycle. Since the attribute parameters carried in the request message at different stages in the life cycle are different, the preset rule here corresponds to the attribute parameter carried in each stage.
  • the request message when the request message is in the sending phase, the request message includes parameters such as a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, and the like, wherein the request method is The name can be delete, get, trace, or ping, etc.; when the request message is in the response phase, the request message contains parameters such as UUID, time of receiving the request data, business parameters, response header, request method name, and returned Specific data and so on.
  • parameters such as a UUID, a request sending time, a service parameter, a request header, a request method name, a request address (URL), a source port, a source IP, and the like, wherein the request method is The name can be delete, get, trace, or ping, etc.
  • the request message when the request message is in the response phase, the request message contains parameters such as UUID, time of receiving the request data, business parameters, response header, request
  • the organizational module 13 further includes:
  • a first parsing unit configured to parse the universal unique identifier included in the request message
  • a second parsing unit configured to parse an attribute parameter in the request message corresponding to the same universal unique identifier
  • an organization unit configured to organize the universal unique identifier and the set of the attribute parameters into the monitoring data.
  • the organization module 13 may be organized according to the stage in which the request message belonging to the same UUID is located and the attribute parameters in the corresponding stage are integrated and encapsulated to form monitoring data.
  • the plug-in running module 11 further includes:
  • a thread open unit for opening a thread for running the plugin in the process of the application is a thread open unit for opening a thread for running the plugin in the process of the application.
  • the processing device for monitoring data further includes:
  • the plug-in upgrading unit is configured to upgrade the plug-ins installed in the application when receiving the upgrade instruction of the plug-in.
  • the monitoring data sending module 14 is specifically configured to:
  • the monitoring data is sent to the server;
  • the monitoring data is sent to the server when the time interval between the current time and the time when the monitoring data was last sent to the server is greater than a preset value.
  • each module included in the first processing device of the monitoring data may be implemented in whole or in part by software, hardware or a combination thereof. Further, each module in the first processing device of the monitoring data may be a program segment for implementing a corresponding function.
  • the various modules in the first processing device of the above monitoring data may be implemented in whole or in part by software, hardware, and combinations thereof.
  • the network interface may be an Ethernet card or a wireless network card.
  • the above modules may be embedded in the hardware in the processor or in the memory in the server, or may be stored in the memory in the server, so that the processor calls the corresponding operations of the above modules.
  • the processor can be a central processing unit (CPU), a microprocessor, a microcontroller, or the like.
  • the first processing device of the above monitoring data can be implemented in the form of a computer readable instruction that can be run on a device that is monitored as shown in FIG.
  • FIG. 7 is a block diagram showing an exemplary structure of a second processing device for monitoring data according to an embodiment of the present application.
  • a second processing device for monitoring data according to an embodiment of the present application is described in detail below with reference to FIG. As shown, the second processing device 20 of the monitoring data includes:
  • the monitoring data receiving module 21 is configured to receive monitoring data sent by at least two monitored devices, where the at least two devices include a device that processes a request message corresponding to the same universal unique identifier, where the application runs an application, The plug-in in the application acquires and organizes the request message sent by the application to obtain the monitoring data;
  • the parsing module 22 is configured to parse attribute parameters in the monitoring data
  • the monitoring module 23 is configured to monitor the monitored device according to the attribute parameter.
  • the attribute parameter includes a time T1 when the first device sends the request message, a time T2 when the second device receives the request message, and a time T3 when the second device sends the response message of the request message.
  • the time T4 when the first device receives the response message, the monitoring module 23 is specifically configured to:
  • the value of (T4-T1)-(T3-T2) is calculated, and the calculated value is used as the network time between the first device and the second device.
  • the various modules in the second processing device of the above monitoring data may be implemented in whole or in part by software, hardware, and combinations thereof.
  • the network interface may be an Ethernet card or a wireless network card.
  • the above modules may be embedded in the hardware in the processor or in the memory in the server, or may be stored in the memory in the server, so that the processor calls the corresponding operations of the above modules.
  • the processor can be a central processing unit (CPU), a microprocessor, a microcontroller, or the like.
  • the second processing means of the above monitoring data may be implemented in the form of a computer readable instruction which may be run on a server as shown in FIG.
  • first and second in the above-mentioned first parsing unit and second parsing unit are only to distinguish two parsing units, and are not used to limit which parsing unit has higher priority or other restrictions. significance.
  • each module included in the second processing device of the monitoring data may be implemented in whole or in part by software, hardware or a combination thereof. Further, each module in the second processing device of the monitoring data may also be a program segment for implementing a corresponding function.
  • a monitored device includes a memory, a processor, and computer readable instructions stored on the memory and executable on the processor, the processor performing the above monitoring when the program is executed The method of processing data.
  • FIG. 8 is a schematic diagram of an internal structure of a monitored device according to an embodiment of the present application, and the monitored device may be a server.
  • the apparatus includes a processor coupled through a system bus, a non-volatile storage medium, an internal memory, an input device, and a network interface.
  • the non-volatile storage medium of the device may store an operating system and computer readable instructions, and when the computer readable instructions are executed, the processor may be caused to execute the processing method of the monitoring data applied to the device in various embodiments of the present application.
  • the specific implementation process of the method may refer to the specific content of each embodiment of FIG. 1 and FIG. 2, and details are not described herein again.
  • the device's processor is used to provide computing and control capabilities to support the operation of the entire device.
  • the internal memory can store computer readable instructions that, when executed by the processor, cause the processor to perform a method of processing the monitored data.
  • the input device of the device is used for input of various parameters, and the network interface of the device is used for network communication.
  • the structure shown in FIG. 8 is only a block diagram of a part of the structure related to the solution of the present application, and is not Having a definition of the apparatus to which the present application is applied, the specific apparatus may include more or less components than those shown in the drawings, or some components may be combined, or have different component arrangements.
  • a server includes a memory, a processor, and computer readable instructions stored on the memory and executable on the processor, the processor executing the program to implement the processing of the monitoring data described above. method.
  • FIG. 9 is a schematic diagram of an internal structure of a server according to an embodiment of the present application.
  • the server includes a processor coupled through a system bus, a non-volatile storage medium, an internal memory, an input device, and a network interface.
  • the non-volatile storage medium of the server may store an operating system and computer readable instructions, and when the computer readable instructions are executed, may cause the processor to execute the processing method of the monitoring data applied to the server in various embodiments of the present application.
  • the specific implementation process of the method may refer to the specific content of each embodiment in FIG. 3, and details are not described herein again.
  • the server's processor is used to provide computing and control capabilities that support the operation of the entire server.
  • the internal memory can store computer readable instructions that, when executed by the processor, cause the processor to perform a method of processing the monitored data.
  • the server's input device is used for input of various parameters, and the server's network interface is used for network communication. It will be understood by those skilled in the art that the structure shown in FIG. 9 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the server to which the solution of the present application is applied.
  • the specific server may include a ratio. More or fewer components are shown in the figures, or some components are combined, or have different component arrangements.
  • any reference to a memory, storage, database or other medium as used herein by a device or server may include non-volatile and/or volatile memory.
  • Suitable non-volatile memories can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory.
  • the embodiment further provides a computer readable storage medium having stored thereon computer readable instructions, which are executed by the processor to implement various steps in the method for processing the monitoring data.
  • the steps in the processing method of the monitoring data applied to the device are implemented, or the foregoing application to the server may be implemented. Monitor each step in the data processing method.
  • all or part of the processes in the foregoing embodiment may be completed by using computer readable instructions to instruct related hardware, and the program may be stored in a computer readable storage medium, such as
  • the program can be stored in a storage medium of the computer system and executed by at least one processor in the computer system to implement a process including an embodiment of the methods described above.
  • the storage medium includes, but is not limited to, a magnetic disk, a USB flash drive, an optical disk, and the like.
  • Access speed and quality This solution is based on the filter filter in the servlet standard to monitor services. For many existing systems that are running, you can install the related functions that can be implemented in this application just like installing a plug-in. It will only make a slight change to the business side. In the traditional way of log-based, the system of the business party must transform their system according to the log format developed by the monitoring system. The amount of engineering to be transformed is conceivable, and it may be affected by a slight carelessness.
  • the log-based monitor in the traditional solution needs to maintain the stability of the business process, the log format, and the log collector process. If there is a problem in one place, the monitoring information will not be caused. accurate.
  • the monitoring platform in this application packages the collection of monitoring information, assembles the data into a plug-in, and most importantly, puts the corresponding application in a process, and the probability of occurrence of the problem is definitely higher than that based on the log monitor. The problem is much lower.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Abstract

一种监控数据的处理方法、设备、服务器及存储介质，属于网络通信技术领域。该监控数据的处理方法包括：运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；当通过该应用程序发送该请求消息时，获取该请求消息；按照预设的规则对该请求消息进行重新组织，以得到监控数据；将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。

Description

监控数据的处理方法、设备、服务器及存储介质
本申请要求于2017年9月15日提交中国专利局、申请号为2017108355725、发明名称为“监控数据的处理方法、设备、服务器及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及网络通信技术领域，特别是涉及监控数据的处理方法、设备、服务器及存储介质。
背景技术
目前，对于数据的监控，或者对网络质量、被监控设备的性能进行分析，分析的数据来源一般是监控日志中的数据，通过分析监控日志中的日志数据来达到网络质量监控、设备的监控等目的。
但是由于不用的应用中日志编写的格式等要求与该应用所在的系统平台是对应的，不同的应用也会通过不同的格式来编写日志，在监控不同设备之间的网络质量、或业务数据时，如果按照现在传统的方法将日志中记载的数据作为数据源来进行监控分析，一方面需要按照该日志所对应的应用中规定的格式进行反编译，增加了工作量，另一方面对该日志进行反编译会造成对该日志所在的系统进行侵入，由于监控日志在很多情况下会用到，还可能会对原系统造成破坏。
发明内容
根据本申请的各种实施例，提供一种监控数据的处理方法、设备、服务器及存储介质。
一种监控数据的处理方法，包括：
运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
当通过该应用程序发送该请求消息时，获取该请求消息；
按照预设的规则对该请求消息进行重新组织，以得到监控数据；及
将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
一种监控数据的处理方法，包括：
接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
解析该监控数据中的属性参数；及
根据该属性参数对该被监控的设备进行监控。
一种监控数据的第一处理装置，包括：
插件运行模块，用于运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
请求消息获取模块，用于当通过该应用程序发送该请求消息时，获取该请求消息；
组织模块，用于按照预设的规则对该请求消息进行重新组织，以得到监控数据；及
监控数据发送模块，用于将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
一种监控数据的第二处理装置，包括：
监控数据接收模块，用于接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发 送的请求消息，以得到所述监控数据；
解析模块，用于解析该监控数据中的属性参数；及
监控模块，用于根据该属性参数对该被监控的设备进行监控。
一种被监控的设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行以下步骤：
运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
当通过该应用程序发送该请求消息时，获取该请求消息；
按照预设的规则对该请求消息进行重新组织，以得到监控数据；及
将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
一种服务器，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行以下步骤：
接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
解析该监控数据中的属性参数；及
根据该属性参数对该被监控的设备进行监控。
一个或多个存储有计算机可读指令的非易失性可读存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
当通过该应用程序发送该请求消息时，获取该请求消息；
按照预设的规则对该请求消息进行重新组织，以得到监控数据；及
将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
一个或多个存储有计算机可读指令的非易失性可读存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
解析该监控数据中的属性参数；及
根据该属性参数对该被监控的设备进行监控。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为根据本申请的一个实施例的监控数据的处理方法流程图；
图2为根据本申请的另一实施例的监控数据的处理方法流程图；
图3为根据本申请的一个实施例的应用于服务器的监控数据的处理方法流程图；
图4为根据本申请的一个实施例的监控数据的处理方法的使用场景流程图；
图5为根据本申请的另一实施例的监控数据的处理方法的使用场景流程 图；
图6为根据本申请的一个实施例的监控数据的第一处理装置的示范性结构框图；
图7为根据本申请的一个实施例的监控数据的第二处理装置的示范性结构框图；
图8为根据本申请的一个实施例的被监控的设备的内部结构示意图；
图9为根据本申请的一个实施例的服务器的内部结构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
图1为根据本申请的一个实施例的监控数据的处理方法流程图，下面结合图1来详细描述根据本申请的一个实施例的监控数据的处理方法，该方法应用于被监控的设备，该设备可以是终端设备，也可以是服务器，如图1所示，该监控数据的处理方法包括以下步骤S101至S104。
S101、运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息。
其中，运行的应用程序为安装在本端(或者说是应用端)的应用程序，由于本端可以作为被监控的设备，该应用程序也可以理解为安装在被监控设备上的应用程序。
在其中的一个实施例中，该插件除了用于获取上述应用程序发送的请求消息，还用于按照预设的规则对所述请求消息进行重新组织，以得到监控数据，还可以用于将所述监控数据发送给服务器，指示所述服务器根据所述监控数据进行监控。
在该步骤中，该应用程序可以是安装在被监控的设备上的应用程序，且该应用程序内同时安装有插件。根据本实施例的一个示例，该设备包括但不 限于手机、平板电脑、个人PC机、自助设备等等，该应用程序可以是安装在设备上的APP(Application)应用程序。
根据本实施例的一个示例，安装有该插件的应用程序可以是设备中的某一个或者某几个应用程序，当该应用程序运行时，安装在对应应用程序内的插件同时运行。
根据本实施例的另一示例，同时运行安装在该应用程序中的插件的步骤包括：通过开启新的进程运行该应用程序，在该应用程序的进程中开启用于运行该插件的线程。该示例一改传统方案中在根据日志做数据监控时需要单独起一个主进程来获取日志数据，传统方案通过单独起进程的方法获取日志中的监控数据一是加大了资源损耗，使得一个主进程崩溃后，重起该主进程会更为困难，二是增加了总的主进程的崩溃率，本实施例通过在该应用程序的进程中起一个线程的方式运行该插件，一方面使得插件运行的时间与对应的应用程序运行的时间相符，不会在不合适的时间运行该插件，另一方面对总的主进程的崩溃率没有影响，当该插件的线程出现异常时，重起该线程即可，本实施例中重起线程肯定要比传统方案中重起进程的在难度及工作量上都要低。
S102、当通过该应用程序发送该请求消息时，获取该请求消息。
根据本实施例的一个示例，该请求消息为该应用程序正常的数据请求，例如，当被监控的第一设备向被监控的第二设备发送网络资源的请求消息时，该步骤中的终端请求消息可以是该第一设备向该第二设备正常发出的请求该网络资源的请求消息。
S103、按照预设的规则对该请求消息进行重新组织，以得到监控数据。
根据本实施例的一个示例，该步骤中预设的规则可以是提取请求消息中表示该请求消息在一个生命周期内各个阶段内的数据，该预设的规则用于指示系统对该请求数据中的哪些数据进行重新组织，以形成监控数据，该监控数据用于发送给监控平台所在的服务器，供该服务器依据所述监控数据对本端以及其它端被监控的设备进行监控。在其中的一个实施例中，该预设的规 则对于不同的监控任务可以因程序员设置的不同而不同，例如，当设置监控任务为监控不同待监控设备之间的网络耗时时，则该预设的规则为对请求消息中涉及的请求消息的发送时间、应答消息的接收时间、UUID、源IP、目的端IP进行重新组织，上述的监控数据为重新组织之后的数据。
其中一个请求消息可以由一个UUID(Universally Unique Identifier，通用唯一识别码)来唯一确定，UUID是一个软件建构的标准，一个请求消息的发送及对该请求消息的应答均属同一UUID，其生命周期为一个请求消息的结束，其中，位于生命周期中不同阶段的请求消息携带的属性参数是不同的，这里的预设的规则与各个阶段中携带的属性参数相对应。例如当该请求消息处于发送阶段时，该请求消息包含的参数有UUID、请求发送时间、业务参数、请求头、请求方法名、请求地址(URL)、源端口、源IP等，其中的请求方法名可以是delete、get、trace或ping等等；当该请求消息处于响应阶段时，该请求消息包含的参数有UUID、收到请求数据的时间、业务参数、响应头、请求方法名、返回的具体数据等等。
其中，对该请求消息进行重新组织可以是对该请求消息所在生命周期的阶段内的属性参数进行提取和整合。
S104、将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
在其中一个实施例中，服务器接收至少两个被监控的设备发送的监控数据，当一个请求消息只会在两个被监控的设备之间进行传输时，该服务器接收的监控数据一个是请求消息的发送方设备中的插件采集的，另一个是请求消息的接收处理方设备中的插件采集的。
根据本实施例的一个示例，上述步骤S104中将该监控数据发送给服务器的步骤包括：
当得到的该监控数据的数量超过预设的数值时，将该监控数据发送给服务器；或
当当前时刻距离上一次向该服务器发送该监控数据的时刻之间的时间间 隔大于预设值时，将该监控数据发送给服务器。
本实施例提供了两种发送监控数据的时机，一个是根据按监控数据的数量来判断对应的监控数据发送的时机，另一个是根据当前时刻距离上一次向该服务器发送该监控数据的时刻的时间间隔来判断对应的监控数据的发送时机。
在其中一个实施例中，当将累积的监控数据的数量作为发送监控数据的时机时，可以进行预设，例如可以将上述预设的数值设定为500，即表示当累积的监控数据的数量超过500个时，将累积的监控数据发送给服务器；当将时间间隔作为发送监控数据的时机时，也可以进行预设，例如可以将上述预设值设定为1分钟，即表示当当前时刻距离上一次发送监控数据的时刻之间的时间间隔超过1分钟时，将累积的监控数据发送给服务器。根据该实施例的另一示例，在满足预设的数值这一条件或预设的时间间隔这一条件之前组织成的监控数据可以存储在缓存中，当预设的数值这一条件或预设的时间间隔这一条件被满足时，将存储的监控数据一起发送给服务器。
本实施例通过将监控数据进行累积发送相比于对每个监控数据单独发送，可以减少网络交互的次数，通过减少数据封装及数据解析的此处可以减轻应用端和服务器端的数据处理压力，还可以减少网络中不必要的数据传输。
根据本申请的另一实施例在包括上述步骤S101至S104的基础上，还包括以下步骤：当接收到该插件的升级指令时，对所述应用程序内安装的插件进行升级处理。根据本实施例的一个示例，可以用该新的插件替换安装在该应用程序中原始的插件来完成插件的升级。
根据本实施例的一个示例，上述获取新的插件对应的升级指令可以由系统默认，默认为升级或者不升级，也可以通过用户输入的确定升级，当用户输入升级的指令时，下载新的插件，其中，用户可以通过点击终端屏幕上的升级按钮来下载新的插件。同理，上述确定升级的指令也可以由系统默认，默认安装或是不安装该新的插件，用户也可以通过点击终端屏幕上的升级按钮来完成插件的更新。
本实施例通过在被监控的设备中的应用程序内安装插件，当该应用程序正常发送请求消息时，通过该插件采集该应用程序发送的请求消息，并将该请求消息重新组织以生成监控数据，再将该监控数据发送给服务器，供服务器依据该监控数据对各个被监控的设备进行监控。本申请通过在发送请求数据时，将发送的数据收集并组织为监控数据，不需要对该应用程序所在的系统做侵入，也不需要对该请求数据做反编译，本申请提供的监控数据的处理方法、设备、服务器及存储介质在可以达到监控目的的基础上，使得设备的原有系统更加稳定，同时还可降低开发人员的工作量。
图2为根据本申请的另一实施例的应用于服务器的监控数据的处理方法流程图，下面结合图2来详细描述根据本申请的另一实施例的监控数据的处理方法，如图2所示，该监控数据的处理方法在包括以上步骤S101、S102及S103的基础上，上述步骤S103包括以下步骤S201至S203。
S201、解析该请求消息中包含的通用唯一识别码。
根据本实施例的一个示例，上述的通用唯一识别码即UUID(UniversallyUnique Identifier)。当不同被监控的设备向本端发送具有同一UUID的请求数据时，本端将具有相同UUID的请求消息或应答消息关联起来，以便执行下述的步骤S202。
S202、解析同一通用唯一识别码对应的请求消息中的属性参数。
在其中一个实施例中，上述解析所述属性参数可以是提取请求消息中表示该请求消息在一个生命周期内各个阶段内的数据。其中，位于生命周期中不同阶段的请求消息携带的属性参数是不同的，这里的预设的规则与各个阶段中携带的属性参数相对应。例如当该请求消息处于发送阶段时，该请求消息包含的参数有UUID、请求发送时间、业务参数、请求头、请求方法名、请求地址(URL)、源端口、源IP等，其中的请求方法名可以是delete、get、trace或ping等等；当该请求消息处于响应阶段时，该请求消息包含的参数有UUID、收到请求数据的时间、业务参数、响应头、请求方法名、返回的具体数据等等。
S203、将该通用唯一识别码及该属性参数构成的集合组织为该监控数据。
其中，组织的依据是以将属于同一UUID的请求消息所在的阶段及对应阶段下的属性参数进行整合并封装，以形成监控数据。
图3为根据本申请的一个实施例的应用于服务器的监控数据的处理方法流程图，下面结合图3来详细描述根据本申请的一个实施例的应用于服务器的监控数据的处理方法，该方法应用于监控平台所在的服务器，如图3所示，该监控数据的处理方法包括以下步骤S301至S303。
S301、接收至少两个被监控的设备发送的监控数据，其中，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据。
其中，服务器接收至少两个被监控的设备发送的监控数据，当一个请求消息只会在两个被监控的设备之间进行传输时，该服务器接收的监控数据一个是请求消息的发送方设备中的插件采集的，另一个是请求消息的接收处理方设备中的插件采集的，该服务器可以只接收对应的两个被监控设备发送的监控数据。当一个请求消息需要在三个或者三个以上的被监控的设备之间进行传输和处理时，即当一个UUID对应消息的服务方和消费方的数量为三个或者三个以上时，服务器可以接收所有服务方和消费方发送的请求消息，若未接收到全部服务方或消费方的请求消息则表示其中的一个数据传输环节出现了问题。
其中，所有应用本实施例的监控数据的处理方法的被监控均需要在对应的应用程序中安装用于采集请求消息的插件。
S302、解析该监控数据中的属性参数。
其中，当该请求消息处于发送阶段时，该监控数据中包含的参数包括但不限于UUID、请求发送时间、业务参数、请求头、请求方法名、请求地址(URL)、源端口、源IP等，其中的请求方法名可以是delete、get、trace或ping等等，该步骤中的解析操作即解析上述的UUID、请求发送时间、业务 参数、请求头、请求方法名、请求地址(URL)、源端口、源IP等；当该请求消息处于响应阶段时，该请求消息包含的参数包括但不限于UUID、收到请求数据的时间、业务参数、响应头、请求方法名、返回的具体数据等等，此时，该步骤中的解析操作即解析上述的UUID、收到请求数据的时间、业务参数、响应头、请求方法名、返回的具体数据等等。
S303、根据该属性参数对该被监控的设备进行监控。
在其中一个实施例中，本端可以依据根据该属性参数对各个被监控的设备进行多种形式的监控，例如可以根据对应的发送时间和接收时间监控网络延时，可以监控对应设备是否有相应等等。
根据本实施例的一个示例，该应用于服务器端的监控数据的处理方法在包括上述步骤S301至S303的基础上，该属性参数包括第一设备发送该请求消息的时间T1、第二设备接收该请求消息的时间T2、该第二设备发送该请求消息的应答消息的时间T3、该第一设备接收该应答消息的时间T4，该根据该属性参数对该被监控的设备进行监控的步骤包括：
计算(T4-T1)-(T3-T2)的数值，将计算的所述数值作为该请求数据在该第一设备与该第二设备之间的网络耗时。
本实施例可以避免当调用方和服务方的时间基准不一致时，影响对网络质量的误判，例如同一个时刻服务方本地时间为十点，调用方本地时间为九点，通过本实施例提供的网路耗时的计算方法不会对实际的网络质量造成误判。
在其中的一个实施例中，该方案还包括可以在监控服务器上设置权限，限定哪个人可以查看或者修改哪些数据，其中，权限的设置对象是待监控设备上属于同一层面上的监控数据，例如网络层数据、应用层数据、监控设备的主机运行状态或上述的中间件数据。具体地，对于同一待监控设备上的不同应用程序，如果不同应用程序中的监控请求数据属于相同层面上的监控数据，则用户可以通过只申请一次鉴权来获得访问/修改该相同层面上的监控数据的权限。
在一个实施例中，还可以在监控平台所在的服务器上安装不同种类的负责监控各个任务的监控器，每一个监控器负责一个监控任务，用于监控不同层面的请求数据。例如，对网络层数据、应用层数据、被监控设备的主机运行状态或上述的中间件数据分别配置监控器1、监控器2、监控器3、监控器4，用于监控对应层面的请求数据，监控器1用于监控网络层数据，监控器2用于监控应用层数据，监控器3用于监控被监控设备的主机运行状态，监控器4用于监控中间件数据，其中，上述的中间件数据可以是除网络层数据、应用层数据、表示被监控设备的主机运行状态的数据之外的其它数据。
图4为根据本申请的一个实施例的监控数据的处理方法的使用场景流程图，如图4所示中的监控平台可以是服务器，图4中的系统A和系统B可以是不同的被监控设备，其中，被监控的设备可以是诸如手机、平板、PC机等终端设备，也可以是服务器，系统A和系统B对应的不同被监控的设备将各自整合的监控数据发送给监控平台的监控器monitor，图4中的Filter表示对应模块自身的过滤器，其中的Esg-stub表示插件。
其中，插件里面的监控功能主要就是基于servlet标准中的filter模式进行监控的，Filter模式是针对基于servlet标准对所有处理业务的http请求进行过滤的，在过滤的过程中可以获取每一笔请求中的所有数据详情，例如业务请求的源ip地址，业务请求进入服务器的时间，业务执行的时间。如果业务有报错的相关信息也可以捕获到并发送给监控平台，业务系统的运维人员可以通过错误信息进行分析。例如，通过消费方和服务方的时间数据也可以分析出数据在网络中的传输时间。
图5为根据本申请的另一实施例的监控数据的处理方法的使用场景流程图，图5示出了同一请求消息在不同的被监控设备之间进行的流转及处理过程。
如图5所示，调用方设备中的插件获取到请求消息时，提取该请求消息中的ID、源IP、请求开始时间、请求结束时间等等属性参数，将该参数整合为监控数据之后将该监控数据放在队列中，并对队列中的数据进行跟踪，当 该监控数据的数量超过预设的数值(例如为500)或当前时刻距离上一次向该服务器发送该监控数据的时刻之间的时间间隔大于预设值(例如为1分钟时)时，将对应的监控数据发送给服务器，以保证调用方设备的正常业务不被监控影响。
同样地，服务方设备中的插件获取到请求消息时，创建同一个请求消息ID的跟踪事件，提取该请求消息中的ID、源IP、请求开始时间、请求结束时间等等属性参数，将该参数整合为监控数据之后将该监控数据放在队列中，并对队列中的数据进行跟踪，当该监控数据的数量超过预设的数值(例如为500)或当前时刻距离上一次向该服务器发送该监控数据的时刻之间的时间间隔大于预设值(例如为1分钟时)时，将对应的监控数据发送给服务器，以保证服务方的正常业务不被监控影响。
在本实施例中涉及的请求消息包括被监控的设备发送的原始请求消息，还包括被监控的设备根据该原始的请求消息进行处理得到的应答响应消息。
根据本实施例的一个示例，上述步骤S101～S303的标号并不用于限定本实施例中各个步骤的先后顺序，各个步骤的编号只是为了使得描述各个步骤时可以通用引用该步骤的标号进行便捷的指代，例如上述步骤S201可以在S202的步骤之前，也可以在步骤S202的步骤之后，只要各个步骤执行的顺序不影响本实施例的逻辑关系即可表示在本申请请求保护的范围之内。
图6为根据本申请的一个实施例的监控数据的第一处理装置的示范性结构框图，下面结合图6来详细描述根据本申请的一个实施例的监控数据的第一处理装置，如图6所示，该监控数据的第一处理装置10包括：
插件运行模块11，用于运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
请求消息获取模块12，用于当通过该应用程序发送该请求消息时，获取该请求消息；
组织模块13，用于按照预设的规则对该请求消息进行重新组织，以得到监控数据；
监控数据发送模块14，用于将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
其中，上述预设的规则例如提取请求消息中表示该请求消息在一个生命周期内各个阶段内的数据。由于位于生命周期中不同阶段的请求消息携带的属性参数是不同的，这里的预设的规则与各个阶段中携带的属性参数相对应。例如当该请求消息处于发送阶段时，该请求消息包含的参数有UUID、请求发送时间、业务参数、请求头、请求方法名、请求地址(URL)、源端口、源IP等，其中的请求方法名可以是delete、get、trace或ping等等；当该请求消息处于响应阶段时，该请求消息包含的参数有UUID、收到请求数据的时间、业务参数、响应头、请求方法名、返回的具体数据等等。
在其中一个实施例中，上述的组织模块13还包括：
第一解析单元，用于解析该请求消息中包含的通用唯一识别码；
第二解析单元，用于解析同一通用唯一识别码对应的请求消息中的属性参数；
组织单元，用于将该通用唯一识别码及该属性参数构成的集合组织为该监控数据。
其中，上述组织模块13组织的依据可以是以将属于同一UUID的请求消息所在的阶段及对应阶段下的属性参数进行整合并封装，以形成监控数据。
在其中的一个实施例中，上述的插件运行模块11还包括：
进程开启单元，用于通过开启新的进程运行该应用程序；
线程开启单元，用于在该应用程序的进程中开启用于运行该插件的线程。
在另一实施例中，该监控数据的处理装置还包括：
插件升级单元，用于当接收到该插件的升级指令时，对所述应用程序内安装的插件进行升级处理。
根据本实施例的一个示例，上述的监控数据发送模块14具体用于：
当得到的该监控数据的数量超过预设的数值时，将该监控数据发送给服务器；或
当当前时刻距离上一次向该服务器发送该监控数据的时刻之间的时间间隔大于预设值时，将该监控数据发送给服务器。
其中，该监控数据的第一处理装置中包括的各个模块可全部或部分通过软件、硬件或其组合来实现。进一步地，该监控数据的第一处理装置中的各个模块可以是用于实现对应功能的程序段。
上述监控数据的第一处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。其中，网络接口可以是以太网卡或无线网卡等。上述各模块可以硬件形式内嵌于或独立于服务器中的处理器中，也可以以软件形式存储于服务器中的存储器中，以便于处理器调用执行以上各个模块对应的操作。该处理器可以为中央处理单元(CPU)、微处理器、单片机等。
上述监控数据的第一处理装置可以实现为一种计算机可读指令的形式，计算机可读指令可以在如图8所示被监控的设备上运行。
图7为根据本申请的一个实施例的监控数据的第二处理装置的示范性结构框图，下面结合图7来详细描述根据本申请的一个实施例的监控数据的第二处理装置，如图7所示，该监控数据的第二处理装置20包括：
监控数据接收模块21，用于接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
解析模块22，用于解析该监控数据中的属性参数；
监控模块23，用于根据该属性参数对该被监控的设备进行监控。
根据本实施例的一个示例，上述属性参数包括第一设备发送该请求消息的时间T1、第二设备接收该请求消息的时间T2、该第二设备发送该请求消息的应答消息的时间T3、该第一设备接收该应答消息的时间T4，上述的监控模块23具体用于：
计算(T4-T1)-(T3-T2)的数值，将计算的所述数值作为该请求数据在该第一设备与该第二设备之间的网络耗时。
上述监控数据的第二处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。其中，网络接口可以是以太网卡或无线网卡等。上述各模块可以硬件形式内嵌于或独立于服务器中的处理器中，也可以以软件形式存储于服务器中的存储器中，以便于处理器调用执行以上各个模块对应的操作。该处理器可以为中央处理单元(CPU)、微处理器、单片机等。
上述监控数据的第二处理装置可以实现为一种计算机可读指令的形式，计算机可读指令可以在如图9所示的服务器上运行。
其中上述第一解析单元及第二解析单元中的“第一”和“第二”的意义仅在于将两个解析单元加以区分，并不用于限定哪个解析单元的优先级更高或者其它的限定意义。
其中，该监控数据的第二处理装置中包括的各个模块可全部或部分通过软件、硬件或其组合来实现。进一步地，该监控数据的第二处理装置中的各个模块也可以是用于实现对应功能的程序段。
根据本申请的一个实施例提供的一种被监控的设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机可读指令，该处理器执行该程序时实现上述的监控数据的处理方法。
图8为根据本申请的一个实施例的被监控的设备的内部结构示意图，该被监控的设备可以为服务器。参照图8，该设备包括通过系统总线连接的处理器、非易失性存储介质、内存储器、输入装置和网络接口。其中，该设备的非易失性存储介质可存储操作系统和计算机可读指令，该计算机可读指令被执行时，可使得处理器执行本申请各实施例的应用于设备的监控数据的处理方法，该方法的具体实现过程可参考图1和图2各实施例的具体内容，在此不再赘述。该设备的处理器用于提供计算和控制能力，支撑整个设备的运行。该内存储器中可储存有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行一种监控数据的处理方法。设备的输入装置用于各个参数的输入，设备的网络接口用于进行网络通信。本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不 构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
根据本申请的一个实施例提供的一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机可读指令，该处理器执行该程序时实现上述的监控数据的处理方法。
图9为根据本申请的一个实施例的服务器的内部结构示意图。参照图9，该服务器包括通过系统总线连接的处理器、非易失性存储介质、内存储器、输入装置和网络接口。其中，该服务器的非易失性存储介质可存储操作系统和计算机可读指令，该计算机可读指令被执行时，可使得处理器执行本申请各实施例的应用于服务器的监控数据的处理方法，该方法的具体实现过程可参考图3各实施例的具体内容，在此不再赘述。该服务器的处理器用于提供计算和控制能力，支撑整个服务器的运行。该内存储器中可储存有计算机可读指令，该计算机可读指令被处理器执行时，可使得处理器执行一种监控数据的处理方法。服务器的输入装置用于各个参数的输入，服务器的网络接口用于进行网络通信。本领域技术人员可以理解，图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
如此处设备及服务器所使用的对存储器、存储、数据库或其它介质的任何引用可包括非易失性和/或易失性存储器。合适的非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。
本实施例另提供一种计算机可读存储介质，其上存储有计算机可读指令，该程序被处理器执行时实现上述监控数据的处理方法中的各个步骤。
在一个实施例中，该计算机可读存储介质上存储的计算机可读指令被处理器执行时，实现上述应用于设备的监控数据的处理方法中的各个步骤，也可以是实现上述应用于服务器的监控数据的处理方法中的各个步骤。
根据本实施例的一个示例，上述实施例方法中的全部或部分流程，可以通过计算机可读指令来指令相关的硬件来完成，所述程序可存储于一计算机可读取存储介质中，如本申请实施例中，该程序可存储于计算机系统的存储介质中，并被该计算机系统中的至少一个处理器执行，以实现包括如上述各方法的实施例的流程。该存储介质包括但不限于磁碟、优盘、光盘等。
相比于传统监控数据的处理方案，本申请中的技术方案在以下三个方面可以体现出明显的优势：
1、接入速度和质量：本方案是基于servlet标准中的filter过滤器去监控服务。对于现有很多正在运行的系统，可以就像安装插件一样安装本申请可以实现的相关功能，只会让业务方做稍微的改动。而传统基于日志这种方式，业务方的系统就必须按照监控系统所制定的日志格式对他们的系统进行改造，改造的工程量有多大，可想而知，稍有不慎有可能影响业务。
2、后续的升级维护：如果说需要给被监控数据需要做一些改动，或者监控数据的结构有所变化，依据本申请中的方法进行升级时很简单，直接替换掉原有插件即可，而基于日志的监控系统，还需要业务方去打印日志的逻辑。然后替换升级日志收集器。工作量大，风险高。
3、在运行中出问题的概率：传统方案中基于日志的监控器，需要维护业务进程，日志格式，日志收集器进程三个地方的稳定性，如果某一个地方出现问题，都会导致监控信息不准确。而本申请中的监控平台包装了监控信息收集，将数据组装到一个插件里面，而且最重要的是与对应的用用程序放在一个进程里面，出现问题的概率肯定比基于日志监控器出现的问题要低得多。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干 变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种监控数据的处理方法，包括：
    运行应用程序时，同时运行所述应用程序内安装的插件，所述插件用于采集通过所述应用程序发送的请求消息；
    当通过所述应用程序发送所述请求消息时，获取所述请求消息；
    按照预设的规则对所述请求消息进行重新组织，以得到监控数据；及
    将所述监控数据发送给服务器，指示所述服务器根据所述监控数据进行监控。
  2. 根据权利要求1所述的方法，其特征在于，所述按照预设的规则对所述请求消息进行重新组织，以得到监控数据包括：
    解析所述请求消息中包含的通用唯一识别码；
    解析同一通用唯一识别码对应的请求消息中的属性参数；
    将所述通用唯一识别码及所述属性参数构成的集合组织为所述监控数据。
  3. 根据权利要求1所述的方法，其特征在于，所述运行应用程序时，同时运行所述应用程序内安装的插件包括：
    通过开启新的进程运行所述应用程序；
    在所述应用程序的进程中开启用于运行所述插件的线程。
  4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    当接收到所述插件的升级指令时，对所述应用程序内安装的插件进行升级处理。
  5. 根据权利要求1所述的方法，其特征在于，所述将所述监控数据发送给服务器的步骤还包括：
    当得到的所述监控数据的数量超过预设的数值时，将所述监控数据发送给服务器；或
    当当前时刻距离上一次向所述服务器发送所述监控数据的时刻之间的时间间隔大于预设值时，将所述监控数据发送给服务器。
  6. 一种监控数据的处理方法，包括：
    接收至少两个被监控的设备发送的监控数据，所述至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，所述设备上运行有应用程序，通过所述应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
    解析所述监控数据中的属性参数；及
    根据所述属性参数对所述被监控的设备进行监控。
  7. 根据权利要求6所述的方法，其特征在于，所述属性参数包括第一设备发送所述请求消息的时间T1、第二设备接收所述请求消息的时间T2、所述第二设备发送所述请求消息的应答消息的时间T3、所述第一设备接收所述应答消息的时间T4；
    所述根据所述属性参数对所述被监控的设备进行监控的步骤包括：
    计算(T4-T1)-(T3-T2)的数值，将计算的所述数值作为所述请求数据在所述第一设备与所述第二设备之间的网络耗时。
  8. 一种被监控的设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行以下步骤：
    运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
    当通过该应用程序发送该请求消息时，获取该请求消息；
    按照预设的规则对该请求消息进行重新组织，以得到监控数据；及
    将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
  9. 根据权利要求8所述的设备，其特征在于，所述按照预设的规则对所述请求消息进行重新组织，以得到监控数据包括：
    解析所述请求消息中包含的通用唯一识别码；
    解析同一通用唯一识别码对应的请求消息中的属性参数；
    将所述通用唯一识别码及所述属性参数构成的集合组织为所述监控数据。
  10. 根据权利要求8所述的设备，其特征在于，所述运行应用程序时，同时运行所述应用程序内安装的插件包括：
    通过开启新的进程运行所述应用程序；
    在所述应用程序的进程中开启用于运行所述插件的线程。
  11. 根据权利要求8所述的设备，其特征在于，所述处理器还用于执行以下步骤：
    当接收到所述插件的升级指令时，对所述应用程序内安装的插件进行升级处理。
  12. 根据权利要求8所述的设备，其特征在于，所述将所述监控数据发送给服务器的步骤还包括：
    当得到的所述监控数据的数量超过预设的数值时，将所述监控数据发送给服务器；或
    当当前时刻距离上一次向所述服务器发送所述监控数据的时刻之间的时间间隔大于预设值时，将所述监控数据发送给服务器。
  13. 一种服务器，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行以下步骤：
    接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
    解析该监控数据中的属性参数；及
    根据该属性参数对该被监控的设备进行监控。
  14. 根据权利要求13所述的服务器，其特征在于，所述属性参数包括第 一设备发送所述请求消息的时间T1、第二设备接收所述请求消息的时间T2、所述第二设备发送所述请求消息的应答消息的时间T3、所述第一设备接收所述应答消息的时间T4；
    所述根据所述属性参数对所述被监控的设备进行监控的步骤包括：
    计算(T4-T1)-(T3-T2)的数值，将计算的所述数值作为所述请求数据在所述第一设备与所述第二设备之间的网络耗时。
  15. 一个或多个存储有计算机可读指令的非易失性可读存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    运行应用程序时，同时运行该应用程序内安装的插件，该插件用于采集通过该应用程序发送的请求消息；
    当通过该应用程序发送该请求消息时，获取该请求消息；
    按照预设的规则对该请求消息进行重新组织，以得到监控数据；及
    将该监控数据发送给服务器，指示该服务器根据该监控数据进行监控。
  16. 根据权利要求15所述的存储介质，其特征在于，所述按照预设的规则对所述请求消息进行重新组织，以得到监控数据包括：
    解析所述请求消息中包含的通用唯一识别码；
    解析同一通用唯一识别码对应的请求消息中的属性参数；
    将所述通用唯一识别码及所述属性参数构成的集合组织为所述监控数据。
  17. 根据权利要求15所述的存储介质，其特征在于，所述运行应用程序时，同时运行所述应用程序内安装的插件包括：
    通过开启新的进程运行所述应用程序；
    在所述应用程序的进程中开启用于运行所述插件的线程。
  18. 根据权利要求8所述的存储介质，其特征在于，所述处理器还用于执行以下步骤：
    当接收到所述插件的升级指令时，对所述应用程序内安装的插件进行升级处理。
  19. 根据权利要求15所述的存储介质，其特征在于，所述将所述监控数据发送给服务器的步骤还包括：
    当得到的所述监控数据的数量超过预设的数值时，将所述监控数据发送给服务器；或
    当当前时刻距离上一次向所述服务器发送所述监控数据的时刻之间的时间间隔大于预设值时，将所述监控数据发送给服务器。
  20. 一个或多个存储有计算机可读指令的非易失性可读存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行以下步骤：
    接收至少两个被监控的设备发送的监控数据，该至少两个设备包括处理相同通用唯一识别码对应的请求消息的设备，该设备上运行有应用程序，通过该应用程序中的插件获取并组织所述应用程序发送的请求消息，以得到所述监控数据；
    解析该监控数据中的属性参数；及
    根据该属性参数对该被监控的设备进行监控。
PCT/CN2017/108457 2017-09-15 2017-10-31 监控数据的处理方法、设备、服务器及存储介质 WO2019051948A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710835572.5A CN107704360B (zh) 2017-09-15 2017-09-15 监控数据的处理方法、设备、服务器及存储介质
CN201710835572.5 2017-09-15

Publications (1)

Publication Number Publication Date
WO2019051948A1 true WO2019051948A1 (zh) 2019-03-21

Family

ID=61172681

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/108457 WO2019051948A1 (zh) 2017-09-15 2017-10-31 监控数据的处理方法、设备、服务器及存储介质

Country Status (2)

Country Link
CN (1) CN107704360B (zh)
WO (1) WO2019051948A1 (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109359019A (zh) * 2018-08-15 2019-02-19 中国平安人寿保险股份有限公司 应用程序性能监控方法、装置、电子设备及存储介质
CN109240887A (zh) * 2018-09-04 2019-01-18 北京世纪东方通讯设备有限公司 应用程序运行状态的远程监控方法、监控端及监控服务器
CN109766253B (zh) * 2018-12-15 2023-06-27 平安证券股份有限公司 一种性能数据发送方法、装置、计算机设备及存储介质
CN110188121B (zh) * 2019-04-24 2024-03-19 平安科技（深圳）有限公司 业务数据监控方法、装置、计算机设备及存储介质
CN110569182B (zh) * 2019-09-19 2023-08-29 北京博睿宏远数据科技股份有限公司 一种崩溃率计算方法、装置、计算机设备及存储介质
CN112905254B (zh) * 2019-11-15 2023-10-31 北京百度网讯科技有限公司 用于发送请求的方法和装置
CN111124731A (zh) * 2019-12-20 2020-05-08 浪潮电子信息产业股份有限公司 一种文件系统异常监测方法、装置、设备、介质
CN112000552A (zh) * 2020-08-25 2020-11-27 上海控软网络科技有限公司 机床的监控方法、装置、系统、电子设备及存储介质
CN115277043A (zh) * 2022-05-11 2022-11-01 北京中安星云软件技术有限公司 一种实现api审计防火墙的方法及系统
CN116340104B (zh) * 2023-03-29 2024-01-12 广州易享信息科技有限公司 计算机无盘工作站应用数据鉴定系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102542182A (zh) * 2010-12-15 2012-07-04 苏州凌霄科技有限公司 基于Windows平台的强制访问控制装置及控制方法
CN103248651A (zh) * 2012-02-09 2013-08-14 腾讯科技（深圳）有限公司 一种性能监控的方法和系统以及客户端和服务器
US20140052775A1 (en) * 2012-08-14 2014-02-20 Kt Corporation Forwarding information to designated user terminal

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101655798B (zh) * 2008-08-18 2013-03-27 联想(北京)有限公司 一种虚拟机环境中应用程序部署和运行的装置及方法
CN102043679A (zh) * 2010-12-22 2011-05-04 北京中电普华信息技术有限公司 一种获取应用系统性能分析数据的方法与系统
CN102521136B (zh) * 2011-12-31 2015-06-10 山东中创软件商用中间件股份有限公司 一种应用程序监控装置及方法
CN106649126B (zh) * 2016-12-29 2020-06-30 广州酷狗计算机科技有限公司 一种对应用程序进行测试的方法和装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102542182A (zh) * 2010-12-15 2012-07-04 苏州凌霄科技有限公司 基于Windows平台的强制访问控制装置及控制方法
CN103248651A (zh) * 2012-02-09 2013-08-14 腾讯科技（深圳）有限公司 一种性能监控的方法和系统以及客户端和服务器
US20140052775A1 (en) * 2012-08-14 2014-02-20 Kt Corporation Forwarding information to designated user terminal

Also Published As

Publication number Publication date
CN107704360A (zh) 2018-02-16
CN107704360B (zh) 2020-01-07

Similar Documents

Publication Publication Date Title
WO2019051948A1 (zh) 监控数据的处理方法、设备、服务器及存储介质
US10761913B2 (en) System and method for real-time asynchronous multitenant gateway security
US11132356B2 (en) Optimizing data entries in a log
JP2021529386A (ja) オンデマンドネットワークコード実行システム上での補助機能の実行
CN111158891B (zh) 基于Flink技术的分析任务处理方法、装置及存储介质
US9684534B2 (en) Monitoring and modifying allocated computing resources
WO2021072861A1 (zh) 应用服务处理方法、装置、终端及存储介质
WO2019075774A1 (zh) 设备参数配置方法、装置、计算机设备和存储介质
US10284660B1 (en) Data flow tokens to trace execution of services in a service provider network
US10445214B2 (en) System and method for tracking callback functions for error identification
CN110727560A (zh) 云服务报警方法及装置
CN107644075B (zh) 收集页面信息的方法和装置
WO2021169275A1 (zh) Sdn 网络设备访问方法、装置、计算机设备及存储介质
US20230214229A1 (en) Multi-tenant java agent instrumentation system
CN112583898A (zh) 业务流程编排方法、装置、以及可读介质
WO2019075845A1 (zh) 链路调用关系的构建方法、装置、计算机设备及存储介质
CN110457132B (zh) 一种功能对象的创建方法、装置和终端设备
CN114745295A (zh) 数据采集方法、装置、设备和可读存储介质
CN115001967A (zh) 一种数据采集方法、装置、电子设备及存储介质
CN115705190A (zh) 依赖程度的确定方法及装置
CN117271584A (zh) 数据处理方法及装置、计算机可读存储介质和电子设备
CN112187509A (zh) 多架构云平台执行日志管理方法、系统、终端及存储介质
CN111367686A (zh) 业务接口的调用方法及装置、计算机设备、存储介质
CN114090268B (zh) 容器管理方法及容器管理系统
CN114157662A (zh) 一种云平台参数适配方法、装置、终端设备及储存介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17925443

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25/09/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 17925443

Country of ref document: EP

Kind code of ref document: A1