[DOCS-14398] [SERVER] Log time spent waiting for an authorization lock in the locks section Created: 30/Apr/21 Updated: 13/Nov/23 Resolved: 23/Feb/22 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Dave Cuthbert (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 year, 50 weeks ago | ||||||||
| Epic Link: | DOCSP-15042 | ||||||||
| Story Points: | 3 | ||||||||
| Description |
DescriptionDownstream Change Summary This ticket allows the server to track, log, and profile accesses to the user cache per operation. When at least one access to the user cache has been made for an operation, the following subdocument will appear in the log for that operation and in the `system.profile` document for the operation: Unknown macro: {
"startedUserCacheAcquisitionAttempts"}
Documentation should indicate that these statistics will appear as above in the slow operation logs and in the `system.profile` collection. The slow operation logs page here should have its example updated. The database profiler page here should have a section for `system.profile.authorization`. The description for the `authorization` field should indicate that it provides information about user cache accesses during the operation. `authorization.startedUserCacheAcquisitionAttempts` indicates the number of user cache accesses started while `authorization.completedUserCacheAcquisitionAttempts` indicates the number of those accesses that were completed at the time of profiling. `authorization.userCacheWaitTimeMicros` indicates the amount of time spent waiting on the cache, in microseconds. Description of Linked TicketWhen the server tries to (re-)authorize sessions using the slow LDAP server, this will stall all new authorizations, including those using the SCRAM mechanism. To simplify RCA process I propose to include the new section named Authorization, for example: Before:
After:
Right now it's not obvious that a SCRAM authorization stalled due to the exclusive lock which was held by another session's authorization cache refresh (reaching out to the LDAP server and waiting for a response) - unless server has debug logging enabled. Scope of changesImpact to Other DocsMVP (Work and Date)Resources (Scope or Design Docs, Invision, etc.) |
| Comments |
| Comment by Githook User [ 23/Feb/22 ] |
|
Author: {'name': 'Dave', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}Message: |
| Comment by Githook User [ 23/Feb/22 ] |
|
Author: {'name': 'Dave', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}Message: |
| Comment by Githook User [ 23/Feb/22 ] |
|
Author: {'name': 'Dave', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}Message:
|