用户提出GoldenDB纳管的需求已经很久了，最近我们终于准备在V2.7版本中提供对GoldenDB的支持了。迟迟没有完成GoldenDB纳管的主要原因是因为排期的问题以及和客户与原厂一起探讨如何高效、无害地采集D-SMART所需要的数据，因为D-SMART是一种“运维知识自动化系统”，而不是简单的监控系统，需要采集大量的可观测性数据，才能完成各种模型的建模，并开发相关的诊断工具。目前D-SMART已经定义了600多个监控指标，通过这六百多个指标计算出来的300多个指标将会被用于故障预警、自动化巡检、根因分析、容量管理等运维领域。
最近有几个金融用户因为国产化替代进度提速，也加强了与我们研发团队的交流。从用户侧获得的需求，才是研发最大的保障。因此我们在一个多月前启动了GDB纳管的研发工作，并将于近期发布的V2.7中包含该功能。
目前我们支持GDB的最低版本是V5.3，只要提供ES监控接口，我们就可以比较完整地提供健康模型、故障模型所需要的能力。因为我们的实验室目前只有5.3和6.1.3两种环境，因此针对6.0-6.1.2之间的版本在用户现场还需要做一定的适配工作。因为GDB的insight采集接口到6.1.3以后就比较稳定了，在此之前的各个版本中，接口和提供的监控数据还是有一定的差异的。
下周我们将会完成BETA版的封板，并在一个金融用户的测试环境中开展深度对接。健康模型、关键指标、常用工具、日检等功能都已经完成。日检功能是基于GDB官方文档《GoldenDB分布式数据库例行维护手册》中的相关内容编制的，目的是让这些工作能够周期性的自动化完成。
基于对GDB官方文档的学习，我们初步构建了一系列专家模型。
因为5.x和6.x在关键指标采集接口上的不同，因此6.x中的部分指标在5.x中不存在，健康模型就存在一定的差异。
通过对GDB官方文档的学习，我们目前在GDB集群上构建了51条故障模型，这当然是闭门造车的结果，是否有效，必须在实际生产环境中去做验证，并从实际生产环境中不断提炼新的故障模型。加上三十多条通用故障模型，在GDB的运维经验模板中已经有80多条运维经验了。
因为insight的TOP SQL和慢SQL接口并没有开放，TOP SQL和慢SQL的采集目前还是采用传统的方式，不过还好，基于以往的经验，我们已经能够较为准确地采集到这些SQL了。
目前杀会话功能GDB只在INSIGHT中提供，并且没有开放接口给第三方工具，因此目前“紧急杀会话”功能暂时还是空缺的。后续我们将会和中兴的朋友沟通是否能够开放一个接口。
因为时间关系，集群拓扑的图形版还没有适配完成，不过字符版已经完备了。通过点击DN节点和操作系统，我们可以下钻到DN（DN和OS在D-SMART中被单独当成一个运维对象，可以独立进行分析，也会独立产生故障模型告警）。
目前D-SMART GDB功能已经初步完成纳管，下周将会封BETA版了。目前正在使用GDB的朋友，如果有兴趣的话可以和我们或者DBAIOPS社区联系，申请试用许可。我们也希望能够从一线运维侧获得更多有价值的运维经验。
