Implementing and Managing Auto Instrumentation with AppDynamics Cluster Agent
The Cluster agent uses the init-container approach to instrument apps based on the rule you wish for. It can be used to specifically target apps that belong to a namespace, contain a specific label, or can be for a specific deployment or container name. Again, the Cluster agent can also be tweaked to automatically push one of the 3 APM agents i.e. Java, .NET Core, or Node.JS APM agents.
Looking at the requirements for the Cluster agent, there are not any details on how much the resource requirement is if the Cluster agent auto instrumentation is enabled. This is because of the way the auto instrumentation is done.
Technically speaking one single instance of the Cluster agent is capable of instrumenting an infinite number of deployments but in general as mentioned (in the AppDynamics Doc link above), for every 100 pods 50 MB of memory and 100 Milicores of CPU is required by the Cluster Agent.
Steps involved in auto instrumentation:
- The Cluster agent deployed on env and begins checking deployments/statefulsets and replicasets which confirmed to the instrumentation rules configured.
- The Cluster agent modifies deployments/statefulset and sets them to pending status, and adds the init container and the env variables required for the agent to connect to the controller.
- The rollout of these modified deployments or statefulset happens and the Cluster agent in general does 2 depth checks on the new created pods to ensure auto instrumentation is complete.
- First depth check to check for agent binary in /opt/appdynamics-java or /opt/appdynamics-nodejs or /opt/appdynamics-dotnetcore folder.
- Second depth check to see the APM agent node logs exist - for eg., /opt/appdynamics-java/ver*/logs/. It also does a controller API check the node name exists in UI.
- If both succeed and the rollout is complete the annotation of the deployment gets updated from pending to successful. If not then it's marked failed and Cluster Agent wont re-target them again.
The init-containers are spawned with a fixed Memory and CPU request and limits cannot be modified - i.e. they are hardcoded. They are hardcoded as the init container lifecycle exists only till the binary is not copied to the new pod. Thus in real life the init container exits before the actual container is loaded and started. Also, since the actual container is always bigger than the init container the scheduler will always schedule pods based on the actual container requirement - which is always supposed to be more than the init container.
Having said this the rollout strategy does have a play on the total memory requirement as Cluster agent may create pods which are being spawned with an additional CPU and memory requirement at the start of the pods. This however should be similar to when the app is upgraded as the same rollout strategy comes into play here as well.
