Troubleshooting errors in the App Connect Dashboard

To obtain detailed logging of interactions in the App Connect Dashboard, you can enable debug logging either while creating the Dashboard instance or by editing the custom resource (CR) settings after the Dashboard is created.

• To enable debug logging for the container logs, set the spec.logLevel parameter in the App Connect Dashboard CR to debug.

  
  You can subsequently retrieve the debug logs for the Dashboard UI container by running the following commands to obtain the Dashboard pod name and then write the pod logs to a file (for example, /tmp/dashboard.logs):

  PODNAME=$(kubectl get pods -n namespaceName -l release=dashboardName)
  kubectl logs $PODNAME -n namespaceName -c control-ui > /tmp/dashboard.logs

• To restore the default level of logging, set spec.logLevel to info.

While attempting to access the Configuration page or Configuration panel from the App Connect Dashboard (as described in Configuration types for integration servers and integration runtimes), you might see the following s3Credentials configuration error:

Error occurred while trying to load configurations: invalid configuration type: s3Credentials
Message from the server: invalid configuration type: s3Credentials

This error is expected to occur only if IBM App Connect Operator 1.5.0 (or later) is installed in your cluster and the version (spec.version) of your App Connect Dashboard instance resolves to 11.0.0.12-r1 or earlier. Because support for the S3Credentials configuration type is introduced in IBM App Connect Operator 1.5.0 and App Connect Dashboard 12.0.1.0-r1, an error is emitted if an 11.0.0.12-r1 or earlier Dashboard detects the existence of an unsupported configuration object of type S3Credentials in its namespace. This configuration type provides support for Simple Storage Service (S3) compatible Dashboards, as described in Dashboard reference: Storage.

To resolve this error, complete either of the following actions:

• Upgrade your existing 11.0.0.12-r1 or earlier App Connect Dashboard instance to a spec.version value that resolves to 12.0.1.0-r1 or later. For more information, see Upgrading your instances and spec.version values.
• Delete the configuration object of type S3Credentials from the namespace. Only take this action if you are confident that the configuration object is not being used.

For Dashboard instances that are hosting approximately 60 (or more) integration servers or integration runtimes, you might see the following error after a small delay when you try to open a Dashboard:

Error 3.5.0.0 (timestamp) x86_64

This error typically indicates that the Dashboard pod has crashed. To confirm, complete the following steps:

1. Retrieve the list of pods in the namespace where the Dashboard is installed:

   oc get pods

   You should see output similar to this, with the Dashboard pod name given as dashboardName-dash-uniqueID. (The value in the STATUS field might vary.)

   NAME                                                        READY   STATUS      RESTARTS   AGE
   ...
   feedee-dashbd-dash-6f8d5bcb74-869xp                         2/2     Running     3          4d5h
   ...

2. To obtain more detailed information about the Dashboard pod, run the following command:

   oc describe pod podName

   For example:

   oc describe pod feedee-dashbd-dash-6f8d5bcb74-869xp

3. Review the output to see whether any out of memory (OOM) errors are reported by searching for the text OOMKilled.

If you see any OOM errors, this indicates that the CPU or memory needs to be increased. You can do so by updating the relevant settings in the Dashboard custom resource (CR):

1. Use a command such as oc edit to partially update the CR, where instanceName is the Dashboard name (that is, the metadata.name value in the CR):

   oc edit dashboard  instanceName

   This command will automatically open the default text editor for your operating system.

2. Update the spec.pod.containers.control-ui.resources.limits.cpu and spec.pod.containers.control-ui.resources.limits.memory values as follows. (These are the current default values, but your Dashboard CR might have lower values if it was created by using a Development sample or a CR from an earlier version.)

   spec:
     pod:
       containers:
         control-ui:
           resources:
             limits:
               cpu: '1'
               memory: 512Mi

3. Save the YAML definition and close the text editor to apply the changes.
   
   

   Note: If you continue to see OOM errors for the pod after you save, update the CR again to further increase the values. Tuning your CPU and memory in this way is recommended only if your App Connect Dashboard hosts up to 100 integration servers or integration runtimes. Do not run more than 100 integration servers or integration runtimes within a single namespace if you intend to use the App Connect Dashboard to monitor them.

If a PersistentVolumeClaim (PVC) is in a Pending state, a Dashboard deployment can remain stuck as Pending with the following error:

Waiting for PVC to be 'Ready'. Currently 'Pending'

For a Dashboard deployment to complete, its PVC must be in a bound state. A PVC is typically created and bound to the cluster quickly, but if it fails to bind, the PVC might get stuck in a Pending state, which in turn stops the Dashboard deployment from completing. If the PVC is shown as pending after a reasonable wait, you can investigate and resolve the issue as follows.

From the Red Hat OpenShift web console, complete the following steps to track the progress of the deployment and resolve the error:

1. From the Dashboard tab in your IBM App Connect Operator deployment, click the Dashboard instance name and then check the messages in the Conditions section of the Details tab.
   
2. If you see the message indicating that the PVC is currently pending, complete the following steps to investigate why its provisioning is not succeeding:
   1. Click Storage > PersistentVolumeClaims.
   2. From the PersistentVolumeClaims page, locate and then click the PVC name for the Dashboard. PVC names are in the format dashboardName-content.
      
   3. From the PersistentVolumeClaim details page, click the Events tab. Then review the messages to help you determine why the PVC provisioning failed and resolve the error.