How would I add new instrumentation for a new library? about inspectit HOT 12 OPEN

It looks like the JavaAgent class loads the instrumenting agents. SpringAgent appears to be the only agent after a quick look. If I made an alternative to the SpringAgent, then would I have to update the server's code at all? Or could I just reuse the system that the SpringAgent relies upon?

from inspectit.

I'm not seeing much in the SpringAgent that actually does instrumentation. It looks like it just looks for classes that implement InstrumentationAware and then sets the instrumentation (whatever that is) for that interface. Does that meant that code modification is actually necessary in the instrumented project?

from inspectit.

Is this what you need?

from inspectit.

Hi @WaffleTime , the answer depends on what you want to achieve with the instrumentation. Let's suppose you want to gather specific metrics (like timing information) in these frameworks. You would just use our provided UI with the configuration view and define dynamic mappings / sensors. Please take a look at the following documentation about this: https://inspectit-performance.atlassian.net/wiki/display/DOC17/Configuration+basics

But if you want to gather the request and response data of both of them, connect remote calls spanning multiple inspectIT agents and make them visible in our UI and in the e.g. invocation sequences, it's a little bit different:

• For JMS (ActiveMQ) we released last friday the basis of our new tracing feature based on http://opentracing.io/. This means that very soon, we'll provide out of the box support to extract tracing information and connect this in our server and UI to have data which spans over multiple jvms:
  
• The same could be done for Thrift, but we do not provide any kind of support for this right now as we want to focus on finishing the stuff around the tracing functionality including new views for the UI etc. If you are interested in developing this, let us know and we will help you there!

from inspectit.

Thanks for the response. I'm new to the inspectIT project and I haven't used it yet. I've been looking around for an APM that we could use to test our Java microservices. It's just that we use Thrift and JMS for our network communication mostly (there's also some HTTP.) I love that you've almost added support for JMS. If this is the APM I'm looking for, then I'd be up to take on development of a Thrift sensor.

I haven't quite found a very reliable project yet and I'm not sure if we can afford to use one in our production environments. In order to work in production, we would need it to be very light on the cpu and ram usage (and to an extent disk usage.) At the very least I'd like to be able to instrument our transport layers within our testing environment.

Anyway, it looks like I should be looking at the documentation for the sensors. That seems to be where the different instrumentation logic is located, possibly. Is there a list of commits I could go check out, documentation, examples packages in a project to look through, or something I could check out?

from inspectit.

I should mention that we're also not using spring. It seems like standalone applications are supported by this apm though.

from inspectit.

Hi @WaffleTime,

First, any Java application running in the JVM is possible to instrument.

Second, Thrift is not easy or let's say way complicated than HTTP/JMS communication. It's because the HTTP request and JMS message allows you to easily add HTTP headers and JMS message property values. This way when we can intercept the HTTP request and enrich the request with two IDs that we send over network. If the receiver of this request is also instrumented with inspectIT then it can check if the headers with the IDs are provided and if so correlate this call to an existing trace. If receiver is not instrumented with inspectIT then this IDs will simply be ignored. For Thrift your client needs to know if the server is instrumented with inspectIT, because it must only send IDs if the other side is "expecting them". As your messages are fixed size, if you send anything in addition and the receiving side is not instrumented then you would end up in errors. So there is quite a lot of work around this to make it happen. Also, we currently don't have anything in place to ease-up such implementation (as we have for example for new Http client library, or some other way of communication that can allow easy adding of properties to the call). But if you are interested in helping to make this happen we would be delighted 😄, especially that we have same problems with Java RMI for example.

For start you can do the following:

• Check the sensors we have, how can you configure them, etc. This way you will get idea that sensor can be applied to any methods. https://inspectit-performance.atlassian.net/wiki/display/DOC17/Sensor+assignments+configuration
• Check blog post written by Stefan Siegl on how to create a new sensor in inspectIT (here the configuration was old style in text file, but you will get the point): https://dzone.com/articles/how-to-write-your-own-sensor-for-the-open-source-a
• Then you can have a look on our inspectit.agent.java.sdk which implements the opentracing.io specification and check the tracing/core package in the agent project to understand how do we do remote calls correlation right now for HTTP/JMS.
• Then come back to us if you are still interested and we can have a talk together 📞

from inspectit.

I've got experience with Thrift's protocol and transport layer. It's completely possible to change the protocol layer of Thrift such that some header information is added to each Thrift message and then interpreted by the server. I can do that and it actually wouldn't be too difficult, at first thought. Thanks for the information, I'll check it out more thoroughly over the weekend.

from inspectit.

@WaffleTime Wow that sounds really great.. You having experience with Thrift can be a big benefit for inspectIT remote part 😄 As said, please fell free to contact us, we can discuss and help in order to finish this task faster/better.

from inspectit.

What is the best way to contact your team? Issues are fine with me, since it leaves a record for future readers.

So far I've been getting acquainted with the tool. I've tracked invocation sequences and that is pretty neat. I'm probably going to just make a simple sensor to start off with. I'll get back to you all later after I do more exploration.

from inspectit.

The easiest to reach us is through gitter: https://gitter.im/inspectIT/chat . All of us are always in there 😄

from inspectit.

Just curious, could you already try out to add the Thrift tracing support? If you need help with anything, just let us know!

from inspectit.