可观测性微服务日志记录监测云基础设施分布式系统

微服务与单体系统日志记录的可观测性

微服务可观测性提供跨独立服务的分布式追踪、指标和日志，而单体日志记录则侧重于来自单个应用程序的集中式记录。正确的选择取决于系统的复杂性、规模以及团队需要了解的服务交互程度。

亮点

微服务可观测性将跟踪、指标和日志视为同等信号，而单体日志记录几乎完全依赖于文本记录。
分布式追踪使团队能够精确定位导致故障的具体服务，而传统日志很难跨服务边界做到这一点。
单体日志记录所需的启动基础设施和专业知识要少得多，因此对规模较小或遗留系统很有吸引力。
可观测性会随着系统复杂性的增加而扩展，而单体日志记录往往会随着应用程序规模和流量的增长而降低。

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

采用多维方法，结合跟踪、指标和日志，了解分布式、独立部署的服务的行为。

基于三大支柱：分布式追踪、指标和跨服务的结构化日志记录
使用关联 ID 来跟踪单个请求在数十个或数百个服务之间的跳转。
依赖 OpenTelemetry、Jaeger、Prometheus 和 Grafana 等工具进行数据收集和可视化
专为处理容器和 Pod 不断启动和关闭的临时基础设施而设计
通过服务级别目标和错误预算，使SRE团队能够检测异常情况。

单体系统日志记录是什么？

传统方法是指单个应用程序将日志条目写入集中式文件或单个日志存储，以便进行调试和审计。

日志源自于作为单个进程运行的同一代码库，因此请求路径很容易追踪。
通常使用基于文件的日志记录、syslog 或像 Logback 或 log4j 这样的简单日志聚合器。
调试通常涉及在日志文件中进行搜索或查询单个 ELK 堆栈实例。
由于日志记录在同一个运行时环境中进行，因此性能开销极小。
通过线程本地上下文或简单的会话 ID 更容易实现关联。

比较表

功能	微服务中的可观测性	单体系统日志记录
建筑学	分布在多个服务中	单一统一应用程序
主要数据类型	跟踪、指标和日志	主要记录日志，有时也记录指标。
请求跟踪	使用跨度上下文进行分布式追踪	基于线程或会话的跟踪
工具复杂性	高——需要跨服务的仪器仪表	低——单条日志管道就足够了
可扩展性	随服务次数水平扩展	受单个应用程序吞吐量限制
故障诊断	找出导致延迟或错误的服务。	在同一流程内更容易，但在边界处更难。
存储要求	大容量、通常是时间序列的数据库	中等规模，通常为平面文件或一个索引
实施成本	大量前期投资	较低的初始设置成本

详细对比

核心理念与方法

微服务可观测性假设你无法预先预测所有故障模式，因此需要收集足够多样化的遥测数据，以便在问题发生后提出新的问题。单体式日志记录则采取更简单的策略：捕获足够的文本记录来重构请求期间发生的情况。第一种方法将日志视为众多信号之一，而第二种方法则将日志视为理解系统行为的主要信号。

调试和根本原因分析

当微服务架构出现故障时，工程师会深入查看分布式跟踪日志，以准确找出是哪个服务引入了延迟或返回了错误。而在单体架构中，开发人员通常会打开日志文件，搜索时间戳或用户 ID，然后逐条阅读日志条目。单体架构的这种方式看似更直观，但一旦系统规模扩大到单个日志文件难以管理的程度，这种方式就显得力不从心了。

工具和基础设施

可观测性技术栈通常包含 OpenTelemetry 等检测库、Jaeger 或 Tempo 等追踪后端、Prometheus 等指标存储以及 Grafana 等仪表盘层。单体日志系统通常需要的组件少得多——一个日志框架、Filebeat 等日志收集器，以及可能一个 ELK 或 OpenSearch 集群。微服务工具链需要更高的运维成熟度，但当系统变得复杂时，它的优势就体现出来了。

绩效和开销

分布式追踪会增加网络跳转和序列化开销，因为跨服务边界传播的跨度（span）会增加开销，但采样策略可以将其控制在可控范围内。单体日志记录与应用程序进程紧密相关，因此性能损失主要来自磁盘 I/O 和日志格式化。如果生产环境中的日志级别保持在详细级别，这两种方法都可能降低性能，但微服务环境通常需要更精细的调优。

何时各自合理

在频繁部署、多语言服务以及需要独立拥有组件的团队环境中，可观测性优势显著。单体日志记录仍然适用于小型应用程序、遗留系统或需要简单审计跟踪的监管合规场景。许多组织实际上同时运行这两种方案——保留传统日志以满足合规性要求，同时在其上叠加可观测性工具以提供工程洞察。

优点与缺点

微服务中的可观测性

优点

+ 完整请求可见性
+ 多信号相关性
+ 随复杂性而变化
+ 支持 SRE 实践

