每日优鲜早期只有交易平台存在一套内部的业务监控系统，没有推广到全公司级别。大数据团队与自己的业务监控，运维团队有自己的基础监控。除了交易系统其他业务线的业务监控几乎为零，很多时候都是用户告知我们出问题了，而不是我们主动发现出问题了，导致问题发现的时候已经过去很久了。
监控内容主要是涉及日志中出现的数据统计，所以对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接口，自动创建Dashboard，大致流程如下：
机器的核心指标（cpu、内存、磁盘、带宽），通过应用上报的指标信息中的host tag，生成promql，通过promql从运维的prometheus数据源中获取，自动添加到大盘监控中。
为了方便业务快速接入监控，我们除了对监控自动生成大盘之外，还做了其他的处理，监控系统接入全程自动化，自动化过程如下图所示：
最开始推监控的时候大家对埋点的认知还比较浅，所以主要是通过日志方式进行接入，对埋点存在抵触心理。
监控系统在一次分享大会上做过相关分享，主要分享通用的监控系统的架构是什么样，我们的Monitor监控实现是什么样，支持了哪些功能。
在分享会上再一次重点的宣讲了一下埋点的重要性，因为只有业务人员对自己所负责的业务最熟悉，所以为了方便第一时间发现问题，以及对自己的业务有全局的监控，那么就需要手动去埋点。以登陆功能为例，我们需要在登陆操作的每一步做埋点，我们需要知道登陆成功的pv，失败的pv，是什么原因失败，失败比例各占多少。
指标分组主要是为了方便大家快速定位自己的埋点位置，比如我们有一组与用户登陆相关的埋点数据，埋点指标名称统一为UserLogin_前缀，那么在上报之后我们会自动进行分组，将UserLogin_xxx分到同一组下。为了快速定位一组埋点，对Grafana前端进行大盘进行了拆解显示，可以通过下拉的方式选择自己的埋点指标组，然后会过滤掉无用的展示，只展示该指标组下的内容。
Grafana Git上很多人都对指标查询这个功能有需求，不过官方没有打算做，随着业务指标数量的递增，排查起来非常麻烦，为此，除了可以通过指标分组功能来实现过滤之外，还对指标搜索功能做了实现，可以通过搜索具体的指标来查看具体的单个指标。
不同时段的指标的数据、趋势是不同的，有些业务基本上晚上都没有什么量，为了使得告警更准确，实现了第一版的单时段告警，可以实现在指定时间段内才会对指标进行监控。
这种方式已经满足了大部分的场景，但是业务是多样性的，指标数据、趋势也存在多样性。因此实现了第二个版本，分时段、分策略告警。咋不同时间段可以配置不同的告警策略，从而使得告警更加准确，更加的人性化。
Grafana的指标图根据不同的数据类型，配置、查询方式等都不相同，Grafana的OpenTSDB数据源前端指标图默认无法将不同时间段的数据放在同一个指标图上，为了增加同环比的功能，对OpenTSDB的查询模块在前端做了扩展。做法如下：
Grafana官方的告警策略是不支持分布式的，因此扩展了其分布式告警的功能。
第一版分布式告警
在告警配置数量还在上百个、上千个的时候。在这个阶段，直接在数据库中加了一张锁表，用来处理分布式告警，发送告警前先获取锁，获取成功则继续发送，如果获取失败，取消告警的发送，即谁拿锁谁发送。同时引入了锁检查的任务。
第二版分布式告警
随着接入的应用和指标数达到了一定的量级，配置的告警策略也翻了好几倍，数据库实现的锁表出现一定的瓶颈。因此换了第二版本的实现，即对查询的告警策略数据进行拆分，每个节点跑一部分，实现分布式告警。
针对告警信息做了定制化，添加告警回执、告警处理等功能，实现告警跟踪、溯源。
告警回执
直接将出错内容通过告警发出来，业务方可以快速定位问题。默认取出现频率较高的top5异常。
异常推送
当前监控系统数据收集方面还是分钟级别，机器指标是十秒级别，无法发现峰值的qps，因为接下来的方向考虑加入秒级监控，实现分钟和秒级监控的灵活切换，需要的时候开通秒级监控，平时使用分钟级监控即可，当然，因为秒级监控很耗费性能，所以也可能单独的在谛听平台去做。
引入AI算法，对历史数据进行分析、趋势分析，实现告警的智能化，提前预知告警，防患于未然。
此外当前可观测技术已经越发趋于成熟，Metric、Logging、Tracing逐渐走向统一，三者可以相互跳转、帮助研发快速定位问题，也是我们值得思考的方向，当然我们现在也在逐步的将三者通过一些手段串联起来，加快问题的定位能力。
京公网安备 11010802035086号