[SERVER-44735] track metrics for system initiated operations (commands, reads) separately from client initiated ones Created: 19/Nov/19  Updated: 25/May/23

Status: Backlog
Project: Core Server
Component/s: Diagnostics
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Asya Kamsky Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: qopt-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt Dependency
Related
related to SERVER-41707 Add field to serverStatus that discou... Backlog
related to SERVER-75890 Indicate user/system operations and c... Closed
Assigned Teams:
Query Optimization
Participants:

 Description   

Currently serverStatus splits some operations to allow tracking them separate if they are internally triggered but not all.  For instance deletes from TTL thread are tracked separately from "regular" deletes initiated by client.

It would be useful to do the same for reads, getMores and commands initiated by system, like secondaries reading the oplog, automation agent running commands, etc.



 Comments   
Comment by Davis Haupt (Inactive) [ 12/Oct/21 ]

I was wondering if there could be more clarity in this ticket on what metrics need to be split out into client-initiated vs system-initiated counts. Should part of this ticket include evaluating which metrics need to be split out?

Comment by Bruce Lucas (Inactive) [ 19/Nov/19 ]

We had discussed something like this with regard to the flow control project where we felt it might be useful to exempt "system" operations from flow control on the theory that a) they generally shouldn't need to be throttled, and b) throttling them could be harmful to system health. However no one could come up with a good way of separating system operations from client operations. So it may be difficult to do this; or if a way could be found to do so in this context, that maybe could be applied to flow control.

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