Integration with sdk

Metrics Types

Data that are generated from the tng-sdk-benchmark can be of a Type:

• container specific such as: cpu_usage_total_usage (common in all experiments)
• system under test specific such as: cpu_cores, mem_max (is this common in all experiments?)
• network service specific such as: TO BE COMPLETED (can we have an example here?)

Metrics Naming

Taking under consideration Prometheus best practices for naming:
https://prometheus.io/docs/practices/naming/

container name	monitoring name	dimensions
cname	monitoring name	ns_id & experiment_id

eg. mn_mp_output_vdu01_cpu_stats__online_cpus_int {ns_id:"ns-1vnf-ids-suricata",experiment_id:"suricata_performance"}

Note1: if we will use Prometheus putting the ns_id and experiment_id as a dimension helps to easily querying all timeseries data for a specific network service and/or experiment. Otherwise can be part of the metric name. For example: mn_mp_output_vdu01_cpu_stats__online_cpus_int_ns-1vnf-ids-suricata_suricata_performance

Note2: Some data in csv format can be:

• existing csv format

  • Question: What is the preread and read?
  • Tip: Columns that contain arrays should be split
  • Tip: Timestamp values should be unique (not repeated within the column values)
  • Tip: id column can be removed since timestamp can be used as primary key id

• clean existing csv format

• proposed csv format

Metrics Structure

If metrics come for a specific network service and experiment tabular format will be like this:

timestamp	m1	m2	m3
t1	value11	value12	value13
t2	value21	value22	value23
...	...	...	...
tn	valuen1	valuen2	valuen3

If metrics come for a specific network service and more than one experiments, tabular format will be like this:
(Note4: In case we have to run a profiling analysis upon data that come from different experiments we can only get metrics that are common in all experiments)

Experiment 1:

timestamp	m1	m2	m3
t1	value11	value12	value13
...	...	...	...
tn	valun31	valuen2	valuen3

Experiment 2:

timestamp	m1	m3	m4
tz	valuez1	valuez3	valuez4
...	...	...	...
tk	valunk1	valuek3	valuek4

Result Dataset to be analyzed:
(Note5: m1' & m3' do not include the dimension info so as to be feasible to get matched)

timestamp	m1'	m3'
t1	value11	value13
...	...	...
tk	valunk1	valuek3

Profiling

For more details see API defined here . Profiler is operating as a web server right now, so it's execution is done via curl requests but we foresee to support also a CLI operation mode. End user just has to provide:

• The time period (start_timestap/end_timestap) (*)
• the metrics list as an (JSONArray):
  [mn_mp_output_vdu01_cpu_stats__online_cpus_int{ns_id:"ns-1vnf-ids-suricata",experiment_id:"suricata_performance"}, mn_mp_output_vdu01_networks__eth0__rx_bytes {ns_id:"ns-1vnf-ids-suricata",experiment_id:"suricata_performance"} ]
  if metrics are left empty then all available Prometheus metrics will participate to the analytic process
• The dimensions as a JSONArray:
  • [{ns_id:"ns-1vnf-ids-suricata"}] gets all generated metrics for the specific network service
  • [{ns_id:"ns-1vnf-ids-suricata",experiment_id:"suricata_performance"}] gets all generated metrics for the specific network and only for the specific experiment
  • [{ns_id:"ns-1vnf-ids-suricata",experiment_id:"cpu_limitation"},{ns_id:"ns-1vnf-ids-suricata",experiment_id:"memory_limitation"}] gets all metrics for the specific network and for two different experiments (note3: we should examine whether is meaningful to join data from different experiments )
• monitoring metrics without dimensions as a JSONArray:
  • [mn_mp_output_vdu01_cpu_stats__online_cpus_int,mn_mp_output_vdu01_networks__eth0__rx_bytes] (get these metrics and all their available dimensions)