@stephenw10 said in Properly Prometheus (with alertmanager & exporters) + Grafana installation on CE DEV version:

Not on pfSense directly. 😉

Why? Exactly pfSense have exporter for Prometheus. So the question about version are still actual.

There are quite a few tutorials on how to do exactly this by exporting the data to another host. And that's the correct way to do it IMO.

Of course, I read it. But asking about tho new version are only on official Prometheus web, but quite old version are in FreeBSD repo.

@toddwebnet Did you ever find one you like? I have the same use-case.

RRD intentionally aggregates data into larger intervals as the data gets older.

The monitoring graphs are intended to provide troubleshooting information, not be a high-resolution, historical archive. For that you can query the device using something like cacti or zabbix or a plethora of others.

Setting 8 hours x 1 minute resolution is pretty comprehensive. Anything longer than 8 hours and the resolution will be reduced.

Hello!

Just winging it here...I dont have a rrd dataset to reproduce the problem or test any solutions...

It looks like most (all?) rrd's are setup to hold 2284 days (6.25yr) of data. Once hit, the consolidation strategy must push the resolution out to 7200sec (?).

You could always increase the max. Is 10 years enough? Maybe 12years? There would need to be special update scripts to "resize GROW" all the current data. Yuk!

Maybe just add any possible resolutions to timelookup? What if rrd starts using one that wasnt added?

The simplest solution might be to just convert the timeformat assignment to a ternary operator, like :

var timeFormat = (timeLookup.hasOwnProperty([data[0].step]) ? timeLookup[data[0].step] : "%Y-%m-%d");

Maybe you could backup/zip/post your rrd data set so others could load/test possible solutions?

It is pretty cool that pfsense has the durability/longevity to run into this sort of problem :).

John