关于后端:连载说透运维监控系统01监控系统概述

4次阅读

共计 2682 个字符，预计需要花费 7 分钟才能阅读完成。

这套连载课程，纵观整个行业的解决方案，做出横评比照，而后以夜莺监控零碎为底本，介绍一个监控零碎的方方面面。学习完本教材，会对监控零碎有个十分全面的认知。适宜人群：DevOps 工程师、SRE、研发工程师。作者有 10 余年 DevOps 研发教训，8 年监控零碎开发教训，所以本课程不止解说操作，还会解说很多原理。

监控零碎到底是解决什么问题的？大家通常所谓的监控零碎，其实只是可观测性三大支柱之一，何为可观测性三大支柱？作为支柱之一的指标监控零碎，具体有哪些特点？本章重点来答复这些问题。

最初始的需要，其实只有一句话，就是零碎出问题了咱们能及时感知。当然，随时的时代的倒退，咱们对监控零碎提出了更多的诉求，比方：

通过监控理解到趋势，晓得零碎在将来的某个时刻可能出问题
通过监控理解零碎的水位状况，能够在资源有余的时候及时扩容
通过监控来把脉零碎，感知到哪里须要优化，比方一些中间件的参数的调优
通过监控来洞察业务，晓得业务倒退的状况，业务异样了也能及时感知

监控零碎的重要性越来越高，岂但能够解决下面这些诉求，还能积淀常识，积淀在监控零碎中的稳定性相干的常识，可能要比很多工程师的大脑更为丰盛。当然，这得益于对监控体系的继续经营，特地是一些资深工程师的继续经营成绩。

咱们通常所谓的监控零碎，其实只是指标监控，体现在图表上的一条折线图，比方某个机器的 CPU 利用率，或者某个数据库实例的流量，或者网站的在线人数，都体现为随着工夫变动的一条线，比方：

指标监控只能解决数字，历史数据存储老本较低，实时性好，生态宏大，是可观测性畛域里最重要的一根支柱。有很多零碎都是只解决指标数据，比方 Zabbix、Open-Falcon、Prometheus、Nightingale 这些零碎在业内有很宽泛的利用。

除了指标监控，另一个重要的可观测性支柱，是日志。从日志中也能够失去很多信息，对于理解软件的运行状况、业务的经营状况，都很要害。比方操作系统的日志、接入层的日志、服务日志，都是重要的数据源，从操作系统的日志中，能够得悉很多零碎级的事件产生了，从接入层的日志中，能够得悉有哪些域名、IP、URL 收到了拜访，是否胜利以及提早状况等，从服务日志中能够查问到 Exception 的信息，调用堆栈等，对于排查问题，十分要害。

解决日志这个场景，也有很多专门的零碎，开源产品首推 ELK，商业产品比方 Splunk、Datadog 等，上面是 ELK 中查问日志的一张截图：

理解了指标和日志，可观测三大支柱还有一环，即：链路追踪。随着微服务的遍及，本来的单体利用被拆分成很多个小的服务，服务之间有盘根错节的调用关系，一个问题，是因哪个模块导致的，排查起来并不容易。

链路追踪的思路是，以申请串联上下游模块，为每个申请生成一个随机字符串作为申请 ID，服务之间调用的时候把这个 ID 逐层往下传递，各层别离破费了多久工夫，是否失常解决，都能够收集起来附到这个申请 ID 上，前面追究问题时，拿着申请 ID 就能够把串联的所有信息提取进去。链路追踪这个畛域也有很多产品，比方 Skywalking、Jaeger、Zipkin 等，都是个中翘楚。上面是 Zipkin 的一张截图：

尽管咱们把可观测性畛域划分了 3 大支柱，实际上他们之间是有很强的关联关系的。比方咱们常常会从日志中提取指标，转存到指标监控零碎，或者从日志中提取链路信息来做剖析，这在业界都有诸多实际。

咱们重点探讨的是指标监控，不探讨日志和链路追踪，要理解指标监控，首先要理解何为指标，说白了，指标就是掂量指标的数值。比方 Linux 操作系统，咱们能够从多个方面去掂量它的负载状况，比方 CPU 的使用率方面有 cpu_usage_system（CPU 内核态工夫占比）、cpu_usage_user（CPU 用户态工夫占比）、cpu_usage_idle（CPU 闲暇工夫占比）等指标，内存方面则有 mem_available_percent（内存可用率）、mem_used（内存使用量）等指标，磁盘方面则有 disk_used_percent（磁盘使用率）、diskio_write_bytes（磁盘写入量）等指标。

个别，会在 OS 内装置一个客户端软件，作为一个常驻过程运行，依照一个固定的频率来采集（比方 15 秒），采集到数据之后，发给服务端存储和剖析展现。

故而，指标监控的几个特点：

个别只解决数值数据，不解决字符串（个别监控零碎也能够解决字符串，大部分都不解决）
指标数据是时序数据，每隔一个固定的距离就采集一次，把采集到的数据上报，永不停歇
指标数据是采样数据，比方 15 秒采集一次，只能拿到采集的那一时刻的数据，如果把采集频率调小，能够获取更丰盛的更准确的数据，然而代价会更大，须要更多存储，更多算力来解决，理论生产环境，30 秒或者 60 秒就够了，如果对精度要求高，15 秒就够了，再小的频率，意义不大，因为监控数据的外围是感知异样和感知趋势，如果出现异常，个别异样会继续一段时间，偶然的异样通常也不须要关注，所以采样数据通常也能够感知到异样，而对于趋势，如果查看的工夫越大，采集频率能够越大，如果看 1 小时的数据，15 秒一个点是能够的，如果看 1 年的数据，每小时一个点的频率也齐全够用，太多的数据点，可能会把浏览器打爆
因为是解决的时序数据，每个值都带有一个工夫戳，这种数据很有法则，行业内呈现了专一于这类数据处理的数据库，称为时序数据库，比方 InfluxDB、VictoriaMetrics、M3DB 等，监控零碎依赖一个时序数据库，也就变成了一个典型的架构特点

架构上来说，指标监控零碎除了依赖一个时序库，还必然须要一个采集器去采集各种指标数据，其次就是告警引擎和可视化展现，典型的零碎架构如下：

Collector 示意采集器，专门做采集器的开源我的项目也有很多，比方 Telegraf、Grafana-Agent、Datadog-Agent、Categraf，以及，Prometheus 生态的各种 Exporter。橙色局部是监控的服务端，通常包含 UI 展现能力和服务端告警引擎。最初，依赖一个时序数据库：Time Series Database。

本章就介绍到这里，前面的内容会在上面的号里继续更新，欢送大家继续关注。