10:01 a.m.
Hi
I would like to discuss how best to define the concept of an Application within the BTM
project, how it relates to the existing concept of a "Business Transaction" and
how it may link in with the concept of an application in Hawkular/ManageIQ in general.
Firstly, for those not familiar with Hawkular BTM, without configuration the project can
capture and trace an invocation across multiple interconnected services. The information
can be used to provide stats on the individual components used (endpoints, databases,
ejbs, etc) as well as (in the next version) present a graph showing the relationships
between the communicating services.
The project also enables "Business Transactions" to be configured - this enables
a particular invocation of an endpoint to be labelled with a business transaction name
(which is propagated to the fragments associated with the invoked services), and also
perform additional processing on the messages, such as extract business properties, etc.
Once a "Business Transaction" has been defined, it is possible to view high
level stats about the complete "end to end" business transactions.
This is achieved by creating a configuration that identifies the initial endpoint for the
business transaction, using a regular expression, and then a set of 'processors'
that are used to perform various processing tasks within the scope of that business
transaction.
We now have a requirement to identify the concept of an Application, and be able to
present various stats about it. I believe that the Application can be viewed as orthogonal
to the Business Transaction concept - so an Application represents the various operations
that can be performed on a particular architectural component, whereas the Business
Transaction represents a particular path through multiple Applications/Services, only
using a subset of the operations/endpoints supported by the Application.
However the requirements are very similar - when we detect some activity on a particular
endpoint we want to determine if it belongs to an Application, in the same way as we
currently do with Business Transactions. And similarly, once classified as being
associated with an Application, we may want to do some application specific processing on
the data.
Therefore what I am considering is making the existing Business Transaction Configuration
generic so that it is suitable for both tasks, with a simple classifier to indicate
whether it relates to a Business Transaction or Application.
This will mean that the fragments of activity being recorded and sent to the BTM server
could now potentially have two names, one for the business transaction (which is
propagated across application/service boundaries) and one for an application name (which
is not propagated).
Where appropriate, the UI could then be updated to allow the user to also filter
information based on application - this may only make sense on the APM page, but could be
considered if useful elsewhere. We may also want to make the current Business Transaction
overview page more general to include both Business Transactions and Applications, and
then have a different type of details page for applications.
The final point is how this may link into Hawkular/ManageIQ. Was thinking that where
possible, it would be good if a deployment event could be used to trigger the
configuration of the Application in Hawkular BTM - especially if it is possible to obtain
the web context for the application (or JMS queue/topic), which can then be used to
establish the regular expression. If this level of integration was possible, then no user
defined configuration would be necessary to capture application information using the same
name as in Hawkular - allowing an integrated view of the information to be made
available.
Thoughts?
Regards
Gary
6:20 a.m.
On Wed, May 11, 2016 at 5:01 PM, Gary Brown <gbrown(a)redhat.com> wrote:
Hi
I would like to discuss how best to define the concept of an Application
within the BTM project, how it relates to the existing concept of a
"Business Transaction" and how it may link in with the concept of an
application in Hawkular/ManageIQ in general.
Firstly, for those not familiar with Hawkular BTM, without configuration
the project can capture and trace an invocation across multiple
interconnected services. The information can be used to provide stats on
the individual components used (endpoints, databases, ejbs, etc) as well as
(in the next version) present a graph showing the relationships between the
communicating services.
The project also enables "Business Transactions" to be configured - this
enables a particular invocation of an endpoint to be labelled with a
business transaction name (which is propagated to the fragments associated
with the invoked services), and also perform additional processing on the
messages, such as extract business properties, etc. Once a "Business
Transaction" has been defined, it is possible to view high level stats
about the complete "end to end" business transactions.
This is achieved by creating a configuration that identifies the initial
endpoint for the business transaction, using a regular expression, and then
a set of 'processors' that are used to perform various processing tasks
within the scope of that business transaction.
We now have a requirement to identify the concept of an Application, and
be able to present various stats about it. I believe that the Application
can be viewed as orthogonal to the Business Transaction concept - so an
Application represents the various operations that can be performed on a
particular architectural component, whereas the Business Transaction
represents a particular path through multiple Applications/Services, only
using a subset of the operations/endpoints supported by the Application.
I quite agree here, except that I would map an application to *several*
achitectural components (for instance N microservices).
Now if you have 2 logical applications (say e-commerce and brand website),
a same architecture component may be shared (say user registration) in the
2 apps.
However the requirements are very similar - when we detect some activity
on a particular endpoint we want to determine if it belongs to an
Application, in the same way as we currently do with Business Transactions.
And similarly, once classified as being associated with an Application, we
may want to do some application specific processing on the data.
So here if an activity on a user registration endpoint is recorded, would
it record for each segment with app it referred to ?
Therefore what I am considering is making the existing Business
Transaction Configuration generic so that it is suitable for both tasks,
with a simple classifier to indicate whether it relates to a Business
Transaction or Application.
This will mean that the fragments of activity being recorded and sent to
the BTM server could now potentially have two names, one for the business
transaction (which is propagated across application/service boundaries) and
one for an application name (which is not propagated).
Where appropriate, the UI could then be updated to allow the user to also
filter information based on application - this may only make sense on the
APM page, but could be considered if useful elsewhere. We may also want to
make the current Business Transaction overview page more general to include
both Business Transactions and Applications, and then have a different type
of details page for applications.
The final point is how this may link into Hawkular/ManageIQ. Was thinking
that where possible, it would be good if a deployment event could be used
to trigger the configuration of the Application in Hawkular BTM -
especially if it is possible to obtain the web context for the application
(or JMS queue/topic), which can then be used to establish the regular
expression. If this level of integration was possible, then no user defined
configuration would be necessary to capture application information using
the same name as in Hawkular - allowing an integrated view of the
information to be made available.
Thoughts?
In general from the very high level view (ManageIQ), I would want to be
able to define a logical notion of "application" for monitoring purposes,
I would expect to be able to add "entities" to that logical view. It may
just be a war file (and in the case of BTM, I would likely be interested by
all entry points to that application) or it could be an "OpenShift Project"
with all its dependencies (all docker containers + everything in it), or it
could be a selection of MW servers...
In the end, the user should be able to dig into infrastructure details (and
he already has that, he can see details about the infrastructure: a
container, a host, a MW server (coming soon), a MW deployment (coming
soon)...) + details on Business transactions but also have that synthetic
view where he knows that all services that makes his online store are
running fine, and have a few KPI such as the Apdex for all user-facing
interactions, the N slowest URLs or DB requests...
(This definitely goes beyond BTM, and we likely need to simplify and work
on iterations of those ideas (or better ideas))
That's what I dream of, as a user.
Thomas
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:47 a.m.
New subject: Definition the concept of Application in Hawkular BTM
Hi Thomas
I think possibly there are different concepts here, so I need to clarify - the one I was
trying to describe is to capture the individual services, which may be user facing, and
would essentially map onto the individual services (in a micro-services world).
So possibly rather than application, it should be termed "service"? which would
actually match the microservices world better anyway.
This service concept, especially in the case of user facing endpoints, would be used to
derive stats like Apdex - although the same stats could be defined for internal services
as well, to provide the dev teams behind those services with a satisfaction index for
their consumers.
I think the highlevel communication diagram provided in the Distributed Tracing UI page
could act as the basis for understanding which 'services' and resources (if we dig
further to understand databases, etc used) are used to deliver the total
'application'.
Having an understanding of the separate 'services' and potentially the resources
they used, could then enable ManageIQ to build the logical grouping that you mention, out
of those services? So to be clear, BTM could provide a highlevel understanding of the
services and their communication paths (and possibly resources used), and ManageIQ could
use this information to selectively (or as a complete set of interrelated services)
present the user with a logical group consisting of those managed objects.
So here if an activity on a user registration endpoint is recorded,
would it
record for each segment with app it referred to ?
Wasn't sure what you meant here, if you could give an example?
Regards
Gary
----- Original Message -----
>
>
> On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown(a)redhat.com > wrote:
>
>
> Hi
>
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
>
> Firstly, for those not familiar with Hawkular BTM, without configuration the
> project can capture and trace an invocation across multiple interconnected
> services. The information can be used to provide stats on the individual
> components used (endpoints, databases, ejbs, etc) as well as (in the next
> version) present a graph showing the relationships between the communicating
> services.
>
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats about
> the complete "end to end" business transactions.
>
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
>
> We now have a requirement to identify the concept of an Application, and be
> able to present various stats about it. I believe that the Application can
> be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
>
>
> I quite agree here, except that I would map an application to *several*
> achitectural components (for instance N microservices).
> Now if you have 2 logical applications (say e-commerce and brand website), a
> same architecture component may be shared (say user registration) in the 2
> apps.
>
>
>
> However the requirements are very similar - when we detect some activity on a
> particular endpoint we want to determine if it belongs to an Application, in
> the same way as we currently do with Business Transactions. And similarly,
> once classified as being associated with an Application, we may want to do
> some application specific processing on the data.
>
So here if an activity on a user registration endpoint is recorded,
would it
record for each segment with app it referred to ?
>
>
> Therefore what I am considering is making the existing Business Transaction
> Configuration generic so that it is suitable for both tasks, with a simple
> classifier to indicate whether it relates to a Business Transaction or
> Application.
>
> This will mean that the fragments of activity being recorded and sent to the
> BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
>
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used to
> trigger the configuration of the Application in Hawkular BTM - especially if
> it is possible to obtain the web context for the application (or JMS
> queue/topic), which can then be used to establish the regular expression. If
> this level of integration was possible, then no user defined configuration
> would be necessary to capture application information using the same name as
> in Hawkular - allowing an integrated view of the information to be made
> available.
>
> Thoughts?
>
> In general from the very high level view (ManageIQ), I would want to be able
> to define a logical notion of "application" for monitoring purposes, I
would
> expect to be able to add "entities" to that logical view. It may just be a
> war file (and in the case of BTM, I would likely be interested by all entry
> points to that application) or it could be an "OpenShift Project" with all
> its dependencies (all docker containers + everything in it), or it could be
> a selection of MW servers...
>
> In the end, the user should be able to dig into infrastructure details (and
> he already has that, he can see details about the infrastructure: a
> container, a host, a MW server (coming soon), a MW deployment (coming
> soon)...) + details on Business transactions but also have that synthetic
> view where he knows that all services that makes his online store are
> running fine, and have a few KPI such as the Apdex for all user-facing
> interactions, the N slowest URLs or DB requests...
>
> (This definitely goes beyond BTM, and we likely need to simplify and work on
> iterations of those ideas (or better ideas))
>
> That's what I dream of, as a user.
>
> Thomas
>
>
>
>
> 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
>
9:23 a.m.
Hello,
What was described in the original email sounded to me like tagging. A
transaction fragment stored in BTM could be tagged with an arbitrarily
number of tags. Here is an example { application: myapp, service:
superservice, datacenter: east}. And then the API needs to allow users to
query data based on tags and query the actual tag values.
So rather than expanding the design to cover just one other single concept
(application) the design with tags is generic and flexible.
Thank you,
Stefan Negrea
Software Engineer
On Thu, May 12, 2016 at 7:47 AM, Gary Brown <gbrown(a)redhat.com> wrote:
Hi Thomas
I think possibly there are different concepts here, so I need to clarify -
the one I was trying to describe is to capture the individual services,
which may be user facing, and would essentially map onto the individual
services (in a micro-services world).
So possibly rather than application, it should be termed "service"? which
would actually match the microservices world better anyway.
This service concept, especially in the case of user facing endpoints,
would be used to derive stats like Apdex - although the same stats could be
defined for internal services as well, to provide the dev teams behind
those services with a satisfaction index for their consumers.
I think the highlevel communication diagram provided in the Distributed
Tracing UI page could act as the basis for understanding which 'services'
and resources (if we dig further to understand databases, etc used) are
used to deliver the total 'application'.
Having an understanding of the separate 'services' and potentially the
resources they used, could then enable ManageIQ to build the logical
grouping that you mention, out of those services? So to be clear, BTM could
provide a highlevel understanding of the services and their communication
paths (and possibly resources used), and ManageIQ could use this
information to selectively (or as a complete set of interrelated services)
present the user with a logical group consisting of those managed objects.
> So here if an activity on a user registration endpoint is recorded,
would it
> record for each segment with app it referred to ?
>
Wasn't sure what you meant here, if you could give an example?
Regards
Gary
----- Original Message -----
>
>
> On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown(a)redhat.com > wrote:
>
>
> Hi
>
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
>
> Firstly, for those not familiar with Hawkular BTM, without configuration
the
> project can capture and trace an invocation across multiple
interconnected
> services. The information can be used to provide stats on the individual
> components used (endpoints, databases, ejbs, etc) as well as (in the next
> version) present a graph showing the relationships between the
communicating
> services.
>
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments
associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats
about
> the complete "end to end" business transactions.
>
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and
then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
>
> We now have a requirement to identify the concept of an Application, and
be
> able to present various stats about it. I believe that the Application
can
> be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
>
>
> I quite agree here, except that I would map an application to *several*
> achitectural components (for instance N microservices).
> Now if you have 2 logical applications (say e-commerce and brand
website), a
> same architecture component may be shared (say user registration) in the
2
> apps.
>
>
>
> However the requirements are very similar - when we detect some activity
on a
> particular endpoint we want to determine if it belongs to an
Application, in
> the same way as we currently do with Business Transactions. And
similarly,
> once classified as being associated with an Application, we may want to
do
> some application specific processing on the data.
>
> So here if an activity on a user registration endpoint is recorded,
would it
> record for each segment with app it referred to ?
>
>
>
> Therefore what I am considering is making the existing Business
Transaction
> Configuration generic so that it is suitable for both tasks, with a
simple
> classifier to indicate whether it relates to a Business Transaction or
> Application.
>
> This will mean that the fragments of activity being recorded and sent to
the
> BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries)
and
> one for an application name (which is not propagated).
>
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want
to
> make the current Business Transaction overview page more general to
include
> both Business Transactions and Applications, and then have a different
type
> of details page for applications.
>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be
used to
> trigger the configuration of the Application in Hawkular BTM -
especially if
> it is possible to obtain the web context for the application (or JMS
> queue/topic), which can then be used to establish the regular
expression. If
> this level of integration was possible, then no user defined
configuration
> would be necessary to capture application information using the same
name as
> in Hawkular - allowing an integrated view of the information to be made
> available.
>
> Thoughts?
>
> In general from the very high level view (ManageIQ), I would want to be
able
> to define a logical notion of "application" for monitoring purposes, I
would
> expect to be able to add "entities" to that logical view. It may just be
a
> war file (and in the case of BTM, I would likely be interested by all
entry
> points to that application) or it could be an "OpenShift Project" with
all
> its dependencies (all docker containers + everything in it), or it could
be
> a selection of MW servers...
>
> In the end, the user should be able to dig into infrastructure details
(and
> he already has that, he can see details about the infrastructure: a
> container, a host, a MW server (coming soon), a MW deployment (coming
> soon)...) + details on Business transactions but also have that synthetic
> view where he knows that all services that makes his online store are
> running fine, and have a few KPI such as the Apdex for all user-facing
> interactions, the N slowest URLs or DB requests...
>
> (This definitely goes beyond BTM, and we likely need to simplify and
work on
> iterations of those ideas (or better ideas))
>
> That's what I dream of, as a user.
>
> Thomas
>
>
>
>
> 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
9:37 a.m.
New subject: Definition the concept of Application in Hawkular BTM
Hi Stefan
Yes that would be possible with the current approach, although the concept of
'service' has a specific benefit as being a first class citizen, in that it can
name a node in the communication diagram, and where the 'service' is implemented
using multiple concurrent threads, then it can also glue together those fragments - but
only because it will have special meaning.
But apart from that, having the ability for the user/administrator to tag the fragments
with concepts that they are interested in, and then query on them (whether on the basis of
being part of a service or business transaction or neither or both) would be possible.
Regards
Gary
----- Original Message -----
Hello,
What was described in the original email sounded to me like tagging. A
transaction fragment stored in BTM could be tagged with an arbitrarily
number of tags. Here is an example { application: myapp, service:
superservice, datacenter: east}. And then the API needs to allow users to
query data based on tags and query the actual tag values.
So rather than expanding the design to cover just one other single concept
(application) the design with tags is generic and flexible.
Thank you,
Stefan Negrea
Software Engineer
On Thu, May 12, 2016 at 7:47 AM, Gary Brown < gbrown(a)redhat.com > wrote:
Hi Thomas
I think possibly there are different concepts here, so I need to clarify -
the one I was trying to describe is to capture the individual services,
which may be user facing, and would essentially map onto the individual
services (in a micro-services world).
So possibly rather than application, it should be termed "service"? which
would actually match the microservices world better anyway.
This service concept, especially in the case of user facing endpoints, would
be used to derive stats like Apdex - although the same stats could be
defined for internal services as well, to provide the dev teams behind those
services with a satisfaction index for their consumers.
I think the highlevel communication diagram provided in the Distributed
Tracing UI page could act as the basis for understanding which 'services'
and resources (if we dig further to understand databases, etc used) are used
to deliver the total 'application'.
Having an understanding of the separate 'services' and potentially the
resources they used, could then enable ManageIQ to build the logical
grouping that you mention, out of those services? So to be clear, BTM could
provide a highlevel understanding of the services and their communication
paths (and possibly resources used), and ManageIQ could use this information
to selectively (or as a complete set of interrelated services) present the
user with a logical group consisting of those managed objects.
> So here if an activity on a user registration endpoint is recorded, would
> it
> record for each segment with app it referred to ?
>
Wasn't sure what you meant here, if you could give an example?
Regards
Gary
----- Original Message -----
>
>
> On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown(a)redhat.com > wrote:
>
>
> Hi
>
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
>
> Firstly, for those not familiar with Hawkular BTM, without configuration
> the
> project can capture and trace an invocation across multiple interconnected
> services. The information can be used to provide stats on the individual
> components used (endpoints, databases, ejbs, etc) as well as (in the next
> version) present a graph showing the relationships between the
> communicating
> services.
>
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats
> about
> the complete "end to end" business transactions.
>
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
>
> We now have a requirement to identify the concept of an Application, and be
> able to present various stats about it. I believe that the Application can
> be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
>
>
> I quite agree here, except that I would map an application to *several*
> achitectural components (for instance N microservices).
> Now if you have 2 logical applications (say e-commerce and brand website),
> a
> same architecture component may be shared (say user registration) in the 2
> apps.
>
>
>
> However the requirements are very similar - when we detect some activity on
> a
> particular endpoint we want to determine if it belongs to an Application,
> in
> the same way as we currently do with Business Transactions. And similarly,
> once classified as being associated with an Application, we may want to do
> some application specific processing on the data.
>
> So here if an activity on a user registration endpoint is recorded, would
> it
> record for each segment with app it referred to ?
>
>
>
> Therefore what I am considering is making the existing Business Transaction
> Configuration generic so that it is suitable for both tasks, with a simple
> classifier to indicate whether it relates to a Business Transaction or
> Application.
>
> This will mean that the fragments of activity being recorded and sent to
> the
> BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
>
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used
> to
> trigger the configuration of the Application in Hawkular BTM - especially
> if
> it is possible to obtain the web context for the application (or JMS
> queue/topic), which can then be used to establish the regular expression.
> If
> this level of integration was possible, then no user defined configuration
> would be necessary to capture application information using the same name
> as
> in Hawkular - allowing an integrated view of the information to be made
> available.
>
> Thoughts?
>
> In general from the very high level view (ManageIQ), I would want to be
> able
> to define a logical notion of "application" for monitoring purposes, I
> would
> expect to be able to add "entities" to that logical view. It may just be
a
> war file (and in the case of BTM, I would likely be interested by all entry
> points to that application) or it could be an "OpenShift Project" with
all
> its dependencies (all docker containers + everything in it), or it could be
> a selection of MW servers...
>
> In the end, the user should be able to dig into infrastructure details (and
> he already has that, he can see details about the infrastructure: a
> container, a host, a MW server (coming soon), a MW deployment (coming
> soon)...) + details on Business transactions but also have that synthetic
> view where he knows that all services that makes his online store are
> running fine, and have a few KPI such as the Apdex for all user-facing
> interactions, the N slowest URLs or DB requests...
>
> (This definitely goes beyond BTM, and we likely need to simplify and work
> on
> iterations of those ideas (or better ideas))
>
> That's what I dream of, as a user.
>
> Thomas
>
>
>
>
> 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
5:24 a.m.
New subject: Definition the concept of Application in Hawkular BTM
Hi Stefan
On further reflection, I think your suggestion of using properties/tags is better. Will
help to simplify the UI and enable greater flexibility in how the fragments are
categorised.
Regards
Gary
----- Original Message -----
Hello,
What was described in the original email sounded to me like tagging. A
transaction fragment stored in BTM could be tagged with an arbitrarily
number of tags. Here is an example { application: myapp, service:
superservice, datacenter: east}. And then the API needs to allow users to
query data based on tags and query the actual tag values.
So rather than expanding the design to cover just one other single concept
(application) the design with tags is generic and flexible.
Thank you,
Stefan Negrea
Software Engineer
On Thu, May 12, 2016 at 7:47 AM, Gary Brown < gbrown(a)redhat.com > wrote:
Hi Thomas
I think possibly there are different concepts here, so I need to clarify -
the one I was trying to describe is to capture the individual services,
which may be user facing, and would essentially map onto the individual
services (in a micro-services world).
So possibly rather than application, it should be termed "service"? which
would actually match the microservices world better anyway.
This service concept, especially in the case of user facing endpoints, would
be used to derive stats like Apdex - although the same stats could be
defined for internal services as well, to provide the dev teams behind those
services with a satisfaction index for their consumers.
I think the highlevel communication diagram provided in the Distributed
Tracing UI page could act as the basis for understanding which 'services'
and resources (if we dig further to understand databases, etc used) are used
to deliver the total 'application'.
Having an understanding of the separate 'services' and potentially the
resources they used, could then enable ManageIQ to build the logical
grouping that you mention, out of those services? So to be clear, BTM could
provide a highlevel understanding of the services and their communication
paths (and possibly resources used), and ManageIQ could use this information
to selectively (or as a complete set of interrelated services) present the
user with a logical group consisting of those managed objects.
> So here if an activity on a user registration endpoint is recorded, would
> it
> record for each segment with app it referred to ?
>
Wasn't sure what you meant here, if you could give an example?
Regards
Gary
----- Original Message -----
>
>
> On Wed, May 11, 2016 at 5:01 PM, Gary Brown < gbrown(a)redhat.com > wrote:
>
>
> Hi
>
> I would like to discuss how best to define the concept of an Application
> within the BTM project, how it relates to the existing concept of a
> "Business Transaction" and how it may link in with the concept of an
> application in Hawkular/ManageIQ in general.
>
> Firstly, for those not familiar with Hawkular BTM, without configuration
> the
> project can capture and trace an invocation across multiple interconnected
> services. The information can be used to provide stats on the individual
> components used (endpoints, databases, ejbs, etc) as well as (in the next
> version) present a graph showing the relationships between the
> communicating
> services.
>
> The project also enables "Business Transactions" to be configured - this
> enables a particular invocation of an endpoint to be labelled with a
> business transaction name (which is propagated to the fragments associated
> with the invoked services), and also perform additional processing on the
> messages, such as extract business properties, etc. Once a "Business
> Transaction" has been defined, it is possible to view high level stats
> about
> the complete "end to end" business transactions.
>
> This is achieved by creating a configuration that identifies the initial
> endpoint for the business transaction, using a regular expression, and then
> a set of 'processors' that are used to perform various processing tasks
> within the scope of that business transaction.
>
> We now have a requirement to identify the concept of an Application, and be
> able to present various stats about it. I believe that the Application can
> be viewed as orthogonal to the Business Transaction concept - so an
> Application represents the various operations that can be performed on a
> particular architectural component, whereas the Business Transaction
> represents a particular path through multiple Applications/Services, only
> using a subset of the operations/endpoints supported by the Application.
>
>
> I quite agree here, except that I would map an application to *several*
> achitectural components (for instance N microservices).
> Now if you have 2 logical applications (say e-commerce and brand website),
> a
> same architecture component may be shared (say user registration) in the 2
> apps.
>
>
>
> However the requirements are very similar - when we detect some activity on
> a
> particular endpoint we want to determine if it belongs to an Application,
> in
> the same way as we currently do with Business Transactions. And similarly,
> once classified as being associated with an Application, we may want to do
> some application specific processing on the data.
>
> So here if an activity on a user registration endpoint is recorded, would
> it
> record for each segment with app it referred to ?
>
>
>
> Therefore what I am considering is making the existing Business Transaction
> Configuration generic so that it is suitable for both tasks, with a simple
> classifier to indicate whether it relates to a Business Transaction or
> Application.
>
> This will mean that the fragments of activity being recorded and sent to
> the
> BTM server could now potentially have two names, one for the business
> transaction (which is propagated across application/service boundaries) and
> one for an application name (which is not propagated).
>
> Where appropriate, the UI could then be updated to allow the user to also
> filter information based on application - this may only make sense on the
> APM page, but could be considered if useful elsewhere. We may also want to
> make the current Business Transaction overview page more general to include
> both Business Transactions and Applications, and then have a different type
> of details page for applications.
>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking
> that where possible, it would be good if a deployment event could be used
> to
> trigger the configuration of the Application in Hawkular BTM - especially
> if
> it is possible to obtain the web context for the application (or JMS
> queue/topic), which can then be used to establish the regular expression.
> If
> this level of integration was possible, then no user defined configuration
> would be necessary to capture application information using the same name
> as
> in Hawkular - allowing an integrated view of the information to be made
> available.
>
> Thoughts?
>
> In general from the very high level view (ManageIQ), I would want to be
> able
> to define a logical notion of "application" for monitoring purposes, I
> would
> expect to be able to add "entities" to that logical view. It may just be
a
> war file (and in the case of BTM, I would likely be interested by all entry
> points to that application) or it could be an "OpenShift Project" with
all
> its dependencies (all docker containers + everything in it), or it could be
> a selection of MW servers...
>
> In the end, the user should be able to dig into infrastructure details (and
> he already has that, he can see details about the infrastructure: a
> container, a host, a MW server (coming soon), a MW deployment (coming
> soon)...) + details on Business transactions but also have that synthetic
> view where he knows that all services that makes his online store are
> running fine, and have a few KPI such as the Apdex for all user-facing
> interactions, the N slowest URLs or DB requests...
>
> (This definitely goes beyond BTM, and we likely need to simplify and work
> on
> iterations of those ideas (or better ideas))
>
> That's what I dream of, as a user.
>
> Thomas
>
>
>
>
> 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
4:14 a.m.
On 12 May 2016, at 14:47, Gary Brown wrote:
So possibly rather than application, it should be termed
"service"?
which would actually match the microservices world better anyway.
An application is in my understanding composed of multiple services.
Those can be micro services calling other micro services, external
providers
or things just like a database. Some may be provided by multiple micro
services
running (or being deployed) in parallel on several machines.
I don't think the concept of an application in the BTM world is much
different
from what we always said.
A user first wants to know "is my application doing all right?". And if
not,
she wants to zoom in to figure out where bottlenecks are.
The other direction is true as well: the user sees a machine clamped at
100%
cpu and wants to see what is creating the load, which service and
ultimately
which application (and if only for billing purposes).
5:04 a.m.
----- Original Message -----
On 12 May 2016, at 14:47, Gary Brown wrote:
> So possibly rather than application, it should be termed "service"?
> which would actually match the microservices world better anyway.
An application is in my understanding composed of multiple services.
Those can be micro services calling other micro services, external
providers
or things just like a database. Some may be provided by multiple micro
services
running (or being deployed) in parallel on several machines.
+1
I don't think the concept of an application in the BTM world is much
different
from what we always said.
A user first wants to know "is my application doing all right?". And if
not,
she wants to zoom in to figure out where bottlenecks are.
The other direction is true as well: the user sees a machine clamped at
100%
cpu and wants to see what is creating the load, which service and
ultimately
which application (and if only for billing purposes).
I think we need to build up a list of use cases that we wish to support with the
integration of MiQ and BTM.
But as outlined in your scenarios, it will be important to have a common concept of
services and resources across the two. At the moment BTM only understands activities
triggered at endpoints, so this needs to be linked to these static notions of service and
resource (e.g. database).
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:41 a.m.
Hi,
Based on my previous experience, I'll make an example that I would've considered
important to me. This is coming from something that used to be called "SaaS" or
outsourced processing or pick any other neat word of the time. The important part that I
think you presented in the message is that the users of BTM could provide different
information to their customers and to themselves.
So assuming the full service would have been: "we send invoice in, it gets processed
to the next company, archived and it's passthrough is monitored". For internal
use that means basically: "it's received by the front-end server, transferred to
the back-end server, processed in the invoicing router, a copy is sent to the archiving
process, one copy is sent to the next party and the invoice router waits for
acknowledgement message from next party". These were very simple definitions of these
two.
Thus, there are multiple transactions inside a transaction. For the customer who pays, the
transaction is a single one: "how long did it take until next customer received
it" and in some cases "how long did it take on the first party to process it and
ship it to the next destination" (different SLA on both scenarios). And of course the
most important "did all the messages get processed and delivered"
For the internal monitoring usage, there are multiple cases. How long did it take for each
service to process something? How long did it take until the invoice reached the next
microservice (there could be asynchronous transfers between services, lets not forget that
not all communication is using something like HTTP, there are many FTP batch jobs in the
world still doing the most important things in the world) ? Did the acknowledgement come
from the next party inside 24 hours?
I don't like the term "service" or "application" in this case a
lot, since all of these are services, yet from different perspectives the size of the
service changes. However obviously we would need to call the application the smallest part
for example and service the larger part. However, there are certainly micro-transactions
inside the transactions which would need to be linked to get all the relevant information
(the acknowledgement processing is sort of the same as the invoicing processing, including
all the front-end/back-end stuff as well, but it also plays a part in the larger
transaction).
So couldn't we just have tree of transaction-ids and not a definition of
"service/application" ? It would scale to any depth.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 11, 2016 6:01:56 PM
Subject: [Hawkular-dev] Definition the concept of Application in Hawkular BTM
Hi
I would like to discuss how best to define the concept of an Application within the BTM
project, how it relates to the existing concept of a "Business Transaction" and
how it may link in with the concept of an application in Hawkular/ManageIQ in general.
Firstly, for those not familiar with Hawkular BTM, without configuration the project can
capture and trace an invocation across multiple interconnected services. The information
can be used to provide stats on the individual components used (endpoints, databases,
ejbs, etc) as well as (in the next version) present a graph showing the relationships
between the communicating services.
The project also enables "Business Transactions" to be configured - this enables
a particular invocation of an endpoint to be labelled with a business transaction name
(which is propagated to the fragments associated with the invoked services), and also
perform additional processing on the messages, such as extract business properties, etc.
Once a "Business Transaction" has been defined, it is possible to view high
level stats about the complete "end to end" business transactions.
This is achieved by creating a configuration that identifies the initial endpoint for the
business transaction, using a regular expression, and then a set of 'processors'
that are used to perform various processing tasks within the scope of that business
transaction.
We now have a requirement to identify the concept of an Application, and be able to
present various stats about it. I believe that the Application can be viewed as orthogonal
to the Business Transaction concept - so an Application represents the various operations
that can be performed on a particular architectural component, whereas the Business
Transaction represents a particular path through multiple Applications/Services, only
using a subset of the operations/endpoints supported by the Application.
However the requirements are very similar - when we detect some activity on a particular
endpoint we want to determine if it belongs to an Application, in the same way as we
currently do with Business Transactions. And similarly, once classified as being
associated with an Application, we may want to do some application specific processing on
the data.
Therefore what I am considering is making the existing Business Transaction Configuration
generic so that it is suitable for both tasks, with a simple classifier to indicate
whether it relates to a Business Transaction or Application.
This will mean that the fragments of activity being recorded and sent to the BTM server
could now potentially have two names, one for the business transaction (which is
propagated across application/service boundaries) and one for an application name (which
is not propagated).
Where appropriate, the UI could then be updated to allow the user to also filter
information based on application - this may only make sense on the APM page, but could be
considered if useful elsewhere. We may also want to make the current Business Transaction
overview page more general to include both Business Transactions and Applications, and
then have a different type of details page for applications.
The final point is how this may link into Hawkular/ManageIQ. Was thinking that where
possible, it would be good if a deployment event could be used to trigger the
configuration of the Application in Hawkular BTM - especially if it is possible to obtain
the web context for the application (or JMS queue/topic), which can then be used to
establish the regular expression. If this level of integration was possible, then no user
defined configuration would be necessary to capture application information using the same
name as in Hawkular - allowing an integrated view of the information to be made
available.
Thoughts?
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:16 a.m.
On 13.05.2016 08:41, Michael Burman wrote:
So couldn't we just have tree of transaction-ids and not a
definition of "service/application" ? It would scale to any depth.
Adding Stefan's tagging feature on top of this, there could be a nice
feature of grouping transactions by affinity based on tags. So,
service/application is something that could be defined by a tag or a
collection of tags.
- Juca.
2:50 a.m.
----- Original Message -----
On 13.05.2016 08:41, Michael Burman wrote:
> So couldn't we just have tree of transaction-ids and not a definition of
> "service/application" ? It would scale to any depth.
Adding Stefan's tagging feature on top of this, there could be a nice
feature of grouping transactions by affinity based on tags. So,
service/application is something that could be defined by a tag or a
collection of tags.
A business transaction is something that spans across multiple
services/applications/resources and provides the context for a particular use of these
shared components. There is the ability to 'tag' fragments captured (associated
with a business txn or not) so this type of grouping is possible now.
Regards
Gary
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:47 a.m.
Hi Micke
Thanks for the detailed response.
I agree that we may want to model a hierarchy of business transactions, but each
transaction is likely to extend across multiple 'services' - just considering a
micro-service architecture for now. So it would be good to be able to obtain information
about those shared sub-business transactions in the context of the higher level
transactions.
Having said that, I believe we still need to be able to identify the individual component
parts of the architecture, whether services or resources, and from an operational
perspective be able to provide stats that are independent of the particular business
transaction instances - although those stats may need to be filtered to narrow in on
specific criteria, which may include focusing on a particular business transaction.
So having the ability to decompose the overall business transaction into a hierarchy of
sub transactions that are relevant to different parts of the organisation would be a great
idea.
Regards
Gary
----- Original Message -----
Hi,
Based on my previous experience, I'll make an example that I would've
considered important to me. This is coming from something that used to be
called "SaaS" or outsourced processing or pick any other neat word of the
time. The important part that I think you presented in the message is that
the users of BTM could provide different information to their customers and
to themselves.
So assuming the full service would have been: "we send invoice in, it gets
processed to the next company, archived and it's passthrough is monitored".
For internal use that means basically: "it's received by the front-end
server, transferred to the back-end server, processed in the invoicing
router, a copy is sent to the archiving process, one copy is sent to the
next party and the invoice router waits for acknowledgement message from
next party". These were very simple definitions of these two.
Thus, there are multiple transactions inside a transaction. For the customer
who pays, the transaction is a single one: "how long did it take until next
customer received it" and in some cases "how long did it take on the first
party to process it and ship it to the next destination" (different SLA on
both scenarios). And of course the most important "did all the messages get
processed and delivered"
For the internal monitoring usage, there are multiple cases. How long did it
take for each service to process something? How long did it take until the
invoice reached the next microservice (there could be asynchronous transfers
between services, lets not forget that not all communication is using
something like HTTP, there are many FTP batch jobs in the world still doing
the most important things in the world) ? Did the acknowledgement come from
the next party inside 24 hours?
I don't like the term "service" or "application" in this case a
lot, since
all of these are services, yet from different perspectives the size of the
service changes. However obviously we would need to call the application the
smallest part for example and service the larger part. However, there are
certainly micro-transactions inside the transactions which would need to be
linked to get all the relevant information (the acknowledgement processing
is sort of the same as the invoicing processing, including all the
front-end/back-end stuff as well, but it also plays a part in the larger
transaction).
So couldn't we just have tree of transaction-ids and not a definition of
"service/application" ? It would scale to any depth.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 11, 2016 6:01:56 PM
Subject: [Hawkular-dev] Definition the concept of Application in Hawkular BTM
Hi
I would like to discuss how best to define the concept of an Application
within the BTM project, how it relates to the existing concept of a
"Business Transaction" and how it may link in with the concept of an
application in Hawkular/ManageIQ in general.
Firstly, for those not familiar with Hawkular BTM, without configuration the
project can capture and trace an invocation across multiple interconnected
services. The information can be used to provide stats on the individual
components used (endpoints, databases, ejbs, etc) as well as (in the next
version) present a graph showing the relationships between the communicating
services.
The project also enables "Business Transactions" to be configured - this
enables a particular invocation of an endpoint to be labelled with a
business transaction name (which is propagated to the fragments associated
with the invoked services), and also perform additional processing on the
messages, such as extract business properties, etc. Once a "Business
Transaction" has been defined, it is possible to view high level stats about
the complete "end to end" business transactions.
This is achieved by creating a configuration that identifies the initial
endpoint for the business transaction, using a regular expression, and then
a set of 'processors' that are used to perform various processing tasks
within the scope of that business transaction.
We now have a requirement to identify the concept of an Application, and be
able to present various stats about it. I believe that the Application can
be viewed as orthogonal to the Business Transaction concept - so an
Application represents the various operations that can be performed on a
particular architectural component, whereas the Business Transaction
represents a particular path through multiple Applications/Services, only
using a subset of the operations/endpoints supported by the Application.
However the requirements are very similar - when we detect some activity on a
particular endpoint we want to determine if it belongs to an Application, in
the same way as we currently do with Business Transactions. And similarly,
once classified as being associated with an Application, we may want to do
some application specific processing on the data.
Therefore what I am considering is making the existing Business Transaction
Configuration generic so that it is suitable for both tasks, with a simple
classifier to indicate whether it relates to a Business Transaction or
Application.
This will mean that the fragments of activity being recorded and sent to the
BTM server could now potentially have two names, one for the business
transaction (which is propagated across application/service boundaries) and
one for an application name (which is not propagated).
Where appropriate, the UI could then be updated to allow the user to also
filter information based on application - this may only make sense on the
APM page, but could be considered if useful elsewhere. We may also want to
make the current Business Transaction overview page more general to include
both Business Transactions and Applications, and then have a different type
of details page for applications.
The final point is how this may link into Hawkular/ManageIQ. Was thinking
that where possible, it would be good if a deployment event could be used to
trigger the configuration of the Application in Hawkular BTM - especially if
it is possible to obtain the web context for the application (or JMS
queue/topic), which can then be used to establish the regular expression. If
this level of integration was possible, then no user defined configuration
would be necessary to capture application information using the same name as
in Hawkular - allowing an integrated view of the information to be made
available.
Thoughts?
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
3:02 a.m.
The "Application" is definitely first a user notion, I am personally
interested to think about the user facing features (in the context of
Application Performance Management/Monitoring) of what we can provide.
So far we have a good understanding of the individual metrics we can track
and how to track those:
- Infrastructure metrics (CPU/Memory of a host)
- Our dear MW metrics (Number of JMS messages sent/received, servlet
response time...)
- Business Transaction time split into "segments
-...
But for the user of the monitoring tools, it's hard to make sense of those
details (but we definitely need them, and the user may want to dig into
those details).
I just accidentally found this article:
http://apmdigest.com/the-anatomy-of-apm-4-foundational-elements-to-a-succ...
"The translation of IT metrics into business meaning (value) is what APM is
all about."
I couldn't agree more :)
I've asked Gary/Pavol to look into the Apdex, it's a relatively interesting
index to measure the user satisfaction, it's "simple" (only based on
response time) but still give 1 indicator that can be useful to quickly
assess the health of an application. It may or may not belong to the BTM
project though.
Thomas
On Fri, May 13, 2016 at 8:41 AM, Michael Burman <miburman(a)redhat.com> wrote:
Hi,
Based on my previous experience, I'll make an example that I would've
considered important to me. This is coming from something that used to be
called "SaaS" or outsourced processing or pick any other neat word of the
time. The important part that I think you presented in the message is that
the users of BTM could provide different information to their customers and
to themselves.
So assuming the full service would have been: "we send invoice in, it gets
processed to the next company, archived and it's passthrough is monitored".
For internal use that means basically: "it's received by the front-end
server, transferred to the back-end server, processed in the invoicing
router, a copy is sent to the archiving process, one copy is sent to the
next party and the invoice router waits for acknowledgement message from
next party". These were very simple definitions of these two.
Thus, there are multiple transactions inside a transaction. For the
customer who pays, the transaction is a single one: "how long did it take
until next customer received it" and in some cases "how long did it take on
the first party to process it and ship it to the next destination"
(different SLA on both scenarios). And of course the most important "did
all the messages get processed and delivered"
For the internal monitoring usage, there are multiple cases. How long did
it take for each service to process something? How long did it take until
the invoice reached the next microservice (there could be asynchronous
transfers between services, lets not forget that not all communication is
using something like HTTP, there are many FTP batch jobs in the world still
doing the most important things in the world) ? Did the acknowledgement
come from the next party inside 24 hours?
I don't like the term "service" or "application" in this case a
lot, since
all of these are services, yet from different perspectives the size of the
service changes. However obviously we would need to call the application
the smallest part for example and service the larger part. However, there
are certainly micro-transactions inside the transactions which would need
to be linked to get all the relevant information (the acknowledgement
processing is sort of the same as the invoicing processing, including all
the front-end/back-end stuff as well, but it also plays a part in the
larger transaction).
So couldn't we just have tree of transaction-ids and not a definition of
"service/application" ? It would scale to any depth.
- Micke
----- Original Message -----
From: "Gary Brown" <gbrown(a)redhat.com>
To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, May 11, 2016 6:01:56 PM
Subject: [Hawkular-dev] Definition the concept of Application in Hawkular
BTM
Hi
I would like to discuss how best to define the concept of an Application
within the BTM project, how it relates to the existing concept of a
"Business Transaction" and how it may link in with the concept of an
application in Hawkular/ManageIQ in general.
Firstly, for those not familiar with Hawkular BTM, without configuration
the project can capture and trace an invocation across multiple
interconnected services. The information can be used to provide stats on
the individual components used (endpoints, databases, ejbs, etc) as well as
(in the next version) present a graph showing the relationships between the
communicating services.
The project also enables "Business Transactions" to be configured - this
enables a particular invocation of an endpoint to be labelled with a
business transaction name (which is propagated to the fragments associated
with the invoked services), and also perform additional processing on the
messages, such as extract business properties, etc. Once a "Business
Transaction" has been defined, it is possible to view high level stats
about the complete "end to end" business transactions.
This is achieved by creating a configuration that identifies the initial
endpoint for the business transaction, using a regular expression, and then
a set of 'processors' that are used to perform various processing tasks
within the scope of that business transaction.
We now have a requirement to identify the concept of an Application, and
be able to present various stats about it. I believe that the Application
can be viewed as orthogonal to the Business Transaction concept - so an
Application represents the various operations that can be performed on a
particular architectural component, whereas the Business Transaction
represents a particular path through multiple Applications/Services, only
using a subset of the operations/endpoints supported by the Application.
However the requirements are very similar - when we detect some activity
on a particular endpoint we want to determine if it belongs to an
Application, in the same way as we currently do with Business Transactions.
And similarly, once classified as being associated with an Application, we
may want to do some application specific processing on the data.
Therefore what I am considering is making the existing Business
Transaction Configuration generic so that it is suitable for both tasks,
with a simple classifier to indicate whether it relates to a Business
Transaction or Application.
This will mean that the fragments of activity being recorded and sent to
the BTM server could now potentially have two names, one for the business
transaction (which is propagated across application/service boundaries) and
one for an application name (which is not propagated).
Where appropriate, the UI could then be updated to allow the user to also
filter information based on application - this may only make sense on the
APM page, but could be considered if useful elsewhere. We may also want to
make the current Business Transaction overview page more general to include
both Business Transactions and Applications, and then have a different type
of details page for applications.
The final point is how this may link into Hawkular/ManageIQ. Was thinking
that where possible, it would be good if a deployment event could be used
to trigger the configuration of the Application in Hawkular BTM -
especially if it is possible to obtain the web context for the application
(or JMS queue/topic), which can then be used to establish the regular
expression. If this level of integration was possible, then no user defined
configuration would be necessary to capture application information using
the same name as in Hawkular - allowing an integrated view of the
information to be made available.
Thoughts?
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
2905
days inactive
2907
days old
12 comments
6 participants
participants (6)
-
Gary Brown -
Heiko W.Rupp -
Juraci Paixão Kröhling -
Michael Burman -
Stefan Negrea -
Thomas Heute