MECHANISM FOR AN INTELLIGENT AND COMPREHENSIVE SURVEILLANCE SYSTEM WITH PEER-TO-PEER AGENTS IN A NETWORK

Abstract

Method for facilitating joint peer-to-peer monitoring of a network (220), wherein the method comprises: Deployment of a network monitoring agent on a device (214) in a network; Identifying a plurality of peer devices (212, 216) in the same local network by the device without receiving an instruction orchestrated in the cloud; in response to successful direct communication with a server (204), receiving a network monitoring configuration file for the device from the server, wherein the configuration file specifies network metrics to be monitored and a condition associated with a network metric; In response to unsuccessful direct communication with the server, the configuration file is obtained from the server via an initial peer device; Monitoring the network metrics specified in the configuration file; In response to the fulfillment of a condition corresponding to a monitored network metric, a predetermined action is performed; in response to successful direct communication with the server, data is transmitted to the server that is associated with the monitored metrics and the action; and In response to unsuccessful direct communication with the server, data is transferred to the server via a second peer device. the transmitted data enables the server, in conjunction with a network topology, to display aggregated network monitoring data associated with the device and peer devices in the network.

Description

BACKGROUND

[0001] Network monitoring of enterprise systems can be performed using a combination of hardware- and software-based solutions. Test agents in cloud-based configurations can communicate directly with their cloud backend using the same network they are meant to monitor. The test agents can then perform monitoring tasks and report the results back to the cloud backend. However, limitations include the lack of visibility between different test agents, the varying functionality of the devices to which the test agents are connected, and the need to use different monitoring solutions for each agent.

[0002] US 2008 / 0189406A1 relates generally to software and hardware technology and, in one embodiment, to a system and method of a peer-to-peer web service monitoring network.

[0003] DE 10 2016 203 598 A1 refers to the diagnosis of software programs.

[0004] US 2018 / 0191814A1 generally concerns data forwarding in peer-to-peer (P2P) networks, and in particular the sharing of data in business-to-business (B2B) P2P networks that are subject to Service Level Agreements (SLAs).

[0005] The present invention is defined by independent claims 1 and 13. Embodiments are the subject of the respective dependent claims. BRIEF DESCRIPTION OF THE FIGURES Fig. Figure 1 shows an environment with a conventional monitoring model with various endpoints, as is state-of-the-art. Fig. Figure 2 shows an environment that enables a mechanism for an intelligent and comprehensive monitoring system with peer-to-peer agents, according to one aspect of the present application. Fig. 3 shows the surroundings Fig. 2, including communication between peer devices in the event of a failed uplink from one device, in accordance with an aspect of the present application. Fig. Figure 4 shows an example user dashboard displaying results of an intelligent and comprehensive monitoring system according to one aspect of the present application. Fig. Figure 5A presents a flowchart illustrating a procedure that enables a mechanism for an intelligent and comprehensive monitoring system with peer-to-peer agents in a network according to one aspect of the present application. Fig. Figure 5B shows a flowchart that represents a procedure enabling a mechanism for an intelligent and comprehensive monitoring system using peer-to-peer agents in a network, according to one aspect of the present application. Fig. Figure 6 shows a computer system and a device that enable a mechanism for an intelligent and comprehensive monitoring system using peer-to-peer agents in a network according to one aspect of the present application.

[0006] In the illustrations, identical numbers refer to the same elements of the illustration. DETAILED DESCRIPTION

[0007] The aspects of this application overcome the limitations of isolated monitoring devices by providing a system that utilizes peer-to-peer integration between different types of hardware and software monitoring devices within a network. The described aspects can also perform the detection of preconfigured conditions (e.g., monitored network metrics or test results) that can trigger predetermined corresponding actions, resulting in a comprehensive and intelligent monitoring system across the entire network.

[0008] Network monitoring of enterprise systems can be performed using a combination of hardware- and software-based solutions. Hardware-based solutions can include dedicated hardware platforms that perform continuous network monitoring. An example of this is a purpose-built device strategically placed within the network to enable network- and user-based monitoring, thereby ensuring uptime, performance, and Quality of Service (QoS), and guaranteeing Service Level Agreements (SLAs). Software-based solutions can include client-side software offerings that measure network metrics, such as application-level software running on user-provided host hardware, which also allows monitoring of the desired metrics from the perspective of a specific device.

[0009] In cloud-based configurations, test agents can generally communicate directly with their cloud backend using the same network they are monitoring. The test agents can then perform monitoring tasks and report the results to the cloud backend. Test agents can be connected to endpoint devices (“endpoints”) and non-endpoint devices (as defined below) and can be hardware-based, software-based, or a combination of both. An example of a hardware-based test agent is a user experience insight (UXI) sensor, which can be deployed as a hardware sensor to monitor the health and performance of a network.Based on its configuration, which it receives from the cloud or another server, the UXI sensor can monitor a wireless (or wired) network by continuously monitoring the network and reporting measurements, results, and any issues it detects to a UXI backend. An example of a software-based test agent could be a corresponding software monitoring agent running in a virtualized container. The software agent can be run or deployed on a compatible host, such as an access point (AP), a hardware switch, or as a client software application running on a laptop.

[0010] However, there are some limitations to using current hardware- and software-based solutions, for both endpoints and non-endpoints. One limitation is that a single device on the network has no visibility into other devices or clients on the network and that the individual device performs its monitoring and operation as a "leaf node," essentially isolated from the other devices on the network. Any issues that the individual device detects may be confined to that single device (e.g., firewall policies) or affect a network-wide problem (e.g., an issue related to a software-defined wide area network (SD-WAN) / gateway).

