question

Juha-matti H. avatar image
Juha-matti H. asked ·

Multi-environment setup with shared docker images

Hello,

Is there anyway of disabling Dynatrace externally once its inside a Docker container? I'd like to utilize the same Docker image through the whole pipeline DEV/TEST/STAGING/PROD envs, but not necessarily monitor our DEV environments in full depth. Problem is this does not seem to be so easily, if not at all possible to do?

You can disable hosts on the UI, but each container pops up as a new host, so thats rather a whack-a-mole game. Have tried to inject DT_CUSTOM_PROPS to the env variables of Fargate, but that just gets lumped into a single service in Dynatrace having all of the Environment tags, instead of being apple to separate DEV service from TEST service and so fort. We are using NodeJS inside the containers, so it seems it simply grabs the package.json name and uses that as service name, where ever it might be running. Even if the custom props would separate services, the Host naming does not support environment tags, so I see no way how I could automate the whack-a-mole game...

How would I run the same images in different environments, without actually being forced to also monitor that environment?

And further on, how would I clearly separate DEV service from TEST service in the data?

monitoringdockernodejspaastipstricks
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

1 Answer

Julius L. avatar image
Julius L. answered ·

I guess you are using the paas agent in the do cker image. How are your process groups organized? I would disable monitoring on the process group level for the process groups belonging to the dev environment. This should satisfy your requirements.

2 comments Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

This seems to be precisely what I was after, but I'm really struggling to get this to work. Latest agent (1.165. version actually names process groups automatically based on ECS container / family names, meaning we get something like "dist/index.js (service) app-dev-service" as the process group names.
Tried to set from Process Monitoring rules to "Do not monitor processes if AWS ECS Family name contains 'app-dev' " and al sorts of other rules, but these don't seem to take much effect. Contains, begins, matches against family/cluster names, but the services still get instrumented.

0 Likes 0 · ·

If it's just and only about "Do not monitor DEV environment at all" - you can set the DT_CONNECTION_POINT variable to something non-reachable (not the empty string) in your container entrypoint script - if your entrypoint script is aware of the environment. Processes will be instrumented, but agents will not connect, thus monitoring won't be available.

0 Likes 0 · ·

Space Topics

mobile monitoring dotnet synthetic monitoring reports iis chat kubernetes servicenow amazon web services mysql mainframe rest api errors cassandra dashboard oneagent sdk cmc application monitoring openkit smartscape request attributes monitoring developer community user tagging log monitoring services ufo syntheticadvisory activegate ip addresses auto-detection high five award oracle hyperion webserver uem usql iib test automation license web performance monitoring ios news migration management zones index ibm mq web services custom event alerts notifications sso host monitoring knowledge sharing reports browser monitors java hybris sap vmware maintenance window user action naming javascript appmon ai synthetic classic availability tipstricks automation extensions diagnostic tools session replay permissions davis assistant faq documentation problem detection http monitors server easytravel apdex aws-quickstart network docker tags and metadata cloud foundry google cloud platform synthetic monitoring process groups account usability dynatrace saas gui paas openshift key user actions administration user actions postgresql synthetic locations oneagent security Dynatrace Managed user management custom python technologies mongodb openstack user session monitoring continuous delivery citrix configuration alerting NGINX timestamp action naming linux nam installation masking error reporting database mission control jmeter recorder apache mobileapp RUM php threshold azure purepath davis scripting agent aix nodejs android