Finally, a working application! The heavy lifting is handled by
*prometheus_exporter_base*, which sets up the Hyper server and registers
the *GET /metrics* path operation handler. Really, all we have to
provide is the logic to connect to the BURP stats socket given the
options specified in the configuration file. The `metrics::get_metrics`
function handles the generation of the metrics, which we return as a
string to be served to the HTTP client.
Naturally, we need a configuration mechanism in order to specify
connection parameters for the BURP stats socket. Using the
`serde::Deserialize` trait will make this relatively straightforward and
allows us to choose from a wide variety of data formats as our
configuration language. We will probably use TOML since it is pretty
simple to read and write for both humans and machines, and our data
model is very simple.
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