可观测性是大规模分布式(微服务)系统的必要组件，没有可观测系统的支持，监控和调试分布式系统将是一场灾难。本文讨论了可观测系统的主要功能，并基于流行的开源工具搭建了一套可观测系统架构。原文: A Primer on Distributed Systems Observability
在这篇文章中，我们将探索什么是可观测性和监测系统，讨论怎样构建好的可观测性平台以及可观测性子系统可能的架构。
过去几年，系统体系架构的复杂性急剧增加，特别是基于分布式、微服务的体系架构。大多数情况下，调试和监控日志非常困难，且效率低下，特别是当我们有数百甚至数千个微服务或模块时，更是一场灾难。本文将介绍可观测性和监测系统的基本概念，讨论好的可观察性平台模式，以及可观察性子系统的可能架构。
可观测性(Observability) vs.监测性(Monitoring)
在进入主题之前，我们先介绍一下什么是可观测性，包括哪些组件，以及与监测有什么不同。可观测性允许我们在不知道细节或领域模型的情况下对系统中发生的事情有一个清晰的概述。此外，可观测性可以有效提供以下信息:
- 整个系统或者单一服务的故障或中断
- 常规系统和服务的行为
- 整体安全性和告警
知道了可观测系统应该覆盖什么功能，下面看一下应该收集哪些信息来正确设计可观测性监测平台。
- 指标(Metrics) —— 收集数据了解应用程序和基础设施状态，例如延迟、CPU、内存和存储的使用情况。
- 分布式跟踪(Distributed traces) —— 允许我们调查从一个服务到另一个服务的事件或分发流。
- 日志(Logs) —— 带有时间戳的消息，包含有关应用程序或服务级别错误、异常以及常规信息。
- 告警(Alerting) —— 当发生停机问题，或者某个或某几个服务出现问题时，将通过电子邮件、短信、聊天或电话向运维人员发出告警，通知这些问题，从而能够快速采取行动来解决问题。
- 可用性(Availability) —— 确保所有服务都启动并运行。监测平台向某些服务或组件(HTTP API 端点)发送探测消息，以检查是否响应。如果没有响应，那么可观测性系统将生成告警。
此外，还有一些可观测性监测平台可能包括用户体验监测，如热图和用户操作记录等。
可观测性和监测遵循相同的原则和模式，主要依赖于工具集，所以在我看来，两者之间的区别是出于营销目的。可观测性与监测有何不同并没有明确定义，所有定义都是不同的高级定义。
可观测性模式
所有基于微服务的复杂系统都有建议和模式，使我们能够建立可靠的系统，而不需要重新发明轮子。可观测性系统也有一些基本的模式，下面几节讨论五个最重要的模式。
日志聚合模式
在分布式系统中，日志记录可能很困难。每个微服务都会产生大量日志，查找和分析每个微服务的错误或日志消息是一场噩梦。因此，日志聚合模式可以提供帮助。它包含作为中央日志存储的中央日志聚合服务，该服务提供标记、索引、分类、搜索和分析所有日志的选项。有一些日志聚合平台案例，如Grafana Loki、Splunk、Fluentd和ELK技术栈。
图 1: 日志聚合模式
运行状况检查模式
如果有多个服务或微服务，当然需要知道它们的当前状态。我们可以通过日志聚合服务检查日志，但是服务有可能正在启动，还没有产生日志。此外，当服务失败时，可能会出现日志不可用的情况。
在这些案例中，需要实现运行状况检查模式。我们只需要在服务中创建一个运行状况(或 ping)端点，并指示日志聚合系统检查和收集每个服务的状态，还可以设置服务不可用时的通知或警报，这样可以节省大量时间来识别哪些服务启动失败或关闭。
图 2: 运行状况检查模式
分布式跟踪模式
想象一下这样的场景: 在一个或几个微服务中有多个组件、模块和库，我们需要检查组件执行的整个历史或者将请求发送到某个微服务，并且需要检查从一个服务组件列表到另一个服务组件列表的执行历史。
为此，需要一些分布式系统来收集和分析所有跟踪数据。一些开源服务可以帮助我们实现这一点，例如Jaeger、OpenTelemetry和OpenCensus。请查看Istio文档，里面有分布式跟踪的演示示例。
图 3: 分布式跟踪模式
应用指标模式
具有分布式日志记录和跟踪是必不可少的，然而，如果没有应用程序指标，可观测性系统就还不完整。我们可能需要收集底层和应用层的指标，比如:
- CPU
- 内存
- 硬盘使用情况
- 服务请求/响应时间
- 时延
收集这些指标不仅可以帮助我们了解需要的基础设施规模，还可以帮助我们节省在云供应商上的资金。此外还可以帮助我们快速识别由于缺少 CPU 或内存资源而导致的中断。
下面是一个通过代理收集指标的服务示例，代理聚合遥测数据并将其发送到可观测平台。
图 4: 应用指标模式
可观测性服务网格
服务网格不仅为微服务体系架构提供了中央管理控制平面，而且还提供了单一可观测子系统。
我们可以使用现成的工具来收集指标、分布式跟踪和日志，而不用安装单独的工具。例如，Azure 提供了集成的服务网格附加组件，可以在一分钟内设置好。
或者还可以选择Istio服务网格，它包含了可观测性子系统所需的所有特性。此外，还可以为控制平面收集指标、日志和跟踪。
例如，当我们设置 Grafana、Loki 或其他工具时，也需要为它们启用可观测性，因为它们也可能在工作时或在部署过程中失败，而我们需要排除这种故障。
图 5: 可观测性服务网格
微服务的可观测性架构
下面会用一个智能供暖系统作为可观测性架构的例子。智能供暖是每个家庭(甚至是智能家居)的重要组成部分，可以让业主:
- 通过应用程序手动管理公寓的温度。
- 根据时间和内外温度自动调节温度。
此外，系统还可以执行以下操作来帮助业主:
- 当人们即将到达公寓时，打开/关闭暖气。
- 通知、提醒或只是询问是否有需要人类注意的事情或是否有错误。
图 6: 带有可观测子系统的微服务架构
在图 6 中，可以看到一个基于微服务模式的架构，它工作的很好，代表了所有系统组件，包含主系统和可观测性子系统。每个微服务都基于 Azure Functions，并部署在 Azure Kubernetes 集群上。我们使用KEDA框架将功能部署到 Kubernetes。KEDA 是开源的、基于 Kubernetes 的事件自动扩容框架，允许我们自动部署和扩展我微服务功能。另外，KEDA 还提供了将功能封装到 Docker 容器的工具。如果没有大规模负载，也不需要扩容，也可以不使用 KEDA 和 Kubernetes，而是直接部署微服务功能。该架构包含以下代表主要子系统的组件:
- Azure 作为微服务运行
- Azure 服务总线(或 Azure IoT Hub)作为微服务用于通信的中央消息总线
- Azure API 为移动/桌面应用提供 API
这里的关键部分是一个可观测子系统，包含一组组件和工具，下面的表格介绍了所有组件:
可观测性系统组件
图 7: 带有可观测性子系统和 OpenTelemetry 的智能供暖系统
值得一提的是，我们不一定需要添加 OTel，因为它可能会给系统增加额外的复杂性。上图中可以看到我们需要将所有日志从 Prometheus 转发到 OTel。此外，也可以使用 Jaeger 作为 OTel 的后端服务。Loki 和 Grafana 将从 OTel 获得数据。
结论
在本文中，我们揭开了可观测性和监控系统的神秘面纱，并介绍了具有可观测性子系统的微服务架构示例，这些子系统不仅可以用于 Azure，也可以用于其他云供应商。此外，我们还定义了监控和可观测性之间的主要区别，并介绍了基本的监控和可观测性模式及工具集。开发人员和架构师应该理解可观测性/监控平台是一种允许团队主动调试系统的工具或技术解决方案。
你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind
