,全文长度: 3000字
阅读时间: 10分钟
TL;DR(too long don't read)
想要做到统一监控,不外乎做到下面这么几件事情。阿里云有日志服务,开源有 ELK。
1. 全链路调用唯一ID
2. 标准化日志
3. 打点方案
4. 监控大盘
5. 告警方案
前言
上次写了一篇文章。对业务系统的监控 No.118 。讲的是我们在开发完成之后还需要做些什么事情,我们的系统有哪些方面是需要监控的,很多小伙伴对于怎么落地其实还有一定的疑惑,今天细细说一下。
比如我们对于我们开出去的接口,所依赖调用别人的二方三方服务,究竟是怎样的表现,如果没有监控告警体系,那我们基本就是乱猜。比如,没有客诉,那么大概系统运行得还不错吧。这太瞎扯了,作为一个合格的工程师不允许这种情况出现。
投入一定的资源进行监控告警的建设什么好处呢?最大的好处就是,我们知道究竟有多少个服务被依赖,依赖了多少三方服务,QPS 是多少,接口平均 RT 多长,成功率是多少,失败的各个错误码分布是怎样的,一旦超过阈值能否比较及时触达到开发、运营人员。
有了监控,我们随时都可以对我们的系统有一个比较全面的了解,以及有一个比较全面的把控。有了告警,遇到问题我们可以第一时间感知,也可以第一时间介入。这些事情我们需要去解,各个公司各个平台的技术实力和经济实力都不同,所以解决方案也差别比较大。这些可能都是我们开发人员需要花时间额外去做的,无论是一次性的营销方案,还是长期运行的系统,都需要准备监控告警方案。用钱换时间,以及用时间换钱,这就是我们需要权衡的东西。当然,准备方案基本都是一致的,在这里我先只聊接口层面的监控。其他的关于数据库、JVM、消息队列、分布式缓存、tomcat 线程、主机CPU磁盘网络等,均不在此次讨论范围,这些需要更高层面的聚合服务来实现监控,监控逻辑几乎都是一致的。
监控告警五部曲
想要做到统一监控,不外乎做到下面这么几件事情,但是每一件事都很难很重要。
1. 全链路调用唯一ID
2. 标准化日志
3. 打点方案
4. 监控大盘
5. 告警方案
1. 全链路调用唯一ID
2. 标准化日志
3. 打点方案
Graphite 就做了两件事,第一件事就是存储了时序数字类型的数据,第二件事就是把这些数据用图表的方式展示出来,至于安装和使用的过程比较复杂,请自行进行阅读。 https://www.infoq.cn/article/graphite-intro/ ELK(ElasticSearch + Logstach + Kibana) 这里的监控大盘主要使用了 Kibana 的自定义视图能力,要求就是数据必须写入到 ElasticSearch 里边。 高成本方案 阿里云 SLOG 日志服务 SLOG 是阿里云提供的一个日志服务,只要根据 key-value 的形式将数据写入到 SLOG 上,就可以自定义配置一些监控大盘,一定量以内是免费的。所以如果量不大,技术实力又不强,可以尝试一下这个方案。当然如果有一定的资金,SLOG 本身其实并不算太贵,而且可靠性和性能都非常强。除了官方提供的方式外,也可以对接到一个自定义的日志平台或者监控平台,通过 API 的形式进行监控数据查询,并进行展示。 高技术方案 Flink 实时计算 这里使用的主要 Flink 的基于窗口的聚合能力,能够将大批量的流式数据进行聚合,然后再将聚合的结果输出到某个库,提供一定的大盘能力,比如双十一的 GMV 计算大屏。优点就是可定制型非常非常强以及性能可以得到很好的调优和定制,缺点就是技术实力可能要求比较高,而且对每一个需要监控的点基本都需要进行代码开发。
5. 告警方案
总结