Cloud application and workload detection

Dynatrace allows automatic detection of cloud applications and workloads in your Cloud Foundry and Kubernetes environments. Cloud applications and workloads group similar processes into process groups and services and thus allow for version analysis.

Cloud application and workload detection provides

Starting with Dynatrace version 1.258 and OneAgent version 1.257

See below for how to use Kubernetes workload properties for grouping processes of similar workloads. In addition, generic process detection rules still apply, while ignoring container or platform specific properties.

Workload detection rules for Kubernetes

By default, Dynatrace separates process groups and services for every Kubernetes workload.

You can define rules to support your release strategies (such as blue/green, canary) by using workload properties like Namespace name, Base pod name, or Container name, as well as the environment variables DT_RELEASE_STAGE and DT_RELEASE_PRODUCT for grouping processes of similar workloads. You can also specify the version and build version of the deployed workload by setting the DT_RELEASE_VERSION and DT_RELEASE_BUILD_VERSION environment variables. This gives you extended visibility into the impact of releases on your services.

The rules are scoped for Kubernetes namespaces so that you can easily migrate your existing environment namespace by namespace. The first applicable rule in the list is applied. If no rule matches, the combination of Namespace name, Base pod name, and Container name is used as a fallback.

To create a rule

Impact on the default process group naming

OneAgent versions 1.241+

Dynatrace aims to provide intuitive names for process groups that make sense for DevOps teams. Creating rules for Kubernetes workloads also affects the composition of meaningful default names for process groups. The default pattern for {ProcessGroup:DetectedName} is as follows: “<tech_prefix> <product> <STAGE> <base_pod_name>”, where

Example: "index.js emailservice PROD", where

If the default process group naming is too generic or doesn't reflect your naming standards, you can always customize it by creating process group naming rules.

Example - best practices with Kubernetes labels

We recommend that you propagate Kubernetes labels to environment variables in the deployment configuration (see Version detection with Kubernetes labels) using the Downward API:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: emaildeploy
5spec:
6  selector:
7    matchLabels:
8      app: emailservice
9  template:
10    metadata:
11      annotations:
12        metrics.dynatrace.com/path: /stats/prometheus
13        metrics.dynatrace.com/port: "15090"
14        metrics.dynatrace.com/scrape: "true"
15      labels:
16        app: emailservice
17        app.kubernetes.io/version: 0.3.6
18        app.kubernetes.io/stage: production
19        app.kubernetes.io/name: emailservice
20        app.kubernetes.io/part-of: online-boutique
21    spec:
22      serviceAccountName: default
23      terminationGracePeriodSeconds: 5
24      containers:
25      - name: server
26        image: gcr.io/google-samples/microservices-demo/emailservice:v0.3.6
27        ports:
28        - containerPort: 8080
29        env:
30        - name: PORT
31          value: "8080"
32        - name: DT_RELEASE_VERSION
33          valueFrom:
34            fieldRef:
35              fieldPath: metadata.labels['app.kubernetes.io/version']
36        - name: DT_RELEASE_PRODUCT
37          valueFrom:
38            fieldRef:
39              fieldPath: metadata.labels['app.kubernetes.io/name']
40        - name: DT_RELEASE_STAGE
41          valueFrom:
42            fieldRef:
43              fieldPath: metadata.labels['app.kubernetes.io/stage']
44        - name: DISABLE_TRACING
45          value: "1"
46        - name: DISABLE_PROFILER
47          value: "1"
48        readinessProbe:
49          periodSeconds: 5
50          exec:
51            command: ["/bin/grpc_health_probe", "-addr=:8080"]
52        livenessProbe:
53          periodSeconds: 5
54          exec:
55            command: ["/bin/grpc_health_probe", "-addr=:8080"]
56        resources:
57          requests:
58            cpu: 100m
59            memory: 64Mi
60          limits:
61            cpu: 200m
62            memory: 128Mi
63---

As a next step, this configuration can then be easily leveraged with one rule - Namespace exists.

As an outcome of the applied configuration, Dynatrace will merge similar processes and services with the same Product, Stage, Container name, and Namespace values. Because all these values are identical, this rule also makes workloads merge across different Kubernetes clusters into the same process group.