-
Incident report
-
Resolution: Unresolved
-
Trivial
-
None
-
2.0.7
-
Linux, CentOS-6.4, PostgreSQL 9.1.9, Apache HTTPD-2.2.15, PHP-5.3.3
It took a long time to bring myself to create this report, because I'm not able to provide a process for reproducing this issue.
I got several triggers based on log items that seem now and then to ignore item values.
The triggers change into PROBLEM state if string "foo: not available" appears in last value.
If in PROBLEM state, the triggers change back to OK state if string "foo: available" appears.
But sometimes they stay in PROBLEM state, even though the item received a value including "foo: available".
Trigger expression example:
{TRIGGER.VALUE}=0 & {Template:logrt["\{$LOG_FILE}",foo :( not| partially)? available,ISO8859-1,21,skip].regexp("foo : not available")}=1 |
{TRIGGER.VALUE}=1 & {Template:logrt["\{$LOG_FILE}",foo :( not| partially)? available,ISO8859-1,21,skip].regexp("foo : available")}#1
Event example (no OK event):
30 Aug 2013 18:10:40 foo is not available. PROBLEM
History example (Timestamp/Local time/Value):
2013.Aug.30 18:10:42 2013.Aug.30 18:10:29 bar: available 2013.Aug.30 18:10:42 2013.Aug.30 18:10:29 bar: available 2013.Aug.30 18:10:42 2013.Aug.30 18:10:29 foo: available 2013.Aug.30 18:10:42 2013.Aug.30 18:10:29 bar: available 2013.Aug.30 18:10:41 2013.Aug.30 18:09:55 bar: not available 2013.Aug.30 18:10:40 2013.Aug.30 18:09:55 bar: not available 2013.Aug.30 18:10:40 2013.Aug.30 18:09:49 foo: not available 2013.Aug.30 18:10:40 2013.Aug.30 18:09:49 bar: partially available 2013.Aug.30 18:09:38 2013.Aug.30 18:09:26 bar: not available 2013.Aug.30 18:09:38 2013.Aug.30 18:09:26 bar: not available 2013.Aug.30 18:08:32 2013.Aug.30 18:08:02 bar: available
The only common thing I noticed (for this particular example) is that it happened if between corresponding "not available" / "available" were 30 secs but values were processed in very quick succession.