谈服务可用性监控

jianfengye110 · · 287 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

# 谈服务可用性监控 一个服务的监控从整体考虑,要达到哪些才能算是完善的?我想,如果没有一个全局性的监控思考,一个服务的监控即使加的再多也是会有监控盲区的。 # 监控的层次 从基础机器到上层业务,分为三个不同层次:系统,应用,业务。不同的层次都应该有其不同的监控目的。 ## 系统监控 这个层次监控服务所在服务器的可用性。服务器的各项基本指标是否正常。包括服务器的CPU,服务器的磁盘,服务器的内存等。 有的服务器会进行服务混布,这种监控更为重要。因为其他服务导致的服务器问题只能通过系统监控层面得到反馈。 操作系统层面的监控也是最为基础的了。如果我们购买云服务器,阿里云或者腾讯云上都会有对应的监控设置,但如果是自有的虚拟化集群,集群管理也有对应的开源实现,比如 prometheus + node_exporter 的形式。 这类监控报警通常关注的就是机器CPU负载,空闲内存,网络带宽,磁盘空间等。 ## 应用监控 这个层次监控当前服务进程的可用性。分析当前服务进程与业务无关的各项指标。把一个应用(进程)当作是黑盒,不管其中的业务逻辑正确与否,只观察这个应用的健康状态。大致应用状态包含: * 进程数 * CPU占用 * 内存占用 * Coredump情况 * fd打开数 对于这个级别的监控,prometheus 也有一个 process_exporter 是专门做这个事情的。 在应用监控的时候,对于 Golang 项目,需要监控进程的runtime信息。 这个runtime信息包括: * gorutine个数 * gc暂停时间 * gc次数 * 内存分配 Go 的 runtime 的基本监控方法都是在 Golang 的进程中插入一个包,这个包负责监控 runtime, 并且打点到 metric 系统。 prometheus 也提供了这样一个库: github.com/prometheus/client_golang 能打出这样一些关于runtime的数据: ``` go_gc_duration_seconds{quantile="0"} 0 go_gc_duration_seconds{quantile="0.25"} 0 go_gc_duration_seconds{quantile="0.5"} 0 go_gc_duration_seconds{quantile="0.75"} 0 go_gc_duration_seconds{quantile="1"} 0 go_gc_duration_seconds_sum 0 go_gc_duration_seconds_count 0 # HELP go_goroutines Number of goroutines that currently exist. # TYPE go_goroutines gauge go_goroutines 8 # HELP go_info Information about the Go environment. # TYPE go_info gauge go_info{version="go1.14.2"} 1 # HELP go_memstats_alloc_bytes Number of bytes allocated and still in use. # TYPE go_memstats_alloc_bytes gauge go_memstats_alloc_bytes 2.563056e+06 ``` # 业务监控 这个层次监控具体的业务了。这个层次的监控关注的是业务是否可用,业务是否有走入异常分支,业务哪些服务是比较慢的。 关于业务监控,个人的感觉是尽量不要使用metric监控,因为业务的问题一旦报警,排查是需要分析的,这个时候如果仅仅是告诉开发有异常了,但是没有对应的日志,或者查找日志需要去线上机器一个个捞,是一件很痛苦的事情。 所以业务监控的实现方式,基本上都是落盘日志 + 日志文件采集 + 结构化处理 + 分布式日志存储 + 分析报警。 标准的 ELK 三件套非常适合进行实操部署这套。 业务监控应该从三个方面进行报警: ## 性能监控 监控每个业务请求的性能指标,可以对具体的业务请求的性能进行完整的展示。 我们应该对整体请求的请求时长,所有网络调用的请求时长,所有数据操作的网络时长,以及关键函数的请求时长都有记录。最后在具体分析的时候就能有所抓手。 ## 链路监控 监控每个业务请求的完成链路,这个包括对上游和下游的链路日志,也包括在当前业务中各个模块的日志记录。 对于微服务架构,链路监控是非常重要的。服务与服务间的链路需要通过一个 trace 进行串联。 关于链路监控,已经有很多开源成熟方案可以部署,大都都是基于 Dapper 理论进行实现的。 ## 错误监控 业务中不仅仅只有正常流程的逻辑,也有很多各种各样的错误分支逻辑。对于这些务请求中非正常的错误信息。往往是很有用的。特别是能弥补测试人员没有测试到的一些分支异常。 错误信息必须要保留的应该有错误请求体、错误堆栈、错误触发条件等信息。 # 监控的数据源 关于监控的数据源,无非就分为两类:日志 和 metric(统计) 日志数据源比metric数据源的优势是能有更强大的数据结构,可以进行更为复杂的日志搜索,可以存储更多的信息。缺点则是存储量比metric数据大很多,在大流量业务场景下,很难做到全量采集。很经常采用的是抽样采集记录。这里面就有一个抽样采集策略。 另一方面 metric 数据源理论上比日志数据源有更强的实时性。也可以通过各种环比来得出趋势的变化。 日志又分为几个类型的日志 * 错误日志:记录错误信息 * 运行日志:记录内部运行和数据流转的各种日志记录 * 访问日志:记录请求进出服务的访问入口日志 # 如何衡量监控系统的完整性? 摘抄自 Google SRE: 监控系统的衡量指标: * 速度:需要保证数据的新鲜度和数据获取速度。需要很快获取到最新的数据指标。 * 计算:对数据进行计算可以支持各种复杂的查询需求。 * 接口:既有精确的图表展示,又提供开放的接口查询。 * 告警:灵活的告警系统,可以消除不必要的噪音。 # 总结 感觉基本每个公司差不多都是这些思路,只是在每个具体实现上,可能会针对不同的业务进行不同的定制化。 基本上从不同层面,不同数据源,对某个服务搭建起来完整的监控链路,这个服务的可用性就能得到很好的保证了。

有疑问加站长微信联系(非本文作者))

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

287 次点击  
加入收藏 微博
1 回复  |  直到 2020-12-30 14:09:01
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传