Skip to main content

This Prometheus exporter collects metrics from dCache and provides them via a HTTP server, writes them to standard output or writes them atomically to a file.

Building And Installation

Dependencies

Getting The Source Code

Clone the prometheus-dcache-exporter git repository via either of:

$ git clone ssh://git@gitlab.com/calestyo/prometheus-dcache-exporter.git
$ git clone https://gitlab.com/calestyo/prometheus-dcache-exporter.git

Building A Debian Package

The Debian packaging is maintained in the debian-branch of the prometheus-dcache-exporter git repository.

Preparations:

$ cd prometheus-dcache-exporter
$ git switch -c temporary-build-branch master
$ temporary_version="$(python3 -m setuptools_scm --format plain)"
$ [ -z "$( git tag --list "v${temporary_version}" )" ]  &&  git tag "v${temporary_version}"
$ git merge --allow-unrelated-histories -m "Merge branch 'debian' into temporary-build-branch" debian
$ debian_changelog_version="$(dpkg-parsechangelog --show-field Version)"
$ [ "${temporary_version}"   !=   "$( printf '%s\n' "${debian_changelog_version}"  |  sed -E 's/^[0-9]+://; s/-[^-]+$//;' )" ]    &&    debchange --release-heuristic log --newversion "$( printf '%s\n' "${debian_changelog_version}"  |  sed -E -n 's/^([0-9]+:).*/\1/p' )${temporary_version}-1" 'Local version.'
$ git deborig

Any changes since the tip of the master-branch must be committed right after switching to the temporary-build-branch-branch.

Build via either of:

$ dpkg-buildpackage
$ debuild

optionally adding the --no-sign-option if signing is not desired.

Beware that the above creates files in the parent directory.

git-deborig is part of the git-debpush-package, dpkg-buildpackage and dpkg-parsechangelog are part of the dpkg-dev-package and debuild is part of the devscripts-package.

Installation From The Python Package Index (PyPI)

$ pip install prometheus-dcache-exporter

Usage

There are two main operation modes:

  • Executing prometheus-dcache-exporter in the http-export-mode via a systemd service, et cetera, with the former providing the metrics via an internal HTTP server.
    The metrics are (freshly) collected on every scrape. The scraping is to be done directly (by Prometheus).
  • Executing prometheus-dcache-exporter in the file-export-mode or in the stdout-export-mode together with a program like sponge (in both cases) via a systemd timer, cron job, et cetera, which writes the metrics atomically (via moving a newly created temporary file) to a .prom-file for Prometheus node exporter’s textfile collector.
    The metrics are (periodically) collected (once) on every execution. The scraping is to be done indirectly via the Prometheus node exporter (by Prometheus).

Invoke prometheus-dcache-exporter with the --help- or -h-option for information about the command arguments.

It’s not necessary that dCache respectively the REST interface of its frontend-service and/or the SSH interface of its admin-service are executed on the same host as that on which prometheus-dcache-exporter is executed.
For security reasons and to allow for alleviation of frontend’s rate limiting without affecting other users, it’s suggested to run dedicated instances of (at least) frontend and (possibly also) admin that are only accessible by trusted users (see the example below, which assumes however that all users on the host are trusted).
While sensible defaults have been chosen for all options, in particular the connection and authentication options for the REST and SSH interfaces may need to be adapted.
Amongst others, these are part of the --dcache-frontend-rest.*- respectively the --dcache-admin-ssh.*-family of options.

For example, assuming frontend and admin being executed with their default configurations except for:

frontend.net.listen=localhost
frontend.authn.protocol=http
frontend.authz.readonly=true
frontend.authz.anonymous-operations=READONLY
frontend.authz.unlimited-operation-visibility=true
frontend.limits.rate.overall=10000
frontend.limits.rate.per-client.fractions=100
admin.net.listen=localhost

and login to the SSH interface being authorised for the user admin with the SSH private key at ~/.ssh/id_rsa, prometheus-dcache-exporter might be invoked like:

$ prometheus-dcache-exporter --dcache-frontend-rest.base-url http://localhost:3880/api/ --dcache-admin-ssh.user admin --dcache-admin-ssh.private-key ~/.ssh/id_rsa

Metrics

Collection

