Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Refer to the dedicated page for additional info

Nginx

...

Format

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

Code Block
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

Info

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

Code Block
breakoutModewide
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.

...

: log inspection

CTLive: log inspection

IMChannel: log inspection

Connection to DB

Accessing contact information often requires direct database interaction. For CTLive, this typically involves connecting to either the MongoDB or Redis database. To facilitate this, several tools and configurations are necessary, enabling efficient querying and retrieval of specific contact details. Detailed instructions and explanations on how to connect to and query these databases – MongoDB and Redis – residing on the CTLive server are available in the following articles. These articles provide comprehensive guidance on configuring the necessary tools for accessing and manipulating contact data within the CTLive system's databases.

MongoDB connection

Redis connection

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

  • Component

    image-20250227-163515.pngImage Added
  • Screenshots and/or error logs

  • Results of preliminary checks

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

...

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

...

Useful Contacts

  • Internal Support: contact.highway@enghouse.com

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

  • Support Slack Channel:

...

  • alessandro.rovetto@enghouse.com