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)

1

2

3

Orchestrator

Components Created

TOSCA specified

Outside current charter

KEY

? Monitoring Exception

Monitoring Scenario 1 Features

Feature Provided In MS1?

Define Key Metrics and Groups Yes

Allow for Extended Metric Types Yes

Service Template Requests Monitoring Yes

Service Template Requires Monitoring Yes

Specify Metric Types to be monitored Yes

Limit the Components (sub-node) to be monitored

Yes

Specify Minimum Sample Frequency Yes

Actions on thresholds / state changes No

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 Template External Process Internal ProcessExternal

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])