[jira] [Commented] (EAGLE-464) StateCheck: multiple stage of definition in single policy

["Su Ralph (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/EAGLE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422480#comment-15422480 ] 

Su Ralph commented on EAGLE-464:
--------------------------------

In pr of : https://github.com/apache/incubator-eagle/pull/337. merged draft implementation

> StateCheck: multiple stage of definition in single policy
> ---------------------------------------------------------
>
>                 Key: EAGLE-464
>                 URL: https://issues.apache.org/jira/browse/EAGLE-464
>             Project: Eagle
>          Issue Type: New Feature
>    Affects Versions: v0.5.0
>            Reporter: Su Ralph
>            Assignee: Su Ralph
>             Fix For: v0.5.0
>
>
> The requirement of alert state and transition comes from two real customer needs.
> Alert de-duplication
> "IMO, eagle should do state checks for all services. Eagle should not alert in the first attempt itself. Instead it should change the state to SOFT for 2 tries and then if it is the same state, change the state to HARD and then send the alert." - Aroop
> Currently, eagle's alert engine(and also that of UMP) use a simple deduplication spec of time based redundancy check(dedupIntervalMin of Publishment). This deduplication is not flexible to reflect the need of alerts. There are common requests like to hold a alert/policy state (basically a alert state is policy state on given partition value, more in latter), and trigger alert when the state changed. This state change manner could be 
> > Same alert trigger again in M time interval
> > N alerts in given M time interval.
> NOTE: on here, in this de-duplication mode, there is no required change of the policy itself.
> Alert policy define on transition
> One example of the missingblock policy we met(only alert when missingblock number changes). There is more general case with minor difference, given a metric (or a field of a given stream), define value range, where each range indicate different state. Etc. for perfmon.latency.avg.perpool, define value range state as
> metric
> value range
> state
> alert trigger
> perfmon.latency.avg.perpool.5min	3000 - Unlimited	FATAL	always (every 5min until FATAL fixed or alert muted explictly)
>  	1000 - 3000	CRITICAL	on dual transition
>  	100 - 1000	WARN	on dual transition
>  	10 - 50	NORMAL	on worse transition
>  	0-10	GOOD	on worse transition
> Then the alert should be trigger during the state changed expect for FATAL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)