5 Commits (336ba360bd2012cad3461dbff663afb736989d09)

Author	SHA1	Message	Date
Holger Hans Peter Freyther	2b69cb3e1c	res_prometheus: Fix duplicate output of metric and help text ... 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 7b1807413d)	1 year ago
Holger Hans Peter Freyther	0aa95751db	res_prometheus: Do not generate broken metrics ... 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 (cherry picked from commit 9b93fb9f67)	2 years ago
Naveen Albert	63db7505f2	asterisk: Add macro for curl user agent. ... 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	4 years ago
Matt Jordan	0760af71ad	res_prometheus: Add Asterisk channel metrics ... 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	7 years ago
Matt Jordan	c50f29dfad	Add core Prometheus support to Asterisk ... 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	7 years ago