[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:
Depends
Duplicate
duplicates SERVER-49336 Set client metadata if it is missing ... Closed
Related
related to SERVER-50543 Log the application client starting o... Closed
is related to SERVER-49336 Set client metadata if it is missing ... Closed
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 SERVER-49336 doesn't address your needs.

Comment by Benjamin Caimano (Inactive) [ 15/Oct/20 ]

josef.ahmad, I ran into this again in the course of SERVER-49336. It turns out that we were actually overwriting the internal client (mongos) ClientMetadata with the external client (mongo/driver) ClientMetadata on each operation. We now have both available simultaneously as ClientMetadata::getForClient(opCtx) and ClientMetadata::getForOperation(opCtx). Do you feel that change addresses this ticket?

Comment by Githook User [ 15/Oct/20 ]

Author:

{'name': 'Ben Caimano', 'email': 'ben.caimano@10gen.com'}

Message: SERVER-49336 Set ClientMetadata before CommandInvocations are run

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.

SERVER-50543 is an example where this ticket would have been helpful. We've ended up working around the lack of this ticket by logging the application client metadata in the mongoS, which essentially adds a layer of indirection in the analysis (config server analysis -> mongoS analysis).

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?

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