From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH 4/4] [V2] zabbix_agentd: Add IPFire specific userparameters Date: Mon, 19 Apr 2021 14:42:33 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3049652301029667558==" List-Id: --===============3049652301029667558== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 15 Apr 2021, at 21:34, Robin Roevens wrote: >=20 > Hi Michael >=20 > 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: >=20 > 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 col= lectd. We have a replacement for collectd ready which we will roll out at som= e point and so it will go away eventually. See my remarks about =E2=80=9Cgetipstat=E2=80=9D 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 i= t 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.=20 > 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 :-))=20 This sounds overly complicated to me and will require a lot of things being r= ight (i.e. time). You will end up with corner cases and bad metrics when the system is under lo= ad 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.. >=20 > 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. >=20 > Your thoughts ? I agree :) -Michael >=20 > Regards >=20 > Robin >=20 > Robin Roevens schreef op do 15-04-2021 om 15:12 [+0200]: >>=20 >>>=20 >>> What would a monitoring tool do with a dump of the iptables ruleset? >>> I do not even understand where the use of this is. >>=20 >> The same as IPFire webgui currently does on netother.cgi?fwhits?day >> by calling /sbin/iptables -vnxL | grep "\/\* \*\/" | awk >> '{ print $2 }';: keep history of and eventually react on the number of >> firewall-hits. >>=20 >> 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. >>=20 >> Regards >>=20 >> Robin >>=20 >=20 >=20 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. >=20 --===============3049652301029667558==--