OpenStack - User contributions [en]

Freezer

2016-07-05T20:50:02Z

Deklan: /* Core Team */

[[File:SmallTransparent.png|thumbnail|none|]]

Freezer is a distributed backup restore and disaster recovery as a service platform. It is designed to be multi OS (Linux, Windows, OSX, *BSD), focused on providing efficiency and flexibility for block based backups, file based incremental backups, point-in-time actions, jobs synchronization (i.e. backup synchronization over multiple nodes) and many other features. It is aimed at being useful for all environments, including large ephemeral Clouds. Documentation and Code can be found at the following locations:

* [http://git.openstack.org/cgit/openstack/freezer/ freezer-agent and scheduler Source Code]
* [http://git.openstack.org/cgit/openstack/freezer-api/ freezer-api API Source Code]
* [http://git.openstack.org/cgit/openstack/freezer-dr/ Freezer Disaster Recovery]
* [http://git.openstack.org/cgit/openstack/freezer-web-ui/ Freezer Horizon Web UI Source Code]
* [https://launchpad.net/freezer Launchpad]

== Core Team ==

* Fausto Marzi (daemontool)
* Fabrizio Fresco (felipe)
* Guillermo Garcia (m3m0)
* '''[PTL]''' Pierre-Arthur Mathieu (slashme)
* Eldar Nugaev (reldan)
* Fabrizio Vanni (vannif)
* Jonas Pfannschmidt (jonaspf)
* Saad Zaher (szaher)
* Deklan Dieterly (ddieterly)

== Resources ==

{| border="1" cellpadding="2" cellspacing="0"
| Meetings
| https://etherpad.openstack.org/p/freezer_meetings Chairman: m3m0 or ddieterly
|-
| IRC
| #openstack-freezer on Freenode
|-
| Mailing List
| [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev OpenStack dev] list, prefix with [freezer]
|-
| Milestones
| https://launchpad.net/freezer/+milestones
|-
| Integration
| [[Freezer/Integration]] - Coming soon
|-
| Bug tracker
| https://bugs.launchpad.net/freezer
|-
| Blueprints
| https://blueprints.launchpad.net/freezer
|}

== Getting Started ==

* [https://wiki.openstack.org/wiki/Freezer-getting-started Getting Started]
* [https://wiki.openstack.org/wiki/Freezer-installation Installation]
* [https://wiki.openstack.org/wiki/FreezerDevStack Running Freezer via DevStack - Coming soon]

== Documentation ==

* [https://wiki.openstack.org/wiki/Freezer-getting-started-with-freezer Getting Started with Freezer]
* [https://wiki.openstack.org/wiki/Freezer-concepts Freezer Concepts]
* [https://wiki.openstack.org/wiki/Freezer-install Installing Freezer]
* [https://wiki.openstack.org/wiki/Freezer-docs Using Freezer]
* [https://wiki.openstack.org/wiki/Freezer-backup-restore Backup and Restore your data]
* [https://wiki.openstack.org/wiki/Freezer-api Freezer API]
* [https://wiki.openstack.org/wiki/Freezer-web-ui Freezer Web UI]
* [https://wiki.openstack.org/wiki/Python-freezerclient Python Freezer Client]

== Contributing ==

A good place to start is by reading at the [[How_To_Contribute]] to OpenStack page. For information on contributing to Freezer specifically see the [http://docs.openstack.org/developer/freezer/contribute/getting_involved.html Getting Involved] page in the developer documentation.

== Discussions / Etherpads ==
* [https://etherpad.openstack.org/p/freezer_meetings Weekly meetings notes]

'''Every Thursday there's a weekly meeting starting from 3:00 p.m. UTC on IRC room: openstack-meeting-alt'''

== Automation Details ==

* [https://wiki.openstack.org/wiki/FreezerAutomation Freezer Automation (Chef) - Coming soon]

== Technical Details ==

* [https://github.com/openstack/freezer/blob/master/README.rst Architecture]
* [https://wiki.openstack.org/wiki/FreezerFeatures Detailed features list]

== Presentations ==

* https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/freezer-the-openstack-back-up-as-a-service-platform

== Roadmap ==
* [https://wiki.openstack.org/wiki/FreezerRoadmap Freezer Roadmap]
[[category: Backup]]

== miscellaneous ==
* [https://wiki.openstack.org/wiki/FreezerLogo Logo]

Monasca

2015-08-13T20:58:03Z

Deklan:

== Overview ==

Monasca is a open-source multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution that integrates with OpenStack. It uses a REST API for high-speed metrics processing and querying and has a streaming alarm engine and notification engine.

==== Project Launchpad ====
: https://launchpad.net/monasca

==== Team Launchpad ====
: https://launchpad.net/~monasca

==== Documentation ====
: Operating Monasca: [[Monasca/Operations]]
: Monasca API Specification: https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md
: Agent Documentation: https://github.com/stackforge/monasca-agent

==== Presentations ====
: '''Monasca Deep Dive (Paris Summit)'''
:: Video: https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/monasca-deep-dive-monitoring-at-scale
:: Pdf: https://www.openstack.org/assets/presentation-media/Monasca-Deep-Dive-Paris-Summit.pdf

==== Demo ====
:Docker based Image useful for demos or a running API to hit from outside: https://registry.hub.docker.com/u/monasca/demo/

==== Repositories ====

: '''Core'''
:: Core: https://github.com/stackforge?query=monasca
:: Ancillary (grafana, installer, etc.): https://github.com/hpcloud-mon
:: Vagrant Development Environment: https://github.com/stackforge/monasca-vagrant
::: Scripts to aid in cloning all of our git repos exist in the monasca-vagrant project, monasca-repos.sh and monasca-ansible-repos.sh

: '''Deployment'''
:: Ansible: https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca
:: Puppet: https://github.com/openstack/puppet-monasca

==== Communication and Meetings ====
* IRC #openstack-monasca on freenode.net
* Weekly Meetings [[Meetings/Monasca]]
* [[Mailing Lists|OpenStack Mailing Lists]] use the topic tag [Monasca] openstack-dev has a topic filter available
* [https://launchpad.net/~monasca Monasca Team Launchpad] monasca@lists.launchpad.net

== Requirements ==
[[Monasca/Requirements]].

== Features ==

This section describes the overall features.

* A highly performant, scalable, reliable and fault-tolerant Monitoring as a Service (MONaaS) solution that scales to service provider metrics levels of metrics throughput. Performance, scalability and high-availability have been designed in from the start. Can process 100s of thousands of metrics/sec as well as offer data retention periods of greater than a year with no data loss while still processing interactive queries.

* Rest API for storing and querying metrics and historical information. Most monitoring solution use special transports and protocols, such as CollectD or NSCA (Nagios). In our solution, http is the only protocol used. This simplifies the overall design and also allows for a much richer way of describing the data via dimensions.

* Multi-tenant and authenticated. Metrics are submitted and authenticated using Keystone and stored associated with a tenant ID.

* Metrics defined using a set of (key, value) pairs called dimensions.

* Real-time thresholding and alarming on metrics.

* Compound alarms described using a simple expressive grammar composed of alarm sub-expressions and logical operators.

* Monitoring agent that supports a number of built-in system and service checks and also supports Nagios checks and statsd.

* Open-source monitoring solution built on open-source technologies.

== Architecture ==
[[File:monasca-arch-component-diagram.png|Monasca Architecture Component Diagram]]
* Monitoring Agent (monasca-agent): A modern Python based monitoring agent that consists of several sub-components and supports system metrics, such as cpu utilization and available memory, Nagios plugins, statsd and many built-in checks for services such as MySQL, RabbitMQ, and many others.
* Monitoring API (monasca-api): A well-defined and documented RESTful API for monitoring that is primarily focused on the following concepts and areas:
** Metrics: Store and query massive amounts of metrics in real-time.
** Statistics: Query statistics for metrics.
** Alarm Definitions: Create, update, query and delete alarm definitions.
** Alarms: Query and delete the alarm history.
***Simple expressive grammar for creating compound alarms composed of alarm subexpressions and logical operators.
***Alarm severities can be associated with alarms.
***The complete alarm state transition history is stored and queryable which allows for subsequent root cause analysis (RCA) or advanced analytics.
**Notification Methods: Create and delete notification methods and associate them with alarms, such as email. Supports the ability to notify users directly via email when an alarm state transitions occur.
* Persister (monasca-persister): Consumes metrics and alarm state transitions from the MessageQ and stores them in the Metrics and Alarms database. We will look into converting the Persister to a Python component in the future.
* Transform and Aggregation Engine: Transform metric names and values, such as delta or time-based derivative calculations, and creates new metrics that are published to the Message Queue. The Transform Engine is not available yet.
* Anomaly and Prediction Engine: Evaluates prediction and anomalies and generates predicted metrics as well as anomaly likelihood and anomaly scores.
* Threshold Engine (monasca-thresh): Computes thresholds on metrics and publishes alarms to the MessageQ when exceeded. Based on Apache Storm a free and open distributed real-time computation system.
* Notification Engine (monasca-notification): Consumes alarm state transition messages from the MessageQ and sends notifications, such as emails for alarms. The Notification Engine is Python based.
* Message Queue: A third-party component that primarily receives published metrics from the Monitoring API and alarm state transition messages from the Threshold Engine that are consumed by other components, such as the Persister and Notification Engine. The Message Queue is also used to publish and consume other events in the system. Currently, a Kafka based MessageQ is supported. Kafka is a high performance, distributed, fault-tolerant, and scalable message queue with durability built-in. We will look at other alternatives, such as RabbitMQ and in-fact in our previous implementation RabbitMQ was supported, but due to performance, scale, durability and high-availability limitiations with RabbitMQ we have moved to Kafka.
* Metrics and Alarms Database: A third-party component that primarily stores metrics and the alarm state history. Currently, Vertica and InfluxDB are supported.
* Config Database: A third-party component that stores a lot of the configuration and other information in the system. Currently, MySQL is supported.
* Monitoring Client (python-monascaclient): A Python command line client and library that communicates and controls the Monitoring API. The Monitoring Client was written using the OpenStack Heat Python client as a framework. The Monitoring Client also has a Python library, "monascaclient" similar to the other OpenStack clients, that can be used to quickly build additional capabilities. The Monitoring Client library is used by the Monitoring UI, Ceilometer publisher, and other components.
* Alarm Configuration Manager: A Python process that will detect new metrics and configure alarms based on the configuration. It uses the monitoring client library that communicates with the Monitoring API. The Alarm Configuration Manager is a Python Daemon that runs on a configurable interval and detects new metrics that need to be alarmed and creates the alarms.
* Monitoring UI: A Horizon dashboard for visualizing the overall health and status of an OpenStack cloud.
* Ceilometer publisher: A multi-publisher plugin for Ceilometer, not shown, that converts and publishes samples to the Monitoring API.
Most of the components are described in their respective repositories. However, there aren't any repositories for the third-party components used, so we describe some of the relevant details here.

=== Message Schema ===
[[Monasca/Message Schema]]

=== Message Queue ===
A distributed, performant, scalable, HA message queue for distributing metrics, alarms and events in the monitoring system. Currently, based on Kafka.

==== Messages ====
There are several messages that are published and consumed by various components in Monasca via the MessageQ. See [[Monasca/Message Schema|Message Schema]].

=== Metrics and Alarms Database ===

A high-performance analytics database that can store massive amounts of metrics and alarms in real-time and also support interactive queries. Currently Vertica and InfluxDB are supported.

The SQL schema that is used by Vertica is as follows:

* MonMetrics.Measurements: Stores the actual measurements that are sent.
** id: An integer ID for the measurement.
** definition_dimensions_id: A reference to DefinitionDimensions.
** time_stamp
** value
* MonMetrics.DefinitionDimensions
** id: A sha1 hash of (defintion_id, dimension_set_id)
** definition_id: A reference to the Definitions.id
** dimension_set_id: A reference to the Dimensions.dimension_set_id
* MonMetrics.Definitions
** id: A sha1 hash of the (name, tenant_id, region)
** name: Name of the metric.
** tenant_id: The tenant_id that submitted the metric.
** region: The region the metric was submitted under.
* MonMetric.Dimensions
** dimension_set_id: A sha1 hash of the set of dimenions for a metric.
** name: Name of dimension.
** value: Value of dimension.

=== Config Database ===
The config database store all the configuration information. Currently based on MySQL.

The SQL schema is as follows:

* alarm
** id
** tenant_id
** name
** description
** expression
** state
** actions_enabled
** created_at
** updated_at
** deleted_at
* alarm_action
** alarm_id
** alarm_state
** action_id
* notification_method
** id
** tenant_id
** name
** type
** address
** created_at
** updated_at
* sub_alarm
** id
** alarm_id
** function
** metric_name
** operator
** threshold
** period
** periods
** state
** created_at
** updated_at
* sub_alarm_dimension
** sub_alarm_id
** dimension_name
** value

== Events ==
Support for real-time event stream processing in Monasca is in progress. For more details see the link at, [[Monasca/Events]].

== Logging ==
Support for logging in Monasca is under discussion. For more details see the link at, [[Monasca/Logging]].

== Monitoring ==
Enablement and usage for monitoring the status of Monasca is under discussion. For more details see the link at, [[Monasca/Monitoring_Of_Monasca]]

== Value Metadata ==
Adding Metadata to the value of a measurement in Monasca is under discussion. For more details see the link at, [[Monasca/Value_Metadata]]

== Keystone Requirements ==
Monasca relies on keystone for running and there are requirements about which keystone configuration must exist.

* The endpoint for the api must be registered in keystone as the 'monasca' service.
* The api must have an admin token to use in verifying the keystone tokens it receives.
* For each project which uses Monasca two users must exist, one will be in the 'monasca-agent' role and be used by the monasca-agent's running on machines. The other should not be in that role and can be used logging into the UI, using the CLI or for direct queries against the API.

== Post Metric Sequence ==

This section describes the sequence of operations involved in posting a metric to the Monasca API.

[[File:monasca-arch-post-metric-diagram.png|Monasca Architecture Post Metric Diagram]]

# A metric is posted to the Monasca API.
# The Monasca API authenticates and validates the request and publishes the metric to the the Message Queue.
# The Persister consumes the metric from the Message Queue and stores in the Metrics Store.
# The Transform Engine consumes the metrics from the Message Queue, performs transform and aggregation operations on metrics, and publishes metrics that it creates back to Message Queue.
# The Threshold Engine consumes metrics from the Message Queue and evaluates alarms. If a state change occurs in an alarm, an "alarm-state-transitioned-event" is published to the Message Queue.
# The Notification Engine consumes "alarm-state-transitioned-events" from the Message Queue, evaluates whether they have a Notification Method associated with it, and sends the appropriate notification, such as email.
# The Persister consumes the "alarm-state-transitioned-event" from the Message Queue and stores it in the Alarm State History Store.

= Development Environment =

* Comes with a turn-key development environment based on Vagrant, that can be used for quickly deploying on a client system, such as a MAC OS X based system. See https://github.com/stackforge/monasca-vagrant.

* Monasca on LaunchPad. https://launchpad.net/monasca

* Monasca projects source code. https://github.com/search?q=monasca&ref=cmdform

= Coding Standards =

* Python: All Python code conforms to the OpenStack standards at, http://docs.openstack.org/developer/hacking/.

* Java: OpenStack does not have any Java coding standards. We've adopted the Google Java Style at, https://google-styleguide.googlecode.com/svn/trunk/javaguide.html.
** The standard says either 80 or 100 length lines. We've adopted 100.

We are in the process of porting to Python and evaluating the performance for the API layer.

= Technologies =

Uses a number of underlying technologies:

* Apache Kafka (http://kafka.apache.org): Apache Kafka is publish-subscribe messaging rethought as a distributed commit log. Kafka is a highly performant, distributed, fault-tolerant, and scalable message queue with durability built-in.

* Apache Storm (http://storm.incubator.apache.org/): Apache Storm is a free and open source distributed realtime computation system. Storm makes it easy to reliably process unbounded streams of data, doing for realtime processing what Hadoop did for batch processing.

* ZooKeeper (http://zookeeper.apache.org/): Used by Kafka and Storm.

* MySQL:

* Vagrant (http://www.vagrantup.com/): Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.

* Dropwizard (https://dropwizard.github.io/dropwizard/): Dropwizard pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done. Dropwizard has out-of-the-box support for sophisticated configuration, application metrics, logging, operational tools, and much more, allowing you and your team to ship a production-quality web service in the shortest time possible.

* InfluxDB (http://influxdb.com/): An open-source distributed time series database with no external dependencies.

* Vertica (http://www.vertica.com): A commercial Enterprise class SQL analytics database that is highly scalable. It offers built-in automatic high-availability and excels at in-database analytics and compressing and storing massive amounts of data. In the HP Public Cloud we use Vertica in a number of areas such as metrics and many other data streams. Currently, we process around 25 K metrics/sec and store them for > 13 month data retention periods. A free version of Vertica that can store up to 1 TB of data with no time-limit is available at, https://my.vertica.com/community/.

= License =

Copyright (c) 2014 Hewlett-Packard Development Company, L.P.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.

[[File:yklogo.png|200px|thumb|left|Monasca uses YourKit Profiler for Java development]]

<br />
<br />
<br />
<br />

[https://www.yourkit.com/ Visit YourKit website for more information]

2015-01-14T17:37:21Z

Deklan: /* AlarmCreatedEvent */

Monasca/Message Schema

2015-01-14T17:32:15Z

Deklan: /* Example */

Monasca/Message Schema

2015-01-14T17:31:46Z

Deklan: /* AlarmDefinitionUpdatedEvent */

Monasca/Message Schema

2015-01-14T17:28:50Z

Deklan: /* AlarmDefinitionDeletedEvent */

Monasca/Message Schema

2015-01-14T17:24:28Z

Deklan: /* AlarmDefinitionCreatedEvent */