Hello,
On 15 Apr 2021, at 21:34, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
I looked a bit deeper into this and was thinking, as IPfire already runs collectd, another possible solution to preventing zabbix agent from using iptables directly for getting metrics from the firewall, is to request them from collectd:
One way could be by enabling the collectd unixsock plugin (https://collectd.org/documentation/manpages/collectd-unixsock.5.shtml) and to make things 'easier' I could then call collectd-nagios (https://collectd.org/documentation/manpages/collectd-nagios.1.shtml) to collect live metrics from collectd as is explained in this example: https://docs.wallarm.com/admin-en/monitoring/collectd-zabbix/ However the collectd unixsock plugin is currently not enabled and collectd-nagios binary is not installed. So I'm not sure if all that is worth the effort for an optional addon as zabbix_agentd is. Since I assume this would require changes to a core component.
Hmm, it does not strike me as a very straight-forward solution to involve collectd. We have a replacement for collectd ready which we will roll out at some point and so it will go away eventually.
See my remarks about “getipstat” from my other email.
Another way could be by reading the last recorded value from the rrd- files generated by collectd using for example: # rrdtool lastupdate /var/log/rrd/collectd/localhost/iptables-filter- POLICYFWD/ipt_bytes-DROP_FORWARD.rrd
If we have to go this road, this would be a better solution in my view, but it still makes the Zabbix Agent dependant on collectd.
which gives back the timestamp of the measurement and the metric. But this would require a different approach on how to send those values to the Zabbix server since we now also have to send a timestamp together with the metric and this can only be done by using zabbix_sender to actively send metrics to Zabbix. Hence I would have to create a script that collects all required last values from the RRD files, and then send them to Zabbix using zabbix_sender. The executing of that script can be triggered by a cron job or as a custom userparameter by the agent, but then the script needs to finish within the timeout configured in the zabbix agent config (default: 3s, max 10s).. And in de case of a cron job, we'd only want that enabled if the Zabbix server is set up to listen for those specific metric-items. This could possibly integrated in the webgui as a user-configurable setting somehow.. (Providing a webgui-addon for configuring zabbix_agentd is also something I can imagine myself submitting in the future, but I wasn't planning to do that in short terms :-))
This sounds overly complicated to me and will require a lot of things being right (i.e. time).
You will end up with corner cases and bad metrics when the system is under load and the execution of the command is delayed.
So as you see, both have different challenges.. And of course, should collectd silently start to fail, Zabbix also will not get accurate data anymore. Or if the RRD file(s) would become corrupt (which I had once after migrating from i586 vm to x86_64 appliance)..
They are not corrupt, just incompatible between different architectures.
The result is the same :)
Up to some level, additional checks by Zabbix on collectd and the rrd files could possibly detect such failures..
But I still prefer for zabbix agent (or any monitoring tool for that matter) to have the shortest and most trustworthy direct path to the metrics it wants, in this case iptables statistics, hence the iptables command. So those wrapper scripts I brought up before are still my preferred solution on this.
Your thoughts ?
I agree :)
-Michael
Regards
Robin
Robin Roevens schreef op do 15-04-2021 om 15:12 [+0200]:
What would a monitoring tool do with a dump of the iptables ruleset? I do not even understand where the use of this is.
The same as IPFire webgui currently does on netother.cgi?fwhits?day by calling /sbin/iptables -vnxL <chain> | grep "/* <rule> */" | awk '{ print $2 }';: keep history of and eventually react on the number of firewall-hits.
But you are completely right that access to iptables should be restricted to just that what we want to get from it, which can be achieved with a wrapper script as explained below in my previous mail.
Regards
Robin
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.