架构设计|给系统加上眼睛(服务端监控要怎么做())
给系统加上眼睛:服务端监控要怎么做?
- 监控指标如何选择
- 如何采集数据指标
- 监控数据的处理和存储
- 总结
在一个项目的生命周期里,运行维护占据着很大的比重,在重要性上,它几乎与项目研发并 驾齐驱。而在系统运维过程中,能够及时地发现问题并解决问题,是每一个团队的本职工 作。所以,我们的系统在搭建之初,运维团队肯定完成了对于机器 CPU、内存、磁 盘、网络等基础监控,期望能在出现问题时,及时地发现并且处理。本以为万事大吉,却没想到系统在运行过程中,频频得到用户的投诉,原因是:
- 使用的数据库主从延迟变长,导致业务功能上出现了问题;
- 接口的响应时间变长,用户反馈核心页面出现空白页;
- 系统中出现大量错误,影响了用户的正常使用;
- 首先,监控的指标要如何选择呢?
- 采集这些指标可以有哪些方法和途径呢?
- 指标采集到之后又要如何处理和展示呢?
监控指标如何选择 我们在搭建监控系统时,所面临的第一个问题就是,选择什么样的监控指标,也就是监控什么。有些同学在给一个新的系统,设定监控指标的时候,会比较迷茫,不知道从哪方面入手。其实,有一些成熟的理论和套路,可以直接拿来使用。比如,谷歌针对分布式系统监 控的经验总结,四个黄金信号(Four Golden Signals)。它指的是,在服务层面一般需要监控四个指标,分别是延迟,通信量、错误和饱和度。
- 延迟指的是请求的响应时间。比如,接口的响应时间、访问数据库和缓存的响应时间。
- 通信量可以理解为吞吐量,也就是单位时间内,请求量的大小。比如,访问第三方服务的请求量,访问消息队列的请求量。
- 错误表示当前系统发生的错误数量。这里需要注意的是, 我们需要监控的错误既有显示的,比如在监控 Web 服务时,出现 4 * * 和 5 * * 的响应码; 也有隐示的,比如,Web 服务虽然返回的响应码是 200,但是却发生了一些和业务相关的错误(出现了数组越界 的异常或者空指针异常等),这些都是错误的范畴。
- 饱和度指的是服务或者资源到达上限的程度(也可以说是服务或者资源的利用率),比 如说 CPU 的使用率,内存使用率,磁盘使用率,缓存数据库的连接数等等。
当然,一些组件或者服务还有独特的指标,这些指标也是需要你特殊关注的。比如,的数据库主从延迟数据、消息队列的堆积情况、缓存的命中率等等。我们高并发系统中常见组件的监控指标,整理成了一张表格,其中没有包含诸如 CPU、内存、网络、磁盘等基础监控指标,只是业务上监控指标,主要方便你在实际工作中参考使用。
![架构设计|给系统加上眼睛(服务端监控要怎么做())](https://img.it610.com/image/info8/bd0d469a1f7b4d85abe1be2d45ad9964.jpg)
文章图片
选择好了监控指标之后,接下来要考虑的,是如何从组件或者服务中,采集到这些指标,也就是指标数据采集的问题。
如何采集数据指标 说到监控指标的采集,我们一般会依据采集数据源的不同,选用不同的采集方式,总结起来,大概有以下几种类型:
- 首先,Agent 是一种比较常见的,采集数据指标的方式。
我们通过在数据源的服务器上,部署自研或者开源的 Agent,来收集收据,发送给监控系统,实现数据的采集。在采集数据源上的信息时,Agent 会依据数据源上,提供的一些接口获取数据。
- 另一种很重要的数据获取方式,是在代码中埋点
这个方式与 Agent 的不同之处在于,Agent 主要收集的是组件服务端的信息,而埋点则是 从客户端的角度,来描述所使用的组件,和服务的性能和可用性。
- 最后,日志也是你监控数据的重要来源之一
你所熟知的 Nginx 的访问日志和应用程序的log,都是重要的监控日志。可以通过开源的日志采集工具,将这些日志中的数据发送给监控服务器。目前,常用的日志采集工具有很多,比 如,Apache Flume、Fluentd和Filebeat,可以选择一种熟悉的使用。比如在我的项目中,我会倾向于使用 Filebeat 来收集监控日志数据。
与此同时,我们一般会部署两个队列处理程序,来消费消息队列中的数据。
一个处理程序接收到数据后,把数据写入到 Elasticsearch,然后通过 Kibana 展示数据, 这份数据主要是用来做原始数据的查询;
- 另一个处理程序是一些流式处理的中间件,比如,Spark、Storm。它们从消息队列里,接 收数据后会做一些处理,这些处理包括;
-
- 解析数据格式,尤其是日志格式。从里面提取诸如请求量、响应时间、请求 URL 等数据;
-
- 对数据做一些聚合运算。 比如,针对 Nginx 访问日志,可以计算同一个 URL 一段时间之内的请求量、响应时间分位值、非 200 请求量的大小等等。
-
- 将数据存储在时间序列数据库中。这类数据库的特点是,可以对带有时间标签的数据,做 更有效的存储,而我们的监控数据恰恰带有时间标签,并且按照时间递增,非常适合存储在 时间序列数据库中。目前业界比较常用的时序数据库有 InfluxDB、OpenTSDB、Graphite,选择的方式有多种,可以选择一种熟悉的来使用。
-
- 最后, 就可以通过 Grafana 来连接时序数据库,将监控数据绘制成报表,呈现给开发和运维的同学了。
![架构设计|给系统加上眼睛(服务端监控要怎么做())](https://img.it610.com/image/info8/5788bf6287614d47b6d702be389281d7.jpg)
文章图片
【架构设计|给系统加上眼睛(服务端监控要怎么做())】至此,我们也完成了我们系统的服务端监控系统搭建的全过程。这里再多说一点,我们从不同的数据源中采集了很多的指标,最终在监控系统中一般会形成以下几个报表,我们实际的工作中可以参考借鉴:
- 访问趋势报表。这类报表接入的是 Web 服务器,和应用服务器的访问日志,展示了服务整体的访问量、响应时间情况、错误数量、带宽等信息。它主要反映的是,服务的整体运行情况,帮助我们来发现问题。
- . 性能报表。 这类报表对接的是资源和依赖服务的埋点数据,展示了被埋点资源的访问量和响应时间情况。它反映了资源的整体运行情况,当我们从访问趋势报表发现问题后,可以先从性能报表中,找到究竟是哪一个资源或者服务出现了问题。
- . 资源报表。 这类报表主要对接的是,使用 Agent 采集的,资源的运行情况数据。当我们从性能报表中,发现某一个资源出现了问题,那么就可以进一步从这个报表中,发现资源究竟出现了什么问题,是连接数异常增高,还是缓存命中率下降。这样可以进一步帮助我们分析问题 的根源,找到解决问题的方案。
- 耗时、请求量和错误数是三种最通用的监控指标,不同的组件还有一些特殊的监控指 标,在搭建自己的监控系统的时候可以直接使用;
- Agent、埋点和日志是三种最常见的数据采集方式;
- 访问趋势报表用来展示服务的整体运行情况,性能报表用来分析资源或者依赖的服务是 否出现问题,资源报表用来追查资源问题的根本原因。这三个报表共同构成了我们的服务端监控体系。
推荐阅读
- PMSJ寻平面设计师之现代(Hyundai)
- 喂,你结婚我给你随了个红包
- 成交的种子咖啡冥想
- 一百二十三夜,请嫁给我
- 基于微信小程序带后端ssm接口小区物业管理平台设计
- 每日一话(49)——一位清华教授在朋友圈给大学生的9条建议
- 爱琐搭配(喜欢复古、冷淡,像这种双环设计的气质耳环)
- 历史教学书籍
- 写给陈羡
- 给予孩子心理平衡的机会