AppDynamics Cloud provides visibility into Kubernetes® services that are instrumented with OpenTelemetry™. Additionally, the Operator installed via AppDynamics Cloud Helm chart provides the capability to inject OpenTelemetry auto-instrumentation agents for Java, .NET, and Python applications. If your services are not running on Kubernetes, see Monitoring Services Not Running on Kubernetes.

This document contains references to OpenTelemetry™ documentation. AppDynamics does not own any rights and assumes no responsibility for the accuracy or completeness of such third-party documentation.

Get Started

To get started with Application Performance Monitoring with OpenTelemetry, you need to install Kubernetes and App Service Monitoring. See Install Kubernetes and App Service Monitoring.

Monitoring Kubernetes Services

Kubernetes and App Service Monitoring supports two workflows for collecting OpenTelemetry trace data from Kubernetes services:

  • Services that have been previously instrumented (all language runtimes).
  • Services that have not been instrumented yet (auto-injection in Java, Python, and Node.js runtimes).

Services Already Instrumented with OpenTelemetry

For services that have been already instrumented using OpenTelemetry, the agent/SDK exporter configuration should be updated to send trace data to the AppDynamics OpenTelemetry Collector Service deployed by the AppDynamics Cloud Helm chart. For this workflow, follow these steps:

  1. Install Kubernetes and App Service Monitoring
  2. Send Trace Data to AppDynamics Distribution for OpenTelemetry
  3. Configure OpenSource OpenTelemetry Collector to Send Trace Data to AppDynamics Cloud

Services Not Yet Instrumented with OpenTelemetry

For services that have not been instrumented with OpenTelemetry the OpenTelemetry Operator in Kubernetes and App Service Monitoring supports injecting and configuring OpenTelemetry auto-instrumentation agents in Java, Python, and Node.js application pods. For this workflow, follow these steps:

  1. Install Kubernetes and App Service Monitoring
  2. Auto-Instrument Kubernetes® Services

Monitoring Services Not Running on Kubernetes

For services that are not running on Kubernetes that are instrumented with OpenTelemetry, the tracing data can be sent to AppDynamics Cloud. From the AppDynamics Cloud UI you can view the tracing interactions and APM data associated with these services. The non-Kubernetes services are not correlated with infrastructure, which is only supported by Kubernetes services at this time. See Configure OpenSource OpenTelemetry Collector to Send Trace Data to AppDynamics Cloud.

Infrastructure Correlation

Kubernetes and App Service Monitoring provides the ability to correlate application OpenTelemetry™ Operator For Kubernetes traces to Kubernetes infrastructure metrics and logs. For correlation to happen, the application traces must have container.id as a resource attribute. See Enable Infrastructure Correlation for Non-Java OpenTelemetry Instrumented Services.

Not every language enables correlation, see language-specific OpenTelemetry docs. The following OpenTelemetry™ Operator For Kubernetes details are for Java, .NET, Node.js and Go:

OpenTelemetry for Java

When you auto-instrument the Java Agent, the Container resource is enabled by default, and the hostname is captured, on any SDK that uses auto-configure.

labelvalue
container.id
<container id>

AWS EC2

Not bundled with the Java Agent by default.

labelvalue
cloud.platformAWS
host.id <host id >
cloud.availability_zone <availability zone >
cloud.region <region>
cloud.account.id <account id >

Also, AWS Elastic Beanstalk, AWS Lambda, and Amazon ECS support see each class here: AWS Resource Extensions.

AWS EKS

Not bundled with the Java Agent by default. Requires configuring an EKS token. See https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/aws/src/main/java/io/opentelemetry/sdk/extension/aws/resource/EksResource.java.

labelvalue
cloud.platform AWS
container.id <container id>

cluster.name 

<cluster name>

OpenTelemetry for Node.js

OpenTelemetry detectors are available to capture container metadata based on the container type. See npm package resource-detector-aws. These can be added to the tracing code:

ECS

import { detectResources } from '@opentelemetry/resources';
import { awsEcsDetector } from '@opentelemetry/resource-detector-aws'
const resource = await detectResources({
   detectors: [awsEcsDetector],
})

const tracerProvider = new NodeTracerProvider({ resource });
JS

EKS

import { detectResources } from '@opentelemetry/resources';
import { awsEksDetector } from '@opentelemetry/resource-detector-aws'
const resource = await detectResources({
   detectors: [awsEksDetector],
})

const tracerProvider = new NodeTracerProvider({ resource });
JS

Additional Detectors are available awsBeanstalkDetector, awsEc2Detector, awsLambdaDetector

OpenTelemetry for Go

The Go OpenTelemetry SDK provides detectors for collecting container.id information for containers in ECS, EKS  environments. These detectors can be enabled in code by placing these lines in the application during SDK initialization.

ECS

// Instantiate a new ECS Resource detector
ecsResourceDetector := ecs.NewResourceDetector()
resource, err := ecsResourceDetector.Detect(context.Background())

// container.name container.id are collected and annotated to resource metadata
YML

EKS

// Instantiate a new EKS Resource detector
eksResourceDetector := eks.NewResourceDetector()
resource, err := eksResourceDetector.Detect(context.Background())

// k8s.cluster.name container.id are collected and annotated to resource metadata
YML

OpenTelemetry for .NET

OpenTelemetry detectors are available to capture the container.id based on the environment type. It is not bundled with opentelemetry-dotnet sdk by default. These detectors can be enabled in code by adding the required package and below lines in the sample application.

Amazon ECS:
An additional package needs to be added to extract the resources from an ECS environment. See opentelemetry-dotnet-contrib project.

using OpenTelemetry;
using OpenTelemetry.Contrib.Extensions.AWSXRay.Resources;
using OpenTelemetry.Contrib.Extensions.AWSXRay.Trace;
 
Sdk.CreateTracerProviderBuilder()
    .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("aws-otel-integ-test").AddTelemetrySdk().AddDetector(new AWSECSResourceDetector()))
    .AddXRayTraceId()
    ...
    .Build();
 
 Sdk.SetDefaultTextMapPropagator(new AWSXRayPropagator());
CODE


Amazon EKS:
An additional package needs to be added to extract the resources from an EKS environment. See opentelemetry-dotnet-contrib project.

using OpenTelemetry;
using OpenTelemetry.Contrib.Extensions.AWSXRay.Resources;
using OpenTelemetry.Contrib.Extensions.AWSXRay.Trace;
 
Sdk.CreateTracerProviderBuilder()
    .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("aws-otel-integ-test").AddTelemetrySdk().AddDetector(new AWSEKSResourceDetector()))
    .AddXRayTraceId()
    ...
    .Build();
 
 Sdk.SetDefaultTextMapPropagator(new AWSXRayPropagator());
BASH


AKS:

An additional package needs to be added to extract the resources from a Docker environment. See opentelemetry-dotnet-contrib project.

using OpenTelemetry;
using OpenTelemetry.Extensions.Docker.Resources;
var tracerProvider = Sdk.CreateTracerProviderBuilder()
                        // other configurations
                        .SetResourceBuilder(ResourceBuilder
                            .CreateEmpty()
                            .AddDetector(new DockerResourceDetector()))
                        .Build();
BASH

All these resources can be extracted only if the containers are running in a Linux environment, not in a Windows environment. 

OpenTelemetry™ and Kubernetes® (as applicable) are trademarks of The Linux Foundation®.