docs/architecture.md

   1 <!--
   2 This file is part of OSM Monitoring module
   3 All Rights Reserved to Whitestack, LLC
   4
   5 Licensed under the Apache License, Version 2.0 (the "License"); you may
   6 not use this file except in compliance with the License. You may obtain
   7 a copy of the License at
   8
   9         http://www.apache.org/licenses/LICENSE-2.0
  10
  11 Unless required by applicable law or agreed to in writing, software
  12 distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
  13 WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
  14 License for the specific language governing permissions and limitations
  15 under the License.
  16
  17 For those usages not covered by the Apache License, Version 2.0 please
  18 contact: bdiaz@whitestack.com or glavado@whitestack.com
  19 -->
  20 # Monitoring module (MON)
  21
  22 ## Summary
  23
  24 MON accomplishes the following tasks:
  25
  26 * Collects VDU metrics exposed by the VIM.
  27 * Collects VNF metrics exposed by the VNF via Juju charms.
  28 * Collects infrastructure metrics of external components, such as VIMs, WIMs and SDN controllers.
  29 * Stores metrics in a TSDB.
  30 * Manages and evaluates alarms related to VNF/VDU metrics.
  31
  32 ## Overview
  33
  34 ![](assets/MON_Overview_Diagram.jpg)
  35
  36 MON has the following components:
  37
  38 * MON Server: Handles alarms CRUD operations, through messages in the Kafka bus.
  39 * MON Collector: Collects VNF related metrics from VIMs and VCA and infrastructure metrics from external components, and then exports them to a Prometheus TSDB. It uses a plugin model both for collectors and for backends.
  40 * MON Evaluator: Evaluates alarms and sends notifications through the Kafka bus when they trigger.
  41
  42 ## MON Server
  43
  44 ![](assets/MON_Server_Create_Alarm.jpg)
  45
  46 MON Server subscribes to the message bus and waits for the following messages:
  47
  48 * topic: alarm_request - key: create_alarm_request
  49 * topic: alarm_request - key: delete_alarm_request
  50
  51 It performs the corresponding action and sends a response through a unique topic made of 'alarm_response_' plus a correlation_id, which is a field contained in the request message.
  52
  53 Alarms are stored in MON database in the OSM MySQL engine.
  54
  55 ## MON Collector
  56
  57 ![](assets/MON_Collector_VNF_Metric.jpg)
  58
  59 MON Collector handles two different types of metrics:
  60
  61 * VNF related metrics: Provided by the VIM (eg. cpu utilization of a VDU) or directly from the VNF itself (eg. number of users connected).
  62 * Infrastructure metrics: Correspond to metrics regarding external components such as VIMs (eg. status, hypervisor capacity, etc), WIMs and SDN controllers.
  63
  64 The module uses a plugin model to do the metric collection. In every collection cycle, it iterates over the running VNFs (VNFRs) as obtains the declared metrics in their VNFD. If it is a VIM provided metric (nfvi_metric), it selects the corresponding VIM plugin for doing that collection. In the case of an application metric (defined using proxy charms and the juju metrics framework), it is done through the Juju plugin.
  65
  66 Similar situation happens for external components. The module iterates over the registered VIMs, SDNCs and WIMs, and does collection of the status and other metrics through the corresponding plugin (eg. OpenStack, ONOS).
  67
  68 ## MON Evaluator
  69
  70 ![](assets/MON_Evaluator_Evaluate_Alarm.jpg)
  71
  72 MON Evaluator iterates over the alarms stored in the system and evaluates the corresponding metric by querying the TSDB against the alarm defined threshold. Then it published to the message bus a message containing the alarm info and the corresponding status.
  73
  74 An alarm can have three status:
  75
  76 * ok: The metric has not crossed the threshold.
  77 * alarm: The metric crossed the threshold.
  78 * insufficient-data: There is no metric data in the TSDB.