3.9 KiB
- title
-
Monitoring
Monitoring
Statsd reporting
Zuul comes with support for the statsd protocol, when enabled and configured (see below), the Zuul scheduler will emit raw metrics to a statsd receiver which let you in turn generate nice graphics.
Configuration
Statsd support uses the statsd
python module. Note that
support is optional and Zuul will start without the statsd python module
present.
Configuration is in the statsd
section of zuul.conf
.
Metrics
These metrics are emitted by the Zuul scheduler
:
zuul.event.<driver>.event.<type>
Zuul will report counters for each type of event it receives from each of its configured drivers.
zuul.<tenant>.pipeline
Holds metrics specific to jobs. This hierarchy includes:
<pipeline name>
A set of metrics for each pipeline named as defined in the Zuul config.
all_jobs
Number of jobs triggered by the pipeline.
current_changes
The number of items currently being processed by this pipeline.
project
This hierarchy holds more specific metrics for each project participating in the pipeline.
<canonical_hostname>
The canonical hostname for the triggering project. Embedded
.
characters will be translated to _
.
<project>
The name of the triggering project. Embedded /
or
.
characters will be translated to _
.
<branch>
The name of the triggering branch. Embedded /
or
.
characters will be translated to _
.
job
Subtree detailing per-project job statistics:
<jobname>
The triggered job name.
<result>
A counter for each type of result (e.g., SUCCESS
or
FAILURE
, ERROR
, etc.) for the job. If the
result is SUCCESS
or FAILURE
, Zuul will
additionally report the duration of the build as a timer.
current_changes
The number of items of this project currently being processed by this pipeline.
resident_time
A timer metric reporting how long each item for this project has been in the pipeline.
total_changes
The number of changes for this project processed by the pipeline since Zuul started.
resident_time
A timer metric reporting how long each item has been in the pipeline.
total_changes
The number of changes processed by the pipeline since Zuul started.
wait_time
How long each item spent in the pipeline before its first job started.
As an example, given a job named myjob in mytenant triggered by a change to myproject on the master branch in the gate pipeline which took 40 seconds to build, the Zuul scheduler will emit the following statsd events:
zuul.tenant.mytenant.pipeline.gate.project.example_com.myproject.master.job.myjob.SUCCESS
+1zuul.tenant.mytenant.pipeline.gate.project.example_com.myproject.master.job.myjob.SUCCESS
40 secondszuul.tenant.mytenant.pipeline.gate.all_jobs
+1