继续

− 更高的模具成本
− 更陡峭的学习曲线
− 更多存储开销
− 需要仪器操作方面的专业知识

单体系统日志记录

优点

+ 易于实施
+ 更低的运营成本
+ 大多数团队都熟悉
+ 轻松进行审计跟踪

继续

− 跨服务洞察力有限
− 尺寸缩放效果差
− 单点故障
− 事件关联性较差

常见误解

神话

单凭日志就足以调试任何系统。

现实

日志对于单体架构效果显著，但在分布式系统中，单个请求会涉及多个服务，因此日志的有效性会降低。指标和跟踪可以弥补日志的不足，展现日志难以揭示的模式和因果链。

神话

可观测性只不过是换了个名字的高级日志记录功能。

现实

可观测性是一门更广泛的学科，它不仅包含日志，还将指标和追踪信息作为重要信号。其目标从搜索记录转变为在不编写新代码的情况下，对系统行为提出任意问题。

神话

单体系统不需要可观测性。

现实

即使是单个应用程序，一旦达到一定规模，也能从指标、跟踪和结构化日志中获益。可观测性的核心在于理解系统状态，这与架构无关。

神话

分布式追踪对于生产应用来说成本太高。

现实

现代追踪系统采用基于头部或尾部的采样方法来捕获具有代表性的请求子集。这样既能保持较低的开销，又能提供足够的数据来诊断大多数问题。

神话

切换到微服务架构会自动提高可观测性。

现实

微服务架构使可观测性更难实现，而不是更容易，因为需要监控的组件更多了。如果没有适当的监控和工具，其可见性实际上会比配置完善的单体架构更低。

常见问题解答

可观测性和日志记录有什么区别？

日志记录是遥测数据的一种类型——它记录的是应用程序所记录的离散事件。可观测性是系统的一种属性，它描述了你如何从外部输出了解系统的内部状态。可观测性结合了日志、指标和追踪数据，而日志记录则仅关注文本记录。

为什么微服务需要分布式追踪？

在微服务架构中，单个用户请求可能需要经过五个、十个甚至更多服务才能完成。分布式追踪利用关联 ID 和跨度跟踪该请求跨越服务边界，从而可以查看时间消耗在哪里以及故障源自何处。

微服务环境下可以使用传统日志记录吗？

是的，但如果没有共享标识符，就很难跨服务关联日志。大多数团队会添加带有关联 ID 的结构化日志记录，然后在此基础上叠加跟踪和指标，以全面了解系统行为。

可观测性的三大支柱是什么？

日志、指标和追踪是三大支柱。日志记录离散事件，指标记录一段时间内的数值数据，追踪则显示请求在分布式系统中的路径。它们共同帮助团队解答有关性能、错误和用户体验的问题。

OpenTelemetry 是可观测性的标准吗？

OpenTelemetry 已成为大多数语言和平台上的事实标准。它合并了 OpenTracing 和 OpenCensus 项目，现在由云原生计算基金会 (CNCF) 支持，并得到了众多供应商和开源工具的广泛支持。

与日志记录相比，可观测性成本是多少？

由于需要额外的存储空间、工具许可和用于部署仪器的工程时间，可观测性通常会增加成本。然而，它通常可以缩短平均故障解决时间并防止代价高昂的停机，这可以抵消运行复杂系统的组织的前期投资。

单体架构能否从可观测性工具中获益？

当然。即使是单个应用程序，也能从自身进程内的分布式追踪、揭示性能趋势的指标以及更易于查询的结构化日志中获益。可观测性工具并非微服务专属。

分布式追踪中的 span 是什么？

span 代表跟踪中的单个工作单元，例如数据库查询或服务之间的 HTTP 调用。Span 具有名称、开始时间、持续时间和元数据，它们通过父子关系链接在一起，形成完整的跟踪。

如何关联不同微服务的日志？

团队通常会在系统边缘注入一个关联 ID，并通过 HTTP 标头、消息元数据或线程上下文进行传播。每个服务都会在其日志条目中包含该 ID，因此只需一次搜索即可在所有服务中返回完整的请求路径。

初创公司应该使用可观测性还是坚持使用日志记录？

早期创业公司通常会从结构化日志和基础指标入手，因为这样交付速度更快、成本更低。随着系统规模的扩大和团队的壮大，添加追踪功能和统一的可观测性平台对于保持开发速度就变得至关重要。

裁决

当您的系统跨越多个独立服务，并且您需要实时了解跨服务交互时，请选择微服务可观测性。对于较为简单的应用程序，如果集中式记录能够提供足够的可见性，并且运维开销比细粒度洞察更为重要，则应坚持使用单体日志记录。实际上，成熟的系统通常会将这两种方法结合起来，而不是完全依赖其中一种。