Dynatrace automatically detects event-based message queue handlers for certain technologies like JMS and Rabbit MQ. However, if your application uses a non-standard handler, messaging service, or simply processes messages in a non-event driven fashion, then Dynatrace won't be able to automatically detect how the messages are processed. To get insight into these, you must define a custom messaging service for your consumers.
Define a messaging service
To define a custom messaging service, go to Settings > Server-side service monitoring > Custom service detection. Select whether your messaging service is based on Java, .NET, or Node.js. Click the Define messaging service button.
When you follow the workflow, ensure that you give the service a meaningful name and select the proper technology.
Click Find entry point and select the process group that contains your entry point.
Select the process that contains your entry point and click Continue.
Find the class you want to instrument. Type in the name or part of the name to search for it.
Select the required class or file and click Continue.
For Java and .NET: Define how you want to instrument the class. You have two options:
- Use the selected class for instrumenting methods of the selected class only.
- Use an implemented interface or superclass for instrumenting methods in any interface or super class in the class hierarchy. In such cases, click Load inheritance to load all available superclasses and interfaces, then select the one you need.
Select the methods you want to instrument and click Finish.
Please see the messaging services requirements for Apache Kafka in the section below.
The Define custom service page displays the newly added entry point and methods.
If needed, add more entry points.
If needed, restrict the new custom service to certain process groups. See the Restrict a custom service to specific process groups section below.
Review the entry point and methods to be instrumented.
In the bottom right corner of the page, click Save.
For .NET and Node.js: Restart your consumer application so that the custom messaging service can be detected.
Apache Kafka is different from other messaging services. Its interfaces are designed to process messages in bulk, yet the purpose of Dynatrace is to follow single transactions. Dynatrace can only do this if you define a method that is responsible for processing a single Kafka message in your code and use this as the entry point of your Kafka messaging service.
For Java, you must select a method that has a Kafka
ConsumerRecord as an argument.
For .NET, you can select a method that has a Kafka
Message object as an argument. The argument can be placed anywhere in the parameter list. If you select a method that doesn't have an argument, the context will be propagated via
ThreadLocal (on .NET Framework 4.5) or via
AsyncLocal (on .NET Framework 4.6/.NET Core 2.0 or later). Asynchronous methods without any arguments or without the Kafka type arguments (
Message) are only supported on .NET Framework 4.6/.NET Core 2.0 or later.
For Node.js, you must select an exported message handler function that has a KafkaJs
EachMessagePayload as an argument.
Priority of messaging services
If you have several custom services defined, the evaluation goes from top to bottom, applying the first matching rule. If for some reason you have the same class and method defined in several custom services, make sure to prioritize the services accordingly.
Edit messaging service
You can edit any custom service at any time. For changes to take effect, you need to restart the affected processes, unless the real-time updates are activated for Java and PHP. For .NET and Node.js, you must restart the process.
To edit a custom service, click the service's Edit button in the list of services.
You can activate/deactivate existing entry points, add/delete entry points, and add/delete methods in entry points.
You can also restrict the custom service to certain process groups. See the Restrict a custom service to specific process groups section below.
Updates to Java custom messaging services can be applied in near real-time, without process restarts. To activate this feature, enable the Enable real-time updates to Java and PHP services selector at Custom service detection.
Real-time updates may cause CPU spikes when changes are deployed.
Restrict a messaging service to specific process groups
You can restrict usage of any custom service to certain process groups. Custom services rules will apply in specified process groups only and will be ignored in other process groups. You can restrict a custom service during creation or edit it later.
To restrict a custom service:
- On the Define custom service or Edit service page, expand the Optionally restrict custom service rules by process groups drop-down menu.
- Click Add process group.
- Select the process group where you want to apply the custom service.
- Click Add.
- In the bottom right corner of the Define custom service or Edit service page, click Save.