The `burp::error::Error` struct needs to implement the
`std::error::Error` trait (which requires that it also implement
`std::fmt::Display`) so that it can be used in dynamic dispatch
situations. Notably, the `prometheus_exporter_base::render_prometheus`
function requires a closure that returns `Result<String, Box<dyn
std::error::Error>>`, so in order to use the `?` (early return)
operator on on the `metrics::get_metrics` function call, our error must
implement that trait.
The `metrics` module encapsulates the functionality for generating
Prometheus metrics from BURP stats. Given a `BurpClient` instance, the
`get_metrics` function calls the necessary RPC methods to fetch the
latest backup statistics for each known BURP client. It then generates
metrics in Prometheus plain text exposition format, using the excellent
[prometheus_exporter_base] crate. The result is returned as a string,
which can then be used to produce an HTTP response to a Prometheus
scrape request. The *prometheus_exporter_base* crate also provides a
simple HTTP server, based on [Hyper], which we will eventually use to
serve this response.
[prometheus_exporter_base]: https://github.com/MindFlavor/prometheus_exporter_base/
[Hyper]: https://hyper.rs/
The `get_clients`, `get_client`, `get_backup`, `get_backup_log`, and
`get_backup_stats` methods fetch information from the BURP server using
its JSON stats interface. These will be used to populate the metrics we
want to export to Prometheus.
The `burp` module contains an implementation of a BURP stats client. It
uses *tokio* for asynchronous network communication with the BURP stats
TCP socket. The `ClientConnector` struct follows the builder pattern
for specifying connection options, ultimately producing a `Client`
struct that manages communication over the socket.
BURP uses mutual TLS authentication for all its communication. The
client authenticates the server by verifying its certificate using a
trusted CA certificate. This certificate is not usually trusted
system-wide, but specifically by BURP clients. The server also
authenticates the client using a certificate. The official BURP client
uses a normal PEM-encoded X.509 certificate and PKCS #8 key, however,
the *native-tls* library does not support loading these. As such, the
certificate and private key must be encapsulated in a PKCS #12
container.
Dustin