Audit logging basics in MongoDB - Time & Space Complexity
Audit logging in MongoDB records actions on the database for security and tracking.
We want to understand how the time to log each action changes as more actions happen.
Analyze the time complexity of this audit logging setup.
db.createCollection("auditLog")
function logAction(action) {
db.auditLog.insertOne({
timestamp: new Date(),
action: action
})
}
// Example usage
logAction("user_login")
This code creates an audit log collection and inserts a log entry for each action.
Look at what repeats when logging many actions.
- Primary operation: Inserting one document into the auditLog collection.
- How many times: Once per action logged, so as many times as actions happen.
Each new action causes one insert operation.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 insert operations |
| 100 | 100 insert operations |
| 1000 | 1000 insert operations |
Pattern observation: The number of operations grows directly with the number of actions logged.
Time Complexity: O(n)
This means the time to log actions grows linearly with how many actions you record.
[X] Wrong: "Logging many actions happens instantly and does not slow down."
[OK] Correct: Each log entry requires a database insert, so more actions mean more inserts and more time.
Understanding how logging scales helps you design systems that keep track of activity without slowing down.
"What if we batch multiple log entries into one insert? How would the time complexity change?"
Practice
Solution
Step 1: Understand audit logging function
Audit logging captures actions performed on the database to help track security events and troubleshoot issues.Step 2: Compare options
Options B, C, and D describe unrelated functions like speed, backup, or hardware monitoring, which are not audit logging purposes.Final Answer:
To record database actions for security and troubleshooting -> Option BQuick Check:
Audit logging = record actions [OK]
- Confusing audit logging with backup
- Thinking audit logs improve query speed
- Mixing audit logs with hardware monitoring
Solution
Step 1: Identify MongoDB config file
MongoDB usesmongod.confto configure server settings including audit logging.Step 2: Eliminate incorrect options
Files likemongo.cfg,audit.log, anddb.configare not standard MongoDB config files.Final Answer:
mongod.conf -> Option AQuick Check:
Audit logging config = mongod.conf [OK]
- Confusing log file with config file
- Using wrong file extensions
- Assuming audit.log is a config file
mongod.conf:
auditLog:
destination: file
format: JSON
path: /var/log/mongodb/audit.json
filter: '{ atype: { $in: ["authCheck", "createUser"] } }'
What events will be logged?Solution
Step 1: Analyze the filter field
The filter usesatypewith$into include only "authCheck" and "createUser" event types.Step 2: Understand event selection
Only events matching these types will be logged, excluding others like user deletion or all events.Final Answer:
Only authentication checks and user creation events -> Option DQuick Check:
Filter limits events = authCheck, createUser [OK]
- Assuming all events are logged
- Confusing createUser with deleteUser
- Thinking syntax error disables logging
mongod.conf but audit logs are not created:
auditLog:
destination: file
format: JSON
path: /var/log/mongodb/audit.json
filter: '{ atype: "authCheck" }'
What is the likely problem?Solution
Step 1: Check configuration correctness
The filter syntax is valid for a single event type; JSON format and path are correct.Step 2: Consider service restart requirement
Changes inmongod.confrequire restarting the mongod service to apply new audit logging settings.Final Answer:
Audit logging requires restart of mongod service -> Option AQuick Check:
Config changes need restart [OK]
- Assuming filter syntax error without checking
- Ignoring need to restart mongod
- Thinking JSON format is unsupported
dropUser. Which filter correctly achieves this in mongod.conf?Solution
Step 1: Understand $nin operator
The$ninoperator excludes specified values, so{ $nin: ["dropUser"] }excludes dropUser events.Step 2: Check other options
filter: '{ atype: { $in: ["createUser", "updateUser"] } }' logs only createUser and updateUser, missing other user events. Options B and C log only dropUser events, opposite of requirement.Final Answer:
filter: '{ atype: { $nin: ["dropUser"] } }' -> Option CQuick Check:
Exclude dropUser with $nin [OK]
- Using $in instead of $nin to exclude events
- Selecting only some user events instead of excluding one
- Confusing $eq with exclusion
Ready to prove it?
Pass the test and this pattern moves unknown
