<div dir="ltr"><div><div>Hello,<br><br></div>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.<br><br></div><div>So rather than expanding the design to cover just one other single concept (application) the design with tags is generic and flexible.<br></div><div><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Thank you,<br>Stefan Negrea<br><br>Software Engineer<br></div></div></div>
<br><div class="gmail_quote">On Thu, May 12, 2016 at 7:47 AM, Gary Brown <span dir="ltr"><<a href="mailto:gbrown@redhat.com" target="_blank">gbrown@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Thomas<br>
<br>
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).<br>
<br>
So possibly rather than application, it should be termed "service"? which would actually match the microservices world better anyway.<br>
<br>
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.<br>
<br>
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'.<br>
<br>
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.<br>
<span class=""><br>
> So here if an activity on a user registration endpoint is recorded, would it<br>
> record for each segment with app it referred to ?<br>
><br>
<br>
</span>Wasn't sure what you meant here, if you could give an example?<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Gary<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
><br>
><br>
> On Wed, May 11, 2016 at 5:01 PM, Gary Brown < <a href="mailto:gbrown@redhat.com">gbrown@redhat.com</a> > wrote:<br>
><br>
><br>
> Hi<br>
><br>
> I would like to discuss how best to define the concept of an Application<br>
> within the BTM project, how it relates to the existing concept of a<br>
> "Business Transaction" and how it may link in with the concept of an<br>
> application in Hawkular/ManageIQ in general.<br>
><br>
> Firstly, for those not familiar with Hawkular BTM, without configuration the<br>
> project can capture and trace an invocation across multiple interconnected<br>
> services. The information can be used to provide stats on the individual<br>
> components used (endpoints, databases, ejbs, etc) as well as (in the next<br>
> version) present a graph showing the relationships between the communicating<br>
> services.<br>
><br>
> The project also enables "Business Transactions" to be configured - this<br>
> enables a particular invocation of an endpoint to be labelled with a<br>
> business transaction name (which is propagated to the fragments associated<br>
> with the invoked services), and also perform additional processing on the<br>
> messages, such as extract business properties, etc. Once a "Business<br>
> Transaction" has been defined, it is possible to view high level stats about<br>
> the complete "end to end" business transactions.<br>
><br>
> This is achieved by creating a configuration that identifies the initial<br>
> endpoint for the business transaction, using a regular expression, and then<br>
> a set of 'processors' that are used to perform various processing tasks<br>
> within the scope of that business transaction.<br>
><br>
> We now have a requirement to identify the concept of an Application, and be<br>
> able to present various stats about it. I believe that the Application can<br>
> be viewed as orthogonal to the Business Transaction concept - so an<br>
> Application represents the various operations that can be performed on a<br>
> particular architectural component, whereas the Business Transaction<br>
> represents a particular path through multiple Applications/Services, only<br>
> using a subset of the operations/endpoints supported by the Application.<br>
><br>
><br>
> I quite agree here, except that I would map an application to *several*<br>
> achitectural components (for instance N microservices).<br>
> Now if you have 2 logical applications (say e-commerce and brand website), a<br>
> same architecture component may be shared (say user registration) in the 2<br>
> apps.<br>
><br>
><br>
><br>
> However the requirements are very similar - when we detect some activity on a<br>
> particular endpoint we want to determine if it belongs to an Application, in<br>
> the same way as we currently do with Business Transactions. And similarly,<br>
> once classified as being associated with an Application, we may want to do<br>
> some application specific processing on the data.<br>
><br>
> So here if an activity on a user registration endpoint is recorded, would it<br>
> record for each segment with app it referred to ?<br>
><br>
><br>
><br>
> Therefore what I am considering is making the existing Business Transaction<br>
> Configuration generic so that it is suitable for both tasks, with a simple<br>
> classifier to indicate whether it relates to a Business Transaction or<br>
> Application.<br>
><br>
> This will mean that the fragments of activity being recorded and sent to the<br>
> BTM server could now potentially have two names, one for the business<br>
> transaction (which is propagated across application/service boundaries) and<br>
> one for an application name (which is not propagated).<br>
><br>
> Where appropriate, the UI could then be updated to allow the user to also<br>
> filter information based on application - this may only make sense on the<br>
> APM page, but could be considered if useful elsewhere. We may also want to<br>
> make the current Business Transaction overview page more general to include<br>
> both Business Transactions and Applications, and then have a different type<br>
> of details page for applications.<br>
><br>
> The final point is how this may link into Hawkular/ManageIQ. Was thinking<br>
> that where possible, it would be good if a deployment event could be used to<br>
> trigger the configuration of the Application in Hawkular BTM - especially if<br>
> it is possible to obtain the web context for the application (or JMS<br>
> queue/topic), which can then be used to establish the regular expression. If<br>
> this level of integration was possible, then no user defined configuration<br>
> would be necessary to capture application information using the same name as<br>
> in Hawkular - allowing an integrated view of the information to be made<br>
> available.<br>
><br>
> Thoughts?<br>
><br>
> In general from the very high level view (ManageIQ), I would want to be able<br>
> to define a logical notion of "application" for monitoring purposes, I would<br>
> expect to be able to add "entities" to that logical view. It may just be a<br>
> war file (and in the case of BTM, I would likely be interested by all entry<br>
> points to that application) or it could be an "OpenShift Project" with all<br>
> its dependencies (all docker containers + everything in it), or it could be<br>
> a selection of MW servers...<br>
><br>
> In the end, the user should be able to dig into infrastructure details (and<br>
> he already has that, he can see details about the infrastructure: a<br>
> container, a host, a MW server (coming soon), a MW deployment (coming<br>
> soon)...) + details on Business transactions but also have that synthetic<br>
> view where he knows that all services that makes his online store are<br>
> running fine, and have a few KPI such as the Apdex for all user-facing<br>
> interactions, the N slowest URLs or DB requests...<br>
><br>
> (This definitely goes beyond BTM, and we likely need to simplify and work on<br>
> iterations of those ideas (or better ideas))<br>
><br>
> That's what I dream of, as a user.<br>
><br>
> Thomas<br>
><br>
><br>
><br>
><br>
> Regards<br>
> Gary<br>
><br>
> _______________________________________________<br>
> hawkular-dev mailing list<br>
> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> hawkular-dev mailing list<br>
> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
><br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
</div></div></blockquote></div><br></div></div>