分布式系统的监控的总结：
1、健康的监控和警报系统应该是非常简单、易于理解的
2、紧急警报应该关注于现象
3、监控的技术栈层面越高，监控现象越容易
4、Email警报的价值通常极为有限，很容易变为噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况
5、选择那些正在发生和即将发生的问题来进行报警，设置一个可以实际达到的合理目标，保证监控系统可以支持快速的问题定位与检测
Q1：现在美国的实际做到什么程度？
AIOPS在中国炒的比较火，大规模的日志分析和处理美国是做的比较超前的，
1.首先是对设备故障率的预测，它可以从很多磁盘的IO上分析出坏盘的问题，比如提示哪些磁盘或者IO子系统可能会有提前的损坏或故障；
2.访问量的预测，我认为访问量的预测是LTSM（时间序列的网络），它是符合排队论一些基本的点，很多时候我们可以做一些访问量的预测，提升整个系统的运维水平。
3.告警信息的过滤，主要是对关联告警事件的分析。
Q2：监控是否应该花时间去做图形化展示，例如postgres，grafana？
监控如果做图形化展示很多时候是用于大屏展示的，从监控角度来讲更多的运维人员是看的工单系统，比如监控点在1000个节点以上时再漂亮的展示也都是一团黑。我们更多的时候是看一些工单的系统，因为实际上我们的监控工具直接会进入工单系统产生工单，告警的是工单，我们根据告警的工单去做下一步的人工或自动的干预。所以要客观分析我们是要漂亮还是高效。
Q3：访问量预测、告警信息过滤是RCA？
RCA（Root Cause Analysis）是一种根本原因分析方法论，RCA的主要流程是复现整个事件的一个时间序列，复现这个过程到底发生了什么，从根本上分解决这个问题。通常如果出了问题我们会启动人工流程去做RCA，RCA后生成一个报告提交给客户。
Q4：基础设施监控有何建议？使用哪些工具？采集点一般需要部署多少个点？一个节点的服务对多可以监控类似这类的设备多少量？
基础设施监控的有很多软件，第一个选择是看用商业的还是开源的，商业的软件比较成熟但也会有一些缺点，比如升级还有监控agent很占用内存，商业和开源各有各的好处，主要看屁股在哪里，如果从厂商的角度肯定希望用商业的软件，如果从用户或者实际操作者的角度肯定希望用开源的软件，因为相对比较方便省事。如果是工单系统我们通常建议客户使用商业化软件去做事情的处理。
采集点一般需要部署多少个点，这要看监控软件的架构，而且客户的需求不一。一个节点的服务对多可以监控类似这类的设备多少量，关于这个问题还是在于文档。本次我所分享的内容没有涉及到APM的概念，就是应用程序性能监控，大家可以理解为黑盒监控的模式但是也不完全，目前应用APM监控是目前发展的一个方向。
Q5：ELK一般是到什么程度才会用到？
ELK也很好，效率很高速度很。我们团队是在AWS上用的，价格也很贵。我个人是觉得，我们一直缺乏监控方法论的指导，就是说我们应该监控哪些东西，或者说哪些东西对我来讲是重要的，这些也是实际我从Google这本书上学到的东西。
