1. TOSCA Monitoring Reference Architecture Straw-man Roger Dev CA Technologies March 18, 2015 PRELIMINARY

2. TOSCA Monitoring Use Cases As an Application Architect, I want to know which metrics I can expect to be available from a given component. As an Application Architect, I want to define, within the Service Template, the Metrics to be collected for a component, as well as how they are to be collected and managed (thresholded, etc). – Additionally, I may want to use my favorite monitoring tools rather than those provided by the Service Provider. As an Application Operator, I want to be able to access collected metrics and events for any or all of my deployed components, either: – Interactively – Programmatically As an Application Developer, I want to be able to produce custom metrics from my application(s) and have them stored and accessed along with any standard metrics As a Service Provider, I may want to define Monitoring Policies for component types that may be different from those designated by the Application Architect. As a Service Provider, I want to be able to utilize my favorite monitoring tools rather than those supplied with an orchestration framework. As a Service Provider, I want to be able to access a robust set of Metrics and Events about the orchestration framework, since that is a critical component of my infrastructure. As a Service Provider, I want to be able to utilize the full set of topological information provided by the Nested Service Template(s) to enhance my knowledge of running applications. This includes the output sections of the Templates.

3. Important Concepts Monitoring Automation Point (MAP) – Provides an abstract interface between the Service Template and a monitoring system – MAP can be implemented in several ways: A default mechanism provided by the orchestrator A reflection to an external monitoring system provided by the cloud service provider (may be many context-dependent instances of said system). This would override the orchestrator MAP destination for the SP. A reflection to a monitoring component defined within the Service Template. This would override the MAP destination of the orchestrator and SP within the context of the Service Template. – The above mechanisms may utilize a ‘Tee’ structure rather than an override. This would allow e.g., an SP to still receive MAP notifications even if the Service Template specifies its own mechanism in order to allow SP as well as end-user monitoring MAP Address – Provides a designator (abstract at this point) that identifies the location of the specific MAP which is to service the given Service’s MAP requests. – This address can be changed or augmented (see MAP above) by the SP, or the Service Template. Monitoring Interface – Defines a specific type of interaction between TOSCA users and TOSCA implementations – MI is an abstract concept at this point that may be realized through e.g., network protocol, script invocation, orchestrator API, or other mechanism(s) TBD

4. TOSCA Monitoring Interfaces Monitoring Activation and De-activation (MAD) – Define the available metrics for a component type – Define the desired state of monitoring whenever a component is deployed (Monitoring Rules) – Pass Monitoring rules to a Monitoring Automation Point (MAP) whenever a component is activated (i.e. deployed) – Pass Management Access Information (e.g. component identifier, management protocol(s) and credentials) to MAP for each monitored component. – Notify MAP when a component is de-activated Monitored Information Access (MIA) – Provide interface whereby a user or automated process can access monitoring information from the MAP – Continuous feed or Query based or both (TBD) – Incudes Metric time series as well as Events (TBD) Metric Extension Advertisement (MEA) – Interface whereby a service component (node) can advertise the definition of, and the periodically sampled values of non-standard metrics to the MAP Orchestrator Monitoring (OM) – Allows a monitoring system to receive / retrieve Metrics and / or Events from the orchestrator in order to effectively monitor the orchestration activities (e.g. deployments, deployment faults and exceptions, de-activations)

5. 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

6. Phasing Recommendations Define interfaces according to the following priority: – MAD – OM – MIA – MEA Include MAD and possibly OM in the current phase Defer MIA and MEA for a future phase