[SERVER-58534] Collect FCV in FTDC Created: 14/Jul/21  Updated: 29/Oct/23  Resolved: 21/Jul/23

Status: Closed
Project: Core Server
Component/s: Diagnostics
Affects Version/s: 5.0.0
Fix Version/s: 7.1.0-rc0, 4.4.25, 7.0.2, 5.0.22, 6.0.11

Type: Improvement Priority: Major - P3
Reporter: Kevin Arhelger Assignee: Sean Zimmerman
Resolution: Fixed Votes: 1
Labels: former-quick-wins, needs-triage, pm-2821-quick-wins, repl-shortlist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
is duplicated by SERVER-36140 Add featureCompatibilityVersion statu... Closed
is duplicated by SERVER-36826 Report setting of FCV in logs and dia... Closed
Related
related to SERVER-58533 Log FCV at initialization and on log ... Closed
related to SERVER-36140 Add featureCompatibilityVersion statu... Closed
is related to SERVER-82087 FCVServerStatusMetrics::generateSecti... Closed
is related to SERVER-62524 Represent FCV values meaningfully to ... Open
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Backport Requested:
v7.0, v6.0, v5.0, v4.4
Sprint: Repl 2021-11-01, Replication 2021-11-15, Replication 2021-11-29, Replication 2021-12-27, Replication 2022-01-10, Repl 2023-07-24
Participants:
Case:

 Description   

Collecting the Feature Compatibility Version in FTDC would allow an easy anchor to what FCV is currently in use. Adding this as a metric would allow us to see the version change, or revert which can be an issue in some cases.



 Comments   
Comment by Githook User [ 14/Sep/23 ]

Author:

{'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}

Message: SERVER-58534: Collect FCV state in FTDC Metrics
Branch: v6.0
https://github.com/mongodb/mongo/commit/3b705009ddedb036ea29e2d8e278e3704d91d138

Comment by Githook User [ 14/Sep/23 ]

Author:

{'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}

Message: SERVER-58534: Collect FCV state in FTDC Metrics
Branch: v5.0
https://github.com/mongodb/mongo/commit/53fdd699863567deba0f8dcd793caaf851a2da91

Comment by Githook User [ 14/Sep/23 ]

Author:

{'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}

Message: SERVER-58534: Collect FCV state in FTDC Metrics
Branch: v4.4
https://github.com/mongodb/mongo/commit/86de2dd56b0d501686eb2614c2acaf42b2df0ef1

Comment by Githook User [ 13/Sep/23 ]

Author:

{'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}

Message: SERVER-58534: Collect FCV state in FTDC Metrics
Branch: v7.0
https://github.com/mongodb/mongo/commit/8cb247058bf599674914c41763cd0a15d4b396a6

Comment by Githook User [ 21/Jul/23 ]

Author:

{'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}

Message: SERVER-58534: Collect FCV state in FTDC Metrics
Branch: master
https://github.com/mongodb/mongo/commit/89384edde243c77d19c510873fb5460598e06823

Comment by Judah Schvimer [ 12/Jul/23 ]

I agree, I also suspect transitionary FCV states are a common time for things to go wrong, so seeing that in diagnostics clearly would be valuable.

Comment by Samyukta Lanka [ 12/Jul/23 ]

I think being able to track the number of clusters that are in a transitionary FCV state would be valuable.

Comment by Sean Zimmerman [ 12/Jul/23 ]

I think I may have been a bit unclear in my comment, with the current proposal the FCV kDowngradingFrom_7_1_To_7_0 will be logged as major 7, minor 1 and the FCV kUpgradingFrom_7_0_To_7_1 will be logged as major 7, minor 0

If we wanted to capture the upgrade/downgrade we would need a third value, so something like major, minor, upgrading (Downgrading = -1, normal = 0, Upgrading = 1). Another option would be to log the target version like you mentioned

Comment by Kevin Arhelger [ 12/Jul/23 ]

We should be able to combine the target version, along with the current MongoD version to understand if it is an upgrade or downgrade, correct? If that's the case, I'm not especially concerned with the downgrade or upgrade information.

Comment by Sean Zimmerman [ 12/Jul/23 ]

I'm working on this ticket now, do we want to have special handling for FCV values like
kDowngradingFrom_7_1_To_7_0,
kUpgradingFrom_7_0_To_7_1,
if we go with just a major, minor logging then we will reduce these two to 7,1 and 7,0 respectively, losing the information if we are downgrading or upgrading. We can add this as a separate field if we think it is worth it, do we have thoughts on this?

Comment by Vishnu Kaushik [ 04/May/23 ]

The point of SERVER-62524 is to add an interface between the FCV enum values, which are generated by the template file, and any utility functions that we may want. This will help decouple the template file from the utility functions: currently we're just adding utility functions to the template file and eventually that'll make the template file super hard to read (especially because it's written in Cheetah).

However, if we want to get this ticket done quickly we can introduce a new utility function that maps from FCV enum to (maj, min) (example utility function) directly into the template file. Then later on, when time permits, SERVER-62524 can re-factor this bit of code to clean things up. This will break the dependency of SERVER-58534 on SERVER-62524.

I'm going to update the "Issue Links" section of this ticket to reflect the same.

Comment by Diego Rodriguez (Inactive) [ 04/Feb/22 ]

Cool bruce.lucas, thanks for clarifying! The combination of the above + this FCV extra should do the trick then.

Comment by Eric Sedor [ 26/Jul/21 ]

bruce.lucas would you propose the same format used in buildInfo's versionArray field?

Comment by Bruce Lucas (Inactive) [ 14/Jul/21 ]

Would have to be recorded as two separate numbers maj, min (not a string "maj.min") because FTDC records only numbers.

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