Baking an APM agent into an application image ties agent maintenance to the image build. Even when the application code has not changed, an agent update can mean another build, registry push and deployment.

JENNIFER’s automatic-installation approach uses an init container to prepare the agent separately. Teams can manage the monitoring package and settings without rebuilding the application image. The workload still needs to go through its startup and rollout process.

Prepare the agent before startup

Kubernetes runs regular init containers to completion, in order, before the application containers start. Each must succeed before the next stage begins. Shared volumes let init containers provide files to application containers.

In JENNIFER’s design, the initialization step downloads the selected agent package and configuration into a shared volume. The application container then uses those files with the appropriate runtime options. For Java, these include the JVM’s agent-loading option. The application image can stay unchanged while the agent package and settings are managed separately.

Connect the workload to a configuration

The documented workflow has three steps:

  1. Register the appropriate agent package and version.
  2. Create a configuration ID that associates the package with its monitoring options.
  3. Add that ID to the workload’s Pod-template annotations, then roll out the workload.

The annotation key is k8s.jennifersoft.com/apm-agent-config-id. Use the ID generated by your JENNIFER installation, and confirm that the runtime and package are supported before applying it.

Kubernetes annotations hold metadata as string keys and values. Keeping the monitoring reference in the workload’s managed configuration gives reviewers a place to check which setting the workload should use.

Plan the rollout and recovery

For a Deployment, changing the Pod template triggers a rollout. The controller replaces Pods according to the deployment strategy. Changing only the Deployment’s top-level metadata does not make the same change to the Pod template.

Treat the agent update as an operational change. Assign an owner, start with a suitable test workload and keep the previous known-good package and configuration. Agree on a recovery procedure before expanding the change, especially if several applications share a configuration reference. Record the agent package version with the deployment change so it is available during later incident reviews.

Verify startup and transaction reporting

First check that the new Pods initialize successfully. An incomplete regular init container prevents the application from starting. If initialization stalls or fails, inspect its status and logs to find the preparation step that needs attention. Kubernetes exposes this status separately from application-container status.

Then send representative traffic through the application and check the monitoring result. JENNIFER’s application view connects the Pods serving an application with its transaction-performance information. Confirm that the expected workload is reporting and that the transactions you need are visible.

A ready Pod is only part of that check. Before accepting the rollout, verify that the agent is collecting useful APM data as well. With package selection, configuration, rollout and validation recorded together, the team has a process it can reuse for the next agent change.