[0011] Another limitation can be that each device can perform domain-specific tasks. For example, a hardware-based endpoint might monitor the quality of the wireless network, while a software-based endpoint might perform a different type of task relevant to the host (e.g., a switch or access point (AP)) on which the software is running. In existing architectures, collaboration on peer-driven actions and network monitoring may require centralized (e.g., cloud-based) orchestration rather than direct communication between peer devices. If an event or condition of interest (e.g., a fault) occurs with respect to a particular device, a lack of connection to a central entity (e.g., the cloud) may prevent the event or condition from being addressed.In some cases, the event or condition may occur and complete before the connection to the cloud is established, which can prevent correct orchestration from ever being achieved. In other cases, the failure to establish cloud connectivity may mean that the event or condition is never detected or addressed, which can also prevent correct orchestration from ever being achieved.

[0012] Another limitation can be the use of different monitoring solutions for different devices. To manage diverse devices on a network, an end user must configure various monitoring solutions separately. Tracking the different information (e.g., metrics, results, and status) associated with these disparate monitoring solutions can be cumbersome and lead to a cumbersome and inefficient overall network monitoring solution. Furthermore, it can be difficult to consolidate the information obtained from the different device types (and their corresponding monitoring solutions) in a way that presents the data to the user in a useful or coherent manner. This inconsistent information can also make it more challenging for the user to perform root cause analysis and troubleshooting.

[0013] Aspects of the present application address these limitations by providing a system that utilizes peer-to-peer integration between different types of hardware and software monitoring devices within the network, potentially leading to the provision of a comprehensive and intelligent monitoring system across the entire network. The described aspects enable devices to communicate and collaborate to provide a collective overview or representation of the network, i.e., by forming a collective ecosystem of elements, including endpoint and non-endpoint devices. The described aspects of the system can provide a comprehensive and intelligent monitoring system, for example, for a customer's network, and furthermore, offer insights into the user experience at various points within the network infrastructure.By utilizing the shared functionalities of the described aspects, the system can provide network metrics and other related information to, from, or through any device on the network, including endpoint and non-endpoint devices (as described below). Furthermore, the system can use a set of conditions and corresponding actions to perform intelligent monitoring. These conditions / actions can be user-defined or system-defined. This is achieved instead of relying on a single device operating in isolation (as described below in relation to...). Fig. 1 described), can thus use the described aspects peer-to-peer agents together with the condition / action configurations to provide an intelligent and comprehensive monitoring system.

[0014] The terms “endpoint” and “endpoint device” are used interchangeably in this disclosure and refer to a physical or virtual device that can connect to and exchange information with other devices over or within a network. An endpoint device can be an “edge node” or a “leaf node” in a network topology. Examples of endpoint devices include, but are not limited to, desktop computers, laptops, mobile devices, tablets, printers, access points, embedded devices, servers, virtual machines, thin clients, sensors, actuators, point-of-sale terminals, and smart meters.

[0015] The term “non-endpoint device” is used in this disclosure to refer to a physical or virtual device that can connect to and exchange information with other devices over or within a network. A non-endpoint device may be an “internal node” or a “branch node” in a network topology. Examples of non-endpoint devices include switches, access switches, gateways, routers, and one or more of the endpoint devices described herein.

[0016] The terms “peers” and “peer devices” are used synonymously in this disclosure and refer to devices between which a direct communication infrastructure or other communication link may exist.

[0017] The term “test agent” is used in this disclosure to refer to a component, module, unit, or program that may be associated with endpoint and non-endpoint devices and may be based on hardware, software, or a combination of hardware and software. A test agent may perform various functions or operations, including but not limited to testing, monitoring, and transmitting information, such as metrics, results, and the status of network- and device-related information. Traditional surveillance model with separate endpoints versus peer-to-peer agents

[0018] Fig. Figure 1 shows an environment 100 that uses a traditional monitoring model with various endpoints, in accordance with the state of the art. The environment 100 can include: a device 104 connected to a user 106 and a display 108, and devices 110. The device 104 can be a cloud server, a cloud-based service, or a set of servers. Devices 110 can include multiple devices, including but not limited to: an endpoint device; a non-endpoint device; an intermediate device; an edge or leaf node; an internal or branch node; an access point; a switch; an access switch; a gateway; and a router. The device 104 and the devices 110 can communicate with each other over a network 120.For example, the device 110 may include: an access point 112 that communicates with the device 104 via a link 122; a laptop 114 that communicates with the device 104 via a link 124; a switch 116 that communicates with the device 104 via a link 126; and a monitoring sensor 118 that communicates with the device 104 via a link 128.

[0019] In environment 100, each of the devices 112-118 can only operate in isolation from the other devices 112-118 during operation. It may only report its own results via a specific system, which can be accessed through a cloud, backend, or other server, and which are subsequently displayed on screen 108. If a problem occurs with a corresponding link to device 104 (e.g., with link 126 for switch 116), the device associated with that link (e.g., switch 116) may be unable to perform necessary actions, such as: receiving a configuration file from device 104; recording network metrics monitored by switch 116; and reporting device-specific or general network problems observed by switch 116 due to its position in the overall network topology for devices 110.

[0020] Furthermore, these metrics, issues, or results can be reported by each isolated device and may only be accessible through separate user dashboards or backend systems. For example, display 108 may contain information that must be accessed from four separate systems, including: Access Point 112 (“System_1”): monitored network information 170; Laptop 114 (“System_2”): monitored network information 172; Switch 116 (“System_3”): monitored network information 174; and Monitoring Sensor 118 (“System_4”): monitored network information 176. The information (170-176) from the four separate systems may be displayed in a disjointed manner, providing information only about each individual device but not an overall view of the network as a whole.

[0021] Environment 100 demonstrates how each of the devices 112-118 can perform its own monitoring in isolation from the other devices, and the verification of the monitored information by the user can also be performed in isolation from various backend systems.

