Skip to main content

Agent troubleshooting

Installation troubleshooting based on the Helm chart​

In case there is a whatap Helm repository with the same name​

"whatap" already exists with the same configuration, skipping

If another whatap repository with the same name already exists, delete the existing whatap repository by using the following command and then proceed with installation.

helm repo remove whatap

In case there is another namespace named whatap-monitoring in the cluster​

Error: INSTALLATION FAILED: Unable to continue with install: Namespace "whatap-monitoring" in namespace "" exists and cannot be imported into the current release

If the whatap-monitoring namespace exists in the cluster, it is because the user has already installed the Whatap Kubernetes agent based on the yaml file. In this case, delete the existing whatap-monitoring namespace and related resources by using the following commands.

kubectl delete namespace whatap-monitoring
kubectl delete clusterrolebinding whatap
kubectl delete clusterrole whatap

In case the clusterrole and clusterrolebinding resources exist in the cluster​

Error: INSTALLATION FAILED: Unable to continue with install: ClusterRole "whatap" in namespace "" exists and cannot be imported into the current release

If the clusterrole and clusterrolebinding resources already exist in the cluster, delete them by using the following commands.

kubectl delete clusterrolebinding whatap
kubectl delete clusterrole whatap

In case the whatap-monitoring namespace is unavailable​

By default, the WhaTap Kubernetes agent is installed in the whatap-monitoring namespace. However, if the namespace is unavailable or you need to specify a specific namespace, follow the steps below to install the agent in the desired namespace.

Preparation​

  • Cart version: whatap/kube 1.7.11 or later

    Check the chart version by using the following command.

    helm search repo whatap/kube --versions

    If the version is less than 1.7.11, update the chart version by using the following command.

    helm repo update

  • Helm version: Helm 3 or later

Installation procedure​

Install the agent by executing the following command, after entering the namespace to use in <namespace>.

helm install whatap-kube-agent whatap/kube --create-namespace --namespace <namespace> --set namespaceOverrideEnabled=true --wait -f values.yaml

Updating and deleting​

  • Update

    Execute the following command to update the agent.

    helm update whatap-kube-agent whatap/kube --namespace <namespace> --wait

  • Delete

    Execute the following command to remove the agent.

    helm uninstall whatap-kube-agent whatap/kube --namespace <namespace>


Troubleshooting issues that occur when starting the agent​

In case of installation of WhaTap Kubernetes Monitoring via an old YAML file​

Unrecognized VM option 'UseCGroupMemoryLimitForHeap'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

If you installed WhaTap Kubernetes Monitoring via the installation YAML downloaded before August 24, 2022, you may encounter an error or failure to start the node agent (whatap-node-agent).

Possible causes are as follows. The installation YAML file downloaded before August 24, 2022 contains a node agent launch script using the UseCGroupMemoryLimitForHeap JVM option.

Starting from WhaTap node agent 1.2.0 (released on November 21, 2022), the JDK used in the agent has been upgraded, and the upgraded JDK version no longer provides the UseCGroupMemoryLimitForHeap option. If you run the node agent 1.2.0 or later with the WhaTap Kubernetes Monitoring installed using a YAML file downloaded before August 24, 2022, the startup fails with the message Unrecognized VM option 'UseCGroupMemoryLimitForHeap’.

Solution​

To resolve this issue, reinstall the Kubernetes monitoring as follows:

  1. Download the latest YAML file by using Management > Agent Installation

  2. Install the agent by using the YAML file downloaded from the Kubernetes environment.

  3. Check whether any errors are output during installation in the Kubernetes environment.

  4. Make sure the WhaTap monitoring agent Pod is in Running state.

    Note

    Check the Kubernetes environment and the Workload > Pod List menu.

  5. Check the logs generated by each monitoring agent through Management > Kubernetes Agent List

Troubleshooting the application integration issues​

In case the Java monitoring data is not displayed in the container map​

Depending on the configuration and management for Cgroups in your Kubernetes environment, you may encounter the issues with obtaining container IDs in specific situations. To address this situation, WhaTap changed the mapping mechanism between the containers and applications for Kubernetes monitoring. This change applies to WhaTap Kubernetes Agent 1.7.7 and Java Agent 2.2.33, and addresses the issue where container IDs are missing due to Cgroups.

Solution​

Agent Update​

To resolve container ID identification issues in the Kubernetes environment, use the latest version that supports accurate identification of data exchanged between the WhaTap Kubernetes agent and APM. Install Kubernetes Agent 1.7.7 or later and Java Agent 2.2.33 or later.

Note

Currently only the Java agents are supported, and APMs for other languages are supported in the future.

Configuring additional environment variables​

If Java application information does not appear in Container Map even after updating the agent version, you can solve the problem by adding user environment variables. This setting adds the WHATAP_JAVA_AGENT_PATH option to the container manifest (YAML) environment variable where the Java APM has been installed, indicating the absolute path to the Java agent within the container.

The following is an example of adding the corresponding option to the container environment variables where the Java APM has been installed.

env:
- name: NODE_IP
  valueFrom: {fieldRef: {fieldPath: status.hostIP}}
- name: NODE_NAME
  valueFrom: {fieldRef: {fieldPath: spec.nodeName}}
- name: POD_NAME
  valueFrom: {fieldRef: {fieldPath: metadata.name}}
- name: OKIND
  value: {YOUR_OKIND_NAME}
- name: license
  value: <Project Access Key>
- name: whatap.server.host
  value: <collection server IP address>
- name: whatap.micro.enabled
  value: "true"
- name: WHATAP_JAVA_AGENT_PATH
  value: "/whatap/whatap.agent-2.2.35.jar"

How to check mapping between the container and APM​

The following explains how to check that the container and applications are mapped correctly.

  • If any white micro container exists inside the Container Map block in Dashboard > Container Map, it indicates a normal mapping.

  • In Analysis > Metrics Search, if the container field for the app_counter category contains the container ID in which the application is running, the mapping is successful.