文末还有本期PPT的获取路径，不要错过~

Q1：采集的历史数据需要放到啥类型的数据库中？

A：因为我只需要使用三个月左右的数据，所以现在数据还是放在传统的关系型数据库里面，便于查询和处理。其实我更偏向于使用时序数据库存储指标数据。

Q2：一场检测算法，怎么处理营销宝典活动的数据呢？

A：对于促销类的活动，异常检测算法可定会将那段时间的很多指标数据标记成异常。我认为这个行为是应该的，因为确实发生了很大的业务行为变化。这个变化值得运维人员去关注。但是最重要的是要搞清楚这部分新的数据在下次检测的时候要不要。所以是不是要给这个时间窗口打个标记，下次训练排除这部分异常数据。

Q3：像Zabbix、Promethues这类的监控平台能否有效的监控数据库的健康状态？

A：Zabbix和普罗米修斯这些监控平台都是很好的工具。在我行也已经大规模使用。但是这些工具对于数据库的监控其实还是更多依托人为定义采集的数据，因此健康状态这个问题还是DBA来定义的。

Q4：请问有做一场预测模型吗？

预测模型现在还没有做，计划后面针对核心的指标做一些oom这种类型的异常预测。基于历史变化趋势判断未来是否会出现异常。另外一个计划做的事情是磁盘的健康预测。

Q5：请问异常和具体的SQL是怎么关联起来的？

A：异常指标是数据库级别的。SQL自己也有指标。需要做的事情就是基于历史数据，在数据库指标和sql指标之间找到他们的相关性，最后基于相关性来定位sql指标已经sql贡献度。

Q6：您这边没有用到时间序列预测，请问用的是什么模型呢？

A：暂时没有使用时间预测。主要原因是我这边观察大部分数据的时序特征不是很明显。数据库的指标不仅仅受到业务周期的影响，内部各种机制的触发也会影响指标数据。而且时序模型报出来的异常数量会更多。我只从产品健康的角度触发，而且不关心业务的周期，所以最终放弃了时序模型。

Q7：SQL是如何搜集的，是全部采集还是出现问题再采集呢？

Sql也是周期性采集的，间隔5分钟。因为SQL的数据也需要做差值和平均。

Q8：数据采集频率是多长时间呢？

A：1分钟到5分钟不等。这个主要看需求。我个人觉得5分钟就可以。通常一个异常的发现不会被5分钟就平滑掉的。

Q9：请问db2用快照分析，那Oracle和MySQL用什么分析呢？

A：我虽然称为快照数据，但是和db2的snapshot不一样。因为db2的snapshot工具已经弃用了。Db2我用的mon_get_database，Mysql我用的show global status 加上performance schema里面的event wait相关视图。

Q10：每个SQL的执行，都有相关执行时间、等待时间之类的吗？

A：这个是有的。DB2的sql信息里有cpu时间，执行时间，等待时间，各种子的等待时间等，非常详细。因此时间分布饼图就非常好做。结合时间分布和异常的指标信息，分析sql问题就很简单啦。

Q11：数据库诊断日志监控和分析吗？

A：这个还没有做，是在计划里的。主要思路是用爬虫去定期获取官方的问题数据，然后基于自然语言处理里面的一些基础算法，将问题变成向量，诊断日志也变成向量，最终通过相似度来判断是否命中已知问题。

Q12：数据库方面，还有那些场景可以智能运维来实现呢？

A：异常预测，健康度检测，数据库画像，资源动态调配，异常自愈等。其实未来能做的很多。

Q13：如果实现了，dba是不是就没饭吃了？

A：这个问题我特别想回答。我认为未来的DBA是要向两个方向发展的。一种是深度。借助智能运维挖掘的信息价值，DBA能够更了解一个数据库，更能够洞察数据库的运行状态。因此DBA的技术其实是会往深度拓展，这是一片新的天空。还有一种是高度。借助智能运维，DBA可以更清楚管理的所有数据库的运行状态，更能够把握不同数据库产品的特点，不同业务在使用数据库时候的特点。DBA以更贴近业务的管理方式为业务服务，挑选合适的数据库，合适的软硬件。也就是DBA的服务更往前推了。总的来说，未来DBA的影响力更大，更不可或缺。

Q14：关于学习智能运维的算法，有什么推荐的书籍吗？你是怎么入门的？

A：我自己是先看吴恩达的视频开始的。因为他讲的特别透彻，我也比较喜欢从原理还是往结果走。不过他的内容更多的是和深度学习相关。而深度学习在其他领域效果很好，但是在运维领域，因为其不可解释性，反而用的不多。后来是看看机器学习的那些基础算法。Sklean有张机器学习的算法挑选图。建议按照那个图把相关算法都看看。

Q15：机器学习基本算法对开发要求高吗？

A：要求不高，这个算法都有现成的模型。所以只要清楚原理，会用就好。

Q16：目前我们也有收集采集主机信息并加工分析的想法，数据是在源端格式化后采集吗？需要源端加工吗？入库后，需要怎么规划管理这些数据呢？

A：建议源端采集之后就格式化成json数据往后走。数据加工不建议源端做。数据都得管理好生命周期：采集，处理，存储，清理。建议每一步都用做适合的工具。我这边因为数据因为是个旁路分析系统，原始数据在其他系统还有，因此我也不需要保存历史。基本上保存3到6个月数据就行。所以我直接清理了。否则的话还需要归档。