One of my nodes upgraded to v0.21.1 today and I noticed that my ingress/egress graphs in my monitoring system weren’t getting data anymore. It looks like data.bandwidth.egress and data.bandwidth.ingress were removed from the dashboard API call, and there isn’t any replacement for them that I can see.
Can this information please be added back in the next release? It seems silly to me that it was removed in the first place; this is useful information to be able to obtain automatically.
none of the scripts I know returns data …
Some of the data was restructured, but the detailed bandwidth information was totally removed.
This is a pretty big deal, Storjlings. Removing data that we rely upon to monitor our nodes is a really bad idea, at least without communicating in advance and providing alternatives.
#!/bin/bash
tmpf=$(mktemp)
docker logs storagenode > ${tmpf} 2>&1
echo -e "Unrecoverable Failed Audits:\t$(cat "tmpf" | grep GET_AUDIT | grep failed | grep open -c)" echo -e "Recoverable Failed Audits:\t(cat "tmpf" | grep GET_AUDIT | grep failed | grep -v open -c)" echo -e "Successful Audits:\t\t(cat "tmpf" | grep GET_AUDIT | grep downloaded -c)" echo -e "Failed Downloads:\t\t(cat "tmpf" | grep '"GET"' | grep failed -c)" echo -e "Successful Downloads:\t\t(cat "tmpf" | grep '"GET"' | grep downloaded -c)" echo -e "Failed Uploads:\t\t\t(cat "tmpf" | grep '"PUT"' | grep failed -c)" echo -e "Successful Uploads:\t\t(cat "tmpf" | grep '"PUT"' | grep uploaded -c)" echo -e "Failed Download Pieces:\t\t(cat "tmpf" | grep GET_REPAIR | grep failed -c)" echo -e "Successful Download Pieces:\t(cat "tmpf" | grep GET_REPAIR | grep downloaded -c)" echo -e "Failed Upload Pieces:\t\t(cat “tmpf" | grep PUT_REPAIR | grep failed -c)" echo -e "Successful Upload Pieces:\t(cat “$tmpf” | grep PUT_REPAIR | grep downloaded -c)”
rm $tmpf this one still works
but this is the data from the log, not from the api …
With the risk of you saying “This is the data from the info.db not the api”…
The info.db is where the api gets its data from as well.
Hmm, this is good to know… I already have a proxy in place to correct some issues with differing units, so maybe I can just have that proxy read the values out of the database and put them back in the JSON payload where they were.
I don’t think the info.db should be treated as public API. That would limit the ability to apply schema changes over time, etc.
I also see value in a REST-based exposure of some form of this data as I track and alert on it as well. That being said, the previous iteration was indicating negative bandwidth utilization and was incomplete so I didn’t bother hooking into that portion of the data and limited my metrics to primarily the reputation artifacts.
I agree, right now I’m using it as a stopgap until this information is restored to some API. (I don’t care if it’s /api/dashboard or something else entirely.)
for me after update 0.21.1 now avarage Last contact is 45 sec.
no increasing egress or ingress…
start thinking… to exit this project… its just take time… and killing hdd . but profit will be just funny low.
This is an expected result of the removal of kademlia, not an issue with your node. You don’t have to do anything. Instead of looking at the slow moving egress and ingress numbers if you want to verify your node is working correctly, just check the logs and see if your have any transfers. You can also see the bandwidth usage by day in the new dashboard.
yeah… but if this will continue like that- it will take for me. 20 years to fill my 20TB space 
New nodes take a while to be vetted. Give it some time. I have a 10TB node and it never filled up that much, but I have already received $140 in actual payouts in 6 months. That means there is even more than that held in escrow. It’s worth it to me at least. My node isn’t really filling up much either, I don’t think it’s realistic to expect them to fill up entirely any time soon. 2.7TB on my node now, so I have plenty of more room to grow. But it doesn’t need to be full to be worth it.
