一般来说，您可以使用两个nodetool命令监视nodetool repair操作：

• 压缩统计数据
• 网络统计

修复操作有两个不同的阶段。首先，它计算节点之间的差异（要完成的修复工作），然后通过将数据流传输到适当的节点来处理这些差异。
这将检查活动的Merkle树计算：

$ nodetool compactionstats
pending tasks: 0
Active compaction remaining time :        n/a

修复流可通过以下方式进行监控：

$ nodetool netstats

事实上，TheLastPickle的Aaron Morton建议使用以下Bash脚本/命令来监视任何活动的修复流：

while true; do date; diff <(nodetool -h localhost netstats) <(sleep 5 && nodetool -h localhost netstats); done

DataStax在他们的支持论坛中有关于troubleshooting hanging repairs的帖子。如果您有任何挂起的修复流，您应该能够看到它们，并显示netstats。如果在修复过程中您的某个节点不可用，则可能发生这种情况。要监视特定的修复操作，您可以检查日志文件中是否有类似以下的条目：
[编写-/172.30.77.197] 2013-05-03 12：43：09，107 OutboundTcpConnection.java（第165行）写入到/172.30.77.197 java.net时出错。套接字异常：连接重置
请注意，修复会话也应在system.log中注明：

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Starting...

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Completed...

当您启动修复命令时，可以使用选项--trace监视修复流：
nodetool repair --trace <key_space> <table>

我们还可以在Opscenter控制台的Activities下监控修复的进度。

如果有人还想知道如何用最新版本的Cassandra监视nodetool repair的状态，从Cassandra 4.0开始，有新的nodetool repair_admin命令来跟踪和中断修复操作。

nodetool repair_admin list

它由包含修复操作历史的新系统表system.repairs支持。