谈服务可用性监控

系统监控

这个层次监控服务所在服务器的可用性。服务器的各项基本指标是否正常。包括服务器的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:

监控系统的衡量指标:

• 计算：对数据进行计算可以支持各种复杂的查询需求。
• 接口：既有精确的图表展示，又提供开放的接口查询。
• 告警：灵活的告警系统，可以消除不必要的噪音。

Original: https://www.cnblogs.com/yjf512/p/14182770.html
Author: 轩脉刃
Title: 谈服务可用性监控