---
title: How to Collect MongoDB Information and Logs
slug: how-to-collect-mongodb-information-and-logs
docTags: 
createdAt: 2025-12-13T10:45:47.000Z
---

This article outlines the steps on how to collect the necessary MongoDB information and logs. This collection is needed by Engineering and MongoDB Support in order to better understand the issue and begin their analysis.

The following items are the most often needed and usually help troubleshoot 90% of issues:

- mongod logs files from all members
- dbPath/diagnostic.data folder content. This contains MongoDB internal metrics, which help in diagnosing i/o, cache, journal, and other issues.

We will use a script to capture the aforementioned items along with additional information to assist with the troubleshooting.

### Turbine Platform Installer (TPI)

1. Download the collect-mongo-logs-tpi.sh script is available at the bottom of this page.
2. For Standalone, the MongoDB PRIMARY member will always be mongo-0.&#x20;
3. If this is HA, then let's start by looking up the MongoDB PRIMARY member. You will need this information when running the script. Because the script will ask you to provide the Primary MongoDB replica.

:::BlockQuote{indent="1"}
export NS=\<SWIMLANE-NAMESPACE>

kubectl -n $NS exec mongo-0 -- mongosh -u Admin -p \<password text> admin --tls --tlsAllowInvalidHostnames --tlsAllowInvalidCertificates admin --eval="rs.isMaster().primary;"
:::

3. Execute the file

:::BlockQuote{indent="1"}
chmod u+x collect-mongo-logs-tpi.sh&#x20;
./collect-mongo-logs-tpi.sh | tee collect-mongo-logs-tpi-results.log
:::

4. Update the Support ticket with the following information:
   1. Upload the resulting /tmp/mongo.logs.####.tar.gz file to our secure portal
   2. Timeframe information of the incident
   3. Is this issue recurring?
   4. Is there any workload-driven pattern?

::File{src="https://api.archbee.com/api/presign/n8uUzk0MM4uC57-zlHNtY/4UNSreenkbT9D_N5rWfWd-20251213-104633.sh" label="collect-mongo-logs-tpi.sh"}

