[SERVER-67535] move_chunk_large_chunk_map_workloads no longer reports timing breakdown of chunk migration due to server logging changes Created: 25/Jun/22  Updated: 29/Oct/23  Resolved: 07/Jul/22

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 6.0.1, 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Enrico Golfieri
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Problem/Incident
is caused by SERVER-61078 Log chunk migration donor critical se... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v6.0
Sprint: Sharding EMEA 2022-07-11
Participants:

 Description   

The changes from 8dda613 as part of SERVER-61078 switched a log line from logv2::LogComponent::kShardMigrationPerf to logv2::LogComponent::kShardingMigration. This broke an internal Python script for parsing the server's structured log messages and matching up the start of the critical section log line with the end of the critical section log line.



 Comments   
Comment by Max Hirschhorn [ 12/Jan/23 ]

Author:

{'name': 'Enrico Golfieri', 'email': 'enrico.golfieri@mongodb.com', 'username': 'enricogolfieri'}

Message: SERVER-67535 move_chunk_large_chunk_map_workloads no longer reports timing breakdown of chunk migration due to server logging changes
Branch: v6.0
https://github.com/mongodb/mongo/commit/942ede89e7f33cb50408574e9a4c6a9e4c0f3fab

Comment by Githook User [ 06/Jul/22 ]

Author:

{'name': 'Enrico Golfieri', 'email': 'enrico.golfieri@mongodb.com', 'username': 'enricogolfieri'}

Message: SERVER-67535 move_chunk_large_chunk_map_workloads no longer reports timing breakdown of chunk migration due to server logging changes
Branch: master
https://github.com/mongodb/mongo/commit/57a8561e7754cca2875f886bf8780e2b7940dba2

Comment by Max Hirschhorn [ 05/Jul/22 ]

My vote would be to restore the original meaning of log ID 4817403 which would be logging at log-level 2 and using the logv2::LogComponent::kShardMigrationPerf component. It isn't enforced or checked, but keeping the semantics of log lines stable between MongoDB versions helps to avoid downstream impact on log parsing tools, both internally and externally.

The other log messages at log-level 0 would be done under new log IDs.

Comment by Enrico Golfieri [ 30/Jun/22 ]

Do we want to fix the log back to the original state (LOGV2_DEBUG_OPTIONS with logv2::LogComponent::kShardMigrationPerf ) or we prefer to catch the durationMillis logged by the new line in the python script?

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