Removing old triggers on Triggers Screen

[jackie]

We are running zabbix 3.0.4 and using postgresql 9.5.4. We are have partitioned the history table (retain 90 days worth) and trends table (retain a years worth). We use sql to manually remove of entries older than a year in the acknowledges, alerts, auditlog, events and service_alarms tables.

The issue is on the Triggers Screen we are seeing triggers that are much older than a year. Is there anyway to remove these old triggers, either with GUI or sql?

Also, I heard that Zabbix may include database partitioning in their product in the future. Any one have any information on that?

Thanks!

[jackie]

I did enable housekeeping on our development box (housekeeping on everything except for history/trends), hoping it would clear out these old triggers. But it did not.

Please....is anyone else seeing this? I think there are many people with partitioned databases, and I'm really curious how you handle this.

Thanks for any info.

[cavaliercoder]

Triggers vs. Events

In my understanding (please challenge this and let me know what you find), triggers don’t actually have a date, but they do have a ‘last changed’ value.

A “trigger” is just an expression used to evaluate inbound metrics as either OK or PROBLEM. The triggers table happens to record the current state of each configured trigger, and the timestamp at which the trigger state last changed. This is what the Triggers view in Zabbix is showing you - the time of the most recent change, and a link to the most recent associated ‘event’, if it still exists.

Here is the last-changed field in the Zabbix sources: https://github.com/zabbix/zabbix/blo...hema.tmpl#L595.
You’ll notice the events table actually has a timestamp for each event: https://github.com/zabbix/zabbix/blo...ema.tmpl#L1045

The relationship between triggers and events is one-to-many. There could be multiple events for each trigger and all triggers are all unique. The most recent event for a trigger should coincide with the last-changed value of the trigger.

Effectively your triggers are not “old” - they are current and still being used to evaluate inbound metrics. They just haven’t changed state in a long time. The details of the most recent change, i.e. the “event”, may have been truncated in your partitioning process.

Please note that partitioning is not supported by Zabbix, and software updates do break partitioned installations from time to time. There is however, a reasonably size community of people who can help (myself included).

In case they are of any help to you, I have posted my partitioning scripts here:

https://github.com/cavaliercoder/zabbix-pgsql-partitioning

Rob Brucks has also published some of his: https://github.com/robbrucks/zabbix-...o-partitioning

[jackie]

Thanks so much for your response!

I may need to clarify what I mean by "old triggers". Below is a screen snapshot from Zabbix. The filter has been set to have a Trigger Status of "Any", instead of "Recent Problem", to show a complete list of entries related to the trigger.

It is clear that we are removing events old than a year, because any Last Change entries older than a year have no events associated with it. In our case a simple SQL statement is used to remove events older than a year each week. This was per the "Mastering Zabbix, 2nd Edition" manual.

My concern is regarding the entries in the triggers table that are older than a year. Seems like that table is going to continue to grow unbounded. We have housekeeping disabled. But my offline testing of housekeeping didn't appear to remove entries older than a year in this Triggers screen (triggers table).

Sorry if I'm being dense on this one, maybe those entries don't need to be removed. But just want to keep the database as clean as possible, since it is so crucial. Very much appreciate any feedback.