cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Docker (swarm) process group detection rules (Redis)

Rapidez
Visitor

Hi, 

By default, Dynatrace uses image names as identifiers for individual process groups, with one process-group instance per host. This behavior means that every instance of container based on the same image is recognized as the same process group name. In Redis case many of our applications uses the same base image from our local repository (artifactory). The image should be reusable.
Because of that we have a problem with tagging process groups by names and assign process group to certain application management zone. It is a big issue for us.

Is there any solution to split process groups by another parameter (ex. container name) ? Redis IS NOT deep monitored process so simple and advanced detection rules do not work)

11 REPLIES 11

AurelienGravier
Advisor

Hello @Rapidez 

 

If i'm focusing on this need : "Because of that we have a problem with tagging process groups by names and assign process group to certain application management zone."

 

It's possible to use entity selector on management zone to add services based on relationships :

https://www.dynatrace.com/support/help/how-to-use-dynatrace/management-zones/management-zone-rules#e...

Very helpful to add all databases requested by a specific service already on your management zone but it could be a workaround on your case.

Example of condition with the 'journey service':

AurelienGravier_1-1673000698004.png

Regards

Observability consultant - Dynatrace Associate/Pro/Services certified

Rapidez
Visitor

Hi @AurelienGravier , thank you for your replay.

Yes, I know this feature but in my case I want to tag Redis process with the name of application which uses this certain instance of Redis process.

The problem is that Redis is not deep monitored technology so there is no service recognized by Dynatrace. It has only additional technology (Redis) metrics gathered by OneAgent extension.

The only way is to have a possibility to distinguish Redis instances, but I think it is not possible for dockerized redis processes in case many containers (different applications) uses the same image name (process grouping for docker is based on image name)


 

Rapidez
Visitor

After consulting the topic in a chat with the support team, I would like to request the addition of the ability to separate groups of processes for technologies not monitored at the "deep level" (e.g. Redis) , and running as a docker container using the various available parameters. At a minimum, there should be an option to choose between image name and container name.

mdouds
Helper

Hi @Rapidez 

Check out the Processes and containers Built-in detection rules - "Use Docker container name to distinguish multiple containers"

Description:

By default, Dynatrace uses image names as identifiers for individual process groups, with one process-group instance per host. Normally Docker container names can't serve as stable identifiers of process group instances because they are variable and auto-generated. You can however manually assign proper container names to their Docker instances. Such manually-assigned container names can serve as reliable process-group instance identifiers. This flag instructs Dynatrace to use Docker-provided names to distinguish between multiple instances of the same image. If this flag is not applied and you run multiple containers of the same image on the same host, the resulting processes will be consolidated into a single process view. Use this flag with caution!

After enabling this, you can also define some custom process detection rules to further separate the process groups based on your environment criteria, etc.

Rapidez
Visitor

@mdouds  I have checked this before posting a topic here.

Checking "Use container name to distinguish .... " only makes each container instance visible as a separate process on the host view. The processes are still assigned to process groups distinguished by the image name. Another issue I mentioned earlier is related to the fact that processes that are not deeply monitored by oneagent are not affected by custom detection rules.

I may be missing something obvious, I do not think deep-monitoring affects these process group detection rules.

We have a docker swarm with oneagent installed but only a small subset of services have deep monitoring enabled. After checking that option and setting up a container-based advanced detection rule, our containers are grouped correctly using a substring of the container name. 

Have you tried combining that feature with an advanced detection rule based on the "Container" property?

 

Here's what we are using:

We have a generic docker image for a large group of nodeJS processes. So our advanced detection rule is based on that image name, then we use the Container property to extract the container name up to a period:

mdouds_0-1673292524008.png

From a process group perspective, each application is now grouped together by container name, regardless of the deep monitoring setting. 

Rapidez
Visitor

I'm sure simple and advanced rules do not affect not deep monitored process. It's described here:

Rapidez_0-1673292666780.png

Rapidez_1-1673292699864.png

It can be tricky. In most cases, container names are similar to image names and default behavior works well. My case is connected with Redis containers (not deep monitored technology). I have situation where different applications uses the same image name from repository. In this case Dynatrace is grouping redis containers in one group. It means I can't tag the group of Redis process separately and assign it to different management zones.

 

Ok, in that case I'm very confused as to how our NodeJS apps with deep-monitoring disabled are being included in the same advanced detection rules as our enabled apps 😀

Rapidez
Visitor

@mdouds NodeJS is deep monitored. You have it on the list and you can restrict rule to this technology. Try to do the same with Redis technology. In my case, it doesn't work. 

That is not true in our case. We have explicitly defined a rule in this docker swarm to disable deep monitoring by default, even for NodeJS processes. However, I understand this does not help your Redis use case.