The prometheus exposition format requires each line to be unique[1].
This is handled by struct prometheus_metric having a list of children
that is managed when registering a metric. In case the scrape callback
is used, it is the responsibility of the implementation to handle this
correctly.
Originally the bridge callback didn't handle NULL snapshots, the crash
fix lead to NULL metrics, and fixing that lead to duplicates.
The original code assumed that snapshots are not NULL and then relied on
"if (i > 0)" to establish the parent/children relationship between
metrics of the same class. This is not workerable as the first bridge
might be invisible/lacks a snapshot.
Fix this by keeping a separate array of the first metric by class.
Instead of relying on the index of the bridge, check whether the array
has an entry. Use that array for the output.
Add a test case that verifies that the help text is not duplicated.
Resolves: #642
[1] https://prometheus.io/docs/instrumenting/exposition_formats/#grouping-and-sorting
(cherry picked from commit d45c8e165f)
In 8d6fdf9c3a invisible bridges were
skipped but that lead to producing metrics with no name and no help.
Keep track of the number of metrics configured and then only emit these.
Add a basic testcase that verifies that there is no '(NULL)' in the
output.
ASTERISK-30474
Currently, each module that uses libcurl duplicates the standard
Asterisk curl user agent.
This adds a global macro for the Asterisk user agent used for
curl requests to eliminate this duplication.
ASTERISK-29861 #close
Change-Id: I9fc37935980384b4daf96ae54fa3c9adb962ed2d
This patch adds basic Asterisk channel statistics to the res_prometheus
module. This includes:
* asterisk_calls_sum: A running sum of the total number of
processed calls
* asterisk_calls_count: The current number of calls
* asterisk_channels_count: The current number of channels
* asterisk_channels_state: The state of any particular channel
* asterisk_channels_duration_seconds: How long a channel has existed,
in seconds
In all cases, enough information is provided with each channel metric
to determine a unique instance of Asterisk that provided the data, as
well as the name, type, unique ID, and - if present - linked ID of each
channel.
ASTERISK-28403
Change-Id: I0db306ec94205d4f58d1e7fbabfe04b185869f59
Prometheus is the defacto monitoring tool for containerized applications.
This patch adds native support to Asterisk for serving up Prometheus
compatible metrics, such that a Prometheus server can scrape an Asterisk
instance in the same fashion as it does other HTTP services.
The core module in this patch provides an API that future work can build
on top of. The API manages metrics in one of two ways:
(1) Registered metrics. In this particular case, the API assumes that
the metric (either allocated on the stack or on the heap) will have
its value updated by the module registering it at will, and not
just when Prometheus scrapes Asterisk. When a scrape does occur,
the metrics are locked so that the current value can be retrieved.
(2) Scrape callbacks. In this case, the API allows consumers to be
called via a callback function when a Prometheus initiated scrape
occurs. The consumers of the API are responsible for populating
the response to Prometheus themselves, typically using stack
allocated metrics that are then formatted properly into strings
via this module's convenience functions.
These two mechanisms balance the different ways in which information is
generated within Asterisk: some information is generated in a fashion
that makes it appropriate to update the relevant metrics immediately;
some information is better to defer until a Prometheus server asks for
it.
Note that some care has been taken in how metrics are defined to
minimize the impact on performance. Prometheus's metric definition
and its support for nesting metrics based on labels - which are
effectively key/value pairs - can make storage and managing of metrics
somewhat tricky. While a naive approach, where we allow for any number
of labels and perform a lot of heap allocations to manage the information,
would absolutely have worked, this patch instead opts to try to place
as much information in length limited arrays, stack allocations, and
vectors to minimize the performance impacts of scrapes. The author of
this patch has worked on enough systems that were driven to their knees
by poor monitoring implementations to be a bit cautious.
Additionally, this patch only adds support for gauges and counters.
Additional work to add summaries, histograms, and other Prometheus
metric types may add value in the future. This would be of particular
interest if someone wanted to track SIP response types.
Finally, this patch includes unit tests for the core APIs.
ASTERISK-28403
Change-Id: I891433a272c92fd11c705a2c36d65479a415ec42
