[SERVER-50804] Make external (application) client info available for commands on shards and config servers Created: 08/Sep/20 Updated: 10/May/21 Resolved: 20/Oct/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Networking, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Josef Ahmad | Assignee: | Shameek Ray |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | sa-groomed | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Sprint: | Service arch 2020-09-21 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
The rpc from mongoS already passes both the internal (mongoS) client info and the external client (application) info into the shards and config servers, the info being host:port and client metadata. However only the mongoS client info is exposed in the Client class. For diagnostics and logging purposes, it would be useful to expose the external client info too. From a conversation with ben.caimano: we encode external client information here. However that is only used in the mongoS hello implementation here. I don't actually see anywhere where it is parsed on the client side. In theory, we could attach this information when it is first seen like we do with other metadata. Then all commands after that hello could access it. |
| Comments |
| Comment by Benjamin Caimano (Inactive) [ 20/Oct/20 ] |
|
We've closed this as duplicate, please reopen if |
| Comment by Benjamin Caimano (Inactive) [ 15/Oct/20 ] |
|
josef.ahmad, I ran into this again in the course of |
| Comment by Githook User [ 15/Oct/20 ] |
|
Author: {'name': 'Ben Caimano', 'email': 'ben.caimano@10gen.com'}Message: This patch does the following:
|
| Comment by Josef Ahmad [ 17/Sep/20 ] |
|
This improvement facilitates the root cause analysis of incidents in the field involving sharded clusters. Namely, this ticket would allow to identify the application client that requested an offending command on a shard. On replica set deployments, we can already identify the application client behind an an operation of interest. On sharded clusters instead, a shard only knows about their direct client (mongoS most of the time). This makes it not trivial to pinpoint the application client behind an operation of interest.
Note that today we already pass the application client info into the shard as part of the remote procedure call, so as far as I understand it, it's only a matter of making this info available in our internal API. |
| Comment by Shameek Ray [ 15/Sep/20 ] |
|
Hi josef.ahmad, Is this something you still need? If so, what will it help you do? |