4 Commits

Author SHA1 Message Date
Christopher Faulet
83070a08a2 MEDIUM: promex: Add support for filters on metric names
It is now possible to filter the metrics on their name, by listing
explicitly metrics to dump or on the opposite to exclude only some metrics
from the dump. To do so, a comma-separated list of metrics must be
specified. If a name is preceded by a minus (-), the metric is excluded from
the dump. If at least one metric is specified to be explicitly dumped, all
metrics are no longer dumped, but only those explicitly listed.

The list is specified via one or more "metrics" parameters in the uri
query-string. For insance:

  # Dumped all metrics, except "haproxy_server_check_status"
  /metrics?metrics=-haproxy_server_check_status

  # Only dump frontends, backends and servers status
  /metrics?metrics=haproxy_frontend_status,haproxy_backend_status,haproxy_server_status

Included and Excluded metrics can be mixed. Only the intersection will be
dumped.

This patch should fix the issue #770.
2024-02-02 09:11:34 +01:00
Christopher Faulet
3e55b3da30 MEDIUM: promex/stick-table: Dump stick-table metrics via a promex module
Create a promex module to dump stick-table metrics. Thanks to this patch,
all references to stick tables were removed from the promex service.
2024-02-02 09:11:34 +01:00
Christopher Faulet
5f875414eb MEDIUM: promex: Dump metrics of registered modules with a way to filter them
This patch adds a dump loop on the registered modules. It is very similar to
other dump loops. When a module registered, a implicit scope is created with
the module's name. It means a module name must be unique. It also means,
metrics dump of modules can be filtered via the "scope" parameter.
2024-02-02 09:11:34 +01:00
Christopher Faulet
eb2128723a MEDIUM: promex: Add a registration mechanism to support modules
In this patch we add a registration mechanism for modules. To do so, a
module must defined the "promex_module" structure. The dump itself will be
based on 2 contexts. One for all the dump and another one for each metric
time-series. These contexts are used as restart points when the dump is
interrupted.

Modules must also implement 6 callback functions:

  * start_metric_dump(): It is an optional callback function. If defined, it
                         is responsible to initialize the dump context use
                         as the first restart point.

  * stop_metric_dump(): It is an optional callback function. If defined, it
                        is responsible to deinit the dump context.

  * metric_info(): This one is mandatory. It returns the info about the
                   metric: name, type and flags and descrition.

  * start_ts(): This one is mandatory, it initializes the context for a time
                series for a given metric. This context is the second
                restart point.

  * next_ts(): This one is mandatory. It interates on time series for a
               given metrics. It is also responsible to handle end of a
               time series and deinit the context.

  * fill_ts(): It fills info on the time series for a given metric : the
               labels and the value.

In addition, a module must set its name and declare the number of metrics is
exposed.
2024-02-02 09:11:24 +01:00