主要谈谈58到家如何实现立体化监控。希望这个能为大家在实现本公司的监控平台的时候提供一些帮助。用户对58到家的服务延时和服务可用性是非常敏感的，所以当线上服务出现波动的时候，需要迅速把这些问题发现出来，通知RD，让他们来排查一些问题。相信这也是许多公司面临的问题。本文整体分为三段：什么是立体化监控平台；二，58到家如何实现立体化监控平台；总结。
整体从宏观角度来说，立体化监控会分三方面：
机器：这个会包括机器的CTL，网络的负载，网络的内存。
服务： 从服务的角度来说，服务的稳定性，服务的吞吐量，服务的响应时间。
业务：再顶层一些就是业务，包括用户的访问量，我们的承担量。
从宏观上来说，就是分这三个方面。经过分析我们细化了一下监控的维度，大概分了九个方面：从Web端进行监控，RBC Clinet监控，日志检控，GVM监控，Db Server，RPC Server， DB client，其他。
58到家监控平台是如何实现的？
可以看到58到家监控平台最上面是管理平台，管理平台分了三部分功能：配置管理，系统状态，系统排行。
首先，配置管理。在配置管理中有四部分：集群类管理、采集规则、告警规则、监控规则。
集群管理包含了集群是属于哪些IP，集群负责人是谁。采集规则包括采集哪些数据项，包括采集哪些日志的高段字等。还有监控规则和告警规则。告警规则是说用哪种方式告警，告警的频率是多少，告警使用了哪些告警通道。
图中间是系统状态，系统状态主要分四部分：系统评分、事故列表、告警列表展示与管理、排行模块。
系统评分即系统的健康状态。排名的作用就是来促进系统负责人来不断的提高安全意识，让大家来相互监督，推动服务不断的优化。
左下角是采集模块，采集模块分两种：探测型、上报型。探测型将采集模块采集的数据后会发送到聚合模块。聚合模块有两个功能：一个是解析。因为采集模块采集的数据是不一样的，数据规则也是不一样的。比如GVM的监控，采集上来的一条数据可能会包含多个数据项，像JC的次数、内存使用状况、限制数，解析模块负责对这块数据的解析。另外解析模块的功能就是解析这一个数据项是属于哪一类的故障。比如我认不认为GVM内存超过一定比例是不是一个故障？再比如对服务进行监控时，一个接口出现多个报警，认不认为是同一个故障？经过解析后会对数据做个聚合，聚合之后也会有一个落地。同时数据聚合之后，会将聚合的数据发送到分析模块。分析模块就会分析，会根据用户在后台配置的监控规则，看过数据吗等等的，如果满足的话就会出现报警故障。一类是异常故障，一类是恢复故障。故障经过下层的过滤模块进行过滤后会上报到告警模块。
告警模块四部分功能，一个是告警的收敛。告警收敛是指对多个告警做一个收敛连发送一条告警，再加上我的告警量。还有就是故障认领，提供了一个地址，用户可以根据这个地址来提供故障认领。还有故障管理，管由告警模块实现的，在这里我需要强调一下，就是在实现告警过程中我们采用的是事件驱动性。就是所有告警都是由事件分析驱动，同时事件会驱动告警模块中告警状态。还有一种实现方式，就是告警模块来，后端起一个线程，我来检查我的故障来触发告警。之所以使用故障驱动的方式，是因为当整个监控是一个闭环的时候，故障检测是Ok的。但是当告警模块是一个开放的时候，我们无法确保，比如说从其他组件接进来的告警是可靠的。比如其他告警上报过来的事件之后，我的告警模块可能会采用故障检测的方式，就会产生一些误报的情况。最后是我们的告警通道，目前支持了三个通道：短信告警，邮件告警，还有阿里的钉钉告警。
采集模块目前是由三类：一种是检测型，还有一种上报型，再有一种就是嵌入式SDK类型。我重点介绍一下探测型和上报型。探测型会有一个中心点来向各个Server发出一个探测包，收到会有一个回包，由中心节点判断回包是否正常。上报型会在每台机器部署一个Agent，由这个来采集数据进行上报，然后再由监控中心做统一的处理。看一下探测类型怎么实现的？这个是探测类型的系统架构，大家可以看一下配置管理，配置管理主要是对监控规则的配置。比如说一个探测频率，是10分钟探测一次，还是1分钟探测一次。
对数据采集模块，探测型由中心节点向各被监控机发送探测包，探测中心再根据探测回包的结果，判断服务是否正常，探测类型的主要应用为端口监控、url监控、接口监控、业务逻辑监控。
另一种是汇总型，汇总型由各agent采集进行监控数据的采集，之后将采集结果汇总到监控中心,这种主要，用来进行日志监控、jvm监控、服务监控、业务监控。
这是探测型监控的系统架构。
调度器是整个监控中心的核心模块，配置管理模块，如果是URL类型用户需要配置，URL路径；如果是rpc或者是job类的，用户需要配置类路径，任务的监控频率，探测结果的校验规则等等，集群管理负责加载集群的一些配置，主要是集群的IP，任务生器的主要职责是根据集群配置中的IP生成具体的探测任务。
调度器根据监控配置进行监控任务调度，当需要发起探测时，调度器会读取集群的管理配置，同时使用任务生成器生成具体的探测任务，这就是整个监控中心的一个职责划分，中间为接口层，接口层抽象了探测层需要实现的接口类型，探测层继承相应类型的接口，并实现具体的发包代码，与回包的逻辑校验即可。
目前到家使用这种模型的监控有端口监控、URL监控、接口监控、业务逻辑监控。在这当中，端口监控与，URL监控不需要进行额外的编码，框架会实现探测层的代码，rpc接口监控与业务逻辑监控需要RD实现相应的探测代码与校验逻辑。
这个是立体化监控平台Agent结构。上报型，是当更新Agent如何进行快速升级。当有新的监控模块加入的时候，如何有效的实现快速的扩充。下面我将结合这个系统架构图来为大家解释一下是如何实现的。首先最顶层有一个管理平台，管理平台会管理用户在后台进行的一些监控的配置，当中是一个命令生成器，用来教用户想执行的一些动作，生成命令。最后一个是版本管理。当中使用的是ZK作为一个下发的通道。当用户进行配置的时候会通过ZK把命令存入到ZK当中。Agent接受到ZK后会执行它的命令，然后会对命令进行解析。当命令解析模块下面是接口层，接口层规定了每一个模块需要接触时，需要实现的接口。
最下面是列举了几个典型的模块，当有新的模块需要加入的时候，只需要实现接口层代码就可以了。举个例子，就是当进行版本升级的时候，用户在管理平台会生成一个升级命令，通过ZK下达到Agent，Agent模块收到升级命令之后，就会解析出会用哪个模块执行，升级命令会由更新模块来执行，更新模块会根据名命令中的一些参数去STP服务器拉取对应用的炸包，拉取到稳定。这个稳定是非常稳定和便利的。同时这个模块进行扩充的时候也是相当于完成一次从0到有的一次升级。刚才讲的Agent的两个问题：一个就是说如何实现模块快速扩充，另一个是如何实现Agent的快速升级。
下面是Agent命令下发的一个流程。
最右边是我们功能模块需要实现的接口，接口规定了初始化需要执行的动作，命令的执行动作，与模块退出时的清理工作。 web的管理模块下发命令到ZK，agent接收到ZK事件，读取相应的内容并解析成命令，一个命令含有三个要素功能模块jar包路径，功能模块类路径，与执行参数，agent会按序执行，agent会将命令交给执行器后，执行器检查内存中有没有加载功能模块，没有加载的话生成新的类加载器并根据命令中的jar路径进行加载，并初始化，用户也可以同时向agent下发多个命令，
首先用户会在Web平台上使用我们的管理功能，像ZK目录下面下发管理命令。Agent受到下发命令后会对命令做一个解析。命令当中有三部分内容，关键的是这三部分，一个是我的模块部署路径，另外一个是需要启动的Class的内部性，还有这个模块所要执行的一些参数。Agent解析后会交由下面的执行器执行。执行器首先会从内存中查到本地有没有加载过模块。如果没有加载过的话会新生成一个来加载到执行模块。这里执行的新生成的Class模块，是想让每个模块隔离，每个模块互不影响。
我们Agent为大家提供监控功能，但是Agent是如何对它进行存活监控的？这也是关键的问题，采用了两种方式：一个是对进程进行监控。对进程监控我们有很多方式，比如Unix上面也有好多监测存活的方式，我们采用的是后面有一个脚本，就是Agent Watcher，这个会监测一下Agent是否存在，如果不存在就会封启起来。
另外是对整个Agent流程的监控，比如我的进程存在，但是并不能代表这个Agent没问题，也可能是Agnet里面产生了一些死锁。在Agent加一个默认的监控，通过默认的监控作为一个心跳上报上来。上报上来之后数据就会进行落地。在我们后台会起一个AgentWatcher线程，这个线程每隔一段时间会检测每一段时间是否有数据上报，如果没有的话，会报警。经过这个方式我增加任何的其他额外的设施，只是增加了一个Agent这个监控就解决了这个小小的问题。
下面是我们到家监控平台的数据图，左下角是数据采集模块。
这是我们采集模块的一个数据流图，采集模块除了我们之前提到的还有SDK类型的，采集模块采集数据并将日志上报到我们的日志收集系统，日志系统将我们的数据打入到Kafka中，不同的采集模块的数据将会放到不同的Kafka主题中，相应的解析模块对应的Kafka主题，当增加新的监控项时，只要增加新的采集模块，与相应的解析模块即可，实现了各监控项的解耦，每个模块采集的数据格式是不同的。
解析模块的主要职责就是对采集上来的数据进行解析，例如jvm监控采集的每一条数据都有多个数据项，比如说ygc的次数fgc的次数，解析之后会将数据写入到es中，同时将发送到聚合模块进行聚合。
聚合模块在时间维度对数据进行聚合运算，我们采用的聚合单位是1分钟，一个监控项数据聚合后会产生四类数据，最大值，最小值，数据和与数据量，其他的数据项也可以由着四类导出，如平均值等等，数据经过聚合模块的聚合，会产生两部分数据，时序数据与上下文数据，时序数据是热数据，我们再查看监控数据的时候大部分都是查看的时序数据，时序数据存储在OpenTSDB中，OpenTSDB是一个基于HBase的时序数据库，对时序数据的存取有很好的支持，上下文数据是冷数据，当点击数据详情时，才会读取，这部分数据存储在HBase中，聚合模块将聚合后的数据打入到实时校验模块。
实时校验模块根据监控规则进行校验，并将监控结果推送到报警模块，告警模块采用的是事件驱动，报警是由事件驱动的，而不是通过检测故障状态，因为故障检测方式，在恢复事件丢失之后会造成误报，事件驱动是分析模块每次讲分析结果进行上报，来驱动告警模块，进行告警，故障状态转换。
再讲讲对报警做的优化。通过使用多个告警通道来做到了告警的必达。另外在监控中经常遇到的问题，就是告警风暴的问题，当系统出现某一个问题的时候，可能会引起大量的告警。采取措施就是告警收敛，有两个维度收敛。之前讲了在分析模块的时候会分析多个数据项属不属于一个故障。比如我刚才举例子了，像GVM中的GC，还有线程数，当这两个数据出现异常是它是不是异常？另外一个告警收敛，就是在时间维度上进行收敛，我们采取的措施，会有告警周期的设计，就是当首次告警的时候是第一次出现，第二次只有满足我们告警周期时才会发送。就是当分析模块上报的事件在一个周期之后，这个事件才会触发告警。再一个周期之内会不会触发告警的。另外一个措施，在告警的同时，会有一个告警认领的功能。当用户认领了这个故障之后，就认为有相应的RD在处理这个问题，就不会再给他发送报警。这就避免了大量告警的骚扰问题。
同时告警认领功能也实现了我们的告警进度的可视化。就是RD或者管理人员可以在后台查看故障的处理的进度，我这个故障是在异常还是说已经认领，还是已经恢复，还是已经处理的状态。
最后，当告警发送了大量告警之后，仍然没有人处理，这个怎么办？我们采取的方式是告警升级的功能。就是把告警通知到我们的领导，领导没有处理的话，会通知到领导的领导，这样来提高故障的处理意识。
上面讲完告警监控平台的实现，下面来看看效果。左边的图是告警内容。在一个是日志中的告警内容。从告警内容中大家可以看到是哪种类型发起的报警，问题的故障时间是多少，叫什么名字，集群中哪个IP发生了故障，再一个这个集群中哪一个日志文件出现了问题。另外，我这个日志文件监控到哪些个词出现了问题。以这个为例，就是Arrow出现了一次这样的告警。还有在告警中会有日志上下文，用户收到告警之后，可以快速的通过日志上下来判断需不需要迅速地进入这件事。因为有些异常是比较敏感的，需要ID快速介入；有些不是那么敏感，ID第二天来处理也是可以的。这就有日志上下文来提示ID这个议程是怎么进行的。也会统计告警认领率来推动ID来认领故障，来对每一个部门的故障处理速度做排名，来推动ID处理相应的问题。右边是采集的数据的表现图。
下面是一个服务监控的例子。上面也会有一个告警内容，同样在告警内容中也会提示是哪一个集群出现了问题？是哪种类型的服务？在这个当中是一个RPC Client监控，我们提示哪个IP出现了问题，当中也有调用接口，接口类型都是有的。最后需要强调的一革新变旧会在告警的内容中附加一个调用请求的ID，也就是比较长的那一串，前面代表的请求ID，0.980代表的是这个请求在整个请求量中的位置。RD可以通过请求ID到后台来查看整个的调用端的情况，可以查看处在哪个位置，是谁调用的我，我又调用了谁，是我引起的故障，还是说我下游引起的故障，这都是可以查看的，用户也可以在后台查看异常详细情况。图右边是服务监控的效果图。用户可以在图中访问，点击相应的采集点来查看请求的上下文来查看整个调用的情况。
总体上来说监控在服务中出现问题时可以通过这个监控快速的预先我们的故障是发生在哪些位置，耗时是多少，产生了哪类的异常，来帮助RD来排除线上问题，优化服务。
下面是系统状态的效果图。四个图，一个图是系统的打分图，一个是监控结果的图，左下角是告警量的图，还有日志监控配置关键字的得分。介绍一下系统打分的策略：针对系统打分不并没有一个统一的计算公式，我们采取的措施，就是说首先列一个公式，这个公式并不需要有多么精确，多么准确的来反映我这个系统的监控的状态，这个公式的主要目的就是来对我的集群进行划分就可以了。划分出得分高的集群和得分低的集群。得分高来推动得分高的集群来进行优化。当某一个公式无法对我的集群做出一个划分的时候，可以调整公式，从而来达到可以划分出两部分集群，也就是我得分高跟得分低这两部分集群就可以了。系统打分的原数据就是使用的后面的监控结果的数据。
这一次介绍了监控平台如何实现了管理平台化。服务状态可视化，一些监控结果的可视化是如何实现的。通过故障排名或者告警排名，实现了问题透明化。此外，在整个监控平台的系统架构当中，我们实现了接入组件化。
DevOps可以给企业带来3大明显的业务优势——加快产品推向市场速度，提升质量以及提高组织的有效性。在加快产品推向市场速度方面，应用DevOps缩短了开发周期时间和更高的部署频率，有研究表明，应用了DevOps实践的组织往往表现出比一般组织快几个数量级的部署和实施。在提升质量方面， DevOps可以有效提高可用性，提高变更成功率，减少故障。在提高组织的有效性方面，DevOps可以减少浪费，同时交付更多的价值至客户手中。
为了让企业更好的应用DevOps，StuQ工作坊特意请来英捷创软（LEAN SOFT）创始人兼首席架构师，DevOps专家——徐磊老师，给大家带来端到端的、可落地的DevOps实施方案指导。
前20位报名，享受7折早鸟票！给自己和同事抢座儿点「 阅读原文 」
1014
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
