2c1a2ed225
5 min was copy/paste from official docs. After reading more about health checks in real world usage most examples was using duration around 5 seconds for interval. By default docker will show if service is unhealthy after 3 intervals return error. So in previous timing service would be taken out of poll (by e.g. docker swarm) after 15 min. For all this time it would be returning errors for any communication to it. Now it will be removed from poll of running services after 15 seconds. Regarding timeout more examples was using something shorter. For all services we are using if anything respond longer than 2 seconds then something is wrong with this service. Monasca is not web service but back-end service that should have high throughput. Change-Id: I4486c4974de38dea33739fdc470f38fd99d428fa
Team and repository tags
Overview
monasca-common is a collection of modules containing
reusable application and platform code for building monitoring related
services.
Python
To install the Python monasca-common modules, git clone the source and run the following command:
$ sudo python setup.py installTo run the unit tests use:
$ tox -e py27,py35For information on contributing, see Contribution Guidelines.
- License: Apache License, Version 2.0
- Source: https://git.openstack.org/cgit/openstack/monasca-common
- Bugs: https://storyboard.openstack.org/#!/project/865
Java
Build Instructions
Download and do mvn install.
$ cd java
$ mvn clean installCaution
There is a pom.xml in the base directory but that should only be used for the Zuul build.
The issue is that currently StackForge’s bare-precise system only has Maven 2 on it and at least one of the modules of monasca-common requires Maven 3.
In order to get around this problem, the pom.xml in the base directory uses the exec-maven-plugin to run the script run_maven.sh. This script checks if the version of mvn is Maven 3 and if it is not, it downloads Maven 3 and then uses it to run the build in the java directory.
In addition, the run_maven.sh script copies the jar files that get
built from java/*/target directories to the target
directory in the base project directory. This is because the StackForge
“monasca-common-localrepo-upload” job uploads any jar files from that
directory to http://tarballs.openstack.org/ci/monasca-common.
Copying the jar files to that directory made it so there didn’t have to
be changes made to the “monasca-common-localrepo-upload” job. The build
for monasca-thresh downloads the jars it depends on from that location
on tarballs.openstack.org.
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.
Application Specific Sub-Projects
- monasca-common-model - Common domain and event models for monitoring services.
Platform Sub-Projects
- monasca-common-dropwizard - Utilities for building and testing dropwizard services.
- monasca-common-hibernate - Hibernate based model of Monasca SQL schema
- monasca-common-influxdb - InfluxDB related utilities.
- monasca-common-kafka - Various utilities for working with Kafka.
- monasca-common-persistence - Persistence related infrastructure and utilities.
- monasca-common-streaming - Streaming related utilities.
- monasca-common-testing - A set of testing related dependencies.
- monasca-common-util - Various utilities such as for serialization, dependency injection, date and time, invocation retries, concurrency, etc.