Re: [PATCH 4/4] [V2] zabbix_agentd: Add IPFire specific userparameters

[Robin Roevens <robin.roevens@disroot.org>]

[-- Attachment #1: Type: text/plain, Size: 3706 bytes --]

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.

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
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 :-)) 


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)..
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 ?

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.