八、微服务监控

• 可观测性
  • 1 事件日志
    • 1.1 如何、怎样输出日志
    • 1.2 收集和缓冲
    • 1.3 加工与聚合
    • 1.4 存储与查询
  • 2 链路追踪
    • 2.1 追踪和跨度
    • 2.2 数据收集
    • 2.3 追踪规范化
  • 3 聚合度量
    • 3.1 指标收集
    • 3.2 存储查询
    • 3.3 监控预警

[toc]

可观测性#

什么是微服务的可观测性？

微服务的可观测性是指在微服务架构中，系统的各个组件和服务能够被有效地监控、度量和分析，以便运维人员和开发团队可以了解系统的运行状况、性能指标和故障情况。可观测性能够提供对每个微服务的实时监控和分析，以及对整个系统的全局视图。

微服务的可观测性有3个具体的方向，分别是

• 事件日志（记录离散事件，主流是ELK）
• 链路追踪（排查故障用发生在哪个环节用的， k8s下的prometheus相对有优势）
• 聚合度量（汇总生成一些统计信息，涉及很多定制化的内容，暂时没有一家独大的情况）。

1 事件日志#

对于事件日志， 现在主流是使用ELK。即 Elasticsearch、Logstash 和 Kibana的结合。
每个微服务可以使用 Logstash 将其日志数据发送到 Elasticsearch 进行存储和索引。然后，通过 Kibana 可以轻松地搜索、过滤和分析这些日志数据，以获得对整个系统的实时可视化监控和故障排查能力。

1.1 如何、怎样输出日志#

对于打印事件日志，作者建议遵循以下这些原则：

• 避免打印敏感信息
• 避免引用慢操作（应该都是直接能取到的信息，避免要调远程接口或者耗时较久的计算）
• 避免打印追踪信息（这种信息交给链路跟踪做）， 包括打印请求体之类的
• 避免误导 他人（例如异常已经吃掉了处理了，后面却还往外打异常日志别人）
• 尽量记录处理请求时的traceId
• 记录关键事件
• 记录启动时的配置信息便于观察配置中心对配置的修改是否生效

1.2 收集和缓冲#

所有日志需要集中收集，因为经常是分布式系统。
相关收集器： Logstash、filebeat。

Logstash适用于复杂的数据处理和转换场景，对于数据管道的灵活性和功能要求较高。

而Filebeat更适合轻量级的日志收集和实时传输，对于资源消耗和简单配置要求较低。

日志可能很大，要保证完全一致性很难，可以加kafka或者redis作为日志的缓冲层

1.3 加工与聚合#

日志一般是非结构化的字符串， 需要有工具处理成结构化的数据，例如处理成json输出到elasticsearch中。
Logstach就能够支持结构化处理， 且还支持引入各种聚合插件。

比如下面这3句日志：

2023-05-14 10:30:15 INFO: User 'john' logged in successfully.
2023-05-14 10:31:02 ERROR: Failed to process request. Error message: Timeout expired.

通过编写好Logstach的配置文件，然后执行logstach处理命令后，即可生成如下的json结构：

{
  "timestamp": "2023-05-14 10:30:15",
  "loglevel": "INFO",
  "message": "User 'john' logged in successfully."
}
{
  "timestamp": "2023-05-14 10:31:02",
  "loglevel": "ERROR",
  "message": "Failed to process request. Error message: Timeout expired."
}

后续即可导入到es中进行进一步的分析和检索了。

1.4 存储与查询#

存储和查询的选择大部分是elasticsearch（大部分时候简称ES）
为什么？

• 从数据特征看，日志是基于时间的数据流，很容易让es按时间范围做索引。
• 数据价值角度看， 日志只会以最近的数据为目标，因此可以进行冷数据和热数据的分开存储。
• 从数据使用角度看，分析日志依赖全文检索 和 即席查询（近实时性）正好是es的强项。

es和kibaba搭配使用还能可视化查看。kibaba是一个

2 链路追踪#

2.1 追踪和跨度#

这是2个概念。

• Trace追踪：从客户端发起请求抵达系统边界开始，记录请求流经的每一个服务，直到客户端返回响应。

• Span跨度： 每次开始调用服务前都会预先埋入一个调用记录，记录时间点、时长。
  Span必须简单， Trace中包含多个span。

需要达成以下4个目标：

• 低性能损耗
• 对应用透明
• 随应用收缩
• 持续的监控

2.2 数据收集#

有三种方式

• 基于日志的追踪思路。 将Trace、span输出到日志中，然后日志收集后进行分析。
  优点：实现简单，侵入性小。
  缺点：日志本身不追求决定的连续性和一致，容易失真。
  典型代表： Spring Cloud Sleuth

• 基于服务的追踪。是最常见的追踪方式。 通过某些手段给应用注入探针，例如java Agent，然后将调用过程发送请求给追踪系统。
  有比较强的侵入性，但是追踪的精确性和稳定有保证
  典型代表：SkyWalking\zipkin\pinpoint

• 基于边车代理的追踪。
  依赖服务网格的实现， 追踪数据通过控制平面上报，避免了追踪影响通信和日志。但是服务网格还不太普及，而且只能是服务调用层面无法细化到方法层面。
  典型代表： Envoy

2.3 追踪规范化#

在过去，有几个不同的追踪规范和工具被开发出来，其中最著名的是OpenTracing和OpenCensus，而这两者已经合并为一个名为OpenTelemetry的项目。

OpenTelemetry是一个全面的观测框架，集成了追踪、度量和日志记录。它提供了一组跨语言的API和库，可以在应用程序中插入代码以收集观测数据。

3 聚合度量#

度量的目的是揭示系统的总体运行状态。 经过聚合统计后的高维度信息，以最简单直观的形式来总结复杂的过程，为监控预警提供决策支持。

本章节主要介绍了Prometheus的功能，是云原生时代的事实标准。

Prometheus是一款开源的系统监控和警报工具，最初由SoundCloud开发，并于2012年发布。

它专注于收集、存储、查询和可视化时间序列数据，并提供强大的监控和警报功能。 以下会介绍这款的3个核心能力

3.1 指标收集#

如何定义指标（有哪些类型）：

• 计数度量器
• 瞬态度量器
• 吞吐率度量器
• 直方图度量器
• 采样点分位图度量器
  prometheus支持计数、瞬态、直方图和采样点分位。

---

如何把指标告诉服务端

• 拉取式
• 推送式
  prometheus选择拉取式， 并且支持有限兼容推送式。

对于网络协议， promethus只支持HTTP但提供了强大的客户端包供使用。

3.2 存储查询#

对于度量数据的存储， 应该优选“时序数据库”
即存储跟随时间而变化， 并且以时间来建立索引。

时序数据库的特点：

• 以日志结构的合并数代替B+树
• 设置激进的数据保留策略， 用过期时间TTL删除相关数据
• 对数据采样节省空间

prometheus就是内置了时序数据库

3.3 监控预警#

prometheus提供了专门用于预警的alert Manager。

通过将Prometheus与Alertmanager集成，用户可以根据监控数据的变化和指定的规则，及时收到关键问题的警报。Alertmanager提供了一个集中化的警报处理和管理平台，使用户能够根据自己的需求定制和配置警报路由，并将警报发送给适当的团队成员和通知渠道，以便及时响应和解决问题。