TOSCA Monitoring Working Group Status Roger Dev June 17, 2015

Working Group Status Determined that providing an interoperable generalized monitoring capability is beyond the reach of the working group – Too complex for the target users of TOSCA to specify – Requires definition of new protocols outside the TOSCA charter Refocused on minimal useful scenario – Monitor Scenario 1 – Service Template defines only service monitoring needs – not methods or mechanisms – Basic monitoring functionality – Limited set of Core Metrics allowing private extensions – No interoperability mechanisms defined Ready to request YAML definition by YAML WG

Monitoring Activation Flow Service Template Virtual Machine (new) Software Component (new) Monitoring Sub-System (MSS) Notify Component State Change: -Create -Modify -Destroy Deliver Metrics (any existing push or pull protocol) Orchestrator Components Created TOSCA specified Outside current charter KEY ? Monitoring Exception

Monitoring Scenario 1 Features FeatureProvided In MS1? Define Key Metrics and GroupsYes Allow for Extended Metric TypesYes Service Template Requests MonitoringYes Service Template Requires MonitoringYes Specify Metric Types to be monitoredYes Limit the Components (sub-node) to be monitored Yes Specify Minimum Sample FrequencyYes Actions on thresholds / state changesNo Derived Metrics (Formulas, Aggregations)No

Not to be defined under MS1 Interfaces between Orchestrator and MSS Metrics publishing interface Access to stored Metrics or Events Monitoring of Orchestrator Explicit support for Services with embedded MSS

Next Steps Define needed extensions to YAML definitions (under review) YAML WG produces YAML definitions Review and approve YAML definitions Define Core Metric Types and Groups Work toward new features: – Thresholds, Events, and Actions – Derived Metrics Should we be working toward interoperability agreement of some sort?

Questions? Suggestions?

BACKUP SLIDES

TOSCA Monitoring Reference Diagram Monitoring Automation Point (MAP) MAD (Monitoring Act / De-act) MIA (Monitorning Info Access) MEA (Monitoring Extension Advert) OM (Orchestrator Monitoring) Service TemplateExternal ProcessInternal Process External Monitoring System - Monitoring Template / Policy -Management Communication Info - Metric Availability - Metric Time Series - Events? -Metric Values -Events? -Metric Time Series -Events Focus on Subset of MAD

YAML Development Request (1 of 2) The Monitoring Ad Hoc Working Group requests that the following YAML definitions be developed and reviewed with this group in preparation for inclusion in the TOSCA specification: – Monitoring Policy – Define a new type of Policy object – Monitoring Policy -- which can specify the following fields. Monitoring will only be enabled for Nodes to which a Monitoring Policy is applied. Monitoring Disposition: – Required – Don’t deploy if you can’t monitor – Best Effort – Deploy in any case, but enable monitoring if available Minimum Sample Frequency (Optional) – Defines the minimum sample frequency in minutes for Metrics collection. If specified, and Monitoring Disposition (above) is set to “Required”, then the deployment will fail if this frequency cannot be met. If omitted, then the default frequency for the installation will be used. Specified in minutes. Metric Filter (Optional) – If not specified, then all of the standard metrics will be collected for all components – Metric Type filter (Optional) – Allows Metric Types to be included or excluded by name or hierarchical grouping. If not specified, then all of the standard metrics will be collected. » Metrics to Include – List of Metric Type Names to explicitly include. This allows core metrics to be named (or included as a group). It also allows non-standard metrics to be specified. A special value should be provided (e.g. “Maximum”) which instructs the Monitoring Subsystem to collect all available Metric Types. » Metrics to Exclude – List of Metric Type Names to exclude. If Metrics to include was specified, then this exclude list will only apply to the included metrics. Otherwise, it will apply to the standard metrics for each node type. – Component Filter (Optional) – Determines which components (below the level of Node) should be included or excluded for List type Metrics. Examples are CPUs, Interfaces, Ports, Storage Media, Users, etc. where metric values are available for multiple components within the Node. If this filter is omitted, then all components will be included. » Components to Include (Optional) -- A list of name filters, each of which can match one or more component names using e.g. wildcard or regular expression filters to match multiple component names. If this field is omitted, then all components will be included. » Components to Exclude (Optional) – A list of component name filters as above, which will be excluded from metrics collection. If components to include was specified, then this field will cause components within that input list to be excluded. Otherwise, this will filter the list of all applicable components for each Node.

YAML Development Request (2 of 2) – Metric Type Definition – Defines the core metrics supported under TOSCA. Metrics are grouped to allow inclusion or exclusion of groups or individual metrics. Metric Types define the following: Metric Type Name – The name by which the metric type is known Metric Type Description – Long text string describing the meaning of the Metric Type Metric Data Type – The base data type for metrics of this type: – String – Integer – Float Component Basis (Optional) – If specified, Metrics of this type will be collected for each component that exists of the specified type. For example, if the Component Basis is “CPU”, then an instance of this Metric Type will be created for each CPU defined for a Node. If omitted, then only a single instance will be created for each node. Units (Optional) – The unit type used for this Metric Type (e.g. Megabytes, Gigabytes, Seconds, Volts, Percent, etc. If not specified then the metric is assumed to be unitless. Constraints (Optional) – Defines constraints on the values which Metrics of this Type can hold – Range (Optional) – Defines a minimum and maximum value for numeric Metrics – Enumeration (Optional). Defines a set of valid values that Metrics of this type may take (e.g.. [‘Green’, ‘Yellow’, ‘Red], [0,1,2])