Difference between revisions of "Monasca/Operations"
Tim Kuhlman (talk | contribs) |
Tim Kuhlman (talk | contribs) (Better headings) |
||
Line 1: | Line 1: | ||
− | + | = Monasca Overview = | |
− | + | Monasca is a monitoring system with many parts that can scale horizontally to service large cloud deployments. The Monasca components can roughly be broken down into two categories, those which are part of the server cluster and the components that interact only with the Monasca API. In the standard flow of data Monasca agents send [https://github.com/stackforge/monasca-agent/blob/master/docs/MonascaMetrics.md measurements] into the system which are then processed by the threshold engine as well as stored for future retrieval and/or graphing. | |
− | |||
− | Monasca is a monitoring system with many parts that can scale horizontally to service large cloud deployments. The Monasca components can roughly be broken down into two categories, those which are part of the server cluster and the components that interact only with the Monasca API. In the standard flow of data | ||
The Monasca threshold engine evaluates metrics according to [https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md#alarm-definitions-and-alarms alarm definitions]. As measurements come into the system alarms are created according to how they match the alarm definitions. Each alarm definition can be associated with a [https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md#notification-methods notification method] which triggers when the alarm changes state. | The Monasca threshold engine evaluates metrics according to [https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md#alarm-definitions-and-alarms alarm definitions]. As measurements come into the system alarms are created according to how they match the alarm definitions. Each alarm definition can be associated with a [https://github.com/stackforge/monasca-api/blob/master/docs/monasca-api-spec.md#notification-methods notification method] which triggers when the alarm changes state. | ||
− | Monasca is fully multi-tenant so each project must configure the agents and alarm definitions to drive the system. | + | = Client Configuration = |
+ | Monasca is fully multi-tenant so each project must configure the various agents and alarm definitions to drive the system. | ||
== Alarm Definition Configuration == | == Alarm Definition Configuration == | ||
Line 16: | Line 15: | ||
An Ansible role for installing and configuring the agent is available at https://github.com/hpcloud-mon/ansible-monasca-agent | An Ansible role for installing and configuring the agent is available at https://github.com/hpcloud-mon/ansible-monasca-agent | ||
− | + | = Server Installation and Configuration = | |
The entire server stack with all of its components can be built and configured using Ansible. The [https://github.com/stackforge/monasca-vagrant team development environment] does this on a small scale. The various [https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca roles] have also been used in fully clustered deployments of Monasca. | The entire server stack with all of its components can be built and configured using Ansible. The [https://github.com/stackforge/monasca-vagrant team development environment] does this on a small scale. The various [https://github.com/search?utf8=%E2%9C%93&q=ansible-monasca roles] have also been used in fully clustered deployments of Monasca. | ||
Additionally some teams have configured [https://github.com/twc-openstack/puppet-monasca Monasca via Puppet.] | Additionally some teams have configured [https://github.com/twc-openstack/puppet-monasca Monasca via Puppet.] |
Revision as of 22:07, 28 April 2015
Contents
Monasca Overview
Monasca is a monitoring system with many parts that can scale horizontally to service large cloud deployments. The Monasca components can roughly be broken down into two categories, those which are part of the server cluster and the components that interact only with the Monasca API. In the standard flow of data Monasca agents send measurements into the system which are then processed by the threshold engine as well as stored for future retrieval and/or graphing.
The Monasca threshold engine evaluates metrics according to alarm definitions. As measurements come into the system alarms are created according to how they match the alarm definitions. Each alarm definition can be associated with a notification method which triggers when the alarm changes state.
Client Configuration
Monasca is fully multi-tenant so each project must configure the various agents and alarm definitions to drive the system.
Alarm Definition Configuration
Alarm definitions can be created directly through the api and via the python-monascaclient cli]. Additionally there is an Ansible module to assist in Alarm definition creation and a role with many default alarms already defined, both found at https://github.com/hpcloud-mon/ansible-monasca-default-alarms.
Agent Configuration
The Monasca agent is highly configurable and can collect measurements from many sources as well as be extended. For information on direct configuration refer to the agent documentation.
An Ansible role for installing and configuring the agent is available at https://github.com/hpcloud-mon/ansible-monasca-agent
Server Installation and Configuration
The entire server stack with all of its components can be built and configured using Ansible. The team development environment does this on a small scale. The various roles have also been used in fully clustered deployments of Monasca.
Additionally some teams have configured Monasca via Puppet.