Count function not working as expected on log item - Trigger permanently enabled.

[carnotan]

Hi Zabbix forums:

First of all, thank you in advance for all the help you might provide. I've been using Zabbix for years now and never have to post here anything. That speaks volumes about the quality of the docummentation. So here's my problem.

Key info: Zabbix Server and agents 5.0.x

We have a fairly big log file (about 2G/d) that we want to monitor for some specific error. In order to do that, heres our Item config:


We are specifically filtering for the lines that match our pattern / error we want to monitor . We do that in order to only store those lines (thus reducing history_log tables, we are a bit size constrained). And that works fine, we receive those lines:

We want to raise the alarm whenver we have more than n hits on a t time period. So, for this example, if we get more than 5 errors in a 5 minute interval, we want to alert. So here is our trigger config:



And here is our problem : either count is not working properly or we are doing something wrong (more than likely that last one) but when it detects the five erros the trigger goes to problem, but it never goes back. It never disables. No matter how much time I wait, it never disables. Even though nothing is written on that file. Even if I write correct / non matching lines on the file. I've read and re read the log item docummentation, the count function docummentation and can't find the error.

What am I doing wrong?

Thanks in advance,
Iván Lago.

[jhboricua]

Maybe try log.count[] for your item instead of log[], which returns the number of matching lines, then you can use your existing count trigger against it.

[carnotan]

I tried it, it didn't work. It behaved exactly the same as if it was a log.item. What did work was a mixing of this and a change of function (so I'll mark it as the answer). Here was our solution:

- Change the item type to log.count, as you suggested. Refresh time 1 minute.
- Change the function to sum. That way, we know in the last n minutes how many accumulated errors we have. And that works exactly as we wanted .

So thank you both jhboricua and Brambo.

[jhboricua]

You can't use the 'greater or equal' operator of the count function againts log events:

Note that:
eq (default), ne, gt, ge, lt, le, band, regexp, iregexp are supported for integer items
eq (default), ne, gt, ge, lt, le, regexp, iregexp are supported for float items
like (default), eq, ne, regexp, iregexp are supported for string, text and log items

Source: https://www.zabbix.com/documentation...tions?hl=count

[carnotan]

First of all, before I read and try some of the solutions: thank you. I really should've caught that. It was in the docummentation. I somehow missed that note.

[jhboricua]

Maybe try log.count[] for your item instead of log[], which returns the number of matching lines, then you can use your existing count trigger against it.

[carnotan]

I tried it, it didn't work. It behaved exactly the same as if it was a log.item. What did work was a mixing of this and a change of function (so I'll mark it as the answer). Here was our solution:

- Change the item type to log.count, as you suggested. Refresh time 1 minute.
- Change the function to sum. That way, we know in the last n minutes how many accumulated errors we have. And that works exactly as we wanted .

So thank you both jhboricua and Brambo.

[Brambo]

What i do for this is (in zabbix 7) make a calculated item, formula count(//itemkey,1h,,) So this item will result in a integer value for the amount of lines of the last hour. Be aware that this is written in zabbix 7 format (which should work in 6 as well).
With this integer value you could also do some nice trend triggers

[jhboricua]

I believe that is what the log.count[] item does, return the number of matching lines as an integer.

[Brambo]

jhboricua yes and no, with the calculated item you do have more options on time period, with the log/ eventlog.count you have other options. More or less you get the same number but depending on your needs 1 might be better.