An actual, honest to god, metric. More...

#include <res_prometheus.h>

Collaboration diagram for prometheus_metric:

[legend]

Data Fields
enum prometheus_metric_allocation_strategy	allocation_strategy
	How this metric was allocated. More...

struct {
struct prometheus_metric * first

struct prometheus_metric * last

}	children
	A list of children metrics. More...

struct {
struct prometheus_metric * next

}	entry

void(*	get_metric_value )(struct prometheus_metric *metric)
	Callback function to obtain the metric value. More...

const char *	help
	Pointer to a static string defining this metric's help text. More...

struct prometheus_label	labels [PROMETHEUS_MAX_LABELS]
	The metric's labels. More...

ast_mutex_t	lock
	A lock protecting the metric `value`. More...

char	name [PROMETHEUS_MAX_NAME_LENGTH]
	Our metric name. More...

enum prometheus_metric_type	type
	What type of metric we are. More...

char	value [PROMETHEUS_MAX_VALUE_LENGTH]
	The current value. More...

Detailed Description

An actual, honest to god, metric.

A bit of effort has gone into making this structure as efficient as we possibly can. Given that a lot of metrics can theoretically be dumped out, and that Asterisk attempts to be a "real-time" system, we want this process to be as efficient as possible. Countering that is the ridiculous flexibility that Prometheus allows for (and, to an extent, wants) - namely the notion of families of metrics delineated by their labels.

In order to balance this, metrics have arrays of labels. While this makes for a very large struct (such that loading one of these into memory is probably going to blow your cache), you will at least get the whole thing, since you're going to need those labels to figure out what you're looking like.

A hierarchy of metrics occurs when all metrics have the same name, but different labels.

We manage the hierarchy by allowing a metric to maintain their own list of related metrics. When metrics are registered (/c prometheus_metric_register), the function will automatically determine the hierarchy and place them into the appropriate lists. When you are creating metrics on the fly in a callback (prometheus_callback_register), you have to manage this hierarchy yourself, and only print out the first metric in a chain.

Note that EVERYTHING in a metric is immutable once registered, save for its value. Modifying the hierarchy, labels, name, help, whatever is going to result in a "bad time", and is also expressly against Prometheus law. (Don't get your liver eaten.)

Definition at line 193 of file res_prometheus.h.

Field Documentation

◆ allocation_strategy

enum prometheus_metric_allocation_strategy allocation_strategy

How this metric was allocated.

Definition at line 201 of file res_prometheus.h.

Referenced by prometheus_metric_create(), and prometheus_metric_free().

◆

struct { ... } children

A list of children metrics.

Children metrics have the same name but different label.

Registration of a metric will automatically nest the metrics; otherwise they are treated independently.

The help of the first metric in a chain of related metrics is the only one that will be printed.

For metrics output during a callback, the handler is responsible for managing the children. For metrics that are registered, the registration automatically nests the metrics.

Referenced by AST_TEST_DEFINE(), channels_scrape_cb(), prometheus_metric_free(), prometheus_metric_register(), prometheus_metric_to_string(), and prometheus_metric_unregister().