Re: [PATCH 0/5] Add Zabbix functionality to suricata-reporter

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

Small correction to my explanation, the statement I made about sending
older events from the time when zabbix functionality is not yet
enabled, is not true, as when zabbix functionality is disabled, events
recorded in the database are not marked as pending, so they won't be
sent to zabbix when that functionality is enabled on a later time.

It does however give the user the implicit functionality of augmenting
the max_age in case zabbix server was unreachable for longer than
current max_age to recover events it missed due to previous max_age
setting.

Regards
Robin

Robin Roevens schreef op do 30-07-2026 om 21:15 [+0200]:
> Hi all,
> 
> As discussed here earlier, I've worked on implementing sending
> Suricata alerts straight to Zabbix from within suricata-reporter
> instead
> of trying to parse the suricata logging separately using the Zabbix
> agent.
> 
> For this I use the zabbix-utils python library, which I submited here
> also as a separate pak (but meanwhile already requires an update,
> which
> I will post soon). This set of patches makes suricata-reporter able
> to
> directly communicate to a Zabbix server without having the
> zabbix_agentd
> pak installed, sending suricata alerts in real-time.
> 
> As Zabbix supports sending items in bulk, I have opted to create an
> async background task that will send all events from last 1 second in
> bulk so that even in the case that there are hundreds of incoming
> alerts, Zabbix server is only contacted once per second.
> 
> When for some reason sending to Zabbix server fails, it will be
> retried
> 3 times and then the background task will be suspended until a new
> suricata event comes in. That will wake the task again and retry to
> send all
> pending events. In environments with many events, that may actually
> not
> have that much of an effect. But in the average environment, this
> will
> give the Zabbix Server some breathing space as it failing to receive
> our
> events, may indicate a Zabbix server overload. 
> 
> For this I have to keep track which events are sent and which are
> pending. So I added a column in the database that keeps track of
> that.
> 
> I have also added an alert_max_age config parameter that allows the
> user
> to set how long suricata-reporter should retry to send events to
> Zabbix.
> Events older than that set age, will no longer be sent to Zabbix.
> This also give the user the implicit option to send older events when
> only just enabling the zabbix sending functionality, since the DB
> column
> exists and no event was ever sent to Zabbix, all events will be
> 'pending". At first run with zabbix functionality enabled, all events
> up
> to alert_max_age that are in the database will be sent to zabbix
> immediatly.
> 
> All events sent to Zabbix contain the timestamp of retrieval by
> suricata-reporter, so Zabbix will register and order them as received
> on that
> timestamp independently of the actual time Zabbix itself received the
> event.
> 
> This is my first adventure in Python async programming, so I hope I
> did
> not make any flagrant mistakes. But the code has been running here
> for
> weeks now without any problem. I have not actually tested large
> bursts
> of events, as I could not simulate that.. But I did make Zabbix
> server
> slow, unavailable and finally replaced it with netcat (to accept the
> connection, but
> not react on it) and I had the connection with the server off for a
> few
> hours to then re-establish the connection to see hundereds of pending
> events 
> being registered in only a few milliseconds.
> I did not notice any problems with suricata-reporter in any of these
> cases.
> 
> Regards
> 
> Robin

-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.