NAME
Metrics::Any::Collector
- module-side of the monitoring metrics reporting API
SYNOPSIS
use Metrics::Any '$metrics',
strict => 0,
name_prefix => [ 'my_module_name' ];
sub do_thing {
$metrics->inc_counter( 'things_done' );
}
DESCRIPTION
Instances of this class provide an API for individual modules to declare metadata about metrics they will report, and to report individual values or observations on those metrics. An instance should be obtained for a reporting module by the use Metrics::Any
statement.
The collector acts primarily as a proxy for the application's configured Metrics::Any::Adapter instance. The proxy will lazily create an adapter when required to first actually report a metric value, but until then any metadata stored by any of the make_*
methods will not create one. This lazy deferral allows a certain amount of flexibility with module load order and application startup. By carefully writing module code to not report any values of metrics until the main activity has actually begin, it should be possible to allow programs to configure the metric reporting in a flexible manner during program startup.
Batch-Mode Reporting
Some adapters may support an optional API for implementing metrics in a more high-performance manner, suitable for use in low-level (perhaps even XS) code that might be invoked at high speed or many times over.
Such code often needs to keep simple counters of particular events that happen a lot. Rather than incurring the cost of a full stack of method calls into the collector and adapter implementation on every event, the instrumented code can register a callback function that the adapter will call on some schedule, that will report the actual metrics. In the meantime, the instrumented code can maintain its own counters of events, using plain Perl scalars (or native integers in XS code), to be reported in bulk when required. This reduces the overall CPU cost involved in collecting metrics.
This is most effective with pull-based adapters such as Test or Prometheus, where the callback might only need to be invoked at the end of a test run, or when the prometheus server polls the /metrics
HTTP endpoint.
my $evcounter = 0;
$metrics->add_batch_mode_callback( sub {
$metrics->inc_counter_by( events => $evcounter );
$evcounter = 0;
} );
sub do_thing {
$evcounter++;
...
}
Because not every adapter may implement this mode, instrumented code should be prepared to fall back on the regular API to report its counters.
my $evcounter = 0;
my $use_batch = $metrics->add_batch_mode_callback( sub {
$metrics->inc_counter_by( events => $evcounter );
$evcounter = 0;
} );
sub do_thing {
$use_batch ? $evcounter++ : $metrics->inc_counter( events => );
...
}
Each adapter implementation should document if and how it handles batch mode.
ENVIRONMENT
METRICS_ANY_DISABLE
Since version 0.07.
Provides a list of packages and namespaces in which to disable Metrics::Any reporting entirely.
This variable gives a comma-separated list of name patterns. Patterns may end with ::*
, where they will match any package whose name starts with that prefix, or they may be literal package names. If any code in matching packages attempts to use Metrics::Any::Collector to report metrics, that code will be given a Null
adapter, and no metrics will be reported from here.
For example, to disable the metrics that Net::Async::HTTP::Server
itself creates when exporting Prometheus metrics:
$ METRICS_ANY_DISABLE=Net::Async::HTTP::Server ./program.pl
ARGUMENTS
name_prefix
Since version 0.05.
Optional prefix to prepend to any name provided to the make_*
functions.
If set, this value and the registered names must be given as array references, not simple strings.
use Metrics::Any '$metrics', name_prefix => [qw( my_program_name )];
$metrics->make_counter( events =>
name => [ "events" ],
);
# Will create a counter named ["my_program_name", "events"] formed by the
# adapter.
strict
Since version 0.05.
Optional boolean which controls whether metrics must be registered by a make_
method before they can be used (when true), or whether to attempt lazily registering them when first encountered by a reporting method (when false).
When strict mode is off and a reporting method (e.g. inc_counter
) is invoked on an unrecognised handle, it will be lazily registered. If the metric is reported with values, an attempt is made to determine what the list of label names is; which will depend on the form the label values are given in. Labels passed by array reference, or by hash reference for a single label will work fine. If a hash reference is passed with multiple keys, a warning is printed that the order may not be reliable. Finally, for (discouraged) flat lists of values directly it is not possible to recover label name information so an exception is thrown.
For this reason, when operating with strict mode off, it is recommended always to use the array reference form of supplying labels, to ensure they are registered correctly.
In the current version this parameter defaults true, and thus all metrics must be registered in advance. This may be changed in a future version for convenience in smaller modules, so paranoid authors should set it explicitly:
use Metrics::Any::Adapter '$metrics', strict => 1;
If strict mode is switched off, it is recommended to set a name prefix to ensure that lazily-registered metrics will at least have a useful name.
BOOLEAN OVERRIDE
Instances of this class override boolean truth testing. They are usually true, except in the case that an adapter has already been created and it is the Null type. This allows modules to efficiently test whether to report metrics at all by using code such as
if( $metrics ) {
$metrics->inc_counter( name => some_expensive_function() );
}
While the Null adapter will simply ignore any of the methods invoked on it, without this conditional test the caller would otherwise still have to calculate the value that won't be used. This structure allows the calculation to be avoided if metrics are not in use.
METHODS
package
$package = $metrics->package
Returns the package name that created the collector; the package in which the
use Metrics::Any '$metrics';
statement was invoked.
add_batch_mode_callback
$ok = $metrics->add_batch_mode_callback( sub { ... } )
Since version 0.09.
If batch mode is supported on the underlying adapter, adds another callback to its list of callbacks, to be invoked when it wishes to collect more metrics; if this is supported then the method returns a true value.
If batch mode is not supported, returns false.
METRIC TYPES
Each type of metric is created by one of the make_*
methods. They all take the following common arguments:
- name => ARRAY[ STRING ] | STRING
-
Optional. An array of string parts, or a plain string name to use for reporting this metric to its upstream service.
Modules should preferrably use an array of string parts to specify their metric names, as different adapter types may have different ways to represent this hierarchially. Base-level parts of the name should come first, followed by more specific parts. It is common for related metrics to be grouped by name having identical prefixes but differing only in the final part.
The name is optional; if unspecified then the handle will be used to form the name, combined with a
name_prefix
argument if one was set for the package. - description => STRING
-
Optional human-readable description. May be used for debugging or other purposes.
- labels => ARRAY[ STRING ]
-
Optional reference to an array of string names to use as label names.
A labelled metric will expect to receive additional information in its reporting method to give values for these labels. This information should be in either an even-length array reference of name/value pairs, or a hash reference. E.g.
$metrics->inc_counter( handle => [ labelname => $labelvalue ] ); $metrics->inc_counter( handle => { labelname => $labelvalue } );
A legacy form where a plain list of values is passed, each corresponding to a named label in the same order, is currently accepted but discouraged in favour of the above forms.
$metrics->inc_counter( handle => $labelvalue );
Note that not all metric reporting adapters may be able to represent all of the labels. Each should document what its behaviour will be.
Counter
The "make_counter" method creates a new metric which counts occurances of some event within the application. Its value begins at zero, and can be incremented by "inc_counter" whenever the event occurs.
Some counters may simple count occurances of events, while others may count in other units, for example counts of bytes. Adapters may make use of the units
parameter of the distribution to perform some kind of adapter-specific behaviour. The following units are suggested:
bytes
Observations give sizes in bytes (perhaps memory buffer or network message sizes), and should be integers.
make_counter
$collector->make_counter( $handle, %args )
Requests the creation of a new counter metric. The $handle
name should be unique within the collector instance, though does not need to be unique across the entire program, as it will be namespaced by the collector instance.
The following extra arguments may be passed:
- units => STRING
-
A hint to the adapter about what kind of measurements are being observed, so it might take specific behaviour.
inc_counter
$collector->inc_counter( $handle, $labels )
Reports that the counter metric value be incremented by one. The $handle
name must match one earlier created by "make_counter".
inc_counter_by
$collector->inc_counter_by( $handle, $amount, $labels )
Reports that a counter metric value be incremented by some specified value.
Distribution
The "make_distribution" method creates a new metric which counts individual observations of some numerical quantity (which may or may not be integral). New observations can be added by the "report_distribution" method.
Some adapter types may only store an aggregated total; others may store some sort of statistical breakdown, either total + count, or a bucketed histogram. The specific adapter documentation should explain how it handles distributions.
Adapters may make use of the units
parameter of the distribution to perform some kind of adapter-specific behaviour. The following units are suggested:
bytes
Observations give sizes in bytes (perhaps memory buffer or network message sizes), and should be integers.
seconds
Observations give durations in seconds.
make_distribution
$collector->make_distribution( $handle, %args )
Requests the creation of a new distribution metric.
The following extra arguments may be passed:
- units => STRING
-
A hint to the adapter about what kind of measurements are being observed, so it might take specific behaviour. If unspecified, a default of
bytes
will apply.
report_distribution
$collector->report_distribution( $handle, $amount, $labels )
Since version 0.05.
Reports a new observation for the distribution metric. The $handle
name must match one earlier created by "make_distribution". The $amount
may be interpreted by the adapter depending on the defined units
type for the distribution.
This method used to be called inc_distribution_by
and is currently still available as an alias.
Gauge
The "make_gauge" method creates a new metric which reports on the instantaneous value of some measurable quantity. Unlike the other metric types this does not have to only increment forwards when certain events occur, but can measure a quantity that may both increase and decrease over time; such as the number some kind of object in memory, or the size of some data structure.
As an alternative to incrementing or decrementing the value when particular events occur, the absolute value of the gauge can also be set directly.
make_gauge
$collector->make_gauge( $handle, %args )
Requests the creation of a new gauge metric.
inc_gauge
$collector->inc_gauge( $handle, $labels )
dec_gauge
$collector->dec_gauge( $handle, $labels )
inc_gauge_by
$collector->inc_gauge_by( $handle, $amount, $labels )
dec_gauge_by
$collector->dec_gauge_by( $handle, $amount, $labels )
Reports that the observed value of the gauge has increased or decreased by the given amount (or 1).
set_gauge_to
$collector->set_gauge_to( $handle, $amount, $labels )
Reports that the observed value of the gauge is now the given amount.
The $handle
name must match one earlier created by "make_gauge".
Timer
The "make_timer" method creates a new metric which measures durations of time consumed by the application. New observations of durations can be added by the "report_timer" method.
Timer metrics may be handled by the adapter similarly to distribution metrics. Moreover, adapters may choose to implement timers as distributions with units of seconds
.
make_timer
$collector->make_timer( $handle, %args )
Requests the creation of a new timer metric.
report_timer
$collector->report_timer( $handle, $duration, $labels )
Since version 0.05.
Reports a new duration for the timer metric. The $handle
name must match one earlier created by "make_timer". The $duration
gives a time measured in seconds, and may be fractional.
This method used to called inc_timer_by
and is currently still available as an alias.
AUTHOR
Paul Evans <leonerd@leonerd.org.uk>