Mongodb has many isMaster commands in the log before the crash without setting the replica set.

  mongodb, question

Mongodb service crashed during scheduled task operation. When the query log found the crash, records in the following two formats were fixed:

command admin.$cmd command: isMaster { ismaster: 1 } numYields:0 reslen:189 locks:{} protocol:op_query 1600ms
 
 serverStatus was very slow: { after basic: 600, after asserts: 1001, after backgroundFlushing:
 1302, after connections: 1701, after dur: 2194, after extra_info: 3300, after globalLock: 3995,
 after locks: 5002, after network: 5304, after opLatencies: 5600, after opcounters: 5799,
 after opcountersRepl: 6104, after repl: 6500, after security: 6802, after storageEngine: 7500,
 after tcmalloc: 8601, after wiredTiger: 32799, at end: 37100 }

Judging from the server’s log, mongodb did a lot of reading when it crashed.
I would like to ask you how to analyze the causes of mongodb service collapse from these two aspects.
The other one puzzled me. We haven’t set up a replica set for mongodb, why is there an isMaster command?

These two logs have nothing to do with the cause of your crash. Usually these two instructions come from the timing sampling of your monitoring system and should be completed quickly under normal circumstances. If both instructions are slow, it means that the database is under great pressure. What are you looking for? What causes the stress and what happened at the last moment before the crash?