第四部分、可观测性和所有权

第 11 章、构建监控系统

了解从运行的应用中应收集哪些信号

构建一套收集度量指标的监控系统

学习如何使用收集的信号来设置告警

观察每个服务的表现以及这些服务作为系统的交互调用

11.1、稳固的监控技术栈

监控能够让开发者了解系统是否在正常运行，可观测性能够让开发者知道系统没有正常运行的原因。

日志和链路追踪构成了可观测性。

监控技术栈的组成部分-度量指标、链路追踪和日志-分别聚合到各自的面板中。

11.1.1、良好的分层监控

如第三层所描述：架构层次：客户端、边界层、服务层、平台层。

11.1.2、黄金标志

• 时延

• 错误量

• 通信量）—系统的需求量（每秒的请求量、网络 I/O）—

• 饱和度（其实就是某个时间点服务的承载能力，阿里通常喜欢称为水位）

11.1.3、度量指标的类型

• 计数器（请求量、错误量、每种 HTTP 状态码所收到的数量以及传输的字节数）

• 计量器（数据库连接数、内存使用量、CPU 使用量、平均负载量和异常运行的服务数）

• 直方图（结果采样，请求时延、I/O 时延、平均负载量和异常运行的服务数）

11.1.4、实践建议

每个指标设定合理的分为 99 分位、95 分位、90 分位

11.2、利用 Prometheus 和 Grafana 监控系统

• Prometheus 开源的系统监控和告警工具箱

• Grafana 是可视化仪表盘的工具基于 Graphite、InfluxDB 和 Prometheus

11.2.1、配置度量指标收集基础设施

• 向 Docker Compose 文件添加组件

• StatsD 导出服务配置

• 配置 Prometheus

• 设置 Grafana

11.2.2、收集基础设施度量指标-RabbitMQ 或者其他消息队列

11.2.3、监控系统功能

11.2.4、告警设置

11.3、生成合理的可执行的告警

11.3.1、系统出错时候那些人需要知悉

开发者和维护者

11.3.2、症状而非原因

减少告警，否则容易疲劳

11.4、检测整个应用

只有全链路的收集和聚合数据才能让系统更加直观的展现别人面前。

第十二章、使用日志和链路追踪了解系统行为

采用一致的结构化方式以机器可读的格式存储日志

搭建一套日志基础设施

使用链路追踪和关联 ID 来了解系统行为

12.1、了解服务间的行为

服务间分布式系统的链路非常复杂，如何将访问每个服务在不同运行实例中的日志数据结构化，人类可读？

12.2、生成一致的、结构化、人类可读的日志

12.2.1、日志中的有用信息

• 时间戳

• 标识符

• 来源

• 日志等级别或类型

12.2.2、结构化和可读性

Logstash 提供插件来实现负责收集、处理和转发来自不同来源的事件和日志消息的工具。

12.3、为系统配置日志基础设施

基于 ELK 的解决方案，使用 Fluentd 的数据收集器。

12.3.1、基于 ELK 和 Fluentd 的解决方案

12.3.2、配置日志解决方案

12.3.3、配置收集的日志

12.3.4、检索服务日志信息（Kibana）

12.2.5、记录合适的信息

12.4、服务间的跟踪交互

OpenTracingAPI 是一个与供应商无关的分布式链路追踪开放标准。

分布式跟踪系统有-Dapper、ZIPkin、HTrace、X-Trace、Jaeger。

12.4.1、请求关联：trace 和 span

trace 是单个或多个 span 组成的有向无环图（DAG），这些 SPAN 的边称为 reference。

12.4.2、服务内配置链路追踪

12.5、链路追踪可视化