Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Introduction

This guide provides troubleshooting instructions for CTLive and is intended for Tier 1 and Tier 2 support. If the issue cannot be resolved through preliminary checks, a ticket on IRRTBUGS project should be created to involve R&D.

Preliminary Checks

Before opening a ticket, perform the following checks:

Infrastructure Status Check

Linux deployment

  • Docker Compose: Ensure all containers are running using docker ps or docker compose ps in the dir containing the docker-compose.yaml (e.g. /etc/ctlive). The usual list of all ctlive modules is:

    • ctlive: core module

    • ctlivebot: connector to external bots

    • ctlivemgr: Admin UI

    • ctlivesocial: connector to social channels (excluded infobip)

    • httperror: it provides a custom http error page

    • imchannel: connector to infobip per whatsapp channel

    • mongodb: main DB containings both settings and contact data (metadeta, transcripts, attachements and images)

    • redis: memory cache to store temporarily data

    • nginx: reverse proxy

  • System Resources: Monitor CPU, memory, and disk space using top, free -m, and df -h.

Log Inspection

Application logs contains important info and most of the time shows the cause of the issues

In a docker compose deployment, they can be checked launching the following command in the base dir (/etc/ctlive)

docker compose logs <container_id> -t | less

Piping the output to less is helpful to search quickly inside the files

“docker compose logs <container_id> -tf” show real-time logs. It’s recommended only during specific tests (not on production for the amount of logs expected)

Refer to the dedicated page for additional info

Nginx

Format

It logs all the incoming http requests. It uses a fixed format:

nginx  | 10.10.10.10 - - [27/Feb/2025:15:44:57 +0000] "POST /imchannel/agm/message HTTP/1.1" 200 28 "-" "java/socket" "-"

It shows the:

  • modulename

  • timestamp ( check the timezone)

  • the request method (GET, POST, OPTIONS)

  • url

  • status code (200 OK, 404 Not Found, 503 Service Unavailable etc)

  • response length

  • Referer (the main page requesting the URL)

  • User-Agent

  • x_forwarded_for

Use cases

Check if messages are incoming from social channels: Looks for /imchannel or /ctlivesocial

Check for not 200 status codes

docker compose logs nginx | grep -v " 200 " | grep -v " 304 " | grep -v " 101 "

Error messages

Besides the access log, nginx reports also internal errors like the following

nginx  | 2025/02/27 14:13:38 [error] 19#19: *4519 connect() failed (111: Connection refused) while connecting to 
upstream, client: 10.10.10.10, server: , 
request: "GET /livechat/socket.io/?EIO=4&transport=polling&t=fd6wt5m8 HTTP/1.1", 
upstream: "http://10.10.0.10:3009/livechat/socket.io/?EIO=4&transport=polling&t=fd6wt5m8", 
host: "ctlive", 
referrer: "http://ctlive:17002/"

It reports that nginx is not able to proxy the request to the internal service (upstream) for a connection refused error.

CTLive

  • CTLive: View application logs using docker logs <container_id> or kubectl logs <pod_name> -n <namespace>.

  • MongoDB Database: Check logs for errors using docker logs <mongo_container_id>.

  • Nginx: Inspect access and error logs at /var/log/nginx/access.log and /var/log/nginx/error.log.

  • Redis: Verify connectivity and availability using redis-cli ping.

2.3 Connectivity Check

  • Network Testing: Verify service reachability using ping, telnet, curl, or nc.

  • Database Connection: Use a MongoDB client (mongosh) to confirm connectivity.

2.4 Functional Application Testing

  • Check if the issue is reproducible by accessing CTLive.

  • Test with different credentials and user accounts.

  • Look for error messages in the frontend.

3. Creating a Jira Ticket

If the issue persists after preliminary checks, open a ticket in the IRRTBUGS project on Jira, including the following details:

  • Clear problem title

  • Detailed description with steps to reproduce the issue

  • Screenshots and/or error logs

  • Results of preliminary checks

  • Customer impact (e.g., number of users affected, severity of the issue)

4. Escalation

If the ticket does not receive a response within the SLA timeframe, directly contact the R&D representative via Slack or email.

5. Useful Contacts

  • Internal Support:

  • R&D Escalation: <R&D email>

  • Support Slack Channel:


By following these guidelines, the support team can ensure efficient handling of issues encountered in CTLive.

  • No labels