From: lavado Date: Sat, 9 Nov 2019 20:42:11 +0000 (+0100) Subject: Metric segmentation & access by project X-Git-Url: https://osm.etsi.org/gitweb/?a=commitdiff_plain;h=4d492597a5b53f5ff2c5d70e34c17d2974db6ef9;p=osm%2FFeatures.git Metric segmentation & access by project Change-Id: I0400a477369c4b7781356af725186dc8ab073d01 --- diff --git a/Release7/metric_segmentation_multitenancy.md b/Release7/metric_segmentation_multitenancy.md new file mode 100644 index 0000000..03c3157 --- /dev/null +++ b/Release7/metric_segmentation_multitenancy.md @@ -0,0 +1,36 @@ +# OSM Metric segmentation & access by project + +## Proposers + +- Gianpietro Lavado (Whitestack) +- Gerardo Garcia (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type + +Feature + +## Target MDG/TF + +SA + +## Description + +Metrics in Prometheus are stored in key-value pairs, grouped per name and differentiated by labels. +Current design keeps metrics grouped by name (i.e. cpu_usage) and allows to differentiate based on +label filtering (i.e. ns_id), so for example, a Grafana dashboard can be created for a single NS ID, +filtering by the metric's label "NS_ID". + +Still, current design has some limitations: +- VIM metrics have different names by default and refer to the same resource for any NS/VNF, but +VNF Metrics (Indicators) using the same name, could have different semantics depending on the VNF, +or worse, different types (gauge and counter for example), and may not be supported. +- There is no role-based authentication or tenant awareness. Prometheus has some limitations, but +Grafana may solve some of ths issues at a higher level by automating the creation of dashboards. + +This feature presents an opportunity to revisit metric segmentation, authentication, and dashboard +automation. + +## Demo or definition of done + +OSM users should be able to see the metrics beloging to their own NS, automatically, in Grafana. \ No newline at end of file