Register metric Histogram names.

Register metric Histogram names.

Currently, if anything at all goes wrong on the long and twisty path to computing
metrics, then the value is simply missing. In order to figure out why it's missing,
we need to dig manually into unstructured logs.

Previously, telemetry could sometimes produce FailureValues, but FailureValues are
specified at the wrong granularity, and don't actually solve the problem, and aren't
produced at every level of the long and twisty path.

If metrics register the names of the values that they produce, then, in the case of
failure, each step of the long and twisty path can still produce all of the values
that should have been produced.

Failure Histograms are the new FailureValues. The secret is that Failure Histograms
are just Histograms with a FailureInfo diagnostic. Everything that applies to
Histograms in the successful case also applies to Failure Histograms, i.e.
TelemetryInfo, BuildbotInfo, DeviceInfo, etc.

Since Failure Histograms have the same names as successful Histograms, they can be
surfaced on the dashboard in the timeseries charts. This is a huge improvement over
the status quo, in which charts often have huge unhelpful gaping holes.

FailureInfo Diagnostics can also be displayed beautifully on sheriff-o-matic and
aggregated to compute long-term big data statistics about failure modes.

BUG=catapult:#3076

[benjhayden, 2017-01-23 22:49:32]

Patchset #1 (id:1) has been deleted

[benjhayden, 2017-01-23 22:53:29]

Patchset #1 (id:20001) has been deleted

[benjhayden, 2017-01-23 23:03:34]

Patchset #1 (id:40001) has been deleted

[benjhayden, 2017-01-23 23:19:24]

Description was changed from

==========
Register metric Histogram names.

BUG=catapult:#3076
==========

to

==========
Register metric Histogram names.

Currently, if anything at all goes wrong on the long and twisty path to
computing
metrics, then the value is simply missing. In order to figure out why it's
missing,
we need to dig manually into unstructured logs.

Previously, telemetry could sometimes produce FailureValues, but FailureValues
are
specified at the wrong granularity, and don't actually solve the problem, and
aren't
produced at every level of the long and twisty path.

If metrics register the names of the values that they produce, then, in the
event of
failure, each step of the long and twisty path can still produce all of the
values
that should have been produced.

Failure Histograms are the new FailureValues. The secret is that Failure
Histograms
are just Histograms, with a FailureInfo diagnostic. Everything that applies to
Histograms in the successful case also applies to Failure Histograms, i.e.
TelemetryInfo, BuildbotInfo, DeviceInfo, etc.

Since Failure Histograms have the same names as successful Histograms, they can
be
surfaced on the dashboard in the timeseries charts. This is a huge improvement
over
the status quo, in which charts often have huge unhelpful gaping holes.

FailureInfo Diagnostics can also be displayed beautifully on sheriff-o-matic and
aggregated to compute long-term big data statistics about failure modes.

BUG=catapult:#3076
==========

[benjhayden, 2017-01-24 05:20:07]

Description was changed from

==========
Register metric Histogram names.

Currently, if anything at all goes wrong on the long and twisty path to
computing
metrics, then the value is simply missing. In order to figure out why it's
missing,
we need to dig manually into unstructured logs.

Previously, telemetry could sometimes produce FailureValues, but FailureValues
are
specified at the wrong granularity, and don't actually solve the problem, and
aren't
produced at every level of the long and twisty path.

If metrics register the names of the values that they produce, then, in the
event of
failure, each step of the long and twisty path can still produce all of the
values
that should have been produced.

Failure Histograms are the new FailureValues. The secret is that Failure
Histograms
are just Histograms, with a FailureInfo diagnostic. Everything that applies to
Histograms in the successful case also applies to Failure Histograms, i.e.
TelemetryInfo, BuildbotInfo, DeviceInfo, etc.

Since Failure Histograms have the same names as successful Histograms, they can
be
surfaced on the dashboard in the timeseries charts. This is a huge improvement
over
the status quo, in which charts often have huge unhelpful gaping holes.

FailureInfo Diagnostics can also be displayed beautifully on sheriff-o-matic and
aggregated to compute long-term big data statistics about failure modes.

BUG=catapult:#3076
==========

to

==========
Register metric Histogram names.

Currently, if anything at all goes wrong on the long and twisty path to
computing
metrics, then the value is simply missing. In order to figure out why it's
missing,
we need to dig manually into unstructured logs.

Previously, telemetry could sometimes produce FailureValues, but FailureValues
are
specified at the wrong granularity, and don't actually solve the problem, and
aren't
produced at every level of the long and twisty path.

If metrics register the names of the values that they produce, then, in the case
of
failure, each step of the long and twisty path can still produce all of the
values
that should have been produced.

Failure Histograms are the new FailureValues. The secret is that Failure
Histograms
are just Histograms with a FailureInfo diagnostic. Everything that applies to
Histograms in the successful case also applies to Failure Histograms, i.e.
TelemetryInfo, BuildbotInfo, DeviceInfo, etc.

Since Failure Histograms have the same names as successful Histograms, they can
be
surfaced on the dashboard in the timeseries charts. This is a huge improvement
over
the status quo, in which charts often have huge unhelpful gaping holes.

FailureInfo Diagnostics can also be displayed beautifully on sheriff-o-matic and
aggregated to compute long-term big data statistics about failure modes.

BUG=catapult:#3076
==========