Prometheus Storj-Exporter

i cleaned the plugin folder already but the same problem.

Hi all, i have the same issue …any any know a solution ?


Is just changed the ip of one of my nodes.
now i have the same node twice in the dashboard.

Is it possible to remove the old ip?

1 Like

It is if you delete the data manually in prometheus. But you just need to wait until the old node goes out of the timeframe of your dashboard then it will vanish by itself.

BTW: If you followed my guide, your nodes should have names and not IPs. Then changing an IP wouldn’t affect your data/dashboard at all.

1 Like

Hi guys I’m not sure if anyone has asked this but is there a way to get retained amount displayed on dashboard as I use L1 payout method I need a few months occasionally for minimum threshold to be reached


For the dashboard you need to wait for an answer from the author @greener.

Meanwhile you can use this script:

It’s already on the dashboard. Click the payout information link. It’s mentioned as undistributed payout.

Not the node dashboard, the grafana dashboard. Afaik nobody integrated that yet into the exporter and dashboard.


Grafana V8.0.6 is out and surprise, it gave the Boom-Tables a new appearance. :shushing_face:



Disk total, use, free and trash seems now to use the same scale, that makes some sense.

But what should be the relationship of Net out and in?

Scratching my head :thinking:

Frustrating indeed… Now I don’t want to update :smiley:

1 Like

I’m still on 7.5.7 for grafana…haven’t found the need to update since I know this version works and don’t really want to spend the time dealing with any issues that come along with new versions.

Is there a way to password protect or otherwise secure the data that the exporter opens up to the web?
I have several nodes running remotely,
and I’d rather not have stuff like node-id, wallet address, etc, publicly accessible.
Minimizing attack vectors and all that.

If your Prometheus server has a static IP address you could restrict the access to the exporter port by a firewall entry on the node host.

Unfortunately that is not an option in my case.
It does give me an idea: reverse dns lookups and iptables scripting,
but that’s getting kinda hackish :upside_down_face:

  • It gives the whole thing a terrible performance.
  • In a worst case scenario your node could be blacklisted by the DNS server. (DDOS attack!)

Wasn’t planning on doing that, to be clear. But more in the lines of something like this:

Current_IP=$(host $HOSTNAME | head -n1 | cut -f4 -d ' ')

if [ ! -f $LOGFILE ]; then
    /usr/sbin/ufw allow from $Current_IP to any port 22 proto tcp
    echo $Current_IP > $LOGFILE

    Old_IP=$(cat $LOGFILE)
    if [ "$Current_IP" = "$Old_IP" ] ; then
        echo IP address has not changed
        /usr/sbin/ufw delete allow from $Old_IP to any port 9651 proto tcp
        /usr/sbin/ufw allow from $Current_IP to any port 9651 proto tcp
        echo $Current_IP > $LOGFILE
        echo iptables have been updated

with crontab
Thank you for the firewall rules inspiration!

don’t expose the port when running it with docker and use an ssh tunnel to get into the server?

Using something like this?:

For the persistent SSH tunnel:

On the Prometheus server you need the typical SSH setup with root disabled, no plaintext passwords, Private/Public Keys for authentication, Fail2Ban installed, if possible changed port.

Fail2Ban with increasing ban times:

Nice idea for a (long?) weekend :smiley:

1 Like

Thats quite a lot of moving parts. (more stuff that can break)
Also don’t like public sshd open on the prom server (defeats vpn)
I care (a bit) less about the nodes :wink:

For now I’ll go with the ufw + crontab script, my train of thoughts:

  1. Only ‘specific ip’ can access 9651
  2. Hostiles have no intel on 9651/ it seems closed (iptables drops the packets)
  3. Hostiles have to know the correct ip + spoof it to gain very little info/attack surface

For me this seems reasonably secure, fast and simple to deploy.

:heart:Fail2ban, forced public key auth(exempt specific ip/subnet), rootlogin disabled. :heart:
Spread the holy word!

I released version 2.1.0 of the exporter recently where some old metrics were deprecated in favour of labels for the same data.

Storj-Exporter-dashboard/Storj-Exporter-Boom-Table.json at 527f9946e625dad9ba0864e90b5a05a2f296145b · anclrii/Storj-Exporter-dashboard · GitHub is updated accordingly, please import the latest version of the dashboard.

Some issues were reported with v2 and other dashboards here 2.0.0 - No Data · Issue #64 · anclrii/Storj-Exporter · GitHub so those may need updating too as they may still be using the deprecated metrics.