目录
前言
一、Google的四类黄金指标
二、RED方法
三、USE方法
RED方法 vs USE方法
四、监控指标
WEB服务监控
MySQL数据库监控
QPS
TPS
最大连接数
缓存监控
总结
众所周知,业界各种大中型软件系统在生产运行时,总会有一些手段来进行保驾护航。Metric 机制作为一个非常重要的监控手段,与日志系统,告警系统,APM 等,共同守护业务系统运行安全。没有“运行时监控机制”的软件系统都是不合格的系统,是根本没有资格上到生产环境上去的,因为掌握不了软件系统的运行状况,就像一个瞎子开着汽车上路了,是极其危险的。Metric 机制承担着收集软件系统各种监控指标的职责,提供的各个监控指标能够帮助运维人员进行系统运行状态的研判,配合告警系统及时进行预警,在出现异常情况的时候,给日志分析团队指明“问题查找”的方向。总之,Metric 的重要程度非常高,可以认为是不可或缺的非功能性需求。
Four Golden Signals是Google针对分布式监控进行的经验总结,将需要重点关注的监控数据分为四类:
这四类指标是Google SRE的经验积累,所观测的指标对于系统的可靠性非常重要,是监控系统创建时的有益参考。
RED是Weave Cloud所提供的方法,这种方法完全以Google的4类黄金指标为基础,以应用请求相关的R(Rate:请求速率)、E(Error:请求错误)和D(Duration:请求耗时)三种关键指标为中心所创建监控体系的方法,被成为RED方法,对于云原生应用或者为微服务架构下的应用有很好地借鉴作用。
RED方法定义了微服务架构中所需要定义的三种指标:
USE方法的全称是Utilization Saturation and Errors Method,相较于RED方法,USE方法从资源使用率(Utilization)、资源饱和度(Saturation)和错误等指标纬度进行监控和分析,在帮助用户进行系统性能分析、资源瓶颈识别等方面有较好的效果。具体指标说明如下所示:
可以看到使用RED方法或者USE方法都可以对服务进行监控,具体选择可根据如下特点进行:
除了在生产和测试环境中被动的等待和确认系统状况,还可以通过更为主动的方式进行持续的学习从而构建更加可靠的系统,而这些离不开一些主动的辅助手段,比如:
一些组件或者服务还有独特的指标,这些指标也是需要你特殊关注的。比如,数据库主从延迟数据、消息队列的堆积情况、缓存的命中率等等。
组件 | 延迟 | 通信量 | 错误 | 饱和度 | 其他 |
---|---|---|---|---|---|
WEB服务 | 响应时间 | 请求量 | 4** 5**请求量 业务错误 |
tomcat线程池的 任务堆积数, 活跃线程数 |
|
MySQL数据库 | 响应时间 慢SQL |
每秒执行操作数 QPS |
请求超时 错误数量 |
连接数 | 主从延迟 CPU 内存 |
缓存 | 响应时间 慢请求 |
请求量 OPS每秒操作数 |
请求超时 错误数量 |
连接数 | BigKey, 命中率 缓存已用容量 |
消息队列 | 响应时间 | 请求量 | 请求超时 错误数量 |
消息堆积 | |
JVM | GC时间 | GC频率 | 内存区域大小 | ||
依赖的服务 | 响应时间 | 请求量 | 请求超时 错误数量 |
说到监控指标的采集,我们一般会依据采集数据源的不同,选用不同的采集方式,总结起来,大概有以下几种类型:
首先,Agent 是一种比较常见的,采集数据指标的方式。
我们通过在数据源的服务器上,部署自研或者开源的 Agent,来收集数据,发送给监控系统,实现数据的采集。在采集数据源上的信息时,Agent 会依据数据源上,提供的一些接口获取数据,我给你举两个典型的例子。
比如,你要从 Redis 服务器上,获取它的性能数据,那么,你就可以在 Agent 中,连接这个 Redis 服务器,并且发送一个 stats 命令,获取服务器的统计信息。然后,你就可以从返回的信息中,挑选重要的监控指标,发送给监控服务器,形成Redis 服务的监控报表。你也可以从这些统计信息中,看出当前 Redis 服务器,是否存在潜在的问题。
连续统计可能是实时监控 Redis 实例的鲜为人知但非常有用的功能之一,要启用此功能,请使用redis-cli --stat。
redis-cli --stat 默认每秒输出一条新行,其中包含有用信息和每个采集点的请求次数差异。使用此命令可以轻松了解内存使用情况、客户端连接计数以及有关已连接 Redis 数据库的各种其他统计信息。
可以使用-i修改采样频率,默认值为1秒,如下面这个命令代表每2s采集一次数据:
yangyanpingdeMacBook-Air:bin yangyanping$ redis-cli --stat -i 2
------- data ------ --------------------- load -------------------- - child -
keys mem clients blocked requests connections
1 1.02M 1 0 1 (+0) 4
1 1.02M 1 0 2 (+1) 4
1 1.02M 1 0 3 (+1) 4
1 1.02M 1 0 4 (+1) 4
1 1.02M 1 0 5 (+1) 4
1 1.02M 1 0 6 (+1) 4
1 1.02M 1 0 7 (+1) 4
1 1.02M 1 0 8 (+1) 4
1 1.02M 1 0 9 (+1) 4
1 1.02M 1 0 10 (+1) 4
1 1.02M 1 0 11 (+1) 4
1 1.02M 1 0 12 (+1) 4
^C
yangyanpingdeMacBook-Air:bin yangyanping$
这个命令用作键空间分析器,它扫描数据集中的大键,但也提供有关数据集所包含的数据类型的信息。
yangyanpingdeMacBook-Air:bin yangyanping$ redis-cli --bigkeys
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest string found so far '"test"' with 4 bytes
-------- summary -------
Sampled 1 keys in the keyspace!
Total key length in bytes is 4 (avg len 4.00)
Biggest string found '"test"' has 4 bytes
1 strings with 4 bytes (100.00% of keys, avg size 4.00)
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
yangyanpingdeMacBook-Air:bin yangyanping$
在采集到监控数据之后,你就可以对它们进行处理和存储了,在此之前,我们一般会先用消息队列来承接数据,主要的作用是削峰填谷,防止写入过多的监控数据,让监控服务产生影响。
与此同时,我们一般会部署两个队列处理程序,来消费消息队列中的数据。一个处理程序接收到数据后,把数据写入到 Elasticsearch,然后通过 Kibana 展示数据,这份数据主要是用来做原始数据的查询;另一个处理程序是一些流式处理的中间件,比如,Spark、Storm。它们从消息队列里,接收数据后会做一些处理,这些处理包括:
- 解析数据格式,尤其是日志格式。从里面提取诸如请求量、响应时间、请求 URL 等数据;
- 对数据做一些聚合运算。 比如,针对 Tomcat 访问日志,可以计算同一个 URL 一段时间之内的请求量、响应时间分位值、非 200 请求量的大小等等。
- 将数据存储在时间序列数据库中。这类数据库的特点是,可以对带有时间标签的数据,做更有效的存储,而我们的监控数据恰恰带有时间标签,并且按照时间递增,非常适合存储在时间序列数据库中。目前业界比较常用的时序数据库有 InfluxDB、OpenTSDB、Graphite,各大厂的选择均有不同,你可以选择一种熟悉的来使用。
- 最后, 你就可以通过 Grafana 来连接时序数据库,将监控数据绘制成报表,呈现给开发和运维的同学了。
至此,你和你的团队,也就完成了垂直电商系统,服务端监控系统搭建的全过程。这里我想再多说一点,我们从不同的数据源中采集了很多的指标,最终在监控系统中一般会形成以下几个报表,你在实际的工作中可以参考借鉴:
1. 访问趋势报表。这类报表接入的是 Web 服务器,和应用服务器的访问日志,展示了服务整体的访问量、响应时间情况、错误数量、带宽等信息。它主要反映的是,服务的整体运行情况,帮助你来发现问题。
2. 性能报表。 这类报表对接的是资源和依赖服务的埋点数据,展示了被埋点资源的访问量和响应时间情况。它反映了资源的整体运行情况,当你从访问趋势报表发现问题后,可以先从性能报表中,找到究竟是哪一个资源或者服务出现了问题。
3. 资源报表。 这类报表主要对接的是,使用 Agent 采集的,资源的运行情况数据。当你从性能报表中,发现某一个资源出现了问题,那么就可以进一步从这个报表中,发现资源究竟出现了什么问题,是连接数异常增高,还是缓存命中率下降。这样可以进一步帮你分析问题的根源,找到解决问题的方案