[Feature Request]: Persistent storage for graphs, etc.

[drewstopherlee]

Enhancement of issue

My NUT server is restarted periodically due to a limitation of CyberPower UPS's with NUT. I've added a restart of the PeaNUT container to this script, as it gets a 500 error if the NUT server is restarted and the container isn't. I'd like to see the historical data from the graphs persist through container restarts.

Solution

Is it possible to add a path mapping to the config for persistent storage of the data that populates the graphs?

Alternatives

No response

Additional Context

No response

[OddSquirrel]

Funnily enough, I'd be delighted if it even persisted until the occasional restart. My graph never shows any data when I open the website, it only seems to capture data while it's actively open in my browser. I'm not sure if that means it's working as intended.

On the other hand, not offering a data volume within the docker-compose file seems to indicate it's by design.

I'm really puzzled at this point. Has anybody found a way to capture long-term data with this? 🤔

[Brandawg93]

I've added a very rudimentary example of connecting the API to InfluxDB. This will definitely help until I can get around to adding this to the app itself.

https://github.com/Brandawg93/PeaNUT/tree/main/examples/persistant-data

[OddSquirrel]

Thanks, @Brandawg93, really appreciate it. Looks like I get to fumble around with InfluxDB / Grafana after all. 😎

Just to understand the issue, how come that graph got into the app in the first place without persistent storage? Did you originally mean to put that in soon afterward and just didn't get around to doing it?

Mind you, I'm not judging, you probably have a life besides PeaNUT, and that's fine. 😊

[Brandawg93]

The initial plan was to have persistent storage directly in the container, but I ran into several issues:

1. I tried using Influxdb directly, but building it on top of a container that had node turned out to be very complicated for some reason. Just installing all the dependencies to make everything happy was a headache.
2. I tried running influxdb beside peanut similar to the example, but directly connected to the UI. But I started having issues with everything being strings, and then all variables being optional and it got really messy. Every UPS brand has its own set of variables, so trying to deal with them all graphically is near impossible.
3. I tinkered with using other db sources such as TimescaleDB which got me further along in the process, but ultimately still gave too many issues similar to 1 and 2.

And by this time I had already gotten bored and created the charts in the UI. 😄

I do believe it's possible to make this work. But I've been having a difficult time deciding on the best architecture while not reinventing the wheel. Do I run the db along side peanut and recreate Grafana (the wheel)? Or do I have an all-in-one container that may not work for certain architectures/OSes?

[OddSquirrel]

Thanks for the detailed response! 😊👍

Yes, that makes perfect sense. I bet it's a real pain to figure it all out, and I wish I could help, but I haven't even touched InfluxDB / Grafana as a user, much less poked around in the dev department. Also, on a scale of 1 to 10, my coding skills are a few miles below my cuneiform expertise, so there's that. 🙈

So, don't go nuts over it (no pun intended 😋)—it'd be great to have, but not at the cost of your sanity.

[Brandawg93]

I've created a new test version (brandawg93/peanut:test) that contains some fixes for grafana users. I also updated the persistent-data example with a better dashboard. You can find it on the grafana branch.

Hopefully someone can test this out and confirm it works for them too! 🤞