Monasca Thresholding Engine
Go to file
Craig Bryant d96fb0d852 Change to use monasca everywhere
service is now monasca_thresh. Config file in /etc/monasca

Fixed start and stop in install script

Change-Id: I5272c8ac32e497be978f8c59c4c5b6964ed4e9d2
2014-08-06 17:23:29 -06:00
download Get initial build to work. 2014-07-24 15:28:13 -06:00
thresh Change to use monasca everywhere 2014-08-06 17:23:29 -06:00
.gitignore Get initial build to work. 2014-07-24 15:28:13 -06:00
.gitreview Get initial build to work. 2014-07-24 15:28:13 -06:00
LICENSE Add in the LICENSE file 2014-05-01 16:05:25 -06:00
README.md Update README with details of StackForge build 2014-07-25 17:43:43 -06:00
mon-thresh-architecture.png Added architecture diagram. 2014-05-01 10:09:20 -06:00
pom.xml Change to use monasca everywhere 2014-08-06 17:23:29 -06:00

README.md

monasca-thresh

Monitoring Thresholding Engine

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. Also uses Apache Kafka, a high-throughput distributed messaging system.

Threshold Engine Architecture

Alarms have three possible states: UNDETERMINED, OK and ALARM. Alarms are defined by an expression. For example:

avg(cpu{service=nova}, 120) > 90 or avg(load{service=nova}, 120) > 15

If the expression evaluates to true, the Alarm state transitions to ALARM, if it evaluates to false, the state transitions to OK and if there aren't any metrics for the two times the measuring period, the Alarm state transitions to UNDETERMINED. Each part of the expression is represented by a Sub Alarm, so for the above example, there are two Sub Alarms.

The Threshold Engine is designed as a series of Storm Spouts and Bolts. For an overview of Storm, look at the tutorial. Spouts feed external data into the system as messages while bolts process incoming messages and optionally produce output messages for a downstream bolt.

The flow of Metrics is MetricSpout to MetricFilteringBolt to MetricAggregationBolt. The MetricSpout reads from Kakfa and sends it on through Storm. Metrics are routed to a specific MetricFilteringBolt based on a routing algorithm that computes a hash code like value based on the Metric Definition so a Metric with the same MetricDefinition is always routed to the same MetricFilteringBolt. The MetricFilteringBolt looks up the Metric Definition and decides if it should be sent on to a MetricAggregationBolt using the same routing algorithm. The MetricAggregationBolt adds the Metric information to its total for each SubAlarms and once a minute evaluates each SubAlarm it has.

So, each Metric is routed through one of the MetricFilteringBolts. The MetricAggregationBolts processes many fewer Metrics because few Metrics are associated with an Alarm.

Once a minute, the MetricAggregationBolts use the Aggregated Metrics to evaluate each Sub Alarms. If the state changes on the Sub Alarm, the state change is forwarded to the AlarmThresholdingBolts. The AlarmThresholdingBolts look at the entire Alarm Expression to evaluate the state of the Alarm.

Events also flow into the Threshold Engine via Kafka so the Threshold Engine knows about Alarm creations, updates and deletes. The EventSpout reads the Events from Kafka and sends them to the appropriate bolts.

=======

Build

Requires monasca-common from https://github.com/stackforge/monasca-common. Download and follow the instructions in the README

cd thresh
mvn package

StackForge Build

There is a pom.xml in the base directory that should only be used for the StackForge build. The StackForge build is a rather strange build because of the limitations of the current StackForge java jobs and infrastructure. This build depends on jars that are built in the monasca-common build. That StrackForge build uploads the completed jars to http://tarballs.openstack.org/ci/monasca-common, but they are just regular jars, and not in a maven repository. Hence, the first thing the maven build from the base project does is execute the build in the download directory. That pom.xml executes the script download.sh which downloads the required jars from http://tarballs.openstack.org/ci/monasca-common and then uses maven to install them in the local directory. The maven install needs the pom.xml so that is pulled from the jar file and then changed to have the right version before the install.

The monasca-common jars also need the base monasca-common pom.xml. So, that is pulled from gihtub.com and also installed in the local repository.

Since this is all rather complex, that part of the build only works on StackForge so follow the simple instruction above if you are building your own monasca-thresh.

Currently this build is executed on the bare-precise nodes in StackForge and they only have maven 2. So, this build must be kept compatible with Maven 2. If another monasca-common jar is added as a dependency to java/pom.xml, it must also be added to download/download.sh.

A change has been submitted to StackForge to switch to bare-trusty for this build in the hopes that those systems will have maven 3, but it is not known how long that change will take to be accepted.

Combining monasca-common, monasca-thresh, monasaca-api and monasca-persister into one build would vastly simplify the builds but that is a future task.

=======

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.