Deploying a Release with Service Metrics
The service metrics release provides a job called
service_metrics that can be co-located with other bosh jobs to gather metrics from them.
metron_agent job must accompany
service_metrics to emit these metrics to the Cloud Foundry Loggregator.
service_metrics job to an instance group in your bosh manifest.
service_metrics job with the following properties:
||string||the name of the service, so it can reference metrics originating from that service in the logs||yes||n/a|
||string||the command to generate the metrics||no||see Metrics command|
||array of strings||any args provided to
||int||how often the metric generation command runs||no||60|
||boolean||turn verbose mode on/off||no||false|
||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|||
metron_agent job with 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
The following example manifests show how to configure
metron_agent for different versions of Pivotal Cloud Foundry (PCF):
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_args properties in the manifest.
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
monit will try to restart the service-metrics job.
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.