New Relic's Java agent collects and reports information on web transactions and non-web transactions, such as background tasks. The agent should instrument supported frameworks automatically, without any need to modify your application code. However, in addition to custom code and frameworks or technology not listed in the Compatibility and requirements for the Java agent documentation, some implementations of supported frameworks may require custom instrumentation.
This document describes how to use the Java agent API to instrument external calls, messaging frameworks, distributed tracing, datastores, and web frameworks. For best results when using the API, ensure that you have the latest Java agent release. Several APIs used in the examples require Java agent 3.36.0 or higher.
External API
The External API enables applications to report external service calls to New Relic. This information appears on the External services page in APM. To report HTTP external activity, simply create an instance of ExternalParameters
using the HttpParameters
builder, and call reportAsExternal(ExternalParameters parameters)
on the traced method you want to report.
External parameters builders
There are several builders to create ExternalParameters
:
DatastoreParameters
HttpParameters
GenericParameters
MessageConsumeParameters
MessageProduceParameters
These builders create the input parameter object for TracedMethod
's reportAsExternal
API call. These parameter objects are used for things like linking HTTP external calls via distributed tracing, tracing external calls to a datastore, tracing external calls to a datastore with additional slow query processing, as well as tracing calls between message producers and consumers.
Importante
All of the methods of this class have the potential to expose sensitive private information. Use caution when creating the arguments, paying particular attention to URIs and string values.
Distributed tracing API
The distributed tracing API allows the New Relic Java agent to link transactions across applications that are instrumented either by the New Relic Java agent or by another open instrumentation standard tool. It uses a wrapper to allow the agent to read/write headers to requests.
Headers wrapper
The agent uses the interface Headers
to read/write headers to a request. Both the client and the server need to implement this interface using the classes from their communications framework. For example:
Distributed tracing implementation using wrappers
Using the wrapper object described in the previous section, you can enable the Java agent to report traces on the client and server side. For example:
In this sample code, the agent is configured to report an external call using distributed tracing on the client that is initiating the request. These steps can be summarized as follows:
- Implement
Headers
using framework classes on the client. - Use
insertDistributedTraceHeaders(Headers headers)
to have the agent add appropriate headers to the outbound request.
In this sample code, the agent is configured to read the headers from the request. These steps can be summarized as follows:
- Implement
Headers
using framework classes on the server. - Use
acceptDistributedTraceHeaders(TransportType transportType, Headers headers)
to link this transaction to the transaction that made the call.
Cross application tracing API
Importante
Cross application tracing has been deprecated as of agent version 7.4.0 and will be removed in a future agent version.
Instead of using cross application tracing, we recommend our distributed tracing features. Distributed tracing is an improvement on the cross application tracing feature and is recommended for large, distributed systems.
The cross application tracing (CAT) API allows the New Relic Java agent to link transactions across applications monitored by New Relic. The API uses client and server wrappers that allow the agent to read headers from requests, and add headers to responses.
Client wrappers
For the agent to write outbound request headers in the client initiating the request, use the OutboundHeaders
interface. For example:
For the agent to read inbound response headers in the client receiving the response, implement the InboundHeaders
. For example:
Server wrappers
For the agent to get web request headers, you must extend the ExtendedRequest
class:
For the agent to set the web response headers, implement the Response
interface:
CAT implementation using wrappers
Using the wrapper objects described in the previous sections, you can enable the Java agent to do cross application tracing (CAT) on the client and server side. For example:
In this sample code, the agent is configured to report an external call using CAT on the client that is initiating the request. These steps can be summarized as follows:
- Implement
OutboundHeaders
andInboundHeaders
using framework classes on the client. - Use
addOutboundRequestHeaders(OutboundHeaders outboundHeaders)
to have the agent add appropriate headers to the outbound request. - Create
ExternalParameters
object usingHttpParameters
builder and provide inbound response headers. - Report as an external request using
reportAsExternal(ExternalParameters params)
.
In this sample code, the agent is configured to report an external call using CAT on the server that is responding to the request. These steps can be summarized as follows:
Implement
Response
and extend theExtendedRequest
class using framework classes on the server.Use
setWebRequest(ExtendedRequest request)
andsetWebResponse(Response response)
to convert the transaction into a web transaction and together provide the agent with the inbound request headers and a place to record the outbound headers.It's important to use both
setWebRequest(ExtendedRequest request)
andsetWebResponse(Response response)
together, because the transaction name depends on the request object, and the response code depends on the response object.Use
addOutboundResponseHeaders()
to have the agent add appropriate headers to the outbound response.Mark the end of the response with a call to
markResponseSent()
.
Messaging API
The messaging API allows applications to report interactions with message queue brokers. It builds on top of the External API by providing the MessageConsumerParametersMessage
and MessageConsumerParameters
.
This API generates the necessary metrics to identify message broker interactions. The UI will use these metrics to display messaging data including segments in transactions with the appropriate action and count (message put, or message take), a dedicated messages tab in transaction traces, and more. Providing inbound and outbound headers to the API also allows the agent to add CAT headers, and record CAT metrics, which enables the UI to draw service maps that show connections between applications.
Importante
The messaging API relies on two-way communication between producers and consumers. If your producer does not receive an acknowledgment from a consumer, like in a fire-and-forget pattern, the messaging API will not accurately reflect the interactions with message queue brokers.
The following example demonstrates how to instrument a fictional JMS library.
To simplify things, the agent assumes that sendMessageToQueue
always puts a message in a named queue. In reality, a message can be sent to different destination types, including named queues, temporary queues, topics, and temporary topics. The API provides an enum to report messages to different destination types: NAMED_QUEUE
, TEMP_QUEUE
, NAMED_TOPIC
, TEMP_TOPIC
. It's important to specify the appropriate destination type because the UI will display the names of named queues and named topics and will omit the names of temporary queues and temporary topics.
If the library is capable of transmitting CAT headers, an OutboundHeaders
object will be provided to the API so that the agent can add CAT headers.
Datastore API
When a traced method is reported as an external datastore call, the call is shown in the APM Databases page. Because datastores are external to the running application, the method is reported as datastore activity using the reportAsExternal(ExternalParameters params)
method. The only difference is that a different builder, DatastoreParameters
, is used to create the appropriate ExternalParameters
object.
Datastore API: Slow query
This API call provides the same behavior as the Datastore API call and extends it to allow slow query information to be tracked. The same reportAsExternal(ExternalParameters params)
method and builder are used, but with an additional builder method.
WebFrameworks API
The WebFrameworks API allows the agent to report additional identifying information about the application.
// Set the dispatcher name and version which is reported to APM.// The dispatcherName is intended to represent the type of server that this// application is running on such as: Tomcat, Jetty, Netty, etc.NewRelic.setServerInfo(String dispatcherName, String version)
// Set the app server port which is reported to APM.NewRelic.setAppServerPort(int port)
// Set the instance name in the environment.// A single host:port may support multiple JVM instances.// The instance name is intended to help identify a specific JVM instance.NewRelic.setInstanceName(String instanceName)
Dica
These values can be set only once. Subsequent calls will have no effect.