-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Server Security
Currently, bson redaction keeps keys and hides (non-sub-object) values. For oplog entries where the actual application data is enveloped, some values can conceivably be displayed. This information would be useful when trying to put a timeline of what a node is doing when diagnosing issues.
I don't know where the dividing line would be on what can and cannot be persisted to a log file, but perhaps in order of usefulness:
- The `ts` and `t` fields (timestamp and term)
<falling off a steep cliff of usefulness, to me> - `op` (operation type, e.g: insert/update...)
- `ui` (collection uuid)
- `ns` (collection namespace)
<another cliff> - `lsid` (logical session id)
I don't believe we can intelligently determine when a redaction is for an oplog entry. What would certainly satisfy my intention is to have a method that redacts a BSONObj as if it were an oplog entry and a brief/best effort scan of repl logging code to use the new method. If the functionality exists, we can convert log lines as they become identified.