Rob Thijssen
6e931842dd
Adds a deploy-metrics job shipping a Prometheus scrape drop-in and a provisioned Grafana dashboard to the fleet metrics host, plus the exposure work the exporters needed to be reachable at all. The node's exporter was loopback-only, so --prometheus-external. The miner's already bound 0.0.0.0 unconditionally (crates/metrics builds the listener from [0,0,0,0], no bind option) -- I had recorded it as loopback in the port registry, which was wrong and is corrected. Both exporters are unauthenticated, so each gets a firewalld service opened by a rich rule scoped to the scrape host; that rule, not the bind, is the access boundary. Dashboard panels are built on metric names read off the running node and the miner's source, not guessed. It leads with the states that look healthy but are not: peers at zero, hash rate at zero while the unit is active, GPU devices at zero, jobs never arriving. Two shared-infra changes are in infra-setup.sh rather than the workflow, since other projects depend on both files: prometheus.yml gains scrape_config_files so projects stop sharing one file, and grafana.container gains a dashboards mount it did not have.
9 lines
361 B
XML
9 lines
361 B
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<service>
|
|
<short>quantus-node-metrics</short>
|
|
<description>Quantus node Prometheus exporter. Unauthenticated, like every
|
|
exporter on this fleet, so it is opened by a firewalld rich rule scoped to the
|
|
scrape host rather than added to the zone outright.</description>
|
|
<port protocol="tcp" port="9615"/>
|
|
</service>
|