User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

monitoring-metrics_network [2014/07/17 12:10] (current)
esunly created
Line 1: Line 1:
 +<WRAP box 200px right :en>
 +//​**__[[testbeds:​monitoring|CONFINE Monitor]]__**//​
 +  - [[testbest:​monitoring-motivation|Motivation]]
 +  - [[testbest:​monitoring-design|Design]]
 +  - [[testbest:​monitoring-client|Monitoring Client]]
 +    - ''​[[testbest:​monitoring-client_components|Client Components]]''​
 +    - ''​[[testbest:​monitoring-client_specifics|Client Specifics]]''​
 +  - [[testbest:​monitoring-server|Monitoring Server]]
 +    - ''​[[testbest:​monitoring-server_components|Server Components]]''​
 +    - ''​[[testbest:​monitoring-server_specifics|Server Specifics]]''​
 +  - **[[testbest:​monitoring-metrics|Monitor Metrics]]**
 +    - ''​[[testbest:​monitoring-metrics_node|Node Metrics]]''​
 +    - ''​[[testbest:​monitoring-metrics_server|Server Metrics]]''​
 +    - **''​[[testbest:​monitoring-metrics_network|Network Topology]]''​**
 +====== Network Topology ======
 +The CONFINE monitoring system also includes a special kind of metrics that allows us to have an idea of the topology of the nodes that are part of the Confine network. This network topology metric is useful to understand the relationships between the different CONFINE nodes, that is, how the Research Devices are related to each other. **Figure 21** shows the information displayed by the monitoring system after collecting the network topology metrics. We can observe the Controller node in yellow, the different RDs in green and other network nodes in light blue.
 +{{ :​monitor:​topology-3.png?​800 |}}
 +                                         ​Figure 21: Network Topology map
 +This new metric is extremely important for researchers that want to deploy experiments in CONFINE. By visualising the Network Topology, an experimenter can easily detect, for example, if all the Research Devices that he was going to select to run his experiments are connected to the same Community Device (CD). Running a experiment before checking this network map would'​ve meant that the experimenter is not really taking advantage of the community networks that are part of CONFINE because all the selected RDs were directly connected to the same node. **Figure 22** depicts an example of the Network Topology of nodes connected to the same CD.
 +{{ :​monitor:​topology-2.png?​800 |}}
 +                               ​Figure 22: Example of selection of RDs connected to the same CD
 +In order to determine the topology of the CONFINE network we add a //​**Traceroute Pluggable Daemon**// to the monitoring clients located in the different RDs. **Figure 23** shows how the RDs containing these daemons send traceroute packages every 60 seconds to the network node that hosts the CONFINE Controller. The Monitoring Server then receives all the traceroute messages from all the RDs belonging to the CONFINE network and responds accordingly.This way, all the Traceroute Daemons collect then information about the path from the specific RD to the Controller.
 +{{ :​monitor:​traceroute-daemon.png?​900 |}}
 +                                       ​Figure 23: Traceroute Pluggable Daemon
 +The information collected by the Traceroute Daemons is saved in a JSON document and sent to the Monitoring Server to be stored at the database. These JSON files are the //​**"​Traceroute"​ type**// documents mentioned in the [[testbest:​monitoring-server_specifics|Server Specifics]] section. The content of these documents is depicted in **Figure 24**.
 +{{ :​monitor:​traceroute.png?​800 |}}
 +                              Figure 24: Traceroute metrics monitored by the server
 +As we can observe, the Traceroute document saved by every RD contains a //​**"​trace"​**//​ or list of the nodes that are in the path from such RD to the Controller. For each node we have the following information:​
 +  * IP address.
 +  * Name.
 +  * Round-Trip Time (RTT).
 +For clarification,​ let consider a network composed by 6 nodes, where 1 of them is the Controller and only 2 of the others are RDs. **Figure 25** shows an example of the list of nodes that each RD would return to the Monitoring Server.
 +{{ :​monitor:​traceroute-nodes.png?​450 |}}
 +                           ​Figure 25: Example of the trace information monitored by the RDs
 +As we can observe in the figure, each RD saves a list containing the hop sequence from such RD to the Controller. When the Monitoring Server located in the Controller performs monitoring tasks every 5 minutes, it collects this information in form of JSON documents and stores them in the Couchbase database. The Middleware component of the server then fetches the hop sequences for each RD from the database and converts them to direct neighbour relationships. According to the example in the figure, we miss information about node 5, but this fact is not a problem for us because we are only interested in having information about RDs and their relationships but we do not need to have a precise representation of the network topology.
monitoring-metrics_network.txt ยท Last modified: 2014/07/17 12:10 by esunly