[0022] The described aspects offer an integration of peer-to-peer agents that enable joint monitoring of a network. Fig. Figure 2 shows an environment 200 for an intelligent and comprehensive peer-to-peer agent surveillance system according to one aspect of the present application. The environment 200 may include: a device 204 connected to a user 206 and a display 208; and devices 210. The device 204 may be a cloud server, a cloud-based service, or a set of servers. Devices 210 may include multiple devices, including but not limited to: an endpoint device, a non-endpoint device, an intermediate device, an edge or leaf node, an internal or branch node, an access point, a switch, an access switch, a gateway, and a router. Device 204 and devices 210 may communicate with each other over a network 220.The devices 210 may include, for example: an access point 112 communicating with device 204 via a link 222; a laptop 214 communicating with device 204 via a link 224; a switch 216 communicating with device 204 via a link 226; and a monitoring sensor 218 communicating with device 204 via a link 228. The display 208 may contain information, as shown below regarding [missing information]. Fig. 3 described.

[0023] In environment 100, the individual devices 112-118 can work together during operation to provide an intelligent and comprehensive monitoring system, in contrast to the one above regarding environment 100. Fig. 1. Isolated monitoring as shown. The devices 210 from Fig. 2 can perform several operations that enable this joint monitoring. Laptop 214 can represent an example device of Devices 210. During operation, Laptop 214 can employ a software-based network monitoring agent. Laptop 214 can discover multiple peer devices on the same local network as Laptop 214 without receiving a cloud-driven instruction. That is, based on the software agent employed, Laptop 214 can discover or identify peer devices by using a protocol such as: a multicast domain name system (mDNS) protocol; a Zigbee protocol; a Bluetooth mesh protocol; and a broadcast Ethernet protocol. Other protocols can also be used by Laptop 214 or any of the Devices 210 to discover its peers. In addition, other radio frequency (RF)-based communication methods (e.g.,Zigbee) is used for communication between devices in different networks. An example result of the discovery process might include the following: Laptop 214 discovers at least Access Point 212 and Switch 216 as its peer devices, with communication possible via links 232 and 234, respectively; Access Point 212 discovers at least Laptop 214 and Switch 216, with communication possible via links 232 and 236, respectively; and Switch 216 discovers at least Access Point 212, Laptop 214, and Monitoring Sensor 218, with communication possible via links 236, 234, and 238, respectively.

[0024] Since this discovery process can be initiated by the software-based agent deployed on a device, it allows for the identification of devices (including endpoints) and the determination of their potential peers without requiring a centrally orchestrated instruction, such as a cloud-orchestrated instruction from device 204. Once the peers are identified, the system can use the peer-to-peer agents to provide joint monitoring, for example, if a link from a device (214) to the server (204) fails, as described below. Fig. 3 described.

[0025] Each compatible device (e.g., Laptop 214) can receive a device-specific configuration file from Server 204. The configuration file can contain or specify network metrics to be monitored by that particular device. The configuration file can also contain one or more condition / action pairs, such as a trigger or condition and a corresponding action to be performed. The conditions / actions can each specify user-defined or system-configured elements, such as rules, thresholds, network metrics to be monitored, messages or notifications to be sent to one or more other devices, processes to be initiated, and so on.

[0026] Fig. 3 shows the area 200 from Fig. 2, including communication between peer devices in the event of a failed uplink from a device, in accordance with an aspect of the present application. If laptop 214 in Fig. If Laptop 214 detects successful direct communication with Device 204, it can retrieve its configuration file from Device 204 (as described above). However, if Laptop 214 detects that direct communication with Device 204 is unsuccessful (e.g., Link 224 from Laptop 214 to Device 204 fails, as indicated by a bold "X" 302), Laptop 214 can select a peer from its list of previously identified peers. Laptop 214 can select the peer based on, for example, a ranking of the identified majority of peer devices and a current network metric associated with one or more of the identified majority of peers. For example, Laptop 214 might maintain a list of its peer devices in a local cache. The list could be prioritized, ranked, or ordered by the number of hops or the latency associated with each of the identified peers.Laptop 214 can use the list to determine alternative communication paths for both receiving data from and transmitting data to the server (e.g., device 204). That is, Laptop 214 can attempt to find a peer device from the list that has a functioning uplink or route through which it can retrieve the configuration file (or transmit its stored monitored network metrics and results, as described below).

[0027] Laptop 214 can communicate with device 204 via the selected peer device. For example, Laptop 214 can send a request for the configuration file to its peer device, Switch 216 (via communication port 304), which can then forward the request to Device 204 (via communication port 306). Device 204 can then send the requested configuration file back to Laptop 214 via Switch 216 using the same communication ports 306 and 304. These features enable autonomous edge configuration for mutual network troubleshooting and monitoring.

[0028] Once Laptop 214 has received its configuration file, it can monitor the network metrics specified in that file. Laptop 214 can be configured to report the results of the monitored network metrics at regular intervals, based on a predetermined time, or in response to the detection of a user-defined or system-configured condition specified in the configuration file. Detecting, determining, or triggering a user-defined or system-configured condition can cause Laptop 214 to perform a specific corresponding action, such as collecting additional network metrics. Example condition / action pairs are described below.

[0029] If Laptop 214 detects successful direct communication with Device 204, it can transmit data associated with the monitored metrics and the action to Device 204 (similar to the direct communication described above for retrieving the configuration file from Device 204). However, if Laptop 214 detects that direct communication with Device 204 is unsuccessful (e.g., if Link 224 from Laptop 214 to Device 204 fails, as indicated by the bold "X" 302), Laptop 214 can select a peer (e.g., Switch 216) from its list of previously identified peers. Laptop 214 can select the peer based on the information above regarding... Fig. Select one of the two factors described. Laptop 214 can communicate with device 204 via the selected peer device. In this example, Laptop 214 can transmit the data associated with the monitored metrics and the action (if applicable) to the server via the selected peer device (e.g., Switch 216). It should be noted that although the same peer device (i.e., Switch 216) is shown as the selected device for both cases of unsuccessful direct communication (i.e., retrieving the configuration file and transmitting monitored network metrics), the selected peer device could be any of the previously identified peer devices of Laptop 214.

