利用关键词进网站后台,有哪些好玩的网页游戏,手机网站开发的目的及定位,iis7网站建设监控系统是整个业务系统中至关重要的一环#xff0c;它就像眼睛一样#xff0c;时刻监测机房、网络、服务器、应用等运行情况#xff0c;并且在出现问题时能够及时做出相应处理。 美团点评刚开始使用的是Zabbix监控系统#xff0c;几经优化#xff0c;在当时能够达到2W机器… 监控系统是整个业务系统中至关重要的一环它就像眼睛一样时刻监测机房、网络、服务器、应用等运行情况并且在出现问题时能够及时做出相应处理。 美团点评刚开始使用的是Zabbix监控系统几经优化在当时能够达到2W机器450W监控项的量。随着各业务线的发展监控项越来越多Zabbix的问题也越来越突出当时针对Zabbix的吐槽问题有 - 不支持扩展本身是一个单点当机器规模超过万台的时候会出现很明显的性能问题。 - 改造难度比较大不支持定制化功能。 - 配置比较复杂学习成本较高。 - 对外提供的API不够丰富很难与其他业务系统集成。 这个时候我们急于寻找一个替代的解决方案经过筛选后最终选择引进最初由小米开源的Open-Falcon监控系统文档。 下面本文将为大家详细介绍Mt-Falcon在原来Open-Falcon的基础上做出的一些改进。 图片转载自Open-Falcon官网 Mt-Falcon相对Open-Falcon改造后比较大的功能点有报警禁用、报警ACK、报警升级、报警任务分布式消费、支持OpenTSDB存储、字符串监控、多条件监控、索引信息存储改造、过期索引信息自动删除且重新上报后会再次重建等。 一、Agent改造 1. 提升Agent数据转发的性能 异步化处理。之前是每调一次Agent的上报接口就会往Transfer上报一次在数据量特别大每次发送条数又比较少的情况下有可能会出现数据丢失的情况。现在会把监控数据先缓存在Agent程序缓存里面每0.5秒往Transfer上报一次每次最多发送1W条监控项。只要一个上报周期默认60s上报的监控项个数100W就不会出现性能问题。 2. 上报网卡流量时标识出机器不同的网卡类型 业务方的机器有可能一部分在千兆集群上一部分在万兆集群上不是很好区分。之前配置网卡监控的时候统一应用的是千兆网卡的监控指标这样就造成了万兆集群上面机器的网卡误报警。在Agent采集网卡指标的时候自动打上网卡类型的Tag就解决了上面的问题。现在机器网卡类型主要有4种千兆、万兆、双千兆、双万兆配置监控策略时可以根据不同的网卡类型设置不同的报警阈值。 3. 支持进程级别的coredump监控 这个类似于普通的进程监控当检测到指定进程出现core时上报特定的监控指标根据这个监控指标配置相应的报警策略即可。 4. 日志自动切分 正常情况下Agent的日志量是很小的对正常情况下。但是凡事总有意外线上出现过Falcon-Agent的日志量达到过100多G的情况。 为了解决这个问题我们引入了一个新的日志处理库Go-Logger。Go-Logger库基于对Golang内置Log的封装可以实现按照日志文件大小或日志文件日期的方式自动切分日志并支持设置最大日志文件保存份数。改进版的Go-Logger只需要把引入的Log包替换成Go-Logger其他代码基本不用变。 Go-Logger的详细用法可参考https://github.com/donnie4w/go-logger。 5. 解决机器hostname重复的问题 系统监控项指标上报的时候会自动获取本地的hostname作为Endpoint。一些误操作如本来想执行host命令的一不小心执行了hostname这样的话本地的hostname就被人为修改了再上报监控项的时候就会以新的hostname为准这样就会导致两台机器以相同hostname上报监控项造成了监控的误报。 为了解决这一问题Falcon-Agent获取hostname的方式改为从/etc/sysconfig/network文件中读取这样就避过了大部分的坑。另外当已经发生这个问题的时候怎么快速定位到是哪台机器hostname出错了呢这个时候可以选择把机器的IP信息作为一个监控指标上报上来。 6. 支持Falcon-Agent存活监控 Falcon-Agent会与HBS服务保持心跳连接利用这个特性来监控Falcon-Agent实例的存活情况每次心跳连接都去更新Redis中当前Falcon-Agent对应的心跳时间戳。 另外启动一个脚本定时获取Redis中所有的Falcon-Agent对应的时间戳信息并与当前时间对应的时间戳做比对如果当前时间对应的时间戳与Falcon-Agent的时间戳的差值大于5分钟则认为该Falcon-Agent跪掉了然后触发一系列告警。 二、HBS改造 1. 内存优化 在进行数据通信的时候有两点比较重要一个是传输协议一个是数据在传输过程中的编码协议。 HBSHeartBeat Server和Judge之间的通信之前是使用JSON-RPC框架进行的数据传输。JSON-RPC框架使用的传输协议是RPCRPC底层其实是TCP编码协议使用的是Go自带的encoding/json。 由于encoding/json在进行数据序列化和反序列化时是使用反射实现的导致执行效率特别低占用内存也特别大。线上我们HBS实例占用的最大内存甚至达到了50多G。现在使用RPCMessagePack代替JSON-RPC主要是编码协议发生了变化encoding/json替换成了MessagePack。 MessagePack是一个高效的二进制序列化协议比encoding/json执行效率更高占用内存更小优化后HBS实例最大占用内存不超过6G。 关于RPC和MessagePack的集成方法可以参考 https://github.com/ugorji/go/tree/master/codec#readme。 2. 提供接口查询指定机器对应的聚合后的监控策略列表 机器和Group关联Group和模板关联模板与策略关联模板本身又支持继承和覆盖所以最终某台机器到底对应哪些监控策略这个是很难直观看到的。但这个信息在排查问题的时候又很重要基于以上考虑HBS开发了这么一个接口可以根据HostID查询当前机器最终应用了哪些监控策略。 3. 解决模板继承问题现在继承自同一个父模板的两个子模板应用到同一个节点时只有一个子模板会生效 两个子模板继承自同一个父模板这两个子模板应用到同一个节点时从父模板中继承过来的策略只会有一个生效因为HBS在聚合的时候会根据策略ID去重。如果两个子模板配置的是不同的报警接收人则有一个模板的报警接收人是收不到报警的。 为了解决这个问题改为HBS在聚合的时候根据策略IDActionID去重保证两个子模板都会生效。 4. 报警禁用 对于未来可以预知的事情如服务器重启、业务升级、服务重启等这些都是已知情况报警是可以暂时禁用掉的。 为了支持这个功能我们现在提供了5种类型的报警禁用类型 - 机器禁用会使这台机器的所有报警都失效一般在机器处于维修状态时使用。 - 模板禁用会使模板中策略全部失效应用此模板的节点都会受到影响。 - 策略禁用会使当前禁用的策略失效应用此策略对应模板的节点都会受到影响。 - 指定机器下的指定策略禁用当只想禁用指定机器下某个策略时可以使用此方式机器的其他监控策略不受影响。 - 指定节点下的指定模板禁用这个功能类似于解除该模板与节点的绑定关系唯一不同点是禁用后会自动恢复。 为了避免执行完禁用操作后忘记执行恢复操作造成监控一直处于禁用状态我们强制不允许永久禁用。 目前支持的禁用时长分别为禁用10分钟、30分钟、1小时、3小时、6小时、1天、3天、一周、两周。 三、Transfer改造 1. Endpoint黑名单功能 Falcon的数据上报方式设计的特别友好在很大程度上方便了用户接入不过有时也会带来一些问题。有业务方上报数据的时候会把一些变量如时间戳作为监控项的构成上报上来因为Transfer端基本没有做数据的合法性校验这样就造成了某个Endpoint下面对应大量的监控项曾经出现过一个Endpoint下面对应数千万个监控项。这对索引数据数据的存储和查询性能都会有很大的影响。 为了解决这个问题我们在Transfer模块开发了Endpoint黑名单功能支持禁用整个Endpoint或者禁用Endpoint下以xxx开头的监控指标。再出现类似问题可与业务方确认后立即禁用指定Endpoint数据的上报而不会影响其他正常的数据上报。 2. 指定监控项发送到OpenTSDB 有些比较重要的监控指标业务方要求可以看到一段时间内的原始数据对于这类特殊的指标现在的解决方案是转发到OpenTSDB里面保存一份。Transfer会在启动时从Redis里面获取这类特定监控项然后更新到Transfer自己的缓存中。当Redis中数据发生变更时会自动触发Transfer更新缓存以此来保证数据的实时性和Transfer本身的性能。 四、Judge改造 1. 内存优化 有很多监控指标上报上来后业务方可能只是想在出问题时看下监控图并不想配置监控策略。据统计80%的监控指标都是属于这种。之前Judge的策略是只要数据上报就会在Judge中缓存一份每个监控指标缓存最近上报的11个数据点。 其实对于没有配置监控策略的监控指标是没有必要在Judge中缓存的。我们针对这种情况做了改进Judge只缓存配置监控策略的监控项数据对于没有配置监控策略的监控项直接忽略掉。 2. 报警状态信息持久化到本地解决Judge重启报警重复发出的问题 之前的报警事件信息都是缓存到Judge内存中的包括事件的状态、事件发送次数等。Judge在重启的时候这些信息会丢掉造成之前未恢复的报警重复发出。 现在改成Judge在关闭的时候会把内存中这部分信息持久化到本地磁盘一般很小也就几十K到几M左右启动的时候再把这些信息Load进Judge内存这样就不会造成未恢复报警重复发出了。 据了解小米那边是通过改造Alarm模块实现的通过比对报警次数来判断当前是否发送报警也是一种很好的解决方案。 3. 报警升级 我们现在监控模板对应的Action里面有第一报警接收组和第二报警接收组的概念。当某一事件触发后默认发给第一报警接收组如果该事件20分钟内没有解决则会发给第二报警接收组这就是报警升级的含义。 4. 报警ACK ACK的功能跟Zabbix中的ACK是一致的当已经确认了解到事件情况不想再收到报警时就可以把它ACK掉。 ACK功能的大致实现流程是 - Alarm发送报警时会根据EndpointMetricTags生成一个ACK链接这个链接会作为报警内容的一部分。 - 用户收到报警后如果需要ACK掉报警可以点击这个链接会调用Transfer服务的ACK接口。 - Transfer收到ACK请求后会根据传输过来的EndpointMetricTags信息把这个请求转发到对应的Judge实例上调用Judge实例的ACK接口。 - Judge收到ACK请求后会根据EventID把缓存中对应的事件状态置为已ACK后续就不会再发送报警。 5. Tag反选 大家都知道配置监控策略时善用Tag可以节省很多不必要的监控策略。比方说我想监控系统上所有磁盘的磁盘空间其实只需要配置一条监控策略Metric填上df.bytes.free.percent就可以不用指定Tags它就会对所有的磁盘生效。 这个时候如果想过滤掉某一块特殊的盘比方说想把mount/dev/shm这块盘过滤掉利用Tag反选的功能也只需要配置一条监控策略就可以Metric填上df.bytes.free.percentTags填上^mount/dev/shm即可Judge在判断告警的时候会自动过滤掉这块盘。 6. 多条件报警转发到plus_judge Judge在收到一个事件后会首先判断当前事件是否属于多条件报警的事件事件信息是在配置监控策略的时候定义的。如果属于多条件报警的事件则直接转发给多条件报警处理模块plus_judge。关于plus_judge后面会重点介绍。 五、Graph改造 1. 索引存储改造 索引存储这块目前官方的存储方式是MySQL监控项数量上来后很容易出现性能问题。我们这边的存储方式也是改动了很多次现在是使用RedisTair实现的。 建议使用Redis Cluster现在Redis Cluster也有第三方的Go client了。详情请参考https://github.com/chasex/redis-go-cluster。 官方我看也在致力于索引存储的改造底层使用BoltDB存储具体的可参考小米来炜的Git仓库 https://github.com/laiwei/falcon-index。 这块我们有专门做过Redis、Tair、BoltDB的性能测试发现这三个存储在性能上差别不是很大。 2. 过期索引自动删除且重新上报后会自动重建 监控项索引信息如果超过1个月时间没有数据上报则Graph会自动删除该索引删除Tair中存储的索引信息时会同步删除indexcache中缓存的索引信息。索引删除后如果对应数据又重新进行上报则会重新创建对应的索引信息。 默认Graph在刚启动的6个小时内时间可配置定为初始启动状态数据放到unindexcache队列里面意味着会重新创建索引。 3. 解决查询历史数据时最新的数据点丢失的问题 改造之前 - 查询12小时内的监控数据时会先从RRD文件取数据再把取到的数据与缓存中的数据集成。集成原则是RRD与缓存中相同时间点的数据一律替换为缓存中的数据所以查询12小时内的数据是可以正常返回的。 - 查询超过12小时内的数据时会直接从RRD文件获取不再与缓存中数据集成所以在取超过12小时内的数据时最新的数据上报点的数据一直是空的。 改造之后 - 查询12小时内的数据处理原则不变。 - 查询超过12小时内的数据时先从RRD文件获取再与缓存中数据集成。集成原则是RRD与缓存中相同时间点的数据如果RRD数据为空则替换为缓存中的数据如果RRD数据不为空则以RRD数据为准。 这里有一个问题超过12小时内的数据都是聚合后的数据缓存中的数据都是原始值相同时间点RRD中为空的数据替换为缓存中的数据相当于聚合后的数据用原始数据替换掉了是有一定误差的不过有胜于无。 六、Alarm改造 1. 报警合并 重写了Alarm模块的报警合并逻辑 - 所有报警都纳入合并范畴 - 按照相同Metric进行合并 - 前3次直接发后续每分钟合并一次 - 如果5分钟内没有报警则下次重新计数 2. 报警发散 报警发散的作用是在宿主机特定监控指标触发后不仅要发给配置的报警组还要发给宿主机上虚拟机对应的负责人。 现在需要发散的宿主机特定监控指标有 - net.if.in.Mbps 网卡入流量 - net.if.out.Mbps 网卡出流量 - icmp.ping.alive 机器存活监控 - cpu.steal CPU偷取 根据机器所属的环境不同发给对应的负责人 - prod环境发给SRE负责人RD负责人 - staging环境发给RD责人 - test环境发给测试负责人 3. 报警白名单 报警白名单是指当某一个指定的Metric发生大量告警时可以迅速屏蔽掉这个Metric的告警这个比较简单就不多说了。 4. 报警任务分布式消费 未恢复报警信息之前是存储在Alarm内存里面现在改为存储到Redis中。这样就可以启动多个Alarm实例同时从Redis报警队列中取任务进行消费。Redis本身是单线程的可以保证一个报警发送任务只会被一个Alarm实例获取到sender模块使用同样逻辑处理从而实现了报警任务的分布式消费处理。 5. 报警方式改造 现在报警方式和事件优先级解绑优先级只是表示故障的严重程度具体报警发送方式可以根据个人喜好自行选择。在美团点评内部可以通过内部IM大象、邮件、短信和电话等方式发送报警。 现在支持的优先级有 - p0: 最高优先级强制发送短信大象和邮件可以自行选择。 - p1: 高优先级强制发送短信大象和邮件可以自行选择。 - p2: 普通优先级强制发送大象邮件可以自行选择。 - p3: 低优先级只发送邮件。 - p9: 特殊优先级强制使用电话短信大象邮件进行发送。 6. 报警持久化和报警统计 报警持久化这块刚开始使用的是InfluxDB不过InfluxDB不方便统计而且还有一些其它方面的坑后来就改成直接存到MySQL中了。 我们每天会对报警信息做一个统计会按服务、人、机器和监控项的维度分别给出Top10。 还会给出最近7天的报警量变化趋势以及在每个BG内部分别按服务、机器、人的维度给出当前Top20的异常数和周同比。 7. 报警红盘 报警红盘的作用是统计一段时间内每个服务新触发报警的数量把Top10的服务展示到页面上。报警数90显示红色50~90之间显示黄色当有事故发生时基本可以从红盘上观察出来哪个服务出现了事故以及事故的影响范围。 8. 监控模板支持发给负责人的选项 监控模板对应的Action中添加一个发给负责人的选项这样Action中的报警组可以设置为空在触发报警的时候会自动把报警信息发给相应的负责人。可以实现不同机器的报警发给不同的接收人这个功能。 9. 触发base监控的时候自动发给相应负责人 为避免报警消息通知不到位我们设置了一批基础监控项当基础监控项触发报警的时候会自动发给相应的负责人。 基础监控项有 - “net.if.in.Mbps”, - “net.if.out.Mbps”, - “cpu.idle”, - “df.bytes.free.percent”, - “df.inodes.free.percent”, - “disk.io.util”, - “icmp.ping.alive”, - “icmp.ping.msec”, - “load.1minPerCPU”, - “mem.swapused.percent”, - “cpu.steal”, - “kernel.files.percent”, - “kernel.coredump”, - “df.mounts.ro”, - “net.if.change”, 七、Portal/Dashboard改造 1. 绑定服务树 创建模板添加策略配置报警接收人等操作都是在服务树上完成。 2. 提供一系列接口支持所有操作接口化并对接口添加权限认证 我们支持通过调用API的方式把监控功能集成到自己的管理平台上。 3. 记录操作日志 引入公司统一的日志处理中心把操作日志都记录到上面做到状态可追踪。 4. shift多选功能 在Dashboard查看监控数据时支持按住shift多选功能。 5. 绘图颜色调整 绘图时线条颜色统一调成深色的。 6. 索引自维护 系统运行过程中会出现部分索引的丢失和历史索引未及时清除等问题我们在Dashboard上开放了一个入口可以很方便地添加新的索引和删除过期的索引。 7. Dashboard刷新功能 通过筛选Endpoint和Metric查看监控图表时有时需要查看最新的监控信息点击浏览器刷新按钮在数据返回之前页面上会出现白板。为了解决这个问题我们添加了一个刷新按钮点击刷新按钮会自动显示最近一小时内的监控数据在最新的数据返回之前原有页面不变。 8. screen中单图刷新功能 screen中图表太多的话有时候个别图表没有刷出来为了看到这个图表还要刷新整个页面成本有点高。所以我们做了一个支持单个图表刷新的功能只需要重新获取这单个图表的数据即可。 9. 支持按环境应用监控模板 现在支持把监控模板应用到指定的环境上比方说把一个模板直接应用到某个业务层节点的prod环境上这样只会对业务层节点或者业务层节点的子节点的prod环境生效staging和test环境没有影响。 八、新增模块 1. Ping监控 使用Fping实现的Ping存话监控和延迟监控每个机房有自己的Ping节点不同节点之前互相Ping实现跨机房Ping监控。 2. 字符串监控 字符串监控跟数值型监控共用一套监控配置也就是Portal和HBS是统一的。当上报上来的数据是字符串类型会交由专门的字符串处理模块string_judge处理。 3. 同比环比监控 同比环比监控类似于nodata的处理方式自行设定跟历史某个时间点数据做对比。因为数据会自动聚合所以与历史上某个时间点做对比的话是存在一定误差的。 官方提供了diff和pdiff函数如果是对比最近10个数据点的话可以考虑使用这种方式。也可以考虑把需要做同比环比监控的监控指标存入到OpenTSDB中做对比的时候直接从OpenTSDB获取历史数据。 4. 多条件监控 有些异常情况可能单个指标出现问题并没有什么影响想实现多个指标同时触发的时候才发报警出来。因为Judge是分布式的多个指标很可能会落到不同的Judge实例上所以判断起来会比较麻烦。后来我们做了一个新的模块plus_judge专门用来处理多条件告警情况。 实现方案是 - 组成多条件监控的多个策略按照策略ID正序排序后生成一个唯一序列号这些策略在存储的时候会一并存下额处的3个信息是否属于多条件监控序列号组成这个多条件监控的策略个数。 - Judge在收到有多条件告警标识的策略触发的告警事件时直接转发给多条件监控处理模块plus_judge。 - plus_judge会根据序列号和多条件个数判断是否多个条件都同时满足如果全都满足则才会发报警。 Mt-Falcon现在在美团点评已经完全替换掉Zabbix监控接入美团点评所有机器数据上报QPS达到100W总的监控项个数超过两个亿。下一步工作重点会主要放在美团点评监控融合统一配置页面改造报警自动处理数据运营等方面。 我们也一直致力于推动Open-Falcon社区的发展上面所列部分Feature已Merge到官方版本后面也会根据需求提相应PR过去。 大闪美团点评SRE组监控团队负责人。曾就职于高德、新浪2015年加入原美团一直负责监控体系建设。目前致力于故障自动追踪与定位、故障自动处理、数据运营等持续提升监控系统稳定性、易用性和拓展性。
