Infrastructure Issues

If the application is unable to connect to the MongoDB database, it will not be able to read or write data, leading to errors or unexpected behavior.

If the MongoDB database is not optimized, it can lead to slow query response times or other performance issues, such as high memory usage or slow disk I/O.

MongoDB databases can encounter data consistency issues, such as duplicate data or missing data, which can lead to unexpected behavior or application errors.

MongoDB databases can have security vulnerabilities that attackers can exploit, such as unsecured databases or weak authentication and authorization mechanisms.

If the MongoDB database is not indexed correctly, it can lead to slow query response times or even crashes.

If the MongoDB database is configured for replication, issues such as data inconsistencies or replication lag can arise when replicating data across multiple servers.

If the MongoDB database is sharded, issues can arise when distributing data across multiple shards, such as imbalanced shards or slow query response times.

For MongoDB-related concerns as well, it is crucial that our support team is aware of the server instance being used by your application. Please share the details with us about the type of your instance, which can be from the following:

1. 1. 1. 1. Standalone instance
         2. Replica set
         3. Sharded cluster

Logs play an important role in debugging an issue related to MongoDB as well. To effectively utilize the logs for troubleshooting, we need to know about the Deployment type of Countly. It can be any of them from the following three options:

1. 1. 1. 1. VM
         2. Docker
         3. Kubernetes

For troubleshooting issues specific to MongoDB, our Support team requires information about the server and any associated load balancers. Nginx is the default load balancer of the Countly server; however, if you are using Docker or Kubernetes setup, you can use other web servers.

Lastly, please make sure to notify the support team about the version of Countly Server being used.

Use the following commands to access MongoDB logs based on your setup: 

Default path:

/var/logs/mongodb/mongod.log

Docker setup: 

docker logs <container name>

Kubernetes setup: 

kubectl logs <pod-name>

Note: If the above paths doesn’t exist, check the log path in /etc/mongod.conf - under systemLog.path: 

# mongod.conf
...
systemLog:
logRotate: reopen
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log <-- log path

If mongod.conf is missing, run systemctl status mongod and look under --config for the correct path: 

● mongod.service - High-performance, schema-free document-oriented database
Loaded: loaded (/etc/systemd/system/mongod.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2025-05-14 18:48:20 UTC; 1 weeks 6 days ago
Docs: https://docs.mongodb.org/manual
Main PID: 730 (mongod)
Memory: 583.4M
CGroup: /system.slice/mongod.service
└─730 /usr/bin/mongod --quiet --config /etc/mongod.conf <-- mongoDB config file path

mongostat gives a quick overview of the performance of a running mongod or mongos instance.

1. Requires auth parameters if enabled
2. Use mongostat --discover for sharded clusters
3. Dirty > 5% = write load is too high
4. Used > 80% = low RAM availability

mongotop shows read/write activity per collection in real-time.

1. Requires auth if enabled
2. Useful to identify slow collections
3. Run it over time to detect spikes or trends

current operations (currentOp) provides a full list of all running MongoDB operations

1. mongosh // include auth if required
2. db.currentOp()

You can use the following commands to save the outputs of each command to a file. 

1. mongostat -n 20 > mongostat.txt

2. mongotop -n 20 > mongotop.txt

3. mongo --eval "db.currentOp()" > currentops.txt

Note: mongostat and mongotop may take time to complete.

1. This helps you know about MongoDB stats.
2. Located in the MongoDB data folder named diagnostic.data.
3. Does not contain customer data.
4. Data path can be found in /etc/mongod.conf under dbPath.
   

   # mongod.conf
   ...
   # Where and how to store data.
   storage:
   directoryPerDB: true
   wiredTiger:
   engineConfig:
   directoryForIndexes: true
   dbPath: /var/lib/mongoo <-- path to the diagnostic.data
   journal:
   

5. If mongod.conf is missing, run systemctl status mongod and look under --config for the correct path: 

   ● mongod.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/etc/systemd/system/mongod.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2025-05-14 18:48:20 UTC; 1 weeks 6 days ago
   Docs: https://docs.mongodb.org/manual
   Main PID: 730 (mongod)
   Memory: 583.4M
   CGroup: /system.slice/mongod.service
   └─730 /usr/bin/mongod --quiet --config /etc/mongod.conf <-- mongoDB config file path

A replica set is a group of mongod instances that host the same data. Replica sets are use to ensure data redundancy and high availability.

• One member acts as the primary, receiving all writes.
• Other members are secondaries, which replicate data from the primary.
• Only one primary exists at a time; if it fails, a secondary is automatically elected.

 Run these commands after logging in via mongo (with auth if enabled):

1. rs.printReplicationInfo()           # Check oplog size 
2. rs.printSecondaryReplicationInfo()  # Check replication lag (>30s may be an issue) 
3. rs.status().members                 # View member statuses 
4. rs.conf()                           # View replica set config

Sharding lets MongoDB scale across multiple servers by splitting data into shards.

• Each shard is a replica set.
• Sharding helps when one server isn’t enough to store or serve all data.
• The balancer distributes data evenly across shards.
• Sharding solves the problem with horizontal scaling.

 Run these commands after logging in via mongo (with auth if enabled):

1. sh.status()               # View sharding status 
2. sh.getBalancerState()     # Check if balancer is enabled 
3. sh.isBalancerRunning()    # Check if balancer is currently running

 Note: You can also run all replica set commands from above in a sharded cluster. 

To resolve server-related concerns, we also need information about the server instance your application is using. Please share the details about your instance type, which can be selected from the options below:

1. 1. 1. 1. Standalone instance
         2. Auto scale group

Effective troubleshooting for Countly server issues relies on utilizing logs. To effectively utilize the logs for troubleshooting, we need to know about the Deployment type of Countly. It can be any of them from the following three options:

1. 1. 1. 1. VM
         2. Docker
         3. Kubernetes;

Please make sure to notify the support team about the version of Countly Server being used.

To solve server-related issues, our Support team requires information about both the server and the load balancers used by your server. Nginx is the default load balancer of the Countly server, however, if you are using Docker or Kubernetes setup, you can use other web servers.

Use the following command to get the logs for your server:

/var/log/nginx/error.log (or docker/kubernetes equivalents)

If there is a bug related to the Load balancer, the following information will be needed:

• 1. Amount of requests
  2. Amount of failed requests
  3. Breakdown of failed request HTTP code