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

43次阅读

共计 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 秒),采集到数据之后,发给服务端存储和剖析展现。

故而,指标监控的几个特点:

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

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

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

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

  • 作者:龙渊秦五,网络 ID:UlricQin,个人主页:https://ulricqin.github.io
  • 夜莺:一款云原生监控零碎,国产开源,附属中国计算机学会开源倒退委员会,我的项目主站:https://n9e.github.io/

本文由 mdnice 多平台公布

正文完
 0