关于诊断工具的巡检模块，前期这边计算用来分析用户observer集群的配置、ob占用的cpu/内存、租户资源配置、系统环境参数等等，根据内部经验帮用户排查已存在或可能出现的问题。
想收集下在OBserver日常运行过程中用户对哪些可能出现的异常有需求。
类似主机系统环境值是否在合理范围内、租户配置是否合理、部分集群配置是否在合理范围内等场景，欢迎跟帖~
2 个赞
系统参数是否合理，比如已经因为大量写入，转储速度跟不上写入，然后再限速了，要出现内存不足，发现这种时间段，然后动态去调整转储时间，限速内存使用百分比；
ob_sql_work_area_percentage这个参数也是
还有很多其他参数，循环，根据租户使用情况，判断给出优化意见，或者更近一步，在资源充足情况下，可以自动调参
分区分布合理性，remote 太多，那给出哪些可以创建table group，哪些改成分区表
1 个赞
十分感谢雨齐给的建议。
诊断工具预计前期不会加入主动调优的手段，毕竟是生产环境如果出现主动调优策略失常容易引起生产安全事故。
社区文档有给出部分场景下的调优策略，策略的实施还是需要DBA来手动触发。诊断工具会给出诊断的结果，方便DBA通过结果通过特定策略触发调优方案。比如某一项压力检查测定出现了集群压力过高时可以输出告警并给出调参建议，DBA在监听到这个告警后可以触发预设的调优方案。
分区合理性这个计划后续调研下，影响的数据可能比较多，所以需要分析一下怎么来做实现。
将这个场景记为根据当前数据库压力情况给出适合的集群参数/租户参数配置建议看下是否可以？
1 个赞
可以的。
巡检给出意见。
如果可以有开关，可以尝试打开自动调参，这样压测，稳定性这些打开可以看到效果，验证效果。使用起来也有底
1 个赞
调参这块由于涉及到实际的集群的一些内容，需要运维经验的介入。
后面可以做个巡检结果获取的功能，在整个巡检结束后通过特定的指令获取巡检结果，然后做个插件判断，是否执行原定的调优策略。
等诊断工具逐步完善了，可以指定几个参数进行自动调优测试
1 个赞
）
