Upgrading fdbmonitor will restart all of its child fdbserver processes. There is no built-in mechanism to try to synchronize the restarting of fdbmonitor, so unless you have your own that can restart them in a tight window, the best approach is to apply the upgrade in a rolling fashion. I would recommend not trying to do this at the same time that you are also trying to upgrade the fdbserver processes.
Each time you upgrade an instance of fdbmonitor that has children serving certain roles (e.g. tlogs, resolvers, proxies, master, cluster controller), the cluster will undergo a recovery. This will appear as a brief (small number of seconds) latency spike or downtime to your clients. If you are using process classes, you can optionally exclude all non-storage class processes that are children of the fdbmonitor being upgraded before killing it, which may help reduce the time spent in recovery by avoiding the need to detect the failed processes. Be sure to include those processes again after you’ve restarted fdbmonitor. It’s probably not desirable to exclude the storage servers unless you don’t intend to start the new fdbmonitor instance right away because that would move all of the data off of those storage servers.
Because of the above, we don’t recommend upgrading fdbmonitor with every release. Instead, it should only be upgraded when there are changes made to it that you need. It’s common for a release to not include any changes to fdbmonitor.
For the other binaries, you can just upgrade those at some point around/between when you’ve deployed the new fdbserver binaries and bounced them. If you are performing a major/minor version upgrade and want to minimize the interruption to these other activities, you could startup processes at the new version before the upgrade and not kill the processes at the old version until after the upgrade.