OPERATIONAL DEFECT DATABASE
...
...
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)
evin.roesle commented on Fri, 30 Oct 2020 22:08:45 +0000: 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. andrew.feierabend commented on Wed, 28 Oct 2020 21:05:55 +0000: 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! JIRAUSER1269871 commented on Tue, 27 Oct 2020 23:08:17 +0000: 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 evin.roesle commented on Tue, 27 Oct 2020 18:42:57 +0000: 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. JIRAUSER1269871 commented on Tue, 27 Oct 2020 18:08:10 +0000: Does that mean it's no longer available in the ramlog, through the getLog command? evin.roesle commented on Tue, 27 Oct 2020 17:54:20 +0000: 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. JIRAUSER1269871 commented on Wed, 9 Sep 2020 17:39:57 +0000: 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. dmitry.agranat commented on Wed, 9 Sep 2020 07:01:51 +0000: 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
Install 4.4. use admin; db.adminCommand({getLog: "rs"});
Click on a version to see all relevant bugs
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
