Solution

1. Log in to the Cluster Control Manager (CCM) console as the customer user.
2. To switch to the root user, type su - and press Enter.
3. Run the following command to view the last log entries for one of the microservices:
   ADDITIONAL INFORMATION:

   for i in $(kubectl get pods | grep async-oceana-adapter | awk '{print $1}'); do echo "**** Logs for Pod $i *****"; echo " "; kubectl logs $i async-aggregator-interface | tail -n 100; done
4. If the logs display data flowing in from the customer, do the following:
   1. Verify that your Messaging endpoint is configured correctly according to your hardware deployment configuration, and is publicly accessible.
   2. If the endpoint is publicly accessible, contact the DevOps team and ensure the team has correctly configured the Messaging endpoint. The DevOps team can also view the logs of the Cloud Provider applications to check whether the Cloud Provider can make a request to your Avaya Common Services (Common Services) Cluster.
   3. If steps a and b are correct, then verify that the customer is configured to the correct Cloud Provider application ID.
5. If the logs do not display data flowing in from the customer, do the following:
   1. Verify that there are no errors, the tenant/application ID is correctly configured for the deployment, and the message is sent.
   2. If there are no errors in the logs, run the following command:
      ADDITIONAL INFORMATION:

      for i in $(kubectl get pods | grep async-oceana-adapter | awk '{print $1}'); do echo "**** Logs for Pod $i *****"; echo " "; kubectl logs $i async-oceana-adapter | tail -n 100; done
6. If the logs display data flowing in from the customer, but there are errors while making a request to Avaya Oceana®, do the following:
   1. Verify that the Avaya Oceana® FQDN is correct and follows the standard FQDN specifications.
   2. Verify that Avaya Oceana® is operational.
   3. Verify that the System Manager CA and Identity certificate are configured for Messaging.
      ADDITIONAL INFORMATION:

      Note:

      You can also view the logs using Kibana by accessing https://<your.Common Services.cluster.fqdn>/app/kibana.

      The following KSQL queries help you isolate the issue:

      • Get all logs for the Messaging Connector microservices:
        kubernetes.pod_name :*async* and not kubernetes.container_image :*istio*
      • Get any errors occurred for the Messaging Connector microservices:
        kubernetes.pod_name :*async* and not kubernetes.container_image :*istio* and level :error
      • Track a specific Message ID as it flows through the system:
        kubernetes.pod_name :*async* and not kubernetes.container_image :*istio* and message :*{the.message.id}*