anchor.diff:  :jbake-status: published
   :jbake-tags: blog, hawkular, alerts, standalone, autoresolve
   
  -Hawkular Alerts provides simple Alert life-cycle management and automated Alert resolution as core features.
  +Hawkular Alerts provide a simple Alert life-cycle management and an automated Alert resolution as core features.
   
   == Alert Lifecycle
   
   Alert definitions (triggers) are used to detect problems. When a problem happens a new alert is generated by the engine
  -with the information of the data that matched into the defined conditions. Also an Alert provides a simple lifecycle to
  +with the information about the data that matched the defined conditions. Also an Alert provides a simple lifecycle to
   indicate the status of the problem.
   
   A new Alert starts with *OPEN* status, optionally moves to *ACKNOWLEDGED* to indicate the alert has been seen and the
  - issue is being resolved, and is finally set to *RESOLVED* to indicate the problem has been fixed.
  +issue is being resolved, and is finally set to *RESOLVED* to indicate that the problem has been fixed.
   
  -Alert lifecycle can be handled manually or can be managed automatically within the tool.
  +Alert lifecycle can be handled manually or can be managed automatically by the AutoResolve tooling.
   
   == AutoResolve triggers
   
  -A trigger definition has one or multiple conditions that are set to detect a problem. When incoming data matched the
  -condition expresions and alert is triggered to inform about this new issue. In this context, if the engine is still
  +A trigger definition has one or multiple conditions that are set to detect a problem. When incoming data matches the
  +condition expresions an alert is triggered to inform about this new issue. In this context, if the engine is still
   receiving data, new alerts will be generated even if it refers to the *same* problem.
   
  -To define multiple alerts over the *same* problem is something it can be controlled with fine granularity.
  +The detection of multiple alerts belonging to the *same* problem can be controlled with fine granularity.
   
  -Hawkular Alerts allows to define that once a problem triggered an alert, the trigger is not going to evaluate more data
  +Hawkular Alerts allow to define that once a problem triggered an alert, the trigger is not going to evaluate more data
   until the issue is resolved to avoid repeated alerts for the same issue.
   
   Resolution of a problem can be done manually or automatically using *AUTORESOLVE* triggers.
   
  -A trigger defines conditions that are responsible to detect a problem, these conditions are called in Hawkular Alerts
  - *FIRING* conditions. Optionally, a trigger can define conditions that are responsible to detect when the problem is
  - gone, these new ones are called *AUTORESOLVE* conditions. So, in the engine a trigger will be in *FIRING* mode when
  - is evaluating data to detect a problem, a in *AUTORESOLVE* mode when is checking that the problem is not present
  - anymore.
  +A trigger defines conditions that are responsible to detect a problem. These conditions are called *FIRING* conditions
  +in Hawkular Alerts. Optionally, a trigger can define conditions that are responsible to detect when the problem is
  +gone. These new ones are called *AUTORESOLVE* conditions. So, in the engine a trigger will be in *FIRING* mode when it
  +is evaluating data to detect a problem while it will be a in *AUTORESOLVE* mode when it found out that the problem
  +is not present anymore.
   
  -These combination of *FIRING* and *AUTORESOLVE* conditions ensures that only *one alert* is generated for a problem,
  - and when the problem is resolved the trigger automatically returns to firing mode.
  +These combination of *FIRING* and *AUTORESOLVE* conditions ensures that only *one alert* is generated for a problem
  +and when the problem is resolved the trigger automatically returns to firing mode.
   
   == Example of alerting on process availability
   
  -Let's define a simple example to show how autoresolve triggers work.
  +Let's define a simple example to show how AutoResolve triggers work.
   
   In link:https://github.com/lucasponce/hawkular-examples/blob/master/extended-tests/process-autoresolve/create-definition-check-process.sh[create-definition-check-process.sh] bash script
  - it is defined an autoresolve trigger activating flags *autoResolve* and *autoResolveAlerts*.
  +we have defined an AutoResolve trigger activating flags *autoResolve* and *autoResolveAlerts*.
   
  -This fragment shows how to mark a trigger as autoresolve:
  +This fragment shows how to mark a trigger as AutoResolve:
   
   [source,json]
   ----
  
positive.code: }
  ----
  
  <1> *autoResolve* flag set to *true* indicates trigger will activate *FIRING* and *AUTORESOLVE* modes. Flag set
  to *false* will run the trigger only in *FIRING* mode.
  <2> *autoResolveAlerts* flag set to *true* will automatically mark alerts as *resolved* when *AUTORESOLVE* trigger
  detect problem is gone. Flag set to *false* will not modify alert lifecycle.
  
  And next fragment will show how to declare *FIRING* and *AUTORESOLVE* conditions linked with the trigger:
  
  [source,json]
  ----
  
negative.code: }
  ----
  
  <1> This *id* should match the *dataId* field defined in the conditions.
  
  Examples can be run using link:/blog/2015/08/19/hawkular-alerts-standalone.html[Hawkular Alerts in Standalone]
  deployment used in the previous post.
  
  More details about Hawkular Alerts features can be found at
  