[0030] The transmitted data, which is associated with the monitored metrics and, in some cases, the action, can include test result metrics such as latency, round-trip time, path convergence, and paths traveled. These metrics (i.e., the "overall test case") can be confirmed or validated by the actual elements or devices involved in transmitting the data. Because each element or device can validate the overall test case, the system can consider the network in its entirety or as a whole. For example, the results of low throughput for a client at the edge can be further investigated by providing packet fragmentation metrics for the corresponding traffic flow. Additionally, the system can validate QoS policies, tagging traffic originating from an edge device or test agent and testing throughput thresholds.By displaying the data at the traffic source and in the transmission infrastructure, the described aspects can lead to a deeper insight not only into a multitude of tests, including routing tests, bandwidth tests, latency and round-trip tests, but also into the status or confirmation of the enforcement of various policies.

[0031] The system can display various information (e.g., on display 208 in Fig. 2 and Fig. 3), including aggregated network monitoring data associated with a device (e.g., 214), as well as information about the transmitted data associated with the monitored metrics and the action (if any). The system can display the information in conjunction with a network topology (e.g., as a geographic map with the physical locations of a device, group of devices, network, or group of networks marked). The displayed information may include, for example: network information 270, which may include a network type 272, sensor status and information 274, and historical information 276; a summary of ongoing issues 278; and a visual representation of the network / topology 280, which may include a communication type 282 and device / network information 284.The displayed information may also include a number associated with a device, group of devices, network, or group of networks. The displayed information may further include: a link or connection between two devices on the network and a link or connection between two networks within the overall network.

[0032] The displayed information may include interactive elements 286 that allow the user 206 to view one or more of the following information: a statistic or status associated with the link or connection; a rate for receiving or transmitting data; a rate for dropped packets; whether an external service is available; whether an unexpected captive portal or proxy is present; whether a power outage is detected; and whether a response is received from a Dynamic Host Configuration Protocol (DHCP) server. The system may display this information on a user dashboard, as shown below in relation to Fig. 4 described.

[0033] As described above, the configuration file can contain condition / action pairs. This means that each metric or test case can correspond to a condition which, when detected, can trigger a proactive or immediate action based on a predetermined threshold, as defined in the configuration file. An example of a condition / pair might be that a device detects a failed uplink to the server or cloud backend, triggering the corresponding action to check the uplink of one or more of the device's peer devices. Another example is that the device detects a problem with a peer device (e.g., the condition that the rate of dropped packets on a switch exceeds a predetermined threshold), triggering the corresponding action of executing a CLI command on the switch to retrieve relevant counters or other interface metrics.In another example, the device can detect the status of a failed uplink on one or more of its peer devices, triggering the corresponding action of performing tests on a specific port of the identified peer device and saving the results to the device itself. Another example is checking the reachability of a critical internal server from various hosts / paths in the network, where the check results can specify various actions to be taken by the device or by other devices to resolve issues related to the check results.

[0034] In these examples, the device can detect a condition that matches a monitored network metric associated with the device itself. For the corresponding triggered action, the device can either directly perform a corresponding first action or notify a peer device to perform a corresponding second action. The device can also detect a condition that matches a monitored network metric associated with a peer device. For the corresponding triggered action, the device can either directly perform a corresponding third action or notify the peer device or another peer device to perform a corresponding fourth action. For example, a device can detect a condition where the result of a test against a specific route falls below a predetermined level, triggering a route analysis from a specific switch (i.e., a peer device).In other words, when the device detects that the condition of the monitored network metric is met, it can inform its peer device—the switch—to perform a specific route analysis action. In some cases, the device can also inform another peer device to execute a predetermined action based on the condition.

[0035] Furthermore, the described aspects can use the techniques mentioned above to aggregate monitored network metrics and forward or apply the aggregated information to an external monitoring instance, e.g., in parallel to an external monitoring assistant (in Fig. 2 and Fig. 3 not shown) to enable access to device 204 and the application of analyses to the aggregated information.

[0036] Furthermore, the described aspects can enrich all network problems uncovered by client test applications with problem-sharing and validation routines that can be executed on parallel network infrastructure components, such as switches, access points, or other network nodes responsible for processing traffic originating from a primary client. For example, a first agent can be installed on a UXI sensor running on a user device and monitoring a specific network. If the first agent detects a problem with the network being monitored by the user device and wants to provide a full report of the detected problem immediately (i.e., in real time or at the time of detection), the first agent may need to deploy a second agent (e.g., a third agent).A UXI Network Analytics Engine (NAE) running on a local switch can be instructed to review the configuration or traffic patterns by executing a series of command-line interface (CLI) commands. This communication can result in the creation of an intelligent and comprehensive monitoring report by aggregating information from various peer devices at the time a problem occurs and presenting / displaying the aggregated information to a network administrator or other end user in a coherent manner. An example display is shown below. Fig. 4 described.

[0037] As in Fig. As illustrated in Figures 2 to 4, the described aspects can perform intelligent and comprehensive network monitoring across multiple “monitoring systems,” where each device or group of devices can be considered a monitoring system, instead of isolated network monitoring performed separately by multiple individual endpoints or devices that are related to Fig. 1 are shown. Exemplary dashboard results and user interaction

