Release Monitoring not working on processes without Code-Module?

[r_weber]

Hello,

I was rather surprised to learn that the release monitoring feature of Dynatrace seems to NOT WORK with processes where no code-level module exists.

I have two pods in my K8s playground, one contains a Nginx container and the other one a Python container. Both are configured with the same standard k8s labels for version, which is also propagated ton environment variables of the process in the deployment spec (as described in the documentation)

spec:
  replicas: 1
  selector:
    matchLabels:
      app: dt-metricexport
  template:
    metadata:
      name: dt-metricexport
      labels:
        app: dt-metricexport
        app.kubernetes.io/version: 1.0.0
    spec:
      containers:
        - name: dt-metricexport
          image: 360performance/dt-metricexport:latest
          imagePullPolicy: Always
          env:
          - name: PYTHONUNBUFFERED
            value: "1"
          - name: DT_RELEASE_VERSION
            valueFrom:
              fieldRef:
                fieldPath: metadata.labels['app.kubernetes.io/version']

In Dynatrace we can confirm the pod labels, however for Nginx (code module exists) more details are picked up (environment variables are propagated to tags automatically, release and stage meta info is created):

For python however (no code module), only the pod label is detected:

The Release overview page only shows Nginx:

In my opinion this means the feature is not complete and/or the documentation for it is not correct.
Please correct me if I'm wrong 🙂
According to the documentation you can use either environment variables OR K8s pod labels. Although the example states to also propagate the labels to environment variables.
In reality it seems that only environment variables (or the tags created from it?) are being used, and since environment variables are only evaluated for processes with code modules it fails for e.g. python processes.

Since the documentation states to stick to k8s recommendations for labeling, Dynatrace should also stick to using these labels directly. Otherwise there will be a discrepancy between other K8s management solutions and what can be seen in Dynatrace. That would be a shame and leaves this feature somewhat crippled.

I'd expect to see all processes on the release overview, not only those where Dynatrace is able to detect services due to code module support.

kr,

Reinhard

[r_weber]

Just confirmed by Dynatrace: my assumption was correct, release tracking only works with processes where code level modules are available and not for generic processes...that's a bummer.

[wolfgang_heider · Accepted solution]

Hi @r_weber , thanks for the feedback - we are aware of the limitation and have the plans in place to also propagate the k8s labels automatically as env.variables.

As stated in documentation, we recommend env.variables, as the full version visibility you can only have with env.variables. This way you also get traces decorated with this data, so that you can split any data based on versions. If you have any further questions to planned features, please also check out the backlog: https://community.dynatrace.com/t5/Feedback-channel/Planned-features-for-Release-Analysis/m-p/168249... 

[r_weber]

Hi @wolfgang_heider ,

thanks for confirming. The manual propagation is not that big issue, but even if they are propagted we would not get version/release info on containers with generic processes ( where no codwlevel visibility exists ).

IMO this has to do with the fact that Dynatrace does not evaluate env variables into tags for non-code module technology processes.