[Hawkular-dev] Tag concept in metrics and alerts

[Gary Brown]

----- Original Message -----
> > 
>> > So just to check - if I include the BT id in the metric being supplied to
> > the
> > engine, then the 'tag' (name/value pairs) information for that metric will
> > be carried into alert as part of the evaluation information?
> > 
> 
> In alert context, the incoming data should match
> org.hawkular.alerts.api.model.data
> 
> https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/model/data
> 
> These data is carried and stored in the evaluation details for an alert.
> 
> But "Tag" in alerts is used as a way to put "alias" on definitions but is not
> related to specific incoming data.

Sorry when I referred to 'tag', I meant the tag in the metrics event, which is a map of name/value pairs.

So when the alerts engine is analysing a metric, is the tag information on the metric stored in the alert's condition evaluation data?

> 
> I have some questions, that may be can help us to refine your requeriment:
> 
> - The incoming data you need is something like a pair of (BT id, value) =
> (bt1, 1000), (bt2, 1002) ...
> 
> - ¿ Where you want to apply conditions matching for specific BT id ?

No, the condition wouldn't refer to the BT id - the id is only included for future reference to enable apps to link back to the business transaction that caused the alert.

> 
> - ¿ Or perhaps you have a more complex incoming data ?
> 
> Can you ellaborate an example ?

Sure - so the business transaction information may be used to derive a latency metric, describing the time delay between one service sending a message and the recipient receiving the message. The metric will include the BT id associated with the latency. The alerts engine will then apply a condition to determine whether the latency is greater than a permitted value, and if so create an alert.

We then need to resulting Alert to directly or indirectly contain the BT id, so that when a user investigates the latency problem, they could navigate back to the business transaction that caused the problem to see if there is anything of interest.

Now in reality this would not happen, as latency would probably be aggregated and only if the aggregate value hit a threshold would an alert be triggered - but it provides a potential example of the end to end flow of business txn data collection -> metrics -> alerts and then having the necessary info in the alert to trace back,

Regards
Gary



> 
> Thanks,
> Lucas