江苏龙网

  1. 主页 > 生活百科 > >

监控系统设计

监控系统

每日优鲜监控系统早期情况系统覆盖不全每日优鲜早期只有交易平台存在一套内部的业务监控系统，没有推广到全公司级别 。大数据团队与自己的业务监控，运维团队有自己的基础监控 。除了交易系统其他业务线的业务监控几乎为零，很多时候都是用户告知我们出问题了，而不是我们主动发现出问题了，导致问题发现的时候已经过去很久了 。
监控类型不完善监控内容主要是涉及日志中出现的数据统计，所以对PV、UV、JVM相关监控都没有，尤其对自身业务的监控几乎为零，我们无法实时的知道当前接口的访问量，错误率等信息；除此之外我们依赖的zookeeper、mq、redis、数据库等中间件的监控也基本没有，所以很难做到深入的排查 。不过好在有一套pinpoint可以帮助故障和性能定位 。但是这并不能代替业务监控 。
监控系统选型和实现选型要实现一套监控系统，必须要保证数据的收集、存储和可视化，然后在基于此实现一套告警系统，最终实现数据的可视化与问题的触达 。
可视化选型在做监控系统选型的时候，最优先定下来的是可视化，即Grafana这套开源产品，因为其支持多数据源，同时也支持告警规则，除此之外其提供了一套完备的API，我们通过程序调用其API实现了监控数据可视化的自动化流程 。
存储选型第二个定下来的是存储系统，监控的数据基本都带有时序性，所以我们自然而然的朝着时序数据库(TSDB)方向进行选型 。最终定下来的存储有两种：存储业务监控数据的OpenTSDB和存储中间件监控数据的Prometheus 。
 
选择OpenTSDB的原因在于我们的业务数据需要长期保留，比如我们现在业务的监控数据已经存储了一年，大家可以轻易的查到?5.17?，?6.18?的历史大盘数据 。
 
中间件等监控数据不需要保留太长时间，所以单独的采用了另一套存储Prometheus的TSDB，为什么选择它的，原因是Prometheus扩展性非常高，通过相关的exporter可以快速的开发一套针对性的中间件监控，同时社区也已经支持了很大一部分的中间件的exporter(收集服务暴露监控数据接口) 。
数据收集监控数据的收集从两方面做的，一方面是提供内存埋点的方式，即我们提供的monitor包，另一方面为了接入了老监控系统能够平滑迁移到新的监控系统上来，我们支持了基于日志的统计，可以统计pv、异常等信息 。
【监控系统设计】 
日志收集也兼容原来的方案，即采用flume进行日志采集，kafka进行日志传输，日志统计系统进行日志数据消费、统计 。
告警系统为了方便与自研的监控系统实现自动化接入以及与现有的组织人员接入，对告警系统做了自研 。
 
告警系统自动化接入： 业务接入监控，如果该业务在应用中心已经注册存在，那么监控系统在第一次收到业务发送的监控数据时，会调用告警平台接口创建告警应用，同时告警平台会根据App_code从应用中心拉取该app_code下所有相关研发人员，全程自动化 。
 
灵活性: 告警平台除了自动化接入，也可以手动接入告警，手动维护告警人员，对外提供了告警接口，业务方可以根据自己的需求接入告警发送、消息通知等功能 。
 
告警方式： 在告警系统上线之初支持短信、邮件、电话三种告警方式，去年年前紧急接入了lark，实现了第一版lark告警功能的接入，到现在告警平台已经对接了多个lark机器人，同时实现了群机器人的告警消息推送 。
 监控系统的架构

监控系统设计

文章插图
 
监控系统的实现业务监控业务监控采用sdk和日志收集两种方式进行统计上报，其中monitor中内置了对数据库连接池的监控、JVM监控、dubbo提供者调用监控、dubbo消费监控等 。
对于JVM监控采用内置的ManagementFactory获取
Dubbo和Http接口的pv和异常监控均采用拦截器的方式，直接集成在monitor中 。
机器监控机器监控的基础数据来源于运维团队的Prometheus，通过业务监控上报上来的机器IP拼接PromQL，并将机器的监控与业务监控的大盘集成，业务可以在业务监控大盘中看到自己的应用的资源使用情况 。
中间件监控中间件监控分为两种方式，早期的redis管理平台和rocketmq各自基于monitor sdk实现了自己的监控埋点，走的路线跟业务监控相同 。
监控系统自身依赖的组件，如hdfs、kafka、opentsdb等直接采用prometheus exporter进行收集,组件内部维护了一组exporter 。


推荐阅读


上一篇：近期百度流量下降40%-80%,潜在可能因素有哪些?

下一篇：大红袍是什么,什么茶叶贵