新的v0.8.4版本中，我们对于诊断工具进行了全面系统化的升级，以提供更加完整和智能化的诊断报告，有助于高效排查 OpenMLDB 集群问题，大幅提升运维效率。

相比于之前的版本，新的诊断工具增添一键诊断功能，使用openmldb_tool inspect就可以一键诊断集群的健康状态。提供的信息包括XX Detail和Summary & Hint两个部分。XX Detail部分提供集群现状信息；Summary & Hint部分总结了重点需要关注的信息点，并且智能提示可能有问题的地方及相应的对策，帮助用户进行集群修复。 一般情况下，Summary & Hint部分的信息足够用户对集群进行对应的修复；对于更棘手的情况，用户可参照XX Detail里的现状信息进行处理，或者向我们提供报告，我们可以更快速地定位集群问题、进行修复指导。诊断工具的具体详情可以参见文档（https://openmldb.ai/docs/zh/main/maintain/diagnose.html）。 接下来我们简单演示如何使用一键诊断功能来查看集群状态以及如何快速解决常见问题。

报告讲解与演示

以OpenMLDB Demo镜像为例，启动OpenMLDB集群。一键诊断后，用户可以直接检查末尾的Summary & Hint报告总结章，它将总结整个集群的状态，包括Server是否在线，和Table是否健康。

健康状态

绿色提示Server均在线和Table均健康，是正常的状态。

异常状态

如果某台Tablet Server掉线了，总结将提示：

Server异常状态

报告中，我们首先看到“offline servers”，报告提示我们需要先重启它们。除非该节点是无数据的，其他任何情况，请优先恢复下线server节点，再对表的健康情况进行诊断。

Table异常状态

我们已经将下线server恢复，再次诊断集群，报告如下图所示。此时仍存在不健康的表。状态有两种：

• 红色Fatal状态，说明此时表处于危险状态，可能会读写失败，需要立即处理。
• 黄色Warn状态，说明表的主分片都在活动中，读写是可以的，但也请及时处理，只是没有Fatal紧急。

请注意这些表虽然仍然不健康，但它们有一些关联的后台OP正在执行。它们是集群自动发起的修复，用户此时不需要手动修复，需要等待后台OP完成。一般情况下，集群自动修复完成后，一键诊断会显示集群已健康。

Table特别异常状态

在实际的运维过程中，可能因为一些意外情况，导致类似下图的情况。Table处于异常状态且并没有后台OP正在运行，它意味着集群并未触发自动修复或修复已经失败。

这时候，就需要用户手动操作了，根据报告末尾的提示链接进行recoverdata。如果recoverdata提示成功，可再次一键诊断，确认集群已恢复健康。

详细报告

对于更棘手的情况，我们可以通过报告中的Detail部分来对当前集群进行分析。

Table Partition Detail

Table Partition Detail部分可以让我们直观地了解各个表现在处于什么样的状态。每个Partition分片的主从副本位于哪台Tablet，副本本身是什么状态，都有清晰的展示。结合Example，我们可以看到，一个分片pX代表其分片id，各个副本在Tablet Server上是元信息丢失，还是信息异常等。

Ops Detail

Ops Detail可以提示我们集群当前的后台情况，是否自动修复失败等。我们可以通过最后一个OP的时间和最后10个非完成OP的详细状态，来判断集群是未触发自动修复，还是正在修复，或者是修复已失败，或者是部分表修复失败。

提供报告

用户如果通过以上流程，仍无法修复集群，请向我们提供Detail部分的信息，我们可以更快速地定位集群问题、进行修复指导。

相关阅读

• OpenMLDB 官网： https://openmldb.ai/
• OpenMLDB GitHub 主页： https://github.com/4paradigm/OpenMLDB
• OpenMLDB 文档： https://openmldb.ai/docs/zh/
• OpenMLDB 微信交流群