与互联网产品的立项模式类似，当我们定义设计一款新产品时，首先需要对用户做需求分析，归纳整理综合分析用户的需求，定义我们的产品定位，功能，业务逻辑，使用界面等等。因此，为了设计好数据库智能监控系统，我们需要对数据库监控系统的目标用户做需求分析，收集用户诉求，挖掘用户潜在需求，绘制典型用户画像。最后，设计数据库监控系统的实现架构，将典型用户的各种需求纳入到产品的设计架构管道中。
数据库智能监控系统的用户实际应用场景中，数据库监控系统的用户可能会有很多种不同的角色。不同公司因为组织架构不同，可能存在更细分或者更聚合的用户角色。但是总的来说可以归纳整理为如下三种用户类型：
应用开发（APP DEV）
运维工程师（SRE）
数据库管理员（DBA）
应用开发工程师角色：主要负责开发云应用中的业务SQL，对云服务的功能和性能负责。同时需要保证写出的SQL高效优质，不会对集群造成额外的资源消耗和时间消耗。因此，应用开发工程师，需要能够对新开发的SQL进行监控，了解该新增查询语句的执行效率以及资源消耗情况。
运维工程师角色：主要负责保证数据库集群的长期稳定运行。需要分别从资源消耗和系统负载两个角度对数据库系统进行评估。需要能够配置数据库的告警场景，并且可以看到实时或预测的数据库告警信息，将发现的问题报告给数据库管理员角色做进一步处理。总的来说，运维工程师角色会监控大量的数据库集群，他不会对每一个集群做非常深入的分析，而是更多的会以问题发现者的角色出现。
数据库管理员角色：主要负责定位数据库问题的根因并且提供相应的解决方案。数据库管理员需要是数据库领域的专家，熟悉数据库的方方面面，他可以从多个维度分析数据库监控数据，定位数据库故障，并提供解决方案。
需要说明的是，以上三种角色并不是指实际生产环境中的岗位，而是为了方便分析用户需求而归纳总结出来的典型角色符号。实际生产环境中，可能出现三种角色为同一个人的场景，或者SRE岗位会身兼SRE与DBA角色的场景。我们这里将用户区分为三种角色，主要是为了方便我们做需求分析并且构建对应的人物画像，从而进一步锁定对应角色人物所需要的工具。最终，呈现给大家一个思路清晰的数据库监控系统开发概念脉络。
数据库智能监控系统工具及应用场景通过上面的抽象和梳理，我们发现在数据库监控运维过程中三种角色分别对应着不同的需求，而不同的需求必将导致不同工具或者同一个工具的不同侧重点。下面我们围绕三种角色，分别展开详细介绍其将要用到的工具：
应用开发角色，他们只关心自己写的SQL是否高效，是否有利用到集群的各种优化特性，是否占用了集群的过多资源？因此，他需要一个能够让他评估其所写SQL执行效率的工具，也就是WebSQL工具，允许用户简单的连接到数据库，并且执行SQL语句。WebSQL可以返回SQL语句的执行结果，也可以返回其执行计划，帮助应用开发角色，了解其SQL语句的执行效率。同时，用户的SQL语句并不是简单的单条语句执行的，而是需要将其放在整个作业流中去执行的。那么衡量其在作业流中的执行时间和资源消耗的基线就变得非常重要。因此，我们就需要查询监控可以针对特性的SQL记录其执行时间和资源的消耗，并且计算最大值，最小值和平均值，作为比对基线，来进一步帮助用户评估其SQL的执行效率。在用户现场，因为资源隔离需求，用户的作业是需要绑定到某个工作负载队列执行的，那么工作敷在队里的资源配置，以及工作负载队列的负载水平等数据又变得非常重要，新加的SQL语句是否会造成工作负载队列的超载？当前工作敷在队列的资源是否合理，这个都需要应用开发角色在新开发的应用上线前有个直观的了解。
系统运维角色角色（SRE），他们关心云上数量庞大的数据库系统的长稳运行，基于这个需求，我们打算提供三个方面的工具来解决问题。
健康指数指标，该指标是一个复合指标，该指标主要由两方面的指标支撑，资源消耗指数和数据库系统负载指数。而这两种指标又有其更下一层的原子指标和延伸指标支撑。集群健康指数的计算需要设计一套相应的数学模型，以该模型为基础我们就可量化系统的健康指数，从而可以使系统管理员非常简单的从云上数以百计的数据库中快速发现有问题的数据库。