D-SMART高斯专版已经开发了几个月了，目前主要技术问题都已经解决，也能够初步看到大概的面貌了。有朋友问我，GaussDB不已经有了TPOPS了，为什么你们还要开发D-SMART高斯专版呢？
实际上TPOPS和D-SMART虽然都可以用于Gaussdb的运维监控，不过其分工还是十分明显的。TPOPS是华为GaussDB自带的运维工具，从数据库部署开始就一直可以使用。TPOPS+DBMind也具有一定的运维分析能力，不过这些功能都是基于传统的运维管理理念的。D-SMART是一个运维知识自动化系统，其目的是实现更加数字化的运维监控、故障预警、根因分析（RCA）、自动化巡检等，今后还会依托D-SMART的数据构建线上的SAAS生态。D-SMART是一个十分强大的知识自动化平台，可以不断沉淀用户自己的运维知识，包括各种健康模型、故障模型和诊断工具。这些都是TPOPS不具备的功能，因此D-SMART可以作为TPOPS的有效补充。
另外一方面，D-SMART高斯专版会支持所有的高斯生态产品，包含华为GaussDB集中式/分布式，openGauss、南大通用GBASE 8C、海量Vastbase、神通数据库、磐维、MogDB等。
D-SMART是从运维视角来看待GaussDB的。从入口上，D-SMART与TPOPS的视角就完全不同。
使用过D-SMART的用户送GaussDB专版没有任何学习成本，可以很轻松的通过工具去对GaussDB集群进行分析。
配套的D-SMART V2.6版本提供了一个图形化的集群拓扑。让习惯于图形界面的DBA看起来更加舒适。
在集群拓扑上可以点击CN/DN节点进行下钻。在D-SMART中，每个有分布式CN/DN节点和集中式DN节点三种子类型，目前我们把它们作为PG兼容子类来看待。因为GaussDB和openGauss都有大量的监控视图与PG兼容，可以复用部分PG的工具，因此我们没有给openGauss/GaussDB节点独立的数据库类别。虽然如此，GaussDB、openGauss和PostgreSQL三种数据库子类在可观测性视图方面已经有了很多差异。作为可观测性能力而言，GaussDB>openGauss >PostgreSQL。更强的可观测性意味着更为强大的自动化/智能化分析能力。
故障模型告警和诊断工具依然沿用D-SMART传统的模式，目前工具的开发还在持续进行中，不过基于运维知识图谱的通用分析工具已经是可用的了。智能指标分析与告警时序分析、等待事件智能分析等工具已经可以使用了。
基于GaussDB强大的可观测能力，目前故障模型的梳理工作也进展顺利，和一些其他的国产数据库不同的是，我们明显感到能够梳理出来的故障模型数量太多了，刚刚发布的时候可能就会有上百个故障模型，比我们2018年发布Oracle版本时的故障模式数量还要多出不少。
故障模型是对数据库运维经验的一种总结，能够构建其丰富的故障模型对于承载大型关键应用系统十分关键。而故障模型的构建依赖于强大的可观测能力，以及将数据库状态指标化的能力，再辅以专家的经验才能完成。这种能力可以让一些原本需要专家才能发现的问题实现自动化发现与自动化预警。
目前我们针对GaussDB的故障模型涉及组件健康状态、容量、高可用、并发、负载、性能、资源、实例健康、任务等维度。实际上这是针对GaussDB集群的故障模型，针对每个组件，比如CN/DN，以及承载CN/DN的服务器也都会设计故障模型。这样才能保证整个数据库运行环境出现问题，都能够被提前发现。
分布式数据库的运维工具开发起来比较麻烦，在前面的开发过程中我们也遇到了很多问题，比如DN节点的切换后，系统能否立即无缝跟踪到这个变化，如果复制组中存在硬件配置上的不同，可能会影响模型的评估，如何能够在每隔2-3分钟的评估中避开数据错误，这些都在不断的完善中。这个月底希望有一个评估版本可以完成，届时也希望生产环境中有GaussDB的朋友能一起合作来验证工具。
作者：白鳝的洞穴
欢迎小伙伴们交流~
标签：TPOPS,运维,GaussDB,故障,构建,模型,SMART From： https://www.cnblogs.com/xiaoxu0211/p/18512150