LATEST VERSION: 1.5.10 - CHANGELOG
Service Metrics v1.5.10

Deploying a Release with Service Metrics

Add service metrics to your bosh manifest

The service metrics release provides a job called service_metrics that can be co-located with other bosh jobs to gather metrics from them.

The metron_agent job must accompany service_metrics to emit these metrics to the Cloud Foundry Loggregator.

Add service_metrics job

Add the service_metrics job to an instance group in your bosh manifest.

Configure the service_metrics job with the following properties:

Field Type Description Required Default Value
origin string the name of the service, so it can reference metrics originating from that service in the logs yes n/a
metrics_command string the command to generate the metrics no see Metrics command
metrics_command_args array of strings any args provided to metrics_command no []
execution_interval_seconds int how often the metric generation command runs no 60
debug boolean turn verbose mode on/off no false
monit_dependencies array of strings jobs that must run before monit attempts to start the service metrics job. This is a way to define job dependencies, which are not supported by BOSH. no []

Add metron_agent job

Co-locate the metron_agent job with the service_metrics job.

Configure the metron_agent job as appropriate for the version of Cloud Foundry Loggregator that you want to target.

Loggregator release provides a summary for how to configure metron_agent using the loggregator release.

The following example manifests show how to configure metron_agent for different versions of Pivotal Cloud Foundry (PCF):

Metrics command

The default metrics_command is /var/vcap/jobs/service-metrics-adapter/bin/collect-service-metrics.

We recommend creating a service-metrics-adapter job in your service release that templates this script. The collect-service-metrics script can encapsulate any commands and arguments required to capture metrics, instead of using the metrics_command and metrics_command_args properties in the manifest.

If the metrics_command fails, for example if the [MY-SERVICE]-metrics binary exits with a non-zero exit code, the service-metrics job will not start, or will exit with 0 if it was already running. In this case, the BOSH instance shows as failing and monit will try to restart the service-metrics job.

Logging

Service metrics logs to files in /var/vcap/sys/log/service-metrics, and also to syslog.

For forwarding syslog to a third party syslog drain (e.g. Papertrail) we recommend co-locating the syslog-release.

Internal checksums

If you are publishing a tile to be consumed by Ops Manager 1.8.x or 1.9.x, you will need to build your tile using releases with SHA1 internal checksums. Service Metrics releases are published using SHA2 internal checksums. You can convert these releases to use SHA1 internal checksums using the BOSH CLI command sha1ify-release.

Create a pull request or raise an issue on the source for this page in GitHub