一篇文章教你选择合适的linux系统监控工具！

Posted 2021-08-13 测试员小静

前言

在业界有很多优秀的开源产品可供选择，能满足绝大部分的监控需求，如果能从中选择一款满足企业当下的诉求，显然最省时省力。当然，对于大公司来说开源的工具可能不适用，此时公司都会选择二次开发甚至自研。我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。(文末有学习笔记分享)

监控系统俗称“第三只眼”，几乎是我们每天都会打交道的系统，下面一些基础知识我认为是必须要了解的。
本文的内容并未涉及到全链路监控、日志监控、以及 Web 前端和客户端的监控，可见监控真的是一个庞大且复杂的体系，如果想理解透彻，必须理论结合实践再做深入。

1、监控系统的7大作用

正所谓“无监控，不运维”，监控系统的地位不言而喻，对于做性能测试的朋友而言亦是如此。不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么?它能发挥什么作用?

A、实时采集监控数据：包括硬件、操作系统、中间件、应用程序等各个维度的数据。

B、实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。

C、预知故障和告警：能够提前预知故障风险，并及时发出告警信息。

D、辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位。

E、辅助性能调优：为性能调优提供数据支持，比如慢 SQL，接口响应时间等。

F、辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑。

G、辅助自动化运维：为自动扩容或者根据配置的 SLA 进行服务降级等智能运维提供数据支撑。

2、如何使用监控系统

出任何线上事故，先不说其他地方有问题，监控部分一定是有问题的。听着很甩锅的一句话，仔细思考好像有一定道理。
我们在事故复盘时，通常会思考这三个和监控有关的问题：
有没有做监控?
监控是否及时?
监控信息是否有助于快速定位问题?
可见光有一套好的监控系统还不够，还必须知道如何用好它。一个成熟的研发团队通常会定一个监控规范，用来统一监控系统的使用方法。

A、了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对 JVM 进行监控，你必须清楚 JVM 的堆内存结构和垃圾回收机制。

B、确定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态?比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。

C、定义合理的报警阈值和等级：达到什么阈值需要告警?对应的故障等级是多少?不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。

D、建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和 oncall 机制，让故障及时被跟进处理。

3、监控的对象和指标都有哪些？

监控已然成为了整个产品生命周期非常重要的一环，运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。可见，监控的对象已经越来越立体化。
这里，我对常用的监控对象以及监控指标做了分类整理：

A、硬件监控
电源状态、CPU 状态、机器温度、风扇状态、物理磁盘、raid 状态、内存状态、网卡状态。

B、服务器基础监控
CPU：单个 CPU 以及整体的使用情况。
内存：已用内存、可用内存。
磁盘：磁盘使用率、磁盘读写的吞吐量。
网络：出口流量、入口流量、TCP 连接状态。

C、数据库监控
数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询。

D、中间件监控
nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX 错误率。
Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC 次数和耗时。
缓存：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率。
消息队列：连接数、队列数、生产速率、消费速率、消息堆积量。

E、应用监控
HTTP 接口：URL 存活、请求量、耗时、异常量。
RPC 接口：请求量、耗时、超时量、拒绝量。
JVM：GC 次数、GC 耗时、各个内存区域的大小、当前线程数、死锁线程数。
线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数。
连接池：总连接数、活跃连接数。
日志监控：访问日志、错误日志。
业务指标：视业务来定，比如 PV、订单量等。

4、监控系统的基本流程

无论是开源的监控系统还是自研的监控系统，监控的整个流程大同小异。

一般都包括以下模块：

A、数据采集：采集的方式有很多种，包括日志埋点进行采集(通过 Logstash、Filebeat 等进行上报和解析)，JMX 标准接口输出监控指标，被监控对象提供 REST API 进行数据采集(如 Hadoop、ES)，系统命令行，统一的 SDK 进行侵入式的埋点和上报等。

B、数据传输：将采集的数据以 TCP、UDP 或者 HTTP 协议的形式上报给监控系统，有主动 Push 模式，也有被动 Pull 模式。

C、数据存储：有使用 mysql、Oracle 等 RDBMS 存储的，也有使用时序数据库 RRDTool、OpentTSDB、InfluxDB 存储的，还有使用 HBase 存储的。

D、数据展示：数据指标的图形化展示。

E、监控告警：灵活的告警设置，以及支持邮件、短信、IM 等多种通知通道。

5、主流监控系统介绍

下面再来认识下主流的开源监控系统，由于篇幅有限，我挑选了 3 款使用最广泛的监控系统：Zabbix、Open-Falcon、Prometheus，会对它们的架构进行介绍，同时总结下各自的优劣势。

A、Zabbix

Zabbix 于 1998 年诞生，核心组件采用 C 语言开发，Web 端采用 php 开发。

它属于老牌监控系统中的优秀代表，监控功能很全面，使用也很广泛，差不多有 70% 左右的互联网公司都曾使用过 Zabbix 作为监控解决方案。

Zabbix 的架构设计如下：

Zabbix 架构图详解：

Zabbix 的优势：

Zabbix 的劣势：

B、Open-Falcon

Open-falcon 是小米 2015 年开源的企业级监控工具，采用 Go 和 Python 语言开发，这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过 200 家公司在使用它。

小米初期也使用的 Zabbix 进行监控，但是机器量和业务量上来后，Zabbix 就有些力不从心了。

因此，后来自主研发了 Open-Falcon，在架构设计上吸取了 Zabbix 的经验，同时很好地解决了 Zabbix 的诸多痛点。

Open-Falcon 的架构设计如下：

Open-Falcon 架构图详解：

Open-Falcon 的优势：

Open-Falcon 的劣势：

C、Prometheus

Prometheus(普罗米修斯)是由前 Google 员工 2015 年正式发布的开源监控系统，采用 Go 语言开发。

它不仅有一个很酷的名字，同时它有 Google 与 K8s 的强力支持，开源社区异常火爆。

Prometheus 于 2016 年加入云原生基金会，是继 K8s 后托管的第二个项目，未来前景被相当看好。

它和 Open-Falcon 最大不同在于：数据采集是基于 Pull 模式的，而不是 Push 模式，并且架构非常简单。

Prometheus 的架构设计如下：

Prometheus 架构图详解：

Prometheus 的优势：

Prometheus 的劣势：

6、监控系统的选型建议

通过上面的介绍，大家对主流的监控系统应该有了一定的认识。

面对选型问题，我的建议是：

最后，为方便大家自学软件测试，特意给大家准备了一份13G的超实用干货学习资源，涉及的内容非常全面。

包括软件学习路线图，50多天的上课视频、16个突击实战项目，80余个软件测试用软件，37份测试文档，70个软件测试相关问题，40篇测试经验级文章，上千份测试真题分享,还有2021软件测试面试宝典，还有软件测试求职的各类精选简历，希望对大家有所帮助…..

关注我的微信公众号：【程序员小濠】就可以免费获取了~

我的软件测试交流群：175317069欢迎大家一起讨论交流，里面也有各种软件测试资料和技术交流

如果对你有帮助的话，点个赞收个藏，给作者一个鼓励。也方便你下次能够快速查找。