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

[Michael Tremer <michael.tremer@ipfire.org>]

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

Hello,

> On 15 Apr 2021, at 21:34, Robin Roevens <robin.roevens(a)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.
>