[0038] Fig. Figure 4 shows an example user dashboard 400 with the displayed results of an intelligent and comprehensive monitoring system, in accordance with one aspect of the present application. The user dashboard can be displayed on a screen of a device assigned to a user (or a server that the user can access or that is authenticated for use by them), e.g., as above with regard to display 208 of the Fig. 2 and Fig. 3. The user dashboard 400 can contain an information display section 402 and a visual representation 460 of the network topology. The information display section 402 can contain a network section 404, which summarizes information about a given network type, including: the number of sensors currently in operation and their status for that network type; and a historical status of that network for a given number of previous time intervals (e.g., hours). The network section 404 can contain rows indicating a given network type, with columns displaying: a network type 410; a column with a visual representation and the number of sensors currently in operation (Sensors now 430); and a column with a historical status (Last 24H ongoing 440).Network types (410) can include: Wi-Fi 412; Ethernet 414; Captive Portal 416; Dynamic Host Configuration Protocol (DHCP) 418; Domain Name System (DNS) 420; and Gateway 422.

[0039] Each line can contain the information described above. For example, a line 406 for Wi-Fi 412 can contain: a number of sensors currently operating, as a value of 656 (element 432); a bar or other visual representation (element 434) indicating various states relative to the total number of sensors currently operating, e.g., a filled pattern can indicate a relative number of offline sensors or sensors not currently receiving a signal; a diagonally striped fill pattern can indicate a relative number of online sensors or sensors currently receiving data; and an unfilled or blank pattern can indicate a relative number of sensors currently being powered on or undergoing diagnostics.

[0040] Line 406 for Wi-Fi 412 may also contain: a visual representation (element 442) of the overall state of the respective network over a recent historical period, e.g., 24 hours, where one bar may represent each hour and a shade or color (not specified) of the bar may represent the overall state of the respective network during that hour; and a number relating to the overall state of the respective network as a value of 108 (element 444), where this value may, for example, indicate a number of sensor problems or errors in the last 24 hours, a number of resets or restarts related to the respective network, etc.

[0041] Information Display Section 402 may also contain a Running Section 450, which summarizes the number of problems currently occurring or unresolved. Lines 452 may contain information about specific problems and list the number of sensors and networks affected by the problem. As shown in line 452, for example, a running problem of "low receive bitrate" may affect 30 sensors and 4 networks; a running problem of "external service is unavailable" may affect 14 sensors and 5 networks; a running problem of "unexpected captive portal or proxy" may affect 15 sensors and 2 networks; a running problem of "power outage detected" may affect 15 sensors; and a running problem of "no response from DHCP server" may affect 7 sensors and 5 networks.Other problems may also be displayed (line 454).

[0042] The visual representation of the network topology (460) can be displayed as a map, with the physical location of each network indicated by a label (e.g., labels 462 and 464). Different types of communication links between networks can be shown with different types of arrows, e.g., a double-sided arrow (e.g., 470) to indicate one type of communication, and a straight, bold line without arrows (e.g., 478 and 480) to indicate a second type of communication link. The number or value displayed in each label can correspond to different values, and each label can be colored or displayed in another visual way.Examples of the different types of values ​​include: the number of devices in a given network at the marked location; the number of subnetworks within the given network; the number of sensors associated with the given network; and the number of power outages in the given network. Different colors (not shown) or other visual indicators (e.g., stripes, patterns, shading, highlights, etc.) can be used to indicate the type of value being displayed. In some aspects, the user can use an input device (e.g., by moving the mouse pointer over a label or by entering a specific keystroke or pattern on a keyboard) or a finger gesture (e.g., by swiping, moving, tapping, or holding part of a touchscreen) to view or change the displayed labels.

[0043] The user can also use interactive elements (not shown) on the user dashboard 400 to display specific or detailed information about a particular sensor, device, or communication link within a given network, e.g., by clicking on the label 462 and further clicking through a hierarchically organized view of the respective network and related information, which may be displayed in section 402, in a further scrollable area of ​​section 402, or as an overlay on section 402.

