[SERVER-55870] Add diagnostic information to killOp and killSession* logging Created: 07/Apr/21  Updated: 29/Oct/23  Resolved: 23/Jun/21

Status: Closed
Project: Core Server
Component/s: Diagnostics, Security
Affects Version/s: None
Fix Version/s: 5.1.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Judah Schvimer Assignee: Sergey Galtsev (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Issue split
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4, v4.2
Sprint: Security 2021-05-17, Security 2021-06-14, Security 2021-06-28
Participants:
Case:

 Description   

Always log successful killOp and killSession* commands in the system log. We should include any relevant diagnostics, such as the user doing the killing and the user being killed, and the client metadata.



 Comments   
Comment by Githook User [ 23/Jun/21 ]

Author:

{'name': 'Sergey Galtsev', 'email': 'sergey.galtsev@mongodb.com', 'username': 'brushless-glitch'}

Message: SERVER-55870 Add diagnostic information to killOp and killSessionXXX logging
Branch: master
https://github.com/mongodb/mongo/commit/f82fcb094eb1cf989b089e3bc3605e4c44552d5c

Comment by Sergey Galtsev (Inactive) [ 09/Jun/21 ]

https://mongodbcr.appspot.com/771660006/

Comment by Sergey Galtsev (Inactive) [ 08/Jun/21 ]

I brought this up on today's team meeting, and we decided that the way to resolve this ticket would be to log parameters, as tracking session IDs would be too large code change which would also make back-porting risky.

Comment by Judah Schvimer [ 08/Jun/21 ]

I think we should aim to log the actual sessions that were killed. If that is significantly harder, logging the command that was executed seems like a reasonable alternative.

Comment by Sergey Galtsev (Inactive) [ 07/Jun/21 ]

judah.schvimer when command such as killAllSessionsByPattern runs, it is undefined what sessions would actually be killed. For the purpose of this ticket is it important to log what exactly sessions were killed as a result of this command's execution, or should we only log that command was executed and was successful?

Comment by Judah Schvimer [ 01/Jun/21 ]

My opinion is that the perf and disk space impact of 1 default log line on every killOp and killSessions command will be worthwhile.

Comment by Sergey Galtsev (Inactive) [ 01/Jun/21 ]

judah.schvimer milkie given that this command has potential impact on a) performance, and b) disk space, do we want to enable it everywhere by default, or should it be something that user turns on knowingly via flag or increased debug level?

Comment by Eric Milkie [ 19/Apr/21 ]

Auditing is an Enterprise-only feature, so by using auditing you would be restricting the diagnostic information to Enterprise as well.

Comment by Sara Golemon [ 19/Apr/21 ]

Curious if using the audit log for this was discussed.  I believe this information is already captured there and auditing feels like a more correct place to put something non-exceptional like this.

Comment by Eric Milkie [ 12/Apr/21 ]

Since killOp commands are very fast and won't cost users anything, there is a significant resource exhaustion issue if we choose to log every command received in the global system log and a user hammers on the command (intentionally or not). Therefore it is important that this be "successful commands only".

Comment by Judah Schvimer [ 12/Apr/21 ]

This is intended to log all successful killOp/sessions commands. Thank you for the clarifying question!

Comment by Eric Milkie [ 09/Apr/21 ]

Is the behavior to log a message in the system log for every killOp command ever received, successful or not?
(I am confused by the "events" terminology in the Description).

Generated at Thu Feb 08 05:37:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.