Downloading and Installing an Agent¶

Once an agent has been fully configured, it can be downloaded from the BizMetry platform and installed locally within the infrastructure where metrics will be captured.

Deployment Scenarios¶

A BizMetry agent can be deployed in two distinct topologies:

Co-located Deployment¶

The agent is deployed close to the applications running the business logic. In this mode, instrumentation can be captured either automatically — via auto-instrumentation — or manually using the BizMetry SDK.

Edge-location Deployment¶

The agent is deployed near remote applications, sensors, or processes that are generating metrics which need to be sensed and transmitted to BizMetry. As with co-located deployments, both automatic and manual instrumentation are supported depending on the use case.

Agent Packaging¶

BizMetry delivers the agent as a Docker image, bundled together with automation scripts that handle its deployment onto an existing Kubernetes cluster. Once installed, the agent begins synchronizing with the platform autonomously — no additional configuration steps are required.

Deployment Parameters¶

Depending on how the agent was configured, installation parameters are provided in one of two ways:

• Defined at configuration time — all required parameters were entered when the agent was set up in BizMetry. The installer will use them automatically.
• Provided at deploy time — when the agent was configured with the "I will provide deployment parameters at deploy-time" option selected, the required parameters must be entered manually when the installer is executed.

In either case, the following information must be available for the agent to be installed successfully.

Image Registry¶

The installer uses these credentials to push the agent Docker image to your registry before deploying it to the cluster.

Ingress Controller¶

The agent is deployed inside Kubernetes and requires an ingress so that business applications can communicate with it during manual or automatic instrumentation. BizMetry supports the following ingress technologies:

Target Architecture¶

Before downloading the agent, verify that the target architecture configured in the Deployment tab matches the architecture of the Kubernetes nodes where the agent will actually run. The agent image is compiled specifically for the selected architecture — if there is a mismatch, the container will fail to start after deployment.

BizMetry currently supports the following target architectures:

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.architecture}{"\n"}{end}'

Downloading the Agent¶

Before downloading the agent, ensure that all configuration sections have been reviewed and completed — in particular the internal and external security sections, where the respective URLs are specified so that the agent can be reached both from the BizMetry platform (external URL) and from the instrumented applications (internal URL).

To download the agent, click the Download icon on the corresponding agent card.

This will initiate the download process, which may take several minutes depending on your connection speed.

A progress bar indicates how much of the download has completed. Once it reaches 100%, the download is finished and a .ZIP file — referred to as the agent installer — will appear in your browser's downloads folder.

You can cancel the download process by clicking on the "Cancel Download" button.

Pre-Installation Checklist¶

Before running the installer, verify that your infrastructure meets the requirements for your deployment topology. Skipping this step is the most common cause of failed installations.

Co-located Deployment¶

In a co-located deployment, the agent sits alongside the business applications and must be reachable from two directions: from the BizMetry platform over the internet, and from the instrumented applications on the internal network. The following network path must be in place before installation:

BizMetry Platform
       │
       ▼  (HTTPS/TLS — agent external gateway address)
 External Load Balancer  ◄── DMZ, strict security rules
       │
       ▼  (TLS forwarding — internal network)
  Ingress Load Balancer  ◄── Kubernetes cluster ingress
       │
       ▼
   Agent Pod

External Load Balancer

An external load balancer must be in place and configured to listen on the URL you specified as the Agent External Gateway Address in the Security — External tab when configuring the agent in BizMetry. Any traffic arriving at that URL must be forwarded to the internal ingress load balancer. This load balancer is typically positioned in the organizational DMZ and should be governed by strict security rules.

Internal Ingress Load Balancer

The ingress load balancer on the internal network must be configured to accept TLS traffic. TLS termination at the ingress level maximizes the security of communications between the DMZ and the internal cluster network.

Pre-installation checks — Co-located

• A Kubernetes cluster is available and accessible from the host running the installer.
• The ingress controller type you selected during agent configuration matches the ingress controller actually deployed in the target cluster. A mismatch will cause the installation to fail.
• The host running the installer has network access to the image registry you intend to use.
• An external load balancer is configured and listening on the Agent External Gateway Address.
• The internal ingress load balancer is configured to accept TLS traffic.

Edge-location Deployment¶

In an edge-location deployment, the agent is installed as close as possible to the application, sensor, or client that generates the metrics — ideally within the same execution sandbox.

The network requirements follow the same two-tier pattern as co-located, with one key distinction: the external gateway must align with the proxy or load balancer already in front of the edge application or sensor.

External Gateway

The Agent External Gateway Address must match the URL configured on the proxy or load balancer where the edge application or sensor is already exposed. This endpoint must listen over TLS using the certificate you configured during agent setup in BizMetry.

Internal Ingress

As with co-located deployments, the external gateway must forward traffic to the internal ingress load balancer, which must support TLS traffic.

Pre-installation checks — Edge-location

• A Kubernetes cluster is available within the same network segment as the edge application or sensor.
• The ingress controller type selected during agent configuration matches the ingress controller deployed in the target cluster.
• The host running the installer has network access to the image registry you intend to use.
• The external proxy or load balancer in front of the edge application is configured to listen on the Agent External Gateway Address over TLS, using the certificate configured in BizMetry.
• The internal ingress load balancer is configured to accept TLS traffic forwarded from the external gateway.

Installation Steps¶

Step 1 — Transfer the installer to a secure location¶

Copy the downloaded .ZIP file to a secure location with access to your Kubernetes cluster. It is strongly recommended to use a bastion server that has authenticated, restricted access to the cluster.

Step 2 — Extract the archive¶

Unzip the archive. This will produce a directory with the following structure:

agent-install.sh
agent-uninstall.sh
agent.docker.tar
k8s.template.apisix.yaml
k8s.template.contour.yaml
k8s.template.haproxy.yaml
k8s.template.istio.yaml
k8s.template.kong.yaml
k8s.template.nginx.yaml
README.txt
tls_external_cert.pem
tls_external_key.pem
tls_internal_cert.pem
tls_internal_key.pem

The contents are described below:

Step 3 — Run the installer¶

Start the installation by executing the install script:

./agent-install.sh

If the agent was configured with the "I will provide deployment parameters at deploy-time" option enabled, the installer will interactively prompt for the following:

1. Image registry URL — where the agent image will be pushed
2. Image registry credentials — username and password
3. Registry project — the target project or namespace within the registry
4. Ingress controller type — the load balancer technology through which the agent will be exposed

Once all parameters have been confirmed, the installer will push the Docker image to your registry and apply the appropriate Kubernetes manifests to complete the deployment.

Uninstalling the Agent¶

To remove a previously installed agent from your cluster, run the uninstall script from the same extracted directory:

./agent-uninstall.sh

This will remove all Kubernetes resources associated with the agent deployment.

If the agent was configured with the "I will provide deployment parameters at deploy-time" option enabled, the installer will interactively prompt for the following:

1. Ingress controller type — the load balancer technology through which the agent will be exposed

Related Topics¶

• BizMetry Topologies
• Configuring an Agent
• Agent Security Settings
• Understanding Agent Synchronization
• Auto-Instrumentation
• Manual Instrumentation with BizMetry SDK