Single problem event generation creates one problem event when a trigger enters PROBLEM. While the trigger expression remains true, repeated PROBLEM evaluations do not create additional events and do not update the active problem clock.

This is expected for Single mode, but some users want to keep one active problem while still seeing repeated occurrences.

Requested behavior

For triggers using Single problem event generation mode, expose one or more of:

• occurrence counter for repeated PROBLEM evaluations while the problem is active;
• last occurrence timestamp for the active problem;
• optional ability to sort Problems by last occurrence time;
• macro support to show occurrence counter / last occurrence time in operational data;
• optional history-function anchor based on the active problem's first event time.

Examplary use case

External systems send values to a Zabbix trapper item through history.push. The trigger expression is true while data continues to arrive, for example:

nodata(/host/key,5m)=0

The user wants one active problem, not a separate event for every received value. However, they also need to see how many times the alert condition has reoccurred and whether a currently active problem has received fresh data.

Proposed feature details

Add active-problem occurrence metadata for trigger problems generated in Single mode:

• occurrence_count: number of PROBLEM evaluations or source item events seen while the problem is active;
• last_occurrence_clock and last_occurrence_ns: timestamp of the latest repeated PROBLEM evaluation/source value;
• optional first_occurrence_clock, if different from existing event clock semantics are needed;
• problem API output fields for these values;
• supported macros for trigger operational data, event names, actions, and notifications, for example: {EVENT.OCCURRENCE.COUNT} {EVENT.OCCURRENCE.LAST.TIME} {EVENT.OCCURRENCE.LAST.DATE}
• Monitoring > Problems column and sorting option for last occurrence time.

The feature should preserve Single mode semantics: it should not create a new problem event for each repeat. It should only update metadata of the existing active problem.

Expected user-visible behavior

Example:

Trigger:
nodata(/host/app.alert.signal,5m)=0

PROBLEM event generation mode:
Single 

If values arrive at:

10:00:00
10:01:30
10:02:15 

Zabbix should keep one active problem event, but expose:

problem clock:          10:00:00
occurrence count:       3
last occurrence clock:  10:02:15 

The Problems view could still show the original problem start time, but should also allow showing and sorting by last occurrence time.