prometheus-dcache-exporter uses the REST interface of dCache’s frontend-service and the SSH interface of dCache’s admin-service for collecting the metrics. The latter is only used for raw data that isn’t available via the former, yet.

Connections to the REST and SSH interfaces are tried to be kept open and re-used, as configured via the --dcache-frontend-rest.connection-pool-*-family of options respectively the --dcache-admin-ssh.keepalive-interval-option.

Per default, the requests to the REST interface respectively the command executions via the SSH interface are performed concurrently (using multithreading), as configured via the --dcache-frontend-rest.max-concurrent-requests- and --dcache-admin-ssh.max-concurrent-commands-options. This is done, amongst other reasons, so that the raw data is as closely synchronised as possible.

Errors

The metrics of the <metrics-name-prefix>__errors_*-family indicate errors during metric collection, with the <metrics-name-prefix>__errors_occurred-metric being a boolean that indicates whether any (metric collection) errors occurred or not.

Warnings

The metrics of the <metrics-name-prefix>__warnings_*-family indicate warnings during metric collection, with the <metrics-name-prefix>__warnings_occurred-metric being a boolean that indicates whether any (metric collection) warnings occurred or not.

dCache’s Caching Of Raw Data And Reasonable Scrape Intervals

As mentioned previously, the metrics are (freshly) collected on every execution respectively scrape.

However, dCache caches some of the raw data, which may therefore actually be stale when being collected and/or may have already been exported/scraped previously, but would nevertheless be considered fresh and new.

In particular, the frontend-service caches the raw data of resources of the REST interface, thereby affecting the metric collection as follows:
(All metric names (including in regular expressions) are given without the metrics prefix specified via the --metrics.name-prefix-option and without any _-separator after that. All labels are given with their built-in (not renamed) names.)
  • /cells
    Configurable via the frontend-service’s:
    • frontend.service.cell-info.timeout- and frontend.service.cell-info.timeout.unit-options

    • cells set timeout-command

    Affected metrics:
    • cell_info

    Indirectly affected:
    • Due to being used for discovering pools, everything that is affected by the caching of the raw data of the /pools/{pool_name}/usage-resource.

    • Due to being used for discovering poolmanagers, the metrics of the poolmanager_*-family.

    • If the /domains-resource is not supported by the frontend-service, due to being used for discovering domains (by the fallback for determining the domain / host mappings via the SSH interface of the admin-service), everything that would be affected by the caching of the domain name and host parts of the raw data of the /domains-resource.

  • /domains, if supported by the frontend-service
    Configurable via the frontend-service’s:
    • frontend.service.domain-info.timeout- and frontend.service.domain-info.timeout.unit-options

    • domains set timeout-command

    Affected metrics:
    • domain_info

    Affected extra labels (of metrics whose name matches the Python re regular expressions given in parentheses):
    • host (^cell_.*$, ^pool_.*$ and ^poolmanager_.*$)

    • pool_host (^poolmanager_pool_.*$)

  • /pools/{pool_name}/usage
    Configurable via the frontend-service’s:
    • frontend.service.pool-info.timeout- and frontend.service.pool-info.timeout.unit-options

    • pools set timeout-command

    Affected metrics:
    • pool_files

    • pool_mode_state

    • pool_mover_queue_max_movers_by_state

    • pool_mover_queue_movers_by_operation

    • pool_mover_queue_movers_by_state

    • pool_space_gap_bytes

    • pool_space_total_bytes

    • pool_space_used_bytes

    Affected extra labels (of metrics whose name matches the Python re regular expressions given in parentheses):
    • cell_name (^pool_.*$)

    • domain_name (^pool_.*$)

    • pool_cell_name (^poolmanager_pool_.*$)

    • pool_domain_name (^poolmanager_pool_.*$)

    • pool_host (^poolmanager_pool_.*$)

The frontend-service does not cache the raw data of the following resources:

  • /space/linkgroups

  • /space/tokens

This should be considered when choosing Prometheus’ scrape interval, which should usually be slightly larger than the largest caching time.

Extra Labels

In general, labels describe the entity to which a time series of a metric corresponds. For example, in:

