Need Class/method name involved in execution of proxies in Message processor server

[#1]

We want to set up AppDynamics , An APM tool to monitor the APIGEE environment . We have configured Appdynamics agents on the APIGEE servers but we are not able see the time taken to execute proxies, time taken to execute OAuth endpoints. If we get the class/method name we can configure a rule to capture the metrics of the particular class/method

[sarthak]

Hi @Manish Kumar I do not think we can publish the internal class/method names for the various policies. Since those are internal names and are subjected to all sorts of changes at the discretion of our engineering team.

However I know I am not helping you to solve your challenge with AppDynamics. Probably someone else can help you with that ? @alan@apigee.com ?

Sarthak

[DChiesa]

Hi, I'm not familiar with how AppDynamics works. Can you explain how you intend to transmit the "class/method name" to AppDynamics?

Is AppDynamics instrumenting the actual Java code of the Message Processor via code injection and bytecode modification? In that case, I understand what you're asking. Unfortunately, I don't think we can help you. The class and method name within the MP is not part of the documented interface for the Apigee Edge product. We do not document that, and if we did give you a class and method name, we wouldn't be able to guarantee that it wouldn't change. Therefore the approach you describe won't work.

I'd suggest that you use alternative mechanisms for monitoring the performance and behavior of Edge. We do have some documented interfaces for these purposes. First, there are data items in each Analytics Record - you can, for example, produce charts in the Edge Administrative UI that exhibit the time required for any particular endpoint hosted within Edge. Edge also computes transaction percentiles per endpoint as well, so you can view TP95 and TP99 charts. In addition, all of the data that makes up these charts is available via API.

Secondly, there are JMX endpoints on MessageProcessors. You can examine the per-MP behavior by querying this data. See the documentation for OPDK to get more information on all the JMX counters.

I hope this helps!

[#4]

Hi @Dino

Thanks for the quick reply.

We have the Edge Administrative UI to monitor and we are using it too. Since we have Appdynamics as our APM tool, We want to use it to monitor the APIGEE environment too.

In order to have a better clarity on the issue we can set up a meeting with Appdynamics team to discuss it and resolve it.

Please let me know the available 2-3 time slots with timezone so that we can schedule a meeting

[#5]

Hi,

I am actually interested in this topic myself, but want to make sure I understand the end goal here. In my experience with AppDynamics the use case involved end-to-end transaction monitoring where a given app deployed in a J2E compliant application container was known, and traced by AppDynamics. This was great, because then we could track how our client code was executed (also traced by AppDynamics), how it called the middleware, how that middleware handled that transaction and even how this was ultimately handed off to some backend DB.... In Apigee's case, however, these classes aren't the interesting part. The interesting part is the configuration that's driving them. I think with typical AppDynamics tracing one looks for these classes in order to trace the whole call. This isn't usually too difficult, either, as it's usually these particular classes that were developed by the client. In this case, however, one is usually writing configuration that will be handled by Apigee's policies....

As has been stated above, even if we gave you the name of those policies we cannot guarantee that they'd stay the same ... But I want to point out that I think it's even missing the point: as they're kind of luck the underlying servlet-container in my example from above. *That* part isn't what's interesting: it's the custom code that's deployed that AppDynamics can trace.

Now .. If it's possible (somehow) for AppDynamics to trace through singular policy executions associated with a particular client call, backend call and it's own configuration then it would be interesting, but i'm not seeing how this would be easily implementable.

Having said all of this .. I do think that finding an intelligent way to get valuable data out of Apigee via AppDynamics is a good idea, but i'm not certain that this is the right approach.

Thanks,

/geir

[#6]

With the latest release every policy exposes a variable with name

apigee.metrics.policy.<policy name>.timeTaken

The value is the the time taken by the policy in nano-seconds.