From 9cc1b50772d5ab714408f9f1aa0ecb311f873c37 Mon Sep 17 00:00:00 2001 From: Simon Crowle <sgc@it-innovation.soton.ac.uk> Date: Wed, 20 Dec 2017 10:16:23 +0000 Subject: [PATCH] Update monitoring.md --- docs/monitoring.md | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/docs/monitoring.md b/docs/monitoring.md index 21899ef..b2509b7 100644 --- a/docs/monitoring.md +++ b/docs/monitoring.md @@ -25,10 +25,35 @@ Tags can be structured to provide query by dimensions allowing series data to be #### Temporal Measurements -####Spatial Measurements +Monitoring data must have time-stamp values that are consistent and sycnrhonised across the platform. +This means that all VMs hosting SFs should have a synchronised system clock, or at least (and more likely) +a means by which an millisecond offset from the local time can be retrieved so that a 'platform-correct' +time value can be calculated. + + +#### Spatial Measurements Discuss hierarchical tags vs GPS coordinate systems +Location should be provided in two forms: labelled (tag) and numeric (longitude and latitude as digitial degrees). Note that the location label is likely to be a _global tag_. This allows us to support the +following scenarios: + +##### SF with no knowlegde of GPS coordinates + +| loc_label | loc_long | loc_lat | +| --- | --- | --- | +| DATACENTRE_1 | 0 | 0 | + +A SF media transcoder is placed in a lamp-post. It has no means to obtain GPS coordinates but has a _loc_label_ provided to it as a VM environment variable. It provides zeros in the longitude and latitude. In subsequent data analysis we can search for this SF by location label. + +##### SF with full location knowledge + +| loc_label | loc_long | loc_lat | +| --- | --- | --- | +| LAMP_1 | 50.842715 | -0.778276 | + +A SF that is a proxy to a user attached to a NAP running in street lamp post LAMP_1. Here we have knowledge both of the logical location of the service and also the fine-grained, dynamic position of the service user. Lots of interesting possibilities with both of these bits of information! + ### Logical Model The high-level entities involved in the measurement model are defined in the figure below. The core of the model is the Surrogate SF as the primary measurement point as this is the physical realisation of services running on the platform. A Surrogate SF is a process running on a physical or virtual host with ports connecting to other Surrogate SFs within the network. The Surrogate SF has measurement processes running to capture different views on the SF include the network, host resources, and SF usage/performance. The acquisition of these different views on the SF together is a key element of the cross-layer information required for management and control. The measurements about a surrogate SF is captured by different processes running on the VM or container but are brought together by globally asserted monitoring metadata allowing the information to be integrated, correlated and analysed. @@ -98,7 +123,6 @@ A couple of comments * CPU_UTILISATION_M: will be replaced by other metrics provided directly by Telegraf plugins * END_TO_END_LATENCY_M (not clear who the endpoints are) - ### Measurements #### Capacity Measurements -- GitLab