# HELP dcache_space_reservation_space_total_bytes The total space of a space reservation in bytes.
# TYPE dcache_space_reservation_space_total_bytes gauge
dcache_space_reservation_space_total_bytes{space_reservation_id="110000"} 4748869032235006
dcache_space_reservation_space_total_bytes{space_reservation_id="380987"} 292706065309706

the label space_reservation_id uniquely identifies the entity (here, a space reservation), thereby effectively being a “primary key”.

There may also be labels that are not necessary for unique identification, which is particularly (but not only) the case for “info metrics” (whose names typically end in _info). For example, in:

# HELP dcache_space_reservation_info Information about a space reservation.
# TYPE dcache_space_reservation_info gauge
dcache_space_reservation_info{description="ATLASDATADISK",space_reservation_id="110000"} 1.0
dcache_space_reservation_info{description="ATLASLOCALGROUPDISK",space_reservation_id="380987"} 1.0

only the label space_reservation_id identifies the corresponding space reservation uniquely, while the label description – albeit often uniquely used by dCache operators – is strictly speaking not ensured to be unique and is not necessary for identifying the corresponding space reservation.

Per default and except for info metrics, prometheus-dcache-exporter generally includes only the minimal set of labels that are necessary to uniquely identify the corresponding entity.

Sometimes it may however be convenient to have additional labels included. For example, so that the above metric looks like:

# HELP dcache_space_reservation_space_total_bytes The total space of a space reservation in bytes.
# TYPE dcache_space_reservation_space_total_bytes gauge
dcache_space_reservation_space_total_bytes{description="ATLASDATADISK",space_reservation_id="110000"} 4748869032235006
dcache_space_reservation_space_total_bytes{description="ATLASLOCALGROUPDISK",space_reservation_id="380987"} 292706065309706

This can be achieved – for certain metrics and labels where this seemed reasonable – using the --metrics.extra-label-option.

In Prometheus, the addition/removal of a label (as well as the change of its value) results in a new/different time series.
It’s therefore suggested to choose which extra labels to include, if any, already before starting to use prometheus-dcache-exporter and to avoid changing this later.

Label Renaming

The --metrics.rename-label-option allows to rename most labels, which may make sense in some special use cases.

Consider, for example, the metrics of the <metrics-name-prefix>_poolmanager_pool_*-family, which describe a given poolmanager and how that “sees” a given pool.
Every poolmanager is uniquely identified by its cell- and domain-name (for which usually the label names cell_name and domain_name are used) and every pool is uniquely identified by its pool name. It might however make sense to also include every pool’s cell- and domain-name as extra labels.
Regardless of which combination of cell_name/domain_name, poolmanager_cell_name/poolmanager_domain_name and pool_cell_name/pool_domain_name is used, there’s always some ambiguity and/or cumbersome joining with other metrics in PromQL queries.
There’s no general solution to this and while the generic label names (like cell_name/domain_name) are used for the “primary” object of metrics (here, the poolmanager) per default, label renaming may be performed to adapt this, if necessary.
In Prometheus, the addition/removal (which includes renaming) of a label (as well as the change of its value) results in a new/different time series.
It’s therefore suggested to choose which labels to rename, if any, already before starting to use prometheus-dcache-exporter and to avoid changing this later.

It shall further be noted, that renaming labels may impact compatibility with anything (like dashboards) that assumes the built-in names.

Issues

Concurrent Requests To The REST Interface Respectively Command Executions Via The SSH Interface And Connection Re-Use

Currently, quite a number of concurrent requests respectively command executions are made, including one request per dCache pool and one command execution per dCache domain (the latter no longer with frontend-service versions ≧ 12.0.0 as well as with versions ≧ 11.2.6 of the 11.2 release branch).

