我们从开始了解监控系统来说，首先我们要先了解监控的需求来源，即监控系统都可以用于做什么?

监控需求来源

其实最初的需求很简单，即"系统出问题了我们要能及时感知"。后面随着技术的不断发展，我们对监控系统提出了更多的诉求。

• 通过监控了解数据趋势，知道系统在未来的某个时刻可能出问题，预知问题。
• 通过监控了解系统的水位情况，为服务扩缩容提供数据支撑。
• 通过监控来给系统把脉，感知到哪里需要优化，比如一些中间件参数的调优。
• 通过监控来洞察业务，提供业务决策的数据依据，及时感知业务异常

目前监控系统越来越重要，同时也越来越完备。不但能够很好地解决上面这几点诉求，还沉淀出了很多监控系统中的稳定性相关的知识。

可观性的三大支柱

我们这里说的监控系统，其实只是指标监控，使用折线图形态呈现在图表上，比如某个机器的 CPU 利用率、某个数据库实例的流量等，都可以体现为随着时间而变化的趋势图。

指标监控智能处理数字，但它历史数据存储成本较低，实时性好，生态庞大，是可观测性领域里最重要的一根支柱。聚焦在指标监控领域的开源产品有zabbix、prometheus、夜莺等。

除了指标监控，另一个重要的可观察性支柱是日志。从日志中可以得到很多信息，对于了解软件的运行情况、业务的运营情况都很关键。比如操作系统的日志、接入层的日志、服务运行日志，都是重要的数据源。

从操作系统的日志中，可以得知很多系统级事件的发生；从接入层的日志中，可以得知有哪些域名、IP、URL 收到了访问，是否成功以及延迟情况等；从服务日志中可以查到 Exception 的信息，调用堆栈等，对于排查问题来说非常关键。但是日志数据通常量比较大，不够结构化，存储成本较高。处理日志这个场景，也有很多专门的系统，比如开源产品 ELK 和 Loki，商业产品 Splunk 和 Datadog。国内也有很多公有云服务在售。下面是在 Kibana 中查询日志的一个页面。

可观测性最后一大支柱是链路追踪。随着微服务的普及，原本的单体应用被拆分成很多个小的服务，服务之间有错综复杂的调用关系，一个问题具体是哪个模块导致的，排查起来其实非常困难

链路追踪的思路是以请求串联上下游模块，为每个请求生成一个随机字符串作为请求 ID。服务之间互相调用的时候，把这个 ID 逐层往下传递，每层分别耗费了多长时间，是否正常处理，都可以收集起来附到这个请求 ID 上。后面追查问题时，拿着请求 ID 就可以把串联的所有信息提取出来。链路追踪这个领域也有很多产品，比如 Skywalking、Jaeger、Zipkin、CAT 等. 下图为 Skywalking相关页面

业界开源方案对比

老一代整体方案代表 zabbix

Zabbix 是一个企业级的开源解决方案，擅长设备、网络、中间件的监控。

Zabbix 核心由两部分构成，Zabbix Server 与可选组件 Zabbix Agent。Zabbix Server 可以通过 SNMP、Zabbix Agent、JMX、IPMI 等多种方式采集数据，它可以运行在 Linux、Solaris、HP-UX、AIX、Free BSD、Open BSD、OS X 等平台上。拥有很好的兼容性。

Zabbix 还有一些配套组件，Zabbix Proxy、Zabbix Java Gateway、Zabbix Get、Zabbix WEB 等，共同组成了 Zabbix 整体架构

Zabbix 的优点：

• 对各种设备的兼容性较好，Agentd 不但可以在 Windows、Linux 上运行，也可以在 Aix 上运行。
• -架构简单，使用数据库做时序数据存储，易于维护，备份和转储都比较容易。社区庞大，资料多。
• Zabbix 大概是 2012 年开源的，发展的时间比较久，网上可以找到海量的资源。

Zabbix 的缺点

• 使用数据库做存储，无法水平扩展，容量有限。如果采集频率较高，比如 10 秒采集一次，上限大约可以监控 600 台设备，还需要把数据库部署在一个很高配的机器上，比如 SSD 或者 NVMe 的盘才可以。
• Zabbix 面向资产的管理逻辑，监控指标的数据结构较为固化，没有灵活的标签设计，面对云原生架构下动态多变的环境，显得力不从心。

新一代整体方案代表 Prometheus

Prometheus 的设计思路来自 Google 的 Borgmon，师出名门，就像 Borgmon 是为 Borg 而生的，而 Prometheus 就是为 Kubernetes 而生的。它针对 Kubernetes 做了直接的支持，提供了多种服务发现机制，大幅简化了 Kubernetes 的监控。

在 Kubernetes 环境下，Pod 创建和销毁非常频繁，监控指标生命周期大幅缩短，这导致类似 Zabbix 这种面向资产的监控系统力不从心，而且云原生环境下大都是微服务设计，服务数量变多，指标量也呈爆炸态势，这就对时序数据存储提出了非常高的要求。Prometheus 1.0 的版本设计较差，但从 2.0 开始，它重新设计了时序库，性能、可靠性都有大幅提升，另外社区涌现了越来越多的 Exporter 采集器，非常繁荣。

Prometheus 的优点

• 对 Kubernetes 支持得很好，目前来看，Prometheus 就是 Kubernetes 监控的标配。
• 生态庞大，有各种各样的 Exporter，支持各种各样的时序库作为后端的 Backend 存储，也有很好的支持多种不同语言的 SDK，供业务代码嵌入埋点

Prometheus 的缺点

• 使用有一定门槛，比如告警策略需要修改配置文件，协同起来比较麻烦。当然了，对于 IaC 落地较好的公司，反而认为这样更好，不过在国内当下的环境来看，还无法走得这么靠前，大家还是更喜欢用 Web 界面来查看监控数据、管理告警规则。
• Exporter 参差不齐，通常是一个监控目标一个 Exporter，管理成本比较高。
• 容量问题，Prometheus 默认只提供单机时序库，集群方案需要依赖其他的时序库。