运维监控系统实战笔记(day1)

第一次课

监控需求直接的是为了出现问题时能及时感知到。新的需求：

通过监控了解数据趋势，知道系统在未来的某个时刻可能出问题，预知问题。

通过监控了解系统的水位情况，为服务扩缩容提供数据支撑。

通过监控来给系统把脉，感知到哪里需要优化，比如一些中间件参数的调优。

通过监控来洞察业务，提供业务决策的数据依据，及时感知业务异常。

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

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

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

处理日志这个场景，也有很多专门的系统，比如开源产品 ELK 和 Loki，商业产品 Splunk 和 Datadog，等

可观测性最后一大支柱是链路追踪。这是随着微服务应用的兴起来产生的，链路追踪这个领域也有很多产品，比如 Skywalking、Jaeger、Zipkin  等，都是个中翘楚。

老一代整体方案的代表 Zabbix：Zabbix 是一个企业级的开源解决方案，擅长设备、网络、中间件的监控。因为前几年使用的监控系统主要就是用来监控设备和中间件的，所以 Zabbix 在国内应用非常广泛。

Zabbix 的优点：

（1）对各种设备的兼容性较好，Agentd 不但可以在 Windows、Linux 上运行，也可以在 Aix 上运行。

（2）架构简单，使用数据库做时序数据存储，易于维护，备份和转储都比较容易。

（3）社区庞大，资料多。Zabbix 大概是 2012 年开源的，因为发展的时间比较久，在网上可以找到海量的资源。

Zabbix 的缺点：

（1）使用数据库做存储，无法水平扩展，容量有限。如果采集频率较高，比如 10 秒采集一次，上限大约可以监控 600 台设备，还需要把数据库部署在一个很高配的机器上，比如 SSD 或者 NVMe 的盘才可以。

（2）Zabbix 面向资产的管理逻辑，监控指标的数据结构较为固化，没有灵活的标签设计，面对云原生架构下动态多变的环境，显得力不从心。

老一代国产代表 Open-Falcon

Open-Falcon 把组件拆得比较散，组件比较多，部署起来相对比较麻烦。不过每个组件的职能单一，二次开发会比较容易，很多互联网公司都是基于 Open-Falcon 做了二次开发，比如美团、快网、360、金山云、新浪微博、爱奇艺、京东、SEA 等。

主要是小米在主导，各公司做二次开发，但社区贡献度不大

新一代整体方案代表 Prometheus

Prometheus 的设计思路来自 Google 的 Borgmon，师出名门

Prometheus对Kubernetes 支持得很好,但易用性差，exporter参差不齐

新一代国产代表 Nightingale

Nightingale  不止解决设备和中间件的监控，也希望能一并解决云原生环境下的监控问题。但是在 Kubernetes  环境下，Prometheus  已经大行其道，再重复造轮子意义不大，所以 Nightingale  的做法是和 Prometheus  做良好的整合，打造一个更完备的方案。当下的架构，主要是把 Prometheus  当成一个时序库，作为 Nightingale  的一个数据源。

对于不同的监控框架，思维导图总结如下：

学习来源：极客时间 运维监控系统实战笔记(day1)