3:45 a.m.
Hi
Both metrics and alerts use the term 'tag' - however metrics use a name/value pair
for a tag, and alerts uses it as a label. Wondering whether we need consistency?
When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering
whether it would be clearer for metrics to rename tags to properties?
Possibly metrics needs the concept of a tag/label as well?
Regards
Gary
4:02 a.m.
Good point, I guess inventory has or needs tags/labels too
Thomas
On 06/24/2015 10:45 AM, Gary Brown wrote:
Hi
Both metrics and alerts use the term 'tag' - however metrics use a name/value
pair for a tag, and alerts uses it as a label. Wondering whether we need consistency?
When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering
whether it would be clearer for metrics to rename tags to properties?
Possibly metrics needs the concept of a tag/label as well?
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:25 a.m.
Hi,
I don't agree with changing the terms. Many of metrics competing products (such as
InfluxDB / OpenTSDB) use the same terminology, so it is easier for customers to understand
the differences and similarities between products. Using different terminology was one of
the difficulties in RHQ (like noted in the F2F meeting) and I don't think we should
repeat the same mistake.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, June 24, 2015 11:45:56 AM
Subject: [Hawkular-dev] Tag concept in metrics and alerts
Hi
Both metrics and alerts use the term 'tag' - however metrics use a name/value pair
for a tag, and alerts uses it as a label. Wondering whether we need consistency?
When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering
whether it would be clearer for metrics to rename tags to properties?
Possibly metrics needs the concept of a tag/label as well?
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:35 a.m.
Not using the same terminology as "industry standards" is a problem, not using
the same terminology within Hawkular small world is another...
Can we solve both ?
Thomas
On 06/24/2015 12:25 PM, Michael Burman wrote:
Hi,
I don't agree with changing the terms. Many of metrics competing products (such as
InfluxDB / OpenTSDB) use the same terminology, so it is easier for customers to understand
the differences and similarities between products. Using different terminology was one of
the difficulties in RHQ (like noted in the F2F meeting) and I don't think we should
repeat the same mistake.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, June 24, 2015 11:45:56 AM
Subject: [Hawkular-dev] Tag concept in metrics and alerts
Hi
Both metrics and alerts use the term 'tag' - however metrics use a name/value
pair for a tag, and alerts uses it as a label. Wondering whether we need consistency?
When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering
whether it would be clearer for metrics to rename tags to properties?
Possibly metrics needs the concept of a tag/label as well?
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:43 a.m.
+1
I don't mind if we adopt Tag as being name/value pair - but then we should use the
same approach in Alerts. I actually need the Alert to have ability to record name/value
pairs so this would suit my need, but they would then they would need to change their
current Tag to be something else, possibly Label?
Regards
Gary
----- Original Message -----
Not using the same terminology as "industry standards" is a
problem, not
using the same terminology within Hawkular small world is another...
Can we solve both ?
Thomas
On 06/24/2015 12:25 PM, Michael Burman wrote:
> Hi,
>
> I don't agree with changing the terms. Many of metrics competing products
> (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier
> for customers to understand the differences and similarities between
> products. Using different terminology was one of the difficulties in RHQ
> (like noted in the F2F meeting) and I don't think we should repeat the
> same mistake.
>
> - Micke
>
> ----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Wednesday, June 24, 2015 11:45:56 AM
> Subject: [Hawkular-dev] Tag concept in metrics and alerts
>
> Hi
>
> Both metrics and alerts use the term 'tag' - however metrics use a
> name/value pair for a tag, and alerts uses it as a label. Wondering
> whether we need consistency?
>
> When I hear the term tag, I usually envisage a label - e.g. as in git. So
> wondering whether it would be clearer for metrics to rename tags to
> properties?
>
> Possibly metrics needs the concept of a tag/label as well?
>
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:55 a.m.
Perhaps a rename to "Label" can be valid.
Gary, is there some place where I can find more details about the context ?
(Just to understand the whole scenario and see if what can be needed/interesting).
Thanks,
Lucas
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, June 24, 2015 12:43:56 PM
Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
+1
I don't mind if we adopt Tag as being name/value pair - but then we should
use the same approach in Alerts. I actually need the Alert to have ability
to record name/value pairs so this would suit my need, but they would then
they would need to change their current Tag to be something else, possibly
Label?
Regards
Gary
----- Original Message -----
> Not using the same terminology as "industry standards" is a problem, not
> using the same terminology within Hawkular small world is another...
> Can we solve both ?
>
> Thomas
>
> On 06/24/2015 12:25 PM, Michael Burman wrote:
> > Hi,
> >
> > I don't agree with changing the terms. Many of metrics competing products
> > (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier
> > for customers to understand the differences and similarities between
> > products. Using different terminology was one of the difficulties in RHQ
> > (like noted in the F2F meeting) and I don't think we should repeat the
> > same mistake.
> >
> > - Micke
> >
> > ----- Original Message -----
> > From: "Gary Brown" <gbrown(a)redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev(a)lists.jboss.org>
> > Sent: Wednesday, June 24, 2015 11:45:56 AM
> > Subject: [Hawkular-dev] Tag concept in metrics and alerts
> >
> > Hi
> >
> > Both metrics and alerts use the term 'tag' - however metrics use a
> > name/value pair for a tag, and alerts uses it as a label. Wondering
> > whether we need consistency?
> >
> > When I hear the term tag, I usually envisage a label - e.g. as in git. So
> > wondering whether it would be clearer for metrics to rename tags to
> > properties?
> >
> > Possibly metrics needs the concept of a tag/label as well?
> >
> > Regards
> > Gary
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:14 a.m.
Hi Lucas
The context is around the topic of HWKALERTS-49 - being able to replicate the RTGov
'situation' functionality using alerts. I think the main part missing at the
moment is being able to associate the Alert with the business transaction information that
caused it.
I believe there are two scenarios that may occur, where business transaction data may
result in an Alert:
(1) metrics derived from the business transaction data are applied to the alert engine
resulting in an alert - the persisted Alert will need to contain some link back to the
business transaction. Metrics has their 'tag' name/value pair, which I believe
could be used to store this info when the metric is created - so just need a way to carry
that over into the alert.
(2) other 'events' - so for example, if we identify some situation of interest (a
service failure), we create an object representing that situation and send it to the
alerts engine - again the originating business transaction id would need to be carried
across via the intermediate 'service failure' object.
Is it possible this could be handled by the work you are doing on HALERT-57?
Regards
Gary
----- Original Message -----
Perhaps a rename to "Label" can be valid.
Gary, is there some place where I can find more details about the context ?
(Just to understand the whole scenario and see if what can be
needed/interesting).
Thanks,
Lucas
----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Wednesday, June 24, 2015 12:43:56 PM
> Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
>
> +1
>
> I don't mind if we adopt Tag as being name/value pair - but then we should
> use the same approach in Alerts. I actually need the Alert to have ability
> to record name/value pairs so this would suit my need, but they would then
> they would need to change their current Tag to be something else, possibly
> Label?
>
> Regards
> Gary
>
> ----- Original Message -----
> > Not using the same terminology as "industry standards" is a problem,
not
> > using the same terminology within Hawkular small world is another...
> > Can we solve both ?
> >
> > Thomas
> >
> > On 06/24/2015 12:25 PM, Michael Burman wrote:
> > > Hi,
> > >
> > > I don't agree with changing the terms. Many of metrics competing
> > > products
> > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier
> > > for customers to understand the differences and similarities between
> > > products. Using different terminology was one of the difficulties in
> > > RHQ
> > > (like noted in the F2F meeting) and I don't think we should repeat
the
> > > same mistake.
> > >
> > > - Micke
> > >
> > > ----- Original Message -----
> > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > To: "Discussions around Hawkular development"
> > > <hawkular-dev(a)lists.jboss.org>
> > > Sent: Wednesday, June 24, 2015 11:45:56 AM
> > > Subject: [Hawkular-dev] Tag concept in metrics and alerts
> > >
> > > Hi
> > >
> > > Both metrics and alerts use the term 'tag' - however metrics use
a
> > > name/value pair for a tag, and alerts uses it as a label. Wondering
> > > whether we need consistency?
> > >
> > > When I hear the term tag, I usually envisage a label - e.g. as in git.
> > > So
> > > wondering whether it would be clearer for metrics to rename tags to
> > > properties?
> > >
> > > Possibly metrics needs the concept of a tag/label as well?
> > >
> > > Regards
> > > Gary
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:27 a.m.
Thx Gary,
Comments in-line,
Hi Lucas
The context is around the topic of HWKALERTS-49 - being able to replicate the
RTGov 'situation' functionality using alerts. I think the main part missing
at the moment is being able to associate the Alert with the business
transaction information that caused it.
I believe there are two scenarios that may occur, where business transaction
data may result in an Alert:
(1) metrics derived from the business transaction data are applied to the
alert engine resulting in an alert - the persisted Alert will need to
contain some link back to the business transaction. Metrics has their 'tag'
name/value pair, which I believe could be used to store this info when the
metric is created - so just need a way to carry that over into the alert.
(2) other 'events' - so for example, if we identify some situation of
interest (a service failure), we create an object representing that
situation and send it to the alerts engine - again the originating business
transaction id would need to be carried across via the intermediate 'service
failure' object.
Is it possible this could be handled by the work you are doing on HALERT-57?
In HWKALERTS-57 we are improving the Action model to pass the Alert that was linked and
also the Alert should have information about the definition who triggered it.
So, having an action, you will have the alert and the definition data.
If the business transaction info is "mapped" into the definition, the action
will have it.
These requeriments were addressed by plugins but as we are still working on it, we can
join other requeriments in the same context to improve it.
How do you plan to map the BTM info into the definition ? using Tags ?
That can help me to add/modify some aspect of the present work.
Thanks,
Lucas
Regards
Gary
----- Original Message -----
> Perhaps a rename to "Label" can be valid.
>
> Gary, is there some place where I can find more details about the context ?
>
> (Just to understand the whole scenario and see if what can be
> needed/interesting).
>
> Thanks,
> Lucas
>
> ----- Original Message -----
> > From: "Gary Brown" <gbrown(a)redhat.com>
> > To: "Discussions around Hawkular development"
> > <hawkular-dev(a)lists.jboss.org>
> > Sent: Wednesday, June 24, 2015 12:43:56 PM
> > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
> >
> > +1
> >
> > I don't mind if we adopt Tag as being name/value pair - but then we
> > should
> > use the same approach in Alerts. I actually need the Alert to have
> > ability
> > to record name/value pairs so this would suit my need, but they would
> > then
> > they would need to change their current Tag to be something else,
> > possibly
> > Label?
> >
> > Regards
> > Gary
> >
> > ----- Original Message -----
> > > Not using the same terminology as "industry standards" is a
problem,
> > > not
> > > using the same terminology within Hawkular small world is another...
> > > Can we solve both ?
> > >
> > > Thomas
> > >
> > > On 06/24/2015 12:25 PM, Michael Burman wrote:
> > > > Hi,
> > > >
> > > > I don't agree with changing the terms. Many of metrics competing
> > > > products
> > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it is
> > > > easier
> > > > for customers to understand the differences and similarities between
> > > > products. Using different terminology was one of the difficulties in
> > > > RHQ
> > > > (like noted in the F2F meeting) and I don't think we should
repeat
> > > > the
> > > > same mistake.
> > > >
> > > > - Micke
> > > >
> > > > ----- Original Message -----
> > > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > > To: "Discussions around Hawkular development"
> > > > <hawkular-dev(a)lists.jboss.org>
> > > > Sent: Wednesday, June 24, 2015 11:45:56 AM
> > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts
> > > >
> > > > Hi
> > > >
> > > > Both metrics and alerts use the term 'tag' - however metrics
use a
> > > > name/value pair for a tag, and alerts uses it as a label. Wondering
> > > > whether we need consistency?
> > > >
> > > > When I hear the term tag, I usually envisage a label - e.g. as in
> > > > git.
> > > > So
> > > > wondering whether it would be clearer for metrics to rename tags to
> > > > properties?
> > > >
> > > > Possibly metrics needs the concept of a tag/label as well?
> > > >
> > > > Regards
> > > > Gary
> > > > _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > >
> > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:47 a.m.
Hi Lucas
Not sure the alert or definition will be appropriate - assuming that the definition is a
static representation of the trigger?
The information (business transaction id) I am referring to is per business transaction
instance - i.e. it is unique for each invocation of a business transaction. So this can
only be obtained from the information being evaluated by the trigger.
Let me know if I have misunderstand what you meant as definition.
Regards
Gary
----- Original Message -----
Thx Gary,
Comments in-line,
>
> Hi Lucas
>
> The context is around the topic of HWKALERTS-49 - being able to replicate
> the
> RTGov 'situation' functionality using alerts. I think the main part missing
> at the moment is being able to associate the Alert with the business
> transaction information that caused it.
>
> I believe there are two scenarios that may occur, where business
> transaction
> data may result in an Alert:
>
> (1) metrics derived from the business transaction data are applied to the
> alert engine resulting in an alert - the persisted Alert will need to
> contain some link back to the business transaction. Metrics has their 'tag'
> name/value pair, which I believe could be used to store this info when the
> metric is created - so just need a way to carry that over into the alert.
>
> (2) other 'events' - so for example, if we identify some situation of
> interest (a service failure), we create an object representing that
> situation and send it to the alerts engine - again the originating business
> transaction id would need to be carried across via the intermediate
> 'service
> failure' object.
>
> Is it possible this could be handled by the work you are doing on
> HALERT-57?
>
In HWKALERTS-57 we are improving the Action model to pass the Alert that was
linked and also the Alert should have information about the definition who
triggered it.
So, having an action, you will have the alert and the definition data.
If the business transaction info is "mapped" into the definition, the action
will have it.
These requeriments were addressed by plugins but as we are still working on
it, we can join other requeriments in the same context to improve it.
How do you plan to map the BTM info into the definition ? using Tags ?
That can help me to add/modify some aspect of the present work.
Thanks,
Lucas
> Regards
> Gary
>
> ----- Original Message -----
> > Perhaps a rename to "Label" can be valid.
> >
> > Gary, is there some place where I can find more details about the context
> > ?
> >
> > (Just to understand the whole scenario and see if what can be
> > needed/interesting).
> >
> > Thanks,
> > Lucas
> >
> > ----- Original Message -----
> > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > To: "Discussions around Hawkular development"
> > > <hawkular-dev(a)lists.jboss.org>
> > > Sent: Wednesday, June 24, 2015 12:43:56 PM
> > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
> > >
> > > +1
> > >
> > > I don't mind if we adopt Tag as being name/value pair - but then we
> > > should
> > > use the same approach in Alerts. I actually need the Alert to have
> > > ability
> > > to record name/value pairs so this would suit my need, but they would
> > > then
> > > they would need to change their current Tag to be something else,
> > > possibly
> > > Label?
> > >
> > > Regards
> > > Gary
> > >
> > > ----- Original Message -----
> > > > Not using the same terminology as "industry standards" is a
problem,
> > > > not
> > > > using the same terminology within Hawkular small world is another...
> > > > Can we solve both ?
> > > >
> > > > Thomas
> > > >
> > > > On 06/24/2015 12:25 PM, Michael Burman wrote:
> > > > > Hi,
> > > > >
> > > > > I don't agree with changing the terms. Many of metrics
competing
> > > > > products
> > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so it
is
> > > > > easier
> > > > > for customers to understand the differences and similarities
> > > > > between
> > > > > products. Using different terminology was one of the
difficulties
> > > > > in
> > > > > RHQ
> > > > > (like noted in the F2F meeting) and I don't think we should
repeat
> > > > > the
> > > > > same mistake.
> > > > >
> > > > > - Micke
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > > > To: "Discussions around Hawkular development"
> > > > > <hawkular-dev(a)lists.jboss.org>
> > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM
> > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts
> > > > >
> > > > > Hi
> > > > >
> > > > > Both metrics and alerts use the term 'tag' - however
metrics use a
> > > > > name/value pair for a tag, and alerts uses it as a label.
Wondering
> > > > > whether we need consistency?
> > > > >
> > > > > When I hear the term tag, I usually envisage a label - e.g. as
in
> > > > > git.
> > > > > So
> > > > > wondering whether it would be clearer for metrics to rename tags
to
> > > > > properties?
> > > > >
> > > > > Possibly metrics needs the concept of a tag/label as well?
> > > > >
> > > > > Regards
> > > > > Gary
> > > > > _______________________________________________
> > > > > hawkular-dev mailing list
> > > > > hawkular-dev(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > > _______________________________________________
> > > > > hawkular-dev mailing list
> > > > > hawkular-dev(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > >
> > > >
> > > > _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:53 a.m.
Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
Hi Lucas
Not sure the alert or definition will be appropriate - assuming that the
definition is a static representation of the trigger?
The information (business transaction id) I am referring to is per business
transaction instance - i.e. it is unique for each invocation of a business
transaction. So this can only be obtained from the information being
evaluated by the trigger.
Let me know if I have misunderstand what you meant as definition.
No, I think you were right.
Then the BT id is mapped into the data being processed by the engine.
So, then I guess that BT id should be mapped just in the data that alerts use as input for
processing.
The Alert model stores this info by default. Each alert has a list of the evaluations
(conditions definitions + specific data responsible of the trigger).
Then perhaps I understand that you need to code the BT info into the incoming data, right
?
Regards
Gary
----- Original Message -----
> Thx Gary,
>
> Comments in-line,
>
> >
> > Hi Lucas
> >
> > The context is around the topic of HWKALERTS-49 - being able to replicate
> > the
> > RTGov 'situation' functionality using alerts. I think the main part
> > missing
> > at the moment is being able to associate the Alert with the business
> > transaction information that caused it.
> >
> > I believe there are two scenarios that may occur, where business
> > transaction
> > data may result in an Alert:
> >
> > (1) metrics derived from the business transaction data are applied to the
> > alert engine resulting in an alert - the persisted Alert will need to
> > contain some link back to the business transaction. Metrics has their
> > 'tag'
> > name/value pair, which I believe could be used to store this info when
> > the
> > metric is created - so just need a way to carry that over into the alert.
> >
> > (2) other 'events' - so for example, if we identify some situation of
> > interest (a service failure), we create an object representing that
> > situation and send it to the alerts engine - again the originating
> > business
> > transaction id would need to be carried across via the intermediate
> > 'service
> > failure' object.
> >
> > Is it possible this could be handled by the work you are doing on
> > HALERT-57?
> >
>
> In HWKALERTS-57 we are improving the Action model to pass the Alert that
> was
> linked and also the Alert should have information about the definition who
> triggered it.
>
> So, having an action, you will have the alert and the definition data.
>
> If the business transaction info is "mapped" into the definition, the
> action
> will have it.
>
> These requeriments were addressed by plugins but as we are still working on
> it, we can join other requeriments in the same context to improve it.
>
> How do you plan to map the BTM info into the definition ? using Tags ?
>
> That can help me to add/modify some aspect of the present work.
>
> Thanks,
> Lucas
>
>
> > Regards
> > Gary
> >
> > ----- Original Message -----
> > > Perhaps a rename to "Label" can be valid.
> > >
> > > Gary, is there some place where I can find more details about the
> > > context
> > > ?
> > >
> > > (Just to understand the whole scenario and see if what can be
> > > needed/interesting).
> > >
> > > Thanks,
> > > Lucas
> > >
> > > ----- Original Message -----
> > > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > > To: "Discussions around Hawkular development"
> > > > <hawkular-dev(a)lists.jboss.org>
> > > > Sent: Wednesday, June 24, 2015 12:43:56 PM
> > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
> > > >
> > > > +1
> > > >
> > > > I don't mind if we adopt Tag as being name/value pair - but then
we
> > > > should
> > > > use the same approach in Alerts. I actually need the Alert to have
> > > > ability
> > > > to record name/value pairs so this would suit my need, but they
would
> > > > then
> > > > they would need to change their current Tag to be something else,
> > > > possibly
> > > > Label?
> > > >
> > > > Regards
> > > > Gary
> > > >
> > > > ----- Original Message -----
> > > > > Not using the same terminology as "industry standards"
is a
> > > > > problem,
> > > > > not
> > > > > using the same terminology within Hawkular small world is
> > > > > another...
> > > > > Can we solve both ?
> > > > >
> > > > > Thomas
> > > > >
> > > > > On 06/24/2015 12:25 PM, Michael Burman wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I don't agree with changing the terms. Many of metrics
competing
> > > > > > products
> > > > > > (such as InfluxDB / OpenTSDB) use the same terminology, so
it is
> > > > > > easier
> > > > > > for customers to understand the differences and
similarities
> > > > > > between
> > > > > > products. Using different terminology was one of the
difficulties
> > > > > > in
> > > > > > RHQ
> > > > > > (like noted in the F2F meeting) and I don't think we
should
> > > > > > repeat
> > > > > > the
> > > > > > same mistake.
> > > > > >
> > > > > > - Micke
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > > > > To: "Discussions around Hawkular development"
> > > > > > <hawkular-dev(a)lists.jboss.org>
> > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM
> > > > > > Subject: [Hawkular-dev] Tag concept in metrics and alerts
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > Both metrics and alerts use the term 'tag' -
however metrics use
> > > > > > a
> > > > > > name/value pair for a tag, and alerts uses it as a label.
> > > > > > Wondering
> > > > > > whether we need consistency?
> > > > > >
> > > > > > When I hear the term tag, I usually envisage a label - e.g.
as in
> > > > > > git.
> > > > > > So
> > > > > > wondering whether it would be clearer for metrics to rename
tags
> > > > > > to
> > > > > > properties?
> > > > > >
> > > > > > Possibly metrics needs the concept of a tag/label as well?
> > > > > >
> > > > > > Regards
> > > > > > Gary
> > > > > > _______________________________________________
> > > > > > hawkular-dev mailing list
> > > > > > hawkular-dev(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > > > _______________________________________________
> > > > > > hawkular-dev mailing list
> > > > > > hawkular-dev(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > hawkular-dev mailing list
> > > > > hawkular-dev(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > >
> > > > _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:51 a.m.
----- Original Message -----
> Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
>
> Hi Lucas
>
> Not sure the alert or definition will be appropriate - assuming that the
> definition is a static representation of the trigger?
>
> The information (business transaction id) I am referring to is per business
> transaction instance - i.e. it is unique for each invocation of a business
> transaction. So this can only be obtained from the information being
> evaluated by the trigger.
>
> Let me know if I have misunderstand what you meant as definition.
>
No, I think you were right.
Then the BT id is mapped into the data being processed by the engine.
So, then I guess that BT id should be mapped just in the data that alerts use
as input for processing.
The Alert model stores this info by default. Each alert has a list of the
evaluations (conditions definitions + specific data responsible of the
trigger).
Then perhaps I understand that you need to code the BT info into the incoming
data, right ?
Yes that is correct.
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?
Regards
Gary
> Regards
> Gary
>
> ----- Original Message -----
> > Thx Gary,
> >
> > Comments in-line,
> >
> > >
> > > Hi Lucas
> > >
> > > The context is around the topic of HWKALERTS-49 - being able to
> > > replicate
> > > the
> > > RTGov 'situation' functionality using alerts. I think the main
part
> > > missing
> > > at the moment is being able to associate the Alert with the business
> > > transaction information that caused it.
> > >
> > > I believe there are two scenarios that may occur, where business
> > > transaction
> > > data may result in an Alert:
> > >
> > > (1) metrics derived from the business transaction data are applied to
> > > the
> > > alert engine resulting in an alert - the persisted Alert will need to
> > > contain some link back to the business transaction. Metrics has their
> > > 'tag'
> > > name/value pair, which I believe could be used to store this info when
> > > the
> > > metric is created - so just need a way to carry that over into the
> > > alert.
> > >
> > > (2) other 'events' - so for example, if we identify some situation
of
> > > interest (a service failure), we create an object representing that
> > > situation and send it to the alerts engine - again the originating
> > > business
> > > transaction id would need to be carried across via the intermediate
> > > 'service
> > > failure' object.
> > >
> > > Is it possible this could be handled by the work you are doing on
> > > HALERT-57?
> > >
> >
> > In HWKALERTS-57 we are improving the Action model to pass the Alert that
> > was
> > linked and also the Alert should have information about the definition
> > who
> > triggered it.
> >
> > So, having an action, you will have the alert and the definition data.
> >
> > If the business transaction info is "mapped" into the definition,
the
> > action
> > will have it.
> >
> > These requeriments were addressed by plugins but as we are still working
> > on
> > it, we can join other requeriments in the same context to improve it.
> >
> > How do you plan to map the BTM info into the definition ? using Tags ?
> >
> > That can help me to add/modify some aspect of the present work.
> >
> > Thanks,
> > Lucas
> >
> >
> > > Regards
> > > Gary
> > >
> > > ----- Original Message -----
> > > > Perhaps a rename to "Label" can be valid.
> > > >
> > > > Gary, is there some place where I can find more details about the
> > > > context
> > > > ?
> > > >
> > > > (Just to understand the whole scenario and see if what can be
> > > > needed/interesting).
> > > >
> > > > Thanks,
> > > > Lucas
> > > >
> > > > ----- Original Message -----
> > > > > From: "Gary Brown" <gbrown(a)redhat.com>
> > > > > To: "Discussions around Hawkular development"
> > > > > <hawkular-dev(a)lists.jboss.org>
> > > > > Sent: Wednesday, June 24, 2015 12:43:56 PM
> > > > > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
> > > > >
> > > > > +1
> > > > >
> > > > > I don't mind if we adopt Tag as being name/value pair - but
then we
> > > > > should
> > > > > use the same approach in Alerts. I actually need the Alert to
have
> > > > > ability
> > > > > to record name/value pairs so this would suit my need, but they
> > > > > would
> > > > > then
> > > > > they would need to change their current Tag to be something
else,
> > > > > possibly
> > > > > Label?
> > > > >
> > > > > Regards
> > > > > Gary
> > > > >
> > > > > ----- Original Message -----
> > > > > > Not using the same terminology as "industry
standards" is a
> > > > > > problem,
> > > > > > not
> > > > > > using the same terminology within Hawkular small world is
> > > > > > another...
> > > > > > Can we solve both ?
> > > > > >
> > > > > > Thomas
> > > > > >
> > > > > > On 06/24/2015 12:25 PM, Michael Burman wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I don't agree with changing the terms. Many of
metrics
> > > > > > > competing
> > > > > > > products
> > > > > > > (such as InfluxDB / OpenTSDB) use the same
terminology, so it
> > > > > > > is
> > > > > > > easier
> > > > > > > for customers to understand the differences and
similarities
> > > > > > > between
> > > > > > > products. Using different terminology was one of the
> > > > > > > difficulties
> > > > > > > in
> > > > > > > RHQ
> > > > > > > (like noted in the F2F meeting) and I don't think
we should
> > > > > > > repeat
> > > > > > > the
> > > > > > > same mistake.
> > > > > > >
> > > > > > > - Micke
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Gary Brown"
<gbrown(a)redhat.com>
> > > > > > > To: "Discussions around Hawkular
development"
> > > > > > > <hawkular-dev(a)lists.jboss.org>
> > > > > > > Sent: Wednesday, June 24, 2015 11:45:56 AM
> > > > > > > Subject: [Hawkular-dev] Tag concept in metrics and
alerts
> > > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > Both metrics and alerts use the term 'tag' -
however metrics
> > > > > > > use
> > > > > > > a
> > > > > > > name/value pair for a tag, and alerts uses it as a
label.
> > > > > > > Wondering
> > > > > > > whether we need consistency?
> > > > > > >
> > > > > > > When I hear the term tag, I usually envisage a label -
e.g. as
> > > > > > > in
> > > > > > > git.
> > > > > > > So
> > > > > > > wondering whether it would be clearer for metrics to
rename
> > > > > > > tags
> > > > > > > to
> > > > > > > properties?
> > > > > > >
> > > > > > > Possibly metrics needs the concept of a tag/label as
well?
> > > > > > >
> > > > > > > Regards
> > > > > > > Gary
> > > > > > > _______________________________________________
> > > > > > > hawkular-dev mailing list
> > > > > > > hawkular-dev(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > > > > _______________________________________________
> > > > > > > hawkular-dev mailing list
> > > > > > > hawkular-dev(a)lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > hawkular-dev mailing list
> > > > > > hawkular-dev(a)lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > > >
> > > > > _______________________________________________
> > > > > hawkular-dev mailing list
> > > > > hawkular-dev(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > > >
> > > > _______________________________________________
> > > > hawkular-dev mailing list
> > > > hawkular-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > > >
> > > _______________________________________________
> > > hawkular-dev mailing list
> > > hawkular-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:05 a.m.
----- Original Message -----
> > Subject: Re: [Hawkular-dev] Tag concept in metrics and alerts
> >
> > Hi Lucas
> >
> > Not sure the alert or definition will be appropriate - assuming that the
> > definition is a static representation of the trigger?
> >
> > The information (business transaction id) I am referring to is per
> > business
> > transaction instance - i.e. it is unique for each invocation of a
> > business
> > transaction. So this can only be obtained from the information being
> > evaluated by the trigger.
> >
> > Let me know if I have misunderstand what you meant as definition.
> >
>
> No, I think you were right.
>
> Then the BT id is mapped into the data being processed by the engine.
>
> So, then I guess that BT id should be mapped just in the data that alerts
> use
> as input for processing.
>
> The Alert model stores this info by default. Each alert has a list of the
> evaluations (conditions definitions + specific data responsible of the
> trigger).
>
> Then perhaps I understand that you need to code the BT info into the
> incoming
> data, right ?
Yes that is correct.
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-a...
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.
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 ?
- ¿ Or perhaps you have a more complex incoming data ?
Can you ellaborate an example ?
Thanks,
Lucas
Regards
Gary
8:13 a.m.
----- 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-a...
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
9:33 a.m.
On 6/24/2015 9:13 AM, Gary Brown wrote:
----- Original Message -----
> In alert context, the incoming data should match
> org.hawkular.alerts.api.model.data
>
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-a...
> 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?
As you mentioned earlier, Tags are labels that can be attached ad-hoc to
Trigger definitions. They can then be used to filter queries, like,
"give me all of the unresolved alerts for triggers labeled XYZ". That
mechanism is for use by the clients, to be used in their own way.
When a trigger fires an alert it does so based on one or more sets of
true condition evaluations. One evaluation per condition on the
trigger. One set of condition evaluations for each repetition of the
conditions, based on dampening. By default, just one set of conditions
because with default dampening a trigger fires as soon as the conditions
match. Those evaluations are performed on data coming in. An alert
stores with it all of the evaluations and makes that available to the
actions (notifiers). In 0.2.0 it is only a toString of the
information. But in 0.3.0 it will be a json representation.
Every datum has a dataId and some sort of value information. This is
likely where you would get your Tx Ids, and yes, it is captured and made
available. So perhaps this is what you are looking for.
> 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,
So the issue we may have here is that it seems you may want some
supplemental contextual info on the data being sent in. If I understand
the above, you would likely define a Threshold condition. The dataId
(like a metricId, is known in advance, say "latencyMetric". The value
is the Double, and would be the actual latency. But you also have
runtimeInfo, the BTID, not known in advance, but something you want to
store with the datum. Is that correct?
So, perhaps an optional free-format string that could be supplied?
I have another question, would it make any sense for the threshold
matching to be performed completely outside of Alerts? Meaning, let BTM
determine if there is a situation completely on its own, and then just
hook into alerting for the use of trigger dampening, life cycle, action
invocations, etc? This is basically the ExternalCondition hooks I'm
currently working on. It allows an external system to basically do the
condition evaluation, in any way it sees fit. The data sent to alerts
is assumed to already describe a "true" evaluation.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:54 a.m.
----- Original Message -----
On 6/24/2015 9:13 AM, Gary Brown wrote:
>
> ----- Original Message -----
>> In alert context, the incoming data should match
>> org.hawkular.alerts.api.model.data
>>
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-a...
>> 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?
As you mentioned earlier, Tags are labels that can be attached ad-hoc to
Trigger definitions. They can then be used to filter queries, like,
"give me all of the unresolved alerts for triggers labeled XYZ". That
mechanism is for use by the clients, to be used in their own way.
Yes, this is where the use of 'tag' in alerts and metrics differs, so might be
good if Tag in Alerts could be renamed Label.
When a trigger fires an alert it does so based on one or more sets of
true condition evaluations. One evaluation per condition on the
trigger. One set of condition evaluations for each repetition of the
conditions, based on dampening. By default, just one set of conditions
because with default dampening a trigger fires as soon as the conditions
match. Those evaluations are performed on data coming in. An alert
stores with it all of the evaluations and makes that available to the
actions (notifiers). In 0.2.0 it is only a toString of the
information. But in 0.3.0 it will be a json representation.
Every datum has a dataId and some sort of value information. This is
likely where you would get your Tx Ids, and yes, it is captured and made
available. So perhaps this is what you are looking for.
Yes its possible - I need to try out the integration with metrics and alerts soon to make
sure.
>
>> 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,
So the issue we may have here is that it seems you may want some
supplemental contextual info on the data being sent in. If I understand
the above, you would likely define a Threshold condition. The dataId
(like a metricId, is known in advance, say "latencyMetric". The value
is the Double, and would be the actual latency. But you also have
runtimeInfo, the BTID, not known in advance, but something you want to
store with the datum. Is that correct?
Yes that is correct.
So, perhaps an optional free-format string that could be supplied?
May be better if it was a map. Then the information from the 'tags' on metrics,
which are name/value pairs, could simply be copied over.
I have another question, would it make any sense for the threshold
matching to be performed completely outside of Alerts? Meaning, let BTM
determine if there is a situation completely on its own, and then just
hook into alerting for the use of trigger dampening, life cycle, action
invocations, etc? This is basically the ExternalCondition hooks I'm
currently working on. It allows an external system to basically do the
condition evaluation, in any way it sees fit. The data sent to alerts
is assumed to already describe a "true" evaluation.
This sounds like it might be useful for evaluating events.
Regards
Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:35 a.m.
On 06/24/2015 04:54 PM, Gary Brown wrote:
----- Original Message -----
>
>
> On 6/24/2015 9:13 AM, Gary Brown wrote:
>>
>> ----- Original Message -----
>>> In alert context, the incoming data should match
>>> org.hawkular.alerts.api.model.data
>>>
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-a...
>>> 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?
>
> As you mentioned earlier, Tags are labels that can be attached ad-hoc to
> Trigger definitions. They can then be used to filter queries, like,
> "give me all of the unresolved alerts for triggers labeled XYZ". That
> mechanism is for use by the clients, to be used in their own way.
Yes, this is where the use of 'tag' in alerts and metrics differs, so might be
good if Tag in Alerts could be renamed Label.
Do we need 1 word labelling at all or key/value pairs only ?
(BTW to make it more confusing OpenShift/Kubernetes use the term label
for key=value things)
Thomas
>
> When a trigger fires an alert it does so based on one or more sets of
> true condition evaluations. One evaluation per condition on the
> trigger. One set of condition evaluations for each repetition of the
> conditions, based on dampening. By default, just one set of conditions
> because with default dampening a trigger fires as soon as the conditions
> match. Those evaluations are performed on data coming in. An alert
> stores with it all of the evaluations and makes that available to the
> actions (notifiers). In 0.2.0 it is only a toString of the
> information. But in 0.3.0 it will be a json representation.
>
> Every datum has a dataId and some sort of value information. This is
> likely where you would get your Tx Ids, and yes, it is captured and made
> available. So perhaps this is what you are looking for.
>
Yes its possible - I need to try out the integration with metrics and alerts soon to make
sure.
>>
>>> 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,
>
> So the issue we may have here is that it seems you may want some
> supplemental contextual info on the data being sent in. If I understand
> the above, you would likely define a Threshold condition. The dataId
> (like a metricId, is known in advance, say "latencyMetric". The value
> is the Double, and would be the actual latency. But you also have
> runtimeInfo, the BTID, not known in advance, but something you want to
> store with the datum. Is that correct?
Yes that is correct.
>
> So, perhaps an optional free-format string that could be supplied?
>
May be better if it was a map. Then the information from the 'tags' on metrics,
which are name/value pairs, could simply be copied over.
> I have another question, would it make any sense for the threshold
> matching to be performed completely outside of Alerts? Meaning, let BTM
> determine if there is a situation completely on its own, and then just
> hook into alerting for the use of trigger dampening, life cycle, action
> invocations, etc? This is basically the ExternalCondition hooks I'm
> currently working on. It allows an external system to basically do the
> condition evaluation, in any way it sees fit. The data sent to alerts
> is assumed to already describe a "true" evaluation.
This sounds like it might be useful for evaluating events.
Regards
Gary
>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:21 p.m.
On 6/24/2015 11:35 AM, Thomas Heute wrote:
On 06/24/2015 04:54 PM, Gary Brown wrote:
>
> ----- Original Message -----
>>
>> On 6/24/2015 9:13 AM, Gary Brown wrote:
>>> ----- Original Message -----
>>>> In alert context, the incoming data should match
>>>> org.hawkular.alerts.api.model.data
>>>>
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-a...
>>>> 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?
>> As you mentioned earlier, Tags are labels that can be attached ad-hoc to
>> Trigger definitions. They can then be used to filter queries, like,
>> "give me all of the unresolved alerts for triggers labeled XYZ". That
>> mechanism is for use by the clients, to be used in their own way.
> Yes, this is where the use of 'tag' in alerts and metrics differs, so might
be good if Tag in Alerts could be renamed Label.
Do we need 1 word labelling at all or key/value pairs only ?
(BTW to make it more confusing OpenShift/Kubernetes use the term label
for key=value things)
Thomas
I don't really want to rename Tag to Label unless it's really confusing
people. Or until we have complete concensus over the terminology and
semantics. As it stands, ALerts' tags are not 1 word labels, but
actually allow for qualifying 'category', as well as the 'name'.
2:16 a.m.
Hi Jay
Thats fine, better to get consensus, as we don't want to have to rename again in the
future :)
Another alternative that I'd like to suggest, based on your mention of the optional
category, is to actually use Category, as it seems like that is how it is used (i.e. to
categorize alerts) ?
Regards
Gary
----- Original Message -----
On 6/24/2015 11:35 AM, Thomas Heute wrote:
>
> On 06/24/2015 04:54 PM, Gary Brown wrote:
>>
>> ----- Original Message -----
>>>
>>> On 6/24/2015 9:13 AM, Gary Brown wrote:
>>>> ----- Original Message -----
>>>>> In alert context, the incoming data should match
>>>>> org.hawkular.alerts.api.model.data
>>>>>
https://github.com/hawkular/hawkular-alerts/tree/master/hawkular-alerts-a...
>>>>> 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?
>>> As you mentioned earlier, Tags are labels that can be attached ad-hoc to
>>> Trigger definitions. They can then be used to filter queries, like,
>>> "give me all of the unresolved alerts for triggers labeled XYZ".
That
>>> mechanism is for use by the clients, to be used in their own way.
>> Yes, this is where the use of 'tag' in alerts and metrics differs, so
>> might be good if Tag in Alerts could be renamed Label.
> Do we need 1 word labelling at all or key/value pairs only ?
>
> (BTW to make it more confusing OpenShift/Kubernetes use the term label
> for key=value things)
>
> Thomas
I don't really want to rename Tag to Label unless it's really confusing
people. Or until we have complete concensus over the terminology and
semantics. As it stands, ALerts' tags are not 1 word labels, but
actually allow for qualifying 'category', as well as the 'name'.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:40 a.m.
Originally tags were implemented just as a label, not a key/value pair. I saw that a
number of other time series dbs use key/value pairs and decided to make the change. It can
also produce more efficient queries. For example, filtering against N labels would require
querying N partitions (in the original schema). Querying against one tag name with N
different values however would only require querying 1 partition.
On Jun 24, 2015, at 6:25 AM, Michael Burman
<miburman(a)redhat.com> wrote:
Hi,
I don't agree with changing the terms. Many of metrics competing products (such as
InfluxDB / OpenTSDB) use the same terminology, so it is easier for customers to understand
the differences and similarities between products. Using different terminology was one of
the difficulties in RHQ (like noted in the F2F meeting) and I don't think we should
repeat the same mistake.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, June 24, 2015 11:45:56 AM
Subject: [Hawkular-dev] Tag concept in metrics and alerts
Hi
Both metrics and alerts use the term 'tag' - however metrics use a name/value
pair for a tag, and alerts uses it as a label. Wondering whether we need consistency?
When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering
whether it would be clearer for metrics to rename tags to properties?
Possibly metrics needs the concept of a tag/label as well?
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:51 a.m.
Hi John
Thanks for the clarification - that fits with how I need to use metrics. So for example, I
may have btm_id=<some unique id for the transaction instance>, and possibly
service_type=<service associated with the metric>, operation=<op name> - so
assume they would all be ok?
Regards
Gary
----- Original Message -----
Originally tags were implemented just as a label, not a key/value
pair. I saw
that a number of other time series dbs use key/value pairs and decided to
make the change. It can also produce more efficient queries. For example,
filtering against N labels would require querying N partitions (in the
original schema). Querying against one tag name with N different values
however would only require querying 1 partition.
> On Jun 24, 2015, at 6:25 AM, Michael Burman <miburman(a)redhat.com> wrote:
>
> Hi,
>
> I don't agree with changing the terms. Many of metrics competing products
> (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier
> for customers to understand the differences and similarities between
> products. Using different terminology was one of the difficulties in RHQ
> (like noted in the F2F meeting) and I don't think we should repeat the
> same mistake.
>
> - Micke
>
> ----- Original Message -----
> From: "Gary Brown" <gbrown(a)redhat.com>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org>
> Sent: Wednesday, June 24, 2015 11:45:56 AM
> Subject: [Hawkular-dev] Tag concept in metrics and alerts
>
> Hi
>
> Both metrics and alerts use the term 'tag' - however metrics use a
> name/value pair for a tag, and alerts uses it as a label. Wondering
> whether we need consistency?
>
> When I hear the term tag, I usually envisage a label - e.g. as in git. So
> wondering whether it would be clearer for metrics to rename tags to
> properties?
>
> Possibly metrics needs the concept of a tag/label as well?
>
> Regards
> Gary
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:55 a.m.
This is exactly what we have in mind as well as wild cards, e.g., btm_id=<some unique
id for the transaction instance>, service_type=<service associated with metric>,
operation=*
On Jun 24, 2015, at 7:51 AM, Gary Brown <gbrown(a)redhat.com>
wrote:
Hi John
Thanks for the clarification - that fits with how I need to use metrics. So for example,
I may have btm_id=<some unique id for the transaction instance>, and possibly
service_type=<service associated with the metric>, operation=<op name> - so
assume they would all be ok?
Regards
Gary
----- Original Message -----
> Originally tags were implemented just as a label, not a key/value pair. I saw
> that a number of other time series dbs use key/value pairs and decided to
> make the change. It can also produce more efficient queries. For example,
> filtering against N labels would require querying N partitions (in the
> original schema). Querying against one tag name with N different values
> however would only require querying 1 partition.
>
>> On Jun 24, 2015, at 6:25 AM, Michael Burman <miburman(a)redhat.com> wrote:
>>
>> Hi,
>>
>> I don't agree with changing the terms. Many of metrics competing products
>> (such as InfluxDB / OpenTSDB) use the same terminology, so it is easier
>> for customers to understand the differences and similarities between
>> products. Using different terminology was one of the difficulties in RHQ
>> (like noted in the F2F meeting) and I don't think we should repeat the
>> same mistake.
>>
>> - Micke
>>
>> ----- Original Message -----
>> From: "Gary Brown" <gbrown(a)redhat.com>
>> To: "Discussions around Hawkular development"
>> <hawkular-dev(a)lists.jboss.org>
>> Sent: Wednesday, June 24, 2015 11:45:56 AM
>> Subject: [Hawkular-dev] Tag concept in metrics and alerts
>>
>> Hi
>>
>> Both metrics and alerts use the term 'tag' - however metrics use a
>> name/value pair for a tag, and alerts uses it as a label. Wondering
>> whether we need consistency?
>>
>> When I hear the term tag, I usually envisage a label - e.g. as in git. So
>> wondering whether it would be clearer for metrics to rename tags to
>> properties?
>>
>> Possibly metrics needs the concept of a tag/label as well?
>>
>> Regards
>> Gary
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3910
days inactive
3911
days old
20 comments
6 participants
participants (6)
-
Gary Brown -
Jay Shaughnessy -
John Sanda -
Lucas Ponce -
Michael Burman -
Thomas Heute