新手都能看懂的监控报警系统架构设计。监控告警这方面我想过很多次，因为监控告警现在是互联网公司的常见产品。大数据的监控告警只是一系列告警规则的一个子集，虽然这个子集非常复杂。有趣的是，报警系统的底层数据存储引擎也属于大数据存储的范畴。所以我打算从这样一个大纲开始这篇文章：针对大数据集群，监控告警的特点。监控报警系统的发展历程和业务背景。监控和报警系统的一般架构。监控和报警系统的详细信息。图1：根据大数据集群的不同特点，监控告警的特点，比如大数据基础设施部门，不可能配备专门的测试工程师，那么如何跑好这么多机器、服务和应用呢？这就需要一个强大的“自动监控报警系统”。在监控告警方面，不同的公司有不同的解决方案。对于大公司、小公司、创业公司，都是根据自己的实际情况，选择适合自己的合理方案。监控报警系统发展历程及业务背景市场上的监控报警系统五花八门，但市场越是琳琅满目，就越需要擦亮眼睛，看清本质，剥去它的筋骨，才能发现适合您的解决方案。网上有很多关于公司内部监控报警系统的文章，都提到了自己监控系统的实现，但是都是直接说明实现的细节，没有讲骨架和背景。感觉对新手程序员来说会有点生硬，对于想了解监控报警系统内部工作原理的人来说，架构逻辑不够清晰。所以，我写了这篇既谈背景又谈骨架的文章。首先，背景，我们来谈谈软件工程。很久以前，软件开发的技术团队在进行迭代开发时，一般要经历这样一个开发过程：需求分析原型/功能设计测试用例设计（Tdd测试驱动开发）开发人员完成功能，部署测试环境测试根据测试用例进行测试。如果在测试过程中发现bug，会回滚到开发中重新修复。如果测试没有测试出bug，线上生产环境和其他在线用户都会发现bug。好心用户会反馈bug并联系客服。这种人员流动会带来什么问题？一般是简单的“显式”bug，比如“网站关键页面打不开”、“网站订单支付功能一直失效”等。用户和公司都可以在相对较短的时间内发现问题，然后将问题重新组织并报告为错误，修复并回滚。还有一些“隐性”的bug，比如“网站越来越慢”，“支付功能需要30秒才能成功”，“有时成功，有时失败”，“短信验证码变贵了”一周的产品发布”。25秒发送到客户手机”。有时候这样的问题不影响业务逻辑的正常运行，但肯定是系统内部有问题。有时候经过长期的积累，会逐渐暴露出更多的问题，最后导致到核心业务的宕机；有时连产品本身上线后的性能都非常差，这是因为某次上线的“代码/配置”发生了变化，这种“隐性”的bug也会影响用户体验，测试发现显性BUG，隐性BUG呢？随着互联网的发展，各大互联网公司对业务的稳定性和可靠性的要求越来越高，但是公司的业务线越来越多，越来越多。测试工程师不可能没完没了地做人肉手动测试，24小时盯着产品看内部发现问题“快”、“自动”、早于“用户”。这迫使创建“自动定期在线测试”。“早期自动化测试”，就在软件上线之前。比如开发提交新功能后，公司会有Jenkins等持续集成工具自动触发运行测试用例。用例包括开发人员的“单元（白盒）测试”和测试人员编写的“脚本（黑盒）测试”。所有要求都通过后，就可以部署到“生产”环境了。这样，大部分“显示”的bug都能找到，但“隐含”的bug就很难找到了。如果某些程序有内存泄漏，它们不会立即崩溃。可能需要一周甚至一个月的运行时间才会出现问题。“自动定期在线测试”解决隐藏的错误。产品上线后，持续对线上环境的各项指标进行长期观察，定期判断发现异常。如果存在潜在异常，某些监控指标可能会出现问题。当一些异常指标暴露出来时，如果能第一时间联系到相应产品的“负责人”，立即进行补救，从长远来看，产品的口碑会大大提高。例如：某电商网站的支付页面，响应速度持续超过5s，远大于长期平均值（2s）。当这种现象连续出现5次时，就会向该区域的研发人员发出告警，发现程序有资源。泄漏导致机器变慢，然后重启了一些服务以确保用户的速度得到提升，然后立即针对该功能组织了一个Hotfix，最终解决了问题。监控告警系统的总体框架前面讲过“自动化周期在线测试”的历史原因和背景。看来，这是时代发展逼迫技术世界造成的“技术更替”。在接下来的内容中，我们将“自动化周期在线测试”系统统称为“监控报警”系统。因为它代替了人“监控”和测试工程师“报告问题”。图2：监控告警信息流监控告警我觉得分为四大块：采集数据和存储数据（时间序列的存储）告警规则和告警行为下图是这样的：图3：监控告警系统架构图监控报警系统细节分析和数据采集数据采集，我觉得这个经典的《Measure Anything，Measure Everything》（https://www.tuicool.com/articles/A3AFvu6）打开了可以看一篇关于“数据驱动”的博文”新时代的监控运维思维。这里提到的思路也很符合我这个系列文章的主要目的：让大家的决策基于数据。文中提到，企业级监控数据通常包括以下三类：网络数据，包括骨干交换机、核心交换机等硬件设备。服务器数据，包括服务器CPU、内存、硬盘的各种使用数据。应用程序数据。应用数据是三者中最难的，但也是最重要的。应用数据是与业务逻辑密切相关的数据。当业务逻辑发生变化时，应用程序数据的集合也会发生变化。在应用数据方面，有一个名为Statsd的开源项目，催生了“应用数据收集标准”。https://github.com/etsy/statsd/blob/master/docs/metric_types.md这里我也简单提一下：Cumulativevalue(Counting)gorets:1|c服务时间（Timing）glork:320|女士|@0.1指数值(Gauges)gauge:333|g字符串的第一部分是“METRIC”，用冒号分隔的左边是“METRIC_KEY”，右边是“METRIC_VALUE”，竖线右边的部分是“数据类型”。存储数据监控告警的数据都是围绕“监控指标值随时间变化的趋势”这一目标进行设计的。每个监测指标数据序列自然是“按时间排序的”，这是它的特点。业界将存储这种数据结构的工具称为“时序数据库”。这是一个专有数据库，而不是像RDBMS（关系数据库）这样的通用SQL-LIKE数据库。市场上有许多基于时间序列的数据库。无论底层数据结构实现是什么样子，时序存储的本质数据结构始终是：Map>不同的底层实现是不同的。上述数据结构的某些点有不同的扩展，如：s1。METRIC_KEY的分片逻辑在实现上是不同的：选择的分片是一致哈希还是残差哈希。s2.SortedMap的实现不同，本质上是一个按Timestamp排序的序列。s3。阅读和写作的偏好略有不同。这里我不会重点介绍每一??个具体的时序数据库及其底层数据结构的实现。在选择技术时，我们不仅要考虑技术的痛点，还要考虑业务的痛点。业务场景确定了，技术选型也就确定了。那么根据业务场景，还有另外几个选择点：s4.Metrics会不会无限增加？s5.Metrics保留多长时间？s6。上层的业务告警有多重要？为了解决技术选择SELECT，s1-s6，我举几个例子来说明：Metrics是否会无限增加，保留时间专有系统，即解决特定领域某个问题的时序存储，并且Metrickey不会无限增长。例如，我们的Hadoop管理套件Cloudera-Manager或HortonworksAmbari都有自己的监控和报警系统。它们都是将数据存储在本地磁盘上，相当于一个本地数据库。单机版数据库的问题是受限于单机硬盘的物理上限。好在Hadoop技术栈的监控指标有限且收敛，这些数据大部分只需要保留一个月。因此，“Hadoop监控系统”的单机存储空间是可控的。专有系统必须服务于成熟的“有凝聚力的产品”。一般的监控报警系统，Metrickey会无限增长。正如《Measure Anything，Measure Everything》所说，公司各个业务线团队都会将自己的应用数据发送到一个统一的指标数据存储中。随着业务线和监控指标的增长，时序存储的压力无限增大，而数据保留的时间是不确定的，很可能是无限大的（每个应用都有其特殊性，不可估量）。这就要求底层数据存储必须支持“无限水平扩展”。SortedMap实现及读写偏好SortedMap是一个全局排序的映射表，其实现应根据报警监控的实际需要而定。由于专有系统指标有限，数据采集频率也不会异常高，同时写入的数据量应该是可控的。这时候B+Tree和SkipList就是很好的实现方式。对于通用系统，监控指标会无限增加，有些指标需要采集的频率可以达到几十毫秒。这种高频并发的写入需求，一般都是使用lSMTree来实现的。上层的业务告警有多重要（HA&高可用）任何时候，监控告警系统都要可用，要能容忍部分机器故障。不能因为某台机器或某个进程挂了，导致整个监控告警系统宕机。SPOF：https://en.wikipedia.org/wiki/Single_point_of_failure监控报警系统用于“观察公司内部所有业务是否正常运行”，所有产品的直接救命稻草也被压入“监控报警”系统开启。挂了，反映不了公司所有产品的问题。因此，基于单机版数据存储的时间序列无法满足企业级需求。一定要选择高可用的HA（HighAvailable）数据存储方案。对于小型初创公司，可以暂时放弃业务初期和高速增长阶段的高可靠性和可用性，采用“磁盘Raid、定时备份、主从切换”等简单易实现的技术在数据库级别”以快速满足轻型工作负载。量化业务需求。最后附上一些时序数据库引用的论文和文章：wiki：时序数据库https://blog.outlyer.com/top10-open-source-time-series-databasesAlarmrules报警规则模块，首先是自然的个性.为什么？报警规则显然与每个公司的具体业务相关联。这些规则是基于对历史数据的分析和测量。这里涉及到公司业务的个性化，关于个性化业务的细节，本文不再赘述。我们来看看告警规则的一般技术要点：High-Available规则定期检查企业级应用，最重要的是高可用HA，必须避免单点故障SPOF。如果“报警规则模块”出现问题，仍然会导致“监控报警”系统失效。一般来说，告警规则是周期性触发的。因此，需要一个“CronJob-like”调度器。这类调度系统的HA设计可以参考《Azkaban》和《Quartz》：Azkaban:https://azkaban.github.io/Quartz:http://www.quartz-scheduler.org/主要组件调度系统的HA设计有“常规数据库的高可用”和“调度服务器的高可用”两个方面：数据库的高可用是通过Master-Slave主从来实现的。对于调度服务器的高可用，如果有state，就使用zk/etcd来实现高可用；如果没有状态，则启动多个调度服务器。根据调度规则制定一定的分片策略并不难。报警规则定义在观察了一系列监控报警产品后，我大致总结出两种定义“报警规则”的方式：基于“正则表达式”。基于直接“脚本和编程”。基于正则表达式：熟悉表达式语言后，编写起来比较容易，但灵活性较差。复杂的告警规则难以实现，一般适用于简单的告警规则。例如，当一个或两个观察指标达到阈值时触发，如下图所示：Prometheus:Alertingrules|Prometheus图4：基于规则设置告警的Promethus示例也是基于可视化配置规则，比如Zabbix的Trigger配置：ZabbixDocumentation3.2。图5：Zabbix可视化规则配置Grafana在4.0之后也有一个简单的基于规则的告警功能：AlertingEngine&RulesGuide，如下图：图6：Grafana4.0基于规则的告警UI.1图7：Grafana4.0规则-basedalarmUI.2基于“脚本/编程”，这种类型的规则定义提供了无限的灵活性。因为“可编程”意味着你可以“无所不能”。但是也有一些缺点，比如：引入了一个额外的外部依赖：代码管理库，意味着另外一个系统需要高可用HA。公司内部代码管理一般使用Github/Gitlab。当你想快速修改告警规则时，过程会比较慢，因为你要经过代码修改，Merge，最后Submit。告警规则“脚本”定义示例：采集两个数据源的数据，根据自定义规则判断指标是否异常。找出真正的原因。这种稍微复杂的告警规则可以通过编程脚本实现，没有压力，但是基于规则语言实现告警则困难甚至不可能。图8：基于“脚本”的告警规则，定义函数图9：基于“脚本&编程”的告警规则示例告警行为你可能会问，告警行为有什么可说的？无非就是触发报警规则后，通过电话、微信、短信、邮件等媒体找到正确的负责人。这听起来很简单。好了，继续丰富应用场景：比如我们的Hadoop架构组包括HDFS、Yarn、Hive、HBase、Zookeeper、Spark、Presto、Impala、Hue、ClouderaManager……好了，不说了.这么多部件，一个人能操作和维护吗？是否需要在组内多人分工？每个星期？HadoopNamenode的健康检测告警是5分钟一次。每次检测失败都要报警吗？会不会有误报？第一次异常报警后，工程师已经在排查问题。这时候，连续第二、第三次检测异常，我需要连续打电话打扰工程师吗？那么，连续压制多少次报警呢？哪些闹钟很重要，白天晚上都要打电话通知；比较重要的，白天打电话，晚上发邮件或者短信先通知问题；这是次要的，您只能发送电子邮件。有时检测程序也会因为一些“噪音”而抖动。比如检测网页的打开速度限制在2ms，但是访问一次是因为网络链接抖动达到50ms，是不是直接报警？是不是连续3-5次数据都超标，确认问题后再报警？报警行为软件分为“自研”和“第三方”两条路径：自研，此路径适用于报警行为规则强大复杂的大公司。包括告警行为规则的复杂度和告警媒介的复杂度。每个公司使用的内网办公聊天软件和邮件系统可能不同，会有独特的场景需要整合。每个公司、每个群体的告警行为可能不同。有的需要7*24小时，有的只需要白天发邮件，有的甚至只需要工作日白天发邮件。第三方软件，中小企业，创业公司更适合使用第三方软件。据我所知，湾区的大多数公司都使用Pagerduty。详情可参考链接：https://www.pagerduty.com/。不过这款产品还没有汉化，市面上也没有杀手级软件。找了一圈，找到了Oneapm公司的One-Alert（http://www.110monitor.com/），试用了Demo，还不错。个人意见：这方面的需求会增加。希望国内有靠谱、靠谱的企业??，共同推动国内“监控报警”市场的发展。综上所述，我整理了一张表格来描述“监控报警”领域常见的开源产品范围：做技术选型的时候一定要着眼长远，多考虑未来的需求。您不能只专注于快速交付。同时，也希望国内有专注于“报警行为”的公司。作者：王射阳简介：美国视频网站hulu工程师，毕业于北京理工大学计算机专业，目前从事大数据基础设施工作。个人知道《大数据SRE总结》专栏：http://dwz.cn/7ygSgc。
