[SERVER-50768] getLog: rs missing in 4.4 without documented change Created: 04/Sep/20  Updated: 22/Jun/22  Resolved: 30/Oct/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Chad Kreimendahl Assignee: Evin Roesle
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-13877 Investigate changes in SERVER-50768: ... Closed
Operating System: ALL
Steps To Reproduce:

Install 4.4.

use admin;

db.adminCommand({getLog: "rs"});

Participants:

 Description   

We routinely use this information in a dashboard to help us see replicaset changes only without needing the entirety of months of data

Running db.adminCommand({getLog: "rs"}) on 4.4 returns an error as there is no RamLog for replicaset information. 

 

The new JSON format started in 4.4, but did not bring along with it the replicaset log. While documentation about the getLog did change for 4.2, the "breaking changes" list did not include any information that would suggest an exception to be thrown when people requesting this, (assuming they had previously been requesting it, as we do)

 



 Comments   
Comment by Evin Roesle [ 30/Oct/20 ]

Closing this ticket as the documentation has been updated to reflect the change. Users are able to filter the logs by component to find specific logs as mentioned in previous comments.

Comment by Andrew Feierabend (Inactive) [ 28/Oct/20 ]

Hi chad@onspring.com,

The following might be what you're looking for:

mongo --quiet --eval "db.adminCommand( { getLog:'global'} ).log.forEach(x => {print(x)})" | jq -c '. | select(.c=="REPL")'

The mongo --eval portion of the command runs getLog and pulls out the resulting log array in a manner that can be neatly passed to jq, and then the jq portion limits the results to only those log messages of component REPL. Some additional examples of using jq are available here (you can use the jq portion of each example with the mongo --eval method above).

We're updating our docs shortly to draw more attention to the removal of rs as a valid getLog value with v4.4, and I'll add a note to the getLog documentation to provide notice of this method of parsing the output as well – thank you for raising this ticket!

Let me know how the above works for you. Hope this helps!

Comment by Chad Kreimendahl [ 27/Oct/20 ]

Yeah that's not going to help us. We were rendering all of the replica set change notifications onto a dashboard where we monitor the status of all of our internal stuff.

We don't have access to the file system on which it resides in order to pull that off as they are entirely different machines

Comment by Evin Roesle [ 27/Oct/20 ]

chad@onspring.com, This is correct. getLog : rs is no longer available since we label each log with components now and were not maintaining the rs tags.

Filtering the logs is the best way to see the relevant logs. We also have other components that you can filter by outside of the REPL component. You can see the different components here in our documentation.

Comment by Chad Kreimendahl [ 27/Oct/20 ]

Does that mean it's no longer available in the ramlog, through the getLog command?

Comment by Evin Roesle [ 27/Oct/20 ]

Hi chad@onspring.com. Thank you for bringing this to our attention. The reason we removed getLog: rs is because we actually have been labeling each log by component and no longer were labeling logs with rs. This means that the rs tag did not actually contain all of the relevant logs and was no longer useful as it was not giving a complete view.

We make sure that each log is labeled by component so the best way to gather these logs moving forward would be to filter the log file by the component that you are interested in. This will give you an accurate view of the logs that you are looking for.

To perform this filter you can search for "c":"REPL" in the log file and this will show you all of the logs relevant to replication. At this time, we do not provide the ability to filter before getting the logs, so you will have to get all of the logs first and then apply the filter.

We should have correct this before and done a better job of documenting this. I will ask our documentation team to update the documentation on how to filter for the different components in the logs.

Comment by Chad Kreimendahl [ 09/Sep/20 ]

That was my intent... to flag it as a breaking change. 

Any chance we can get the rs log back? We have good and regular use for it.

Comment by Dmitry Agranat [ 09/Sep/20 ]

Thanks chad@onspring.com for flagging this. The valid options for this command for 4.4 is documented in https://docs.mongodb.com/manual/reference/command/getLog/#dbcmd.getLog and yes, it should have also been added to the breaking changes section. I will follow up on this.

Thanks,
Dima

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