一、APP故障小故事

在一个休息日的周六，你和朋友在公司附近逛街，突然，老板来了一通电话：

• 老板：小王，我们 APP 购物详情页面，怎么突然访问不了，一直在那里加载，出了什么 bug，赶紧看看？

• 小王：好的，老板，你等等，我马上回来看看是咋回事。

丢下朋友，一路小跑，火花带闪电，奔回办公室，开机找 bug。

修好 bug 后，就应该思考一下，老板是咋发现这种情况？为什么他能先于我发现呢？有什么好的手段处理这种情况，我能最先发现网站访问异常？然后抓紧处理。

这时，你可能想到了对网站进行监控，化被动为主动，主动去获取 APP 异常信息。不错，这是一个很好的方法。

二、为什么需要监控

从上面的小故事可以得到一些启发，比如 APP 发生不能访问的异常情况时，相关人员能够快速感知到异常情况的发生，先于用户得到异常情况的信息，能让相关人员及时进行应急处理，减少损失。而不是等到多数用户来报告异常情况才去处理，这时损失就变大了。

监控系统不仅可以监控上面提到的应用程序页面访问异常，还可以监控其他页面访问流量，API 调用情况，响应时间，请求频率，错误率等等，这些都关乎业务整体运行情况。

对应用程序本身也可以进行监控，比如 APM（应用程序性能监控）监控，这样遇到应用程序故障时，可以快速定位问题、处理问题。

还有当运行应用程序服务器的 CPU、内存持续走高，磁盘存储空间所剩不多等等各种异常情况，都需要监控来及时发现，并报给运维人员进行处理。

上面不管是业务访问异常，还是服务器资源运行异常，还是 API 调用异常，程序出 bug 等各种异常情况，都需要及时发现并处理，目的是减少业务损失。

可以通过监控系统来及时发现异常情况，并通过系统记录与异常相关联的信息，还原异常出现的现场环境，从而协助运维或研发人员快速定位问题，并及时处理异常情况。

三、监控作用总结

为什么需要监控，除了上面说的作用外，下面对监控的作用做一些总结。（我理解的最大作用是：化被动为主动）

• 近实时了解业务运行的健康状况
• 提前获知业务异常情况信息并告警通知
• 帮助定位各种异常、bug等故障
• 为排障提供详细信息
• 业务运营信息的统计和监控
• 监控系统资源使用情况，保障系统稳定运行
• 对异常情况发出告警通知，及时进行处理

四、监控系统流程

监控系统一般流程如下图：

• 数据采集：

  通过采集工具收集相关监控指标的数据，比如采集操作系统指标， CPU 使用率、内存使用率、TCP 连接数等等。常用的采集数据的方式有代理和埋点 2 种方式。

  • 数据采集的软件工具，有 Filebeat，Fluentd，Fluent Bit，LogStash，Promtai，Vector，Mtail，Flume 等等。

• 数据处理：

  又可以叫数据计算处理，对采集到的原始数据进行各种纬度的计算处理，得到我们想要的一些监控指标数据。比如对于一些业务指标的计算，今天新增用户的数、7 天新增用户数、7 天某页面的 UV 等等数据指标。

  • 处理数据的工具有哪些？一般需要自己开发程序来进行数据处理，简单的指标计算可以通过 SQL 来进行统计。数据量比较大统计实时性高，可以使用 storm，flink 等大数据计算框架来进行计算统计。

• 数据存储：

  这里存储有 3 层含义，第一个是对采集的原始数据进行存储，第二个是对计算后的数据进行存储。第三个是有时我们会对原始数据进行暂存处理，比如暂存在 kafka 中。

  • 数据存储软件，数据暂存型的 kafka，关系型数据库 MySQL、PostgrSQL，时序数据库 InfluxDB、OpenTSDB、TimescaleDB，还有 Elasticsearch、MongoDB、ClickHouse、HBase、Hadoop 等等。

• 查询分析、数据可视化：

  查询分析对监控的指标进行查看然后分析。数据可视化，用图形方式展示监控的指标。

  • 一般都是需要开发人员进行程序开发。log 型的日志有 kibana 工具。

• 告警处理：

  把系统发生的错误、异常信息及时通知给研发、运维等相关人员，让他们及时进行处理。告警通知方式多种多样，有短信、IM、邮件、Slack等等方式。

  • 有简单的告警设置，比如 prometheus 里的。复杂的告警处理就需要研发来进行相关开发。

五、监控类别分层和指标

按照架构分层分类

根据业务系统架构设计，把监控系统类别进行分层，一般可分为 4 层，如下简图：

上面是一个比较大的监控分类，大的监控类别还可以在细分为一些小类和这些类别的一些监控指标，

业务监控：

这一层主要是对业务运营的指标和业务流程进行监控，随时监控业务异常和 bug 状况。

1. 业务运营：日新增注册用户（7日，30日，当天等等），流失用户数，活跃用户数，每个页面的 PV、UV，下单数量，支付数量、结算率 等等数据
2. 业务异常数据：比如某个页面访问异常统计，页面 404,500 等统计
3. 业务链路：业务链路中的关键节点，这些节点的健康情况、数据流向是否异常的监控
4. 用户体验数据：页面加载时间，交互响应时间等等，这些是前端监控数据的一部分

应用监控：

这一层主要是对应用程序运行情况进行监控，

1. API 监控：请求量、响应时间、耗时总长、超时比率，响应错误数、比率，比如 404,500 等统计

2. 链路监控：API 请求之间的链路信息，比如链路的响应时间，耗时等

3. 应用程序监控：对应用程序的持续监控，continue profiling。比如应用程序本身使用的内存，CPU 数，哪部分程序使用比较高

中间件监控：

一些使用的软件，比如 数据库、Nginx、Redis、Kafka、K8S 等等软件，这些软件本身会给出一个接口，这个接口用来统计软件自身的一些信息，可以收集这些信息，然后进行统计。还可以用产生的日志进行统计。

比如说 Redis 的命令 redis info 就会显示 Redis 的很多信息，可以摘出需要的信息进行记录统计。

这里每一个软件都可以进行独立的记录和统计。比如数据库，

• 数据库：数据库连接数，QPS，主从延迟，慢查询，锁的一些信息

基础设施监控：

这里的基础设置包括一些硬件，比如交换机，物理磁盘，网卡状态。还包括操作系统，网络，虚拟机的监控

• 操作系统：CPU 使用率，内存使用情况，硬盘使用情况
• 网络：TCP 连接数、连接状态，网络流入流出流量等网络指标

按照监控内容分类

• 日志类

日志类就是指系统产生的日志信息，代码里记录的一些程序运行信息，还有一些业务级别上记录的日志信息，在带上时间。

比如 Nginx 里记录的访问日志，应用记录下用户登录日志，用户搜索记录日志，下单日志数据，这些都是与用户做某件事情相关联的日志信息。

有助于我们进行一些指标统计，异常信息查找和分析，告警通知。

• 调用链

调用链一般是指程序 API 之间相互调用的一些信息，端到端的访问路径相关信息，也叫链路追踪。这些都是 APM 应用程序性能监控。

我前面有写一篇关于 google 的 Dapper 链路追踪文章，在这里 https://www.cnblogs.com/jiujuan/p/16097314.html 。

• 度量类

度量类指的是记录一串以时间为纬度的数据，然后通过聚合统计，来计算一些监控指标。用来描述一些指标数据和指标变化趋势，可以用图表来表示。

在可观测性里这个叫 metrics 。

上面 3 个分类其实跟可观测性的 3 个指标有点类似，下面就讲一讲可观测性的内容。

六、可观测性Observability

什么是可观测性

维基上：

控制理论中的可观察性（observability）是指系统可以由其外部输出推断其其内部状态的程度。系统的可观察性和可控制性是数学上对偶的概念。它与可控制性（Controllability）一起，是由匈牙利数学家 Rudolf E. Kálmán 提出。

IBM：

一般来说，可观察性是指您仅根据所了解的外部输出对复杂系统内部状态或条件的理解程度。 系统的可观察性越高，您就能越迅速、越准确地从发现的性能问题找到根本原因，而不必进行额外的测试或编码。

• From：https://www.ibm.com/cn-zh/topics/observability IBM的可观测性

CNCF：

可观察性是系统的一种属性，描述了系统可以从其外部输出中被理解的程度。

比如通过 CPU 使用时间、内存使用、磁盘空间、延迟、系统运行的错误信息等来衡量，计算机系统或多或少是可以被观察到的状况。聚合分析这些数据，您可以查看这些可观察的数据来了解系统的运行状况。

IBM 的定义和维基的差不多。

可观测性是对软件的一种度量能力。软件是一个复杂系统，怎么知道它的运行状况是否健康呢？怎么从外部窥见软件的运行状况和异常情况呢？怎么分析出现的异常呢？通过软件内部产生的数据信息（日志信息、链路信息、profilling 等等各种信息）并输出到外部，外部把这些信息通过聚合、计算，用一定的形式组织起来，然后用列表、图表形式展现出来，这样我们就可以肉眼去查看软件系统各种纬度的情况、系统当前所处的状态。

可观测性就像一个显微镜，它仔细观察软件系统的各种指标和状态，系统是否出现异常情况。

可观测的三大支柱

可观测性具体怎么做？有哪些指标。

可观测性一般有 3 个方向，分别是：事件日志、链路追踪 和 聚合度量，这 3 个方向各有自己的重点，又不是完全独立的，它们有重合的地方。

可以看看 Peter Bourgon 的一篇总结文章《Metrics, Tracing, and Logging》，里面有一张很经典图片描述了 3 者之间的关系，受到了业界普遍的关注：

​ （图片来源：《Metrics, Tracing, and Logging》）

指标（Metrics）、追踪（Tracing）、日志（Logging），这是可观测性的3个基本指标。

• 日志 logging

  上面表示 Logging 是 events，它是特定时间发生离散事件的记录。比如 Nginx 的访问日志记录，每条日志记录一般有访问时间戳、响应码、页面 URL、客户端 IP 等信息。还有程序也会记录一些用户访问信息，比如下单记录。

• 链路追踪 Tracing

  端到端请求范围内的调用链路相关信息。比如记录每个请求阶段的开始时间、时长等信息。关于 google 的 Dapper 链路追踪文章，我前面写的 https://www.cnblogs.com/jiujuan/p/16097314.html 。

  链路追踪主要是为了排除故障，比如分析调用链中哪一部分用时比较长、哪个方法出错了等等。

• 度量 Metrics
  度量是对系统中某一类信息的聚合计算。比如服务器中 CPU 利用率、内存剩余数，系统容量等等

七、监控和可观测性的区别

监控是收集一组预定义的指标和日志，来帮助研发和运维观察和了解系统运行状态的工具，并提供解决方案。

可观测性是事先未定义的属性和模式来探索系统出现的问题，有效帮助研发或运维调试系统的工具。

上面是来自 google cloud 。

监控告诉你出了点问题，而可观测性是告诉你哪里出了点问题以及为什么会发生。

监控是一种收集和分析从各个系统中提取的预定义数据，来解决系统中出现的问题。可观测性是一种聚合所有 IT 系统产生的数据的来观察、推演系统内部的状态，并分析系统出现的问题以及为什么出现这个问题。

可观测性的定义范围更广，监控是可观测性的一个子集。

监控和可观测性之间的关系图：

（来自：万字破解云原生可观测性）

八、CNCF 中监控和可观测性软件工具

Monitoring监控工具

（来自：https://landscape.cncf.io/guide#observability-and-analysis--monitoring）

上面最常用的应该是 prometheus + grafana 组合。

除了上面列出的外，还有一款监控系统 - 夜莺监控（Nightingale），它是一款 ALL IN ONE 设计的监控系统。

Nightingale 夜莺监控，一款先进的开源云原生监控分析系统，采用 All-In-One 的设计，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。

github 地址：https://github.com/ccfos/nightingale 。

Logging日志工具

（来自：https://landscape.cncf.io/guide#observability-and-analysis--logging）

上面最常用的应该是 ELK（elasticsearch、logstash、kinbana）

Tracing链路追踪工具

（来自：https://landscape.cncf.io/guide#observability-and-analysis--tracing）

上面常用的链路追踪， jaeger，pinpoint，skywalking，zipkin，OpenTelemetry 等。

九、参考

• https://db-engines.com/en/system
• https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html Peter Bourgon 的 Metrics, Tracing, and Logging
• https://cloud.google.com/architecture/devops/devops-measurement-monitoring-and-observability?hl=zh-cn 监控和可观测性
• https://zhuanlan.zhihu.com/p/137672436 万字破解云原生可观测性
• https://landscape.cncf.io/guide#observability-and-analysis
• https://n9e.github.io/ 夜莺监控