[0044] In this way, the User Dashboard 400 can provide the user with an overview of the entire network (e.g., a customer's network spanning multiple geographic locations). The User Dashboard 400 can also give the user a detailed overview of the entire network and provide statistics via various links (e.g., via the Information Display section 402 and as described above). The various user control options available through the Dashboard 400 can enhance the performance of the comprehensive and intelligent monitoring system described here. Exemplary procedure for enabling an intelligent and comprehensive monitoring system

[0045] Fig. Figure 5A shows a Flowchart 500 illustrating a procedure that provides a mechanism for an intelligent and comprehensive monitoring system using peer-to-peer agents in a network, in accordance with one aspect of the present application. During operation, the system deploys a network monitoring agent on a device in a network (Operation 502). The system uses the device to discover multiple peer devices in the same local network without receiving any instruction from the cloud (Operation 504). When the system detects successful direct communication with a server (Decision 506), the system receives a network monitoring configuration file for the device from the server, the configuration file specifying the network metrics to be monitored and a condition associated with each network metric (Operation 508).If the system detects unsuccessful direct communication with the server (Decision 506), it obtains a network monitoring configuration file for the device from the server via a first peer device (Operation 510). The system can determine or select the first peer device based on the exemplary criteria described above.

[0046] The system monitors the network metrics specified in the configuration file (Operation 512). If the condition corresponding to a monitored network metric is met or triggered (Decision 514), the system performs a predetermined action (Operation 516) and the operation is marked with Label A in Fig. 5B continues. If the condition corresponding to a monitored network metric is not met or is triggered (decision 514), the operation is stopped at Label A in Fig. Continued in 5B.

[0047] Fig. Figure 5B shows a flowchart 520 illustrating a procedure that enables a mechanism for an intelligent and comprehensive monitoring system with peer-to-peer agents in a network according to one aspect of the present application. During operation, if the system detects successful direct communication with the server (decision 522), it transmits data to the server that is associated with the monitored metrics and the action (operation 524). If the system detects that direct communication with the server was unsuccessful (decision 522), the system transmits the data to the server via a second peer device (operation 526). The system can determine or select the first peer device based on the exemplary criteria described above.The system allows the server, in conjunction with a network topology, to display aggregated network monitoring data associated with the device and its peer devices on the network (Operation 528). The system displays the aggregated network monitoring data associated with the device, its peer devices on the network, and other devices on the network on a screen of a device associated with the server (Operation 530). The operation then returns.

[0048] By deploying the network monitoring agent on devices in a network and enabling peer-to-peer discovery to use peers as devices through which configuration information and measurement results or monitoring data are communicated with a central cloud server (or another central server or backend), and by using intelligent monitoring (e.g., the monitored or triggered conditions / actions described above), the described aspects can thus enable a shared, intelligent, and comprehensive peer-to-peer monitoring of a network. Exemplary system and device for enabling an intelligent and comprehensive monitoring system

[0049] Fig. Figure 6 shows a computer system 600 and a device 640 that provide a mechanism for an intelligent and comprehensive monitoring system with peer-to-peer agents in a network according to one aspect of the present application. The computer system 600 comprises a processor 602, a memory 604, and a storage device 606. The memory 604 can include volatile memory (e.g., RAM) that serves as managed memory and can be used to store one or more memory pools. In addition, the computer system 600 can be coupled with user input / output peripheral devices 610 (e.g., a display device 612, a keyboard 614, and a pointing device 616). The computer system 600 can be connected to the device 604. Fig. 1 correspond and the peripheral I / O user devices 610 can be displayed on screen 108 Fig. 1. The computer system 600 can communicate with a plurality of devices (or equipment), e.g., device 640 and device 660, via communication links 680 and 682, respectively. Devices 640 and 660 can communicate with devices 110 from Fig. 1. The storage device 606 can store an operating system 618, a content processing system 620, and data 628.

[0050] The content processing system 620 may contain instructions which, when executed by the computer system 600, can cause the computer system 600 to perform the procedures and / or processes described in this disclosure. In particular, the content processing system 620 may contain instructions for sending and / or receiving data packets to / from other network nodes over a computer network (communication unit 622). A data packet may contain configuration information, network metrics or statistics, data associated with a device or peer device, data associated with a condition / action in a configuration file, and data relating to the operations described herein.

[0051] The Content Processing System 620 may also contain instructions for aggregating data received from one or more devices or equipment (e.g., 640 / 660) (Data Aggregation Unit 624). The Content Processing System 620 may contain instructions for viewing, managing, updating, and modifying data that is displayed or intended to be displayed on a screen using I / O devices 610 (Display Management Unit 626). The Content Processing System 620 may also contain instructions for handling communication with an external unit (Communication Unit 622), such as a unit that can retrieve aggregated network monitoring data or metrics stored by the Computer System 600 and perform further analysis of the retrieved data.

[0052] The data 628 may include all data required as input or generated as output by the methods and / or processes described in this disclosure. In particular, the data 634 may store at least the following: data, network metrics, device-related information, and information relating to the display of network metrics or network topology information.

[0053] Device 640 (as an example of a plurality of devices / equipment, which may also include, for example, 660) can comprise a plurality of units or components that can communicate with each other via a wired, wireless, quantum light, or electrical communication channel. Device 640 can be implemented using one or more integrated circuits and can comprise fewer or more units or devices than those described in Fig. The device 600 may be integrated into a computer system or implemented as a separate device or devices capable of communicating with other computer systems and / or devices. In particular, the device 600 may comprise units 642-656 that perform the functions or operations described herein, including: a communication unit 642 for communicating with one or more other devices or computer systems; an agent deployment unit 644 for deploying a network monitoring agent on a device in a network; and a peer discovery unit 646 for the device to discover multiple peer devices in the same local network that do not receive an instruction orchestrated in the cloud.a configuration file management unit 648 for receiving a network monitoring configuration file for the device from the server (where the configuration file specifies network metrics to be monitored and a condition associated with a network metric) or from the server via an initial peer device, based on a determination of whether directional communication with the server exists, performed by the communication unit 642; a network metric monitoring unit for monitoring the network metrics specified in the configuration file; a condition determination unit 652 for determining whether a condition corresponding to a monitored network metric is satisfied; an action management unit 654 for executing a predetermined action;wherein the communication unit 642 is further intended for transmitting data associated with the monitored metrics and the action to the server or to the server via a second peer device, based on a determination of whether there is directional communication with the server, which is carried out by the communication unit 642; and a display management unit 656 for managing the display of data by the server by allowing the server, in conjunction with a network topology, to display aggregated network monitoring data associated with the device and the peer devices in the network.

[0054] In general, the disclosed aspects provide a method, a non-transitory computer-readable storage medium, a system, and a device for enabling collaborative peer-to-peer monitoring of a network. In one aspect, the system deploys a network monitoring agent on a device within a network. The system uses this device to discover multiple peer devices on the same local network without receiving instructions from a cloud-based system. Upon successful direct communication with a server, the system receives a network monitoring configuration file for the device from the server. This configuration file specifies the network metrics to be monitored and a condition associated with each metric. Upon unsuccessful direct communication with the server, the system receives the configuration file from the server via a first peer device.The system monitors the network metrics specified in the configuration file. When a condition corresponding to a monitored network metric is met, the system performs a predetermined action. Upon successful direct communication with the server, the system transmits data to the server related to the monitored metrics and the action. Upon unsuccessful direct communication with the server, the system transmits the data to the server via a second peer device. This allows the server, in conjunction with the network topology, to display aggregated network monitoring data related to the device and its peers on the network.

[0055] In one variation of this aspect, when the condition corresponding to the monitored network metric is met and is associated with the device, the action includes at least one of the following: The device directly performs a first action; and the device informs a peer device to perform a second action.

[0056] In another variation of this aspect, if the condition corresponding to the monitored network metric is met and is associated with a peer device, the action includes at least one of the following: The device directly performs a third action; and the device informs the peer device or another peer device to perform a fourth action.

[0057] In another variant, the fulfillment of the condition corresponding to the monitored network metric is based on at least one of the following: a system-configured condition for a system-configured action or a user-defined action; and a user-defined condition for a system-configured action or a user-defined action.

[0058] In another variant, the system deploys the network monitoring agent on multiple devices within the same local network, with the majority of devices comprising the peer devices. The system monitors network metrics on each device based on a configuration file for that specific device. The system then transmits these monitored network metrics to the server, or to the server via one or more of the device's peer devices.

[0059] In another variant, the device, the peer devices and other devices in the same local network include at least one of the following: an endpoint device, an intermediate device, an edge or leaf node, an internal or branch node, an access point, a switch, an access switch, a gateway and a router.

[0060] In another variant, the system recognizes the device's peer devices based on a protocol that includes at least one of the following protocols: a Multicast Domain Name System (mDNS) protocol, a Zigbee protocol, a Bluetooth Mesh protocol, and a Broadcast Ethernet protocol.

[0061] In another variant, the system displays aggregated network monitoring data on a screen of a device associated with the server. This data includes information related to the device, its peers on the network, and other devices on the network. The aggregated network monitoring data is displayed in conjunction with the network topology. The displayed aggregated network monitoring data shows at least one of the following: a visual representation of the network topology; the physical location of a device or group of devices on the network; a number assigned to the device or group of devices; and a link or connection between any two devices on the network.

[0062] In another variant, the display also includes interactive user elements that allow a user of the device associated with the server to view one or more of the following: a statistic or status associated with the link or connection; a rate of data reception or transmission; a rate of dropped packets; whether an external service is available; whether an unexpected captive portal or proxy exists; whether a power outage is detected; and whether a response is received from a Dynamic Host Configuration Protocol (DHCP) server.

[0063] In another variant, the system transmits the data associated with the monitored metrics and the action via the server to an external monitoring instance.

[0064] In another variant, the system stores information associated with the identified majority of peer devices in a local cache of the device.

[0065] In another variant, the system determines the first peer device and the second peer device based on at least one of the following: a ranking for the discovered majority of peer devices; and a current network metric assigned to one or more of the discovered majority of peer devices.

[0066] In another aspect, a non-transitory, computer-readable storage medium stores instructions which, when executed by a computer, cause the computer to perform the procedure described above, including those relating to the Fig. 2, Fig. 3, Fig. 4, Fig. 5A and Fig. 5B.

[0067] In another aspect, a device comprises: an agent deployment unit to deploy a network monitoring agent on a device in a network; a peer discovery unit to enable the device to discover multiple peer devices on the same local network without receiving instructions organized in the cloud; a communication unit to determine successful or unsuccessful directional communication with a server; and a configuration file management unit to: in response to the communication unit determining successful direct communication with the server, obtain a network monitoring configuration file for the device from the server, the configuration file specifying network metrics to be monitored and a condition associated with a network metric.and, in response to the communication unit detecting unsuccessful direct communication with the server, to obtain the configuration file from the server via an initial peer device; a network metric monitoring unit to monitor the network metrics specified in the configuration file; a condition determination unit to determine that a monitored network metric is satisfied; an action management unit to execute a predetermined action in response to the condition determination unit determining that a condition corresponding to the monitored network metric is satisfied; wherein the communication unit is further designed to transmit data associated with the monitored metrics and the action to the server in response to the determination of successful direct communication with the server;and, in response to the determination of unsuccessful direct communication with the server, to transmit the data to the server via a second peer device; and a display management unit to enable the server, in conjunction with a network topology, to display aggregated network monitoring data associated with the device and the peer devices in the network.

[0068] The foregoing description is intended to enable the person skilled in the art to produce and use the aspects and examples and is given in connection with a specific application and its requirements. Various modifications of the disclosed aspects will be readily apparent to the person skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of this disclosure. Therefore, the aspects described here are not limited to those shown but have the broadest possible scope consistent with the principles and features disclosed herein.

[0069] Furthermore, the foregoing descriptions of the aspects serve only for illustration and description. They do not claim to be exhaustive and do not limit the aspects described herein to the disclosed forms. Accordingly, many modifications and variations will be obvious to those skilled in the art. Moreover, the above disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the attached claims.

Claims

[1] Method for facilitating joint peer-to-peer monitoring of a network (220), wherein the method comprises: Deployment of a network monitoring agent on a device (214) in a network; Identifying a plurality of peer devices (212, 216) in the same local network by the device without receiving an instruction orchestrated in the cloud; in response to successful direct communication with a server (204), receiving a network monitoring configuration file for the device from the server, wherein the configuration file specifies network metrics to be monitored and a condition associated with a network metric; as a response to unsuccessful direct communication with the server, obtaining the configuration file from the server via an initial peer device; Monitoring the network metrics specified in the configuration file; In response to the fulfillment of a condition corresponding to a monitored network metric, a predetermined action is performed; in response to successful direct communication with the server, data is transmitted to the server that is associated with the monitored metrics and the action; and In response to unsuccessful direct communication with the server, data is transferred to the server via a second peer device. the transmitted data enables the server, in conjunction with a network topology, to display aggregated network monitoring data associated with the device and peer devices in the network. [2] The method of claim 1, wherein, if the condition corresponding to the monitored network metric that is satisfied is associated with the device, the action comprises at least one of the following: The device performs an initial action directly; and The device informs a peer device to perform a second action. [3] Method according to claim 1, wherein, if the condition corresponding to the monitored network metric that is satisfied is associated with a peer device, the action comprises at least one of the following: The device performs a third action directly; and The device informs the peer device or another peer device to perform a fourth action. [4] The method of claim 1, wherein the condition corresponding to the monitored network metric that is satisfied is based on at least one of the following: a system-configured condition for a system-configured action or a user-defined action and a custom condition for a system-configured action or a custom action. [5] The method of claim 1, further comprising: Deployment of the network monitoring agent on a plurality of devices (210) in the same local network, wherein the plurality of devices includes the peer devices; Monitoring network metrics by a respective device based on a configuration file for the corresponding device and Transmission of the monitored network metrics by the respective device to the server or to the server via one or more peer devices of the respective device. [6] Method according to claim 1, wherein the device, peer devices and other devices in the same local network comprise at least one of the following: an endpoint device, an intermediate device, an edge or leaf node, an internal or branch node, an access point, a switch, an access switch, a gateway and a router. [7] The method of claim 1, further comprising identifying the peer devices of the device based on a protocol comprising at least one of the following: a Multicast Domain Name System (mDNS) protocol; a Zigbee protocol; a Bluetooth mesh protocol and a broadcast Ethernet protocol. [8] The method of claim 1, further comprising: Displaying aggregated network monitoring data associated with the device, peer devices on the network, and other devices on the network on a screen of a device associated with the server, where the aggregated network monitoring data is displayed in conjunction with the network topology, and where the displayed aggregated network monitoring data shows at least one of the following: a visual representation of the network topology; a physical location of a device or group of devices on the network; a number assigned to the device or group of devices and a link (232, 234, 236, 238) or a connection between two devices on the network. [9] Method according to claim 8, wherein the display further includes interactive user elements that enable a user of the device associated with the server to see one or more of the following: a statistic or status that is associated with the link or connection; a rate of receiving or transmitting data; a rate of dropped packets; whether an external service is available; whether an unexpected captive portal or an unexpected proxy exists; whether a power outage is detected; and whether a response is received from a Dynamic Host Configuration Protocol (DHCP) server. [10] The method of claim 1, further comprising: Transferring the data associated with the monitored metrics and the action to an external monitoring instance via the server. [11] The method of claim 1, further comprising: Storing information associated with the identified majority of peer devices in a local cache of the device. [12] The method of claim 1, further comprising identifying the first peer device and the second peer device based on at least one of the following: a ranking for the identified majority of peer devices and a current network metric that is assigned to one or more of the identified majority of peer devices. [13] Non-transitory, computer-readable storage medium (604, 606) comprising instructions that can be executed by a computer to: to deploy a network monitoring agent on a device (214) in a network (220); to identify a plurality of peer devices (212, 216) in the same local network by the device without receiving an instruction orchestrated in the cloud; in response to successful direct communication with a server (204), to obtain a network monitoring configuration file for the device from the server, wherein the configuration file specifies network metrics to be monitored and a condition associated with a network metric; as a response to unsuccessful direct communication with the server, to obtain the configuration file from the server via an initial peer device; to monitor the network metrics specified in the configuration file; in response to the fulfillment of a condition corresponding to a monitored network metric, to perform a predetermined action; in response to successful direct communication with the server, to transmit data to the server that is associated with the monitored metrics and the action; and In response to unsuccessful direct communication with the server, the data is transferred to the server via a second peer device. the transmitted data enables the server, in conjunction with a network topology, to display aggregated network monitoring data associated with the device and peer devices in the network. [14] Non-transitory computer-readable storage medium according to claim 13, wherein, if the condition corresponding to the monitored network metric that is satisfied is associated with the device, the action comprises at least one of the following: The device performs an initial action directly; and The device informs a peer device to perform a second action; and wherein, if the condition corresponding to the monitored network metric that is satisfied is associated with a peer device, the action includes at least one of the following: The device performs a third action directly; and The device informs the peer device or another peer device to perform a fourth action. [15] Non-transitory computer-readable storage medium according to claim 14, wherein the condition corresponding to the monitored network metric that is satisfied is based on at least one of the following: a system-configured condition for a system-configured action or a user-defined action; and a custom condition for a system-configured action or a custom action. [16] Non-transitory computer-readable storage medium according to claim 14, wherein the instructions further comprise instructions to: to deploy the network monitoring agent on a plurality of devices (210) in the same local network, wherein the plurality of devices includes the peer devices; To monitor network metrics through a respective device based on a configuration file for that device; and to transmit the monitored network metrics from the respective device to the server or to the server via one or more peer devices of the respective device. [17] Non-transitory computer-readable storage medium according to claim 14, wherein the instructions further comprise instructions to: to display the aggregated network monitoring data associated with the device, peer devices on the network, and other devices on the network on a screen of a device associated with the server, where the aggregated network monitoring data is displayed in conjunction with the network topology, where the displayed aggregated network monitoring data shows at least one of the following: a visual representation of the network topology; a physical location of a device or group of devices on the network; a number assigned to the device or group of devices and a link (232, 234, 236, 238) or a connection between two devices on the network. [18] Non-transitory computer-readable storage medium according to claim 17, wherein the display further includes interactive user elements that enable a user of the device associated with the server to view one or more of the following: a statistic or status that is associated with the link or connection; a rate for receiving or transmitting data; a rate of dropped packets; whether an external service is available; whether an unexpected captive portal or an unexpected proxy exists; whether a power outage is detected; and whether a response is received from a Dynamic Host Configuration Protocol (DHCP) server.

Images