As of [v23.5] AppDynamics APM Java, Node.js, and .NET Agents have been upgraded for dual output, so your existing instrumentation can be consumed by any 3rd party Open Telemetry(OTel) capable backend, such as Splunk Observability Cloud. The application itself doesn’t need to be written to support OpenTelemetry or be re-instrumented in any way. Once you updated your AppDynamics agents, you can enable OTel in the agent and start to push telemetry to your OpenTelemetry collector. To push data to Splunk Observability cloud we recommend the use of the Splunk Distribution of the OTel Collector
In this article...
Re-instrumentation options for OpenTelemetry
There are three options for enabling OTel in your application:
- Manually re-instrument your entire application. While this approach necessitates changes to your code, it provides complete flexibility. Since OpenTelemetry is an industry-standard and vendor-independent, this code-level instrumentation only needs to be performed once.
- Automatically instrument with an OpenSource OpenTelemetry agent, comparable to an AppDynamics agent. You have the option to utilize the standard OpenSource agents or the Splunk Distribution agent, which offers enhancements and preconfiguration.
- Auto-instrument with an AppDynamics agent configured to output OpenTelemetry, allowing you to retain your AppDynamics data and workflows while simultaneously emitting OTel data.
Solutions/Processes
While having multiple options is beneficial, it can sometimes be overwhelming and raise questions about the best choice for specific situations. Although there is no universal solution that fits all scenarios, we aim to provide some high-level guidance and recommendations.
Cloud native applications
For new cloud native applications, it is advantageous to instrument each service natively with OpenTelemetry. As mentioned earlier, OpenTelemetry SDKs and APIs are vendor-neutral, allowing you to send telemetry data to various backends. If you are working with an existing cloud native application, you can also apply auto-instrumentation on a per-service basis. Tools like the OpenTelemetry Operator for Kubernetes simplify this process by enabling instrumentation through annotations when running in Kubernetes environments.
Existing and legacy applications
For existing applications, particularly legacy ones, manual re-instrumentation can be a significant effort. In such cases, you can opt to re-instrument using either an open-source agent or an AppDynamics agent.
If your legacy application is already instrumented with AppDynamics, the simplest approach is to reconfigure it to output OpenTelemetry data instead of switching to an open-source agent. This allows you to retain all your existing configurations, troubleshooting workflows, dashboards, alerts, and notifications while adding OpenTelemetry export capabilities. Additionally, this setup enables AppDynamics agents to correlate data between services instrumented with both OpenTelemetry and AppDynamics, providing comprehensive end-to-end visibility.
AppDynamics Smart Agent Management features make it easier to install, manage, configure, and maintain compared to managing open-source agents.
What are the steps to instrumenting....
OpenTelemetry can be enabled with some simple steps, find here an example for Java:
- Enable OTel using the following configuration flags:
-Dappdynamics.opentelemetry.enabled=true
-Dotel.traces.exporter=otlp
- Set your collector endpoint if the collector is not running on the same host
-Dotel.exporter.otlp.traces.endpoint=http://<your collector ip>:4317
- Pass the additional resource attributes to be included, the service.name is a required attribute
-Dotel.resource.attributes="service.name=myServiceName,service.namespace=myServiceNameSpace"
More information and exact steps, also for .Net and NodeJS, can be found in Instrument Applications with AppDynamics for OpenTelemetry™ documentation.
Additional resources:
