Missing RRD Graphs

[franco]

The option does just that, block IPv6. And that only on non-local traffic. You will always have loopback traffic on IPv6 as long as the system is built as being IPv6 capable. Case in point, squid (proxy server) does this. So even when you disable IPv6, it'll still pass (and block) IPv6 traffic. Hope that helps.

[giovino]

I too miss the RRD graphs and would enable them if that was an option. What do I miss?

1. It was very easy to see 5m, 1h, 1d, 30d, 365d graphs.

2. Traffic Graphs: I like the table stats below the graph (maximum, average, current, period, 95th percentile)
* I realize you can enable "show tables" but you don't get the measurement per sec (MB/s), period or 95th percentile

Note: RRD graphs are not important enough for me to bring up on separate infrastructure in my home network.

[BertM]

The main reason why I liked the RRD Graphs so much is that it was so easy to look at them (traffic) to identify trends in bandwidth usage, or to look at quality to have a historical overview of the stability of the WAN connection, or to see a trend in blocked packets, etc.

And setting-up another machine, just to monitor? We already have capacity problems in our VMware environment, so that is not likely to happen.
But even if we did, it would mean putting time and effort in setting-up yet another system I am not familiar with (LibreNMS was suggested).
And for what?
To have an additional device to query while I am already looking at the firewall involved?

The convenient thing about the RRD Graphs was that they were always available on the same firewall you were already looking at. Having to go elsewhere just to have a look at this just does not make sense.
And it would also mean that our firewalls in branch offices such as in Japan, Russia, Italy, Spain, Germany, etc. would all have to report back to the server that is collecting the info.
In other words: I would have to setup an additional infrastructure just for the purpose of having a look at things that have always been there since the early days of pfSense and also in the first releases of OPNsense.

I am sad they are gone. I consider the system heath to be a bit clumsy. I don't think it is meanth for the average laptop screen. (1366x768)
With RRD Graphs, you just had to scroll up and down to see the graphs for the different periods in different resolutions.
With the System Healt page, I just have to click to select what I want to see, then scroll down to actually see it, and if I want to see another period or resolution, I have to scroll up again, make the changes in my selection and scroll down again to see the picture.

I initially hoped that the fact that they were missing in 15.7.22 was some mistake or error, and that they would return 15.7.23.
It is really sad to hear that such a useful functionality is gone, and will not return.

[AdSchellevis]

System health uses the exact same data as the old rrd graphs did, so technically the functionality is not gone only the presentation is  different.

That wouldn't mean we can't optimize the system health to address some of the current concerns, at least the screen size issue and the amount of scrolling could probably be improved a bit.

I will try to look into this.

[franco]

Okay, so as a requirement I'm seeing "5m, 1h, 1d, 30d, 365d graphs" templates, a multi-graph view and a better screen utilisation. I think that can be arranged in a sort of "compatibility view mode", but I'm not exactly sure about the actual use case other than "better overview". It sounds like a dashboard functionality, not a drill-down page issue?

[BertM]

Considering the fact that the roadmap reads for the 16.1 version: "Replace RRD frontend using a modern alternative", I have to assume this is it.
Maybe I am just an old fossil having problems getting used to "modern".

I know I can use the bar below the graph to define an area to zoom-in to, but not in one nice view.
The problem with that is that it does not show more detail, it just stretches the graph horizontally.
But if you want to look at details, even with the zoom level set to 20 hours and the resolution set to high, zooming-in using the bar below the graph gives the impression (I am not really sure) that there is less detail than with the old RRD graphs.

I guess I will just have to live with this.
For me personally, the actual functionality of OPNsense is more important than the graph.

I am much more eager to learn more about the upcoming IDS/IPS and, for the future maybe, something in the area of "parental control" that would allow me to prevent users from listening to internet radio or visiting sites like youtube over already congested internet links.

Let's not put to much energy in discussing something like graphs. They will always be subject to personal preferences.

[AdSchellevis]

We have done some work to improve the readability a bit, made all a bit less space consuming and provide the option to collapse the options.

Below some examples:

20 hour dataset (high resolution):

1 year dataset (high resolution):


In case you want to try this on your machine before the release, just download this single template:

Code Select Expand


curl -o /usr/local/opnsense/mvc/app/views/OPNsense/Diagnostics/systemhealth.volt https://raw.githubusercontent.com/opnsense/core/master/src/opnsense/mvc/app/views/OPNsense/Diagnostics/systemhealth.volt



I did check the detail level on my end as well, but the level of detail really is the same as in the raw data from the rrd data itself (which hasn't changed) for the time period selected as long as it fits the screen.
(high res for the full 20 hours changes from 1 minute to 2 minutes, zooming results to 1 minute again).

The raw data can be exported using rrdtool (just for reference):

Code Select Expand

/usr/local/bin/rrdtool dump /var/db/rrd/


I totally agree, a lot of things are subjected to preference, although we can try to improve some of it to make it more acceptable for you too :)

[jstrebel]

@BertM, in regard of parental control and service filtering.
OPNsense is actually very good and efficient at this. There is a OpenDNS Client in it which allows you to determine which content and services you allow. Further on it acts also as a excellent phishing filter.
You will find this service entry under Services:DNS tools: Filter
Jakob

[BertM]

@jstrebel:Good suggestion. I will certainly try to play around with OpenDNS.
On some locations in our network it will certainly be an option.

Unfortunately not for all because that will only work if the computers in your network use the OPNsense for DNS.

On locations where we have a Windows DC, DNS from Windows will be used, and that synchronizes with all other DNS servers in our worldwide spread Active Directory. If only one of the DNS servers in the AD knows about the sites you want to block, it will still be reachable.
:'(

[jstrebel]

BertM, may be you could try to install the OpenDNS client in the win DC. So this win DC will get its "external" address resolutions from OpenDNS. (I do not have WIN AD know kow )


Gesendet von iPhone mit Tapatalk

[BertM]

@jstrebel:
I'm not allowed to do that (corp. policy)
However, some time in Q3 this year I will be able to setup a "test lab", so by then I could start playing around with it in a test environment.

[franco]

Ad, I think the data load message is in the wrong place as it keeps "jumping" the graph since it's shown/hidden... it should be static or incorporated into the static header... :)

[AdSchellevis]

Maybe it's better to replace it with a single icon in the title and drop the text (<i class="fa fa-spinner fa-spin"></i>), what do you think?

[franco]

That sounds great. :)

[AdSchellevis]

it looked a bit odd without the text, so I kept the text and moved all to the same panel (because of processing order, it doesn't have a title when performing the initial fetch). The jumping behaviour is fixed now.