每日优鲜监控系统.docxVIP

每日优鲜监控系统 2021-02-03 每日优鲜监控系统晚期情况 系统掩盖不全 每日优鲜晚期只要买卖平台存在一套内部的业务监控系统，没有推广到全公司级别。大数据团队与本人的业务监控，运维团队有本人的基础监控。除了买卖系统其他业务线的业务监控几乎为零，很多时候都是用户告知我们出问题了，而不是我们自动发觉出问题了，导致问题发觉的时候已经过去很久了。 监控类型不完善 监控内容次要是涉及日志中消灭的数据统计，所以对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。 监控图像自动生成 为了监控接入的便捷性，我们实现了监控大盘的自动生成，依据monitor内置的相关埋点进行默认的监控数据上报，如JVM、Dubbo、Http等。通过这些上报数据拼接JSON，同时调用Grafana的创建Dashboard的API接口，自动创建Dashbo