These particular two cases can easily cause high numbers of concurrent requests respectively command executions and while they should eventually be reduced to only two requests (see dCache issues #8126 and #8127), this may cause various failures, which are unfortunately not yet understood (in particular, whether they’re caused by prometheus-dcache-exporter itself, the libraries it uses or dCache respectively the libraries it uses in the frontend- and/or admin-services).

Because of the concurrency, such failures usually cause log message flooding. Further, because threads cannot really be forcibly terminated in Python, the already running (but all failing) threads continue their execution despite exiting signals like SIGINT or SIGTERM.

Tests seemed to have indicated that it even makes a difference when the connections to the REST and/or SSH interfaces are tunnelled via OpenSSH’s port forwarding (using ssh’s -L-option).

Troubleshooting

REST Interface: HTTP Status Code 429 (Too Many Requests)

In case of log messages like:

ERROR: prometheus_dcache_exporter._dcache.frontend: 1: Failed to request the resource `/pools/<pool-name>/usage` from the REST interface of the dCache `frontend` service: Client error '429 Too Many Requests' for url 'http://localhost:3880/api/v1/pools/<pool-name>/usage'
ERROR: prometheus_dcache_exporter._dcache.frontend: 2: For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429

prometheus-dcache-exporter likely exceeded the thresholds of the frontend-service’s rate limiting.

This can be configured via the frontend.limits.rate.overall- and frontend.limits.rate.per-client.fractions-options of the frontend-service (see the example in the chapter “Usage” above).

See also Concurrent Requests To The REST Interface Respectively Command Executions Via The SSH Interface And Connection Re-Use above.

SSH Interface: Timeout opening channel., SSHException And Other Paramiko Errors

In case of log messages like:

ERROR: prometheus_dcache_exporter._dcache.admin: Failed to execute the command `\s <cell-name>@<domain-name> get hostname` via the SSH interface of the dCache `admin` service (try 2 of 2): Timeout opening channel.

despite the Timeout opening channel., the timeout that usually causes this is that configured via the --dcache-admin-ssh.command-channel-timeout-option. Increasing that or decreasing the concurrency via the --dcache-admin-ssh.max-concurrent-commands-option might help.

Ironically and inexplicably, tests have shown that, instead, it might help best to disable connection re-use of the REST interface of dCache’s frontend-service. Similarly, decreasing the concurrency of that via the --dcache-frontend-rest.max-concurrent-requests-options might help.

See also Concurrent Requests To The REST Interface Respectively Command Executions Via The SSH Interface And Connection Re-Use above.

High Memory Usage / Seeming Memory Leak

If prometheus-dcache-exporter has an unexpected high memory usage, which may even seem to grow and indicate a memory leak, the reason might be bad interplay between Python’s threading and the GNU C Library’s memory allocation/de-allocation. In that case, there’s actually no memory leak and the memory usage should eventually stabilise.

If the high memory usage is a problem, either of the following workarounds might help:

The above environment variables need to be set for the prometheus-dcache-exporter-process.
When executed via a systemd service this can, for example, be done via a drop-in configuration file (see the systemd.unit(5)-manpage) and the Environment=-option.

Prometheus “Ignores” Samples/Metrics

If Prometheus’ scrapes fail while “manual” ones succeed, the exporter’s output might be larger than a limit set via Prometheus’ body_size_limit-option.

References

Licence

Release files for prometheus-dcache-exporter 0.4.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for prometheus-dcache-exporter 0.4.0
File Size Uploaded
prometheus_dcache_exporter-0.4.0.tar.gz 44.2 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for prometheus-dcache-exporter 0.4.0
File Interpreter ABI Platform
prometheus_dcache_exporter-0.4.0-py3-none-any.whl Python 3 none any Details

Total release size: 85.0 kB

Release files / prometheus_dcache_exporter-0.4.0.tar.gz

Download URL prometheus_dcache_exporter-0.4.0.tar.gz
Size 44.2 kB
Tags Source
SHA-256 checksum
How to use checksums
6c95132c85d73983596727112d23940e50eb0331ed93dc8af171aaecf9ae1ef6
BLAKE2b-256 checksum
How to use checksums
c95efe3542306eef0e0359166f3ebf069b60da331546ca3e3b74d340bcaf4050
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/6.2.0 CPython/3.14.6

Release files / prometheus_dcache_exporter-0.4.0-py3-none-any.whl

Download URL prometheus_dcache_exporter-0.4.0-py3-none-any.whl
Size 40.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
314565e4f6a2880cfd5b87efc53dfaa48e385048d969457d3e171c6365f14c38
BLAKE2b-256 checksum
How to use checksums
c643b30f034ceca3f77c35651d43bf852621221e583f125162e0d98959b99a6d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/6.2.0 CPython/3.14.6

Release history Release notifications | RSS feed

This release

0.4.0 This release

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page