可观测性的三大支柱：日志、指标和跟踪

许多管理架构和机构依靠三大支柱来确保成功部署。企业责任实践侧重于环境、社会和财务可持续发展，并以此指导业务实践。

即将经历数字化转型的企业通常会采用三大支柱，即“人员、流程和技术”来指导其转型工作。该框架鼓励决策者专注于保留富有创造力和协作精神的技术专家（即“人员”）；使用细致的结构化数据管理和安全实践（即“流程”）；并依靠先进的工具和平台来推动进步。

Scrum 是一套实现敏捷项目管理的框架和原则，其三大支柱是透明度、检查和适应性。在每一个实例中，支柱都是不同的和必要的，但并不完整。每个支柱都有自己的范畴和优先事项，但真正的力量在于它们如何合作和互动，以支持更大的目标。可观测性也不例外。

在 IT 环境中，可观测性应用遥测数据的三大支柱，即“指标、日志和跟踪”来提高庞大计算网络的可见性和易理解性。它使开发人员能够根据系统的外部输出了解其内部状态。当网络具备可观测性时，IT 人员就能通过查看网络生成的数据来确定任何性能问题的根本原因，而无需额外进行测试或编码。

可观测性解决方案使用系统的原始输出数据来完成数据分析，为团队提供有效的故障排除和调试所需的端到端网络可见性和切实可行的见解。

可观测架构能帮助工程团队和网络管理员管理现代计算网络的复杂性。如今，这意味着需要维护大规模的高度动态计算网络，其中通常包括混合云和多云配置，以及一系列云原生应用程序、微服务和 Kubernetes 容器。

可观测性工具（例如开源解决方案 OpenTelemetry）能够为企业提供了解系统健康状况的全面情景化视图。全栈可见性有助于团队在异常数据模式和性能瓶颈影响最终用户之前进行识别。因此，可观测性可以帮助企业最大限度地减少网络停机时间，并维护不同用例的服务可靠性。

然而，无论网络复杂程度如何，可观测性都取决于系统“事件”及其三大支柱。这些支柱使可观测性平台能够收集和分析跨分布式系统运行的前端应用程序、后端服务、CI/CD 管道和流数据管道中的数据。

可观测性需要从网络的每个组件收集细致的数据，以确定系统事件的“内容”、“位置”和“原因”，并阐明事件可能如何影响整个架构的性能。因此，事件是监控和遥测的基础。

事件是指在特定时间内网络上发生的独特事件，通常可为日志、指标和跟踪提供有价值的数据，与可观测性三大支柱——“日志、指标、追踪”同等重要。事件存在于更广泛的情境中。

例如，当客户端从企业服务器请求资源时，客户端会使用端点的 URL 将该请求定向至相应的 API 端点。服务器接收请求后，会检查其身份凭据（如 API 密钥）和客户端权限，并假设其有效，然后根据 API 的规范处理请求（例如，确保响应格式正确）。随后，服务器会向客户端发送包含所请求数据的响应。

事件会在精确的时刻触发不同的行动。因此，可观测性工具依靠它们来启动跟踪、分析和关联流程，从而帮助 DevOps 团队实现 IT 环境可视化并优化其网络。

指标通过测量各种网络参数，提供对系统性能的定量见解。它们帮助团队了解系统问题是“什么”。指标的类型包括：

• 主机指标：内存、磁盘和 CPU 使用率
• 网络性能指标：正常运行时间、延迟、吞吐量
• 应用程序指标：响应时间、请求率和错误率
• 服务器池指标：实例总数、正在运行的实例数
• 外部依赖关系指标：可用性、服务状态

常见指标（例如内存使用率和延迟）与系统健康状况呈直观一致性。但是，许多其他性能和关键绩效指标 (KPI) 可以揭示系统问题。例如，操作系统 (OS) 句位耗尽可能会减慢系统速度，并且通常需要重启才能恢复功能。

指标通常会被汇总，并使用仪表板和其他可视化功能（例如时间序列图）生成摘要视图，以帮助开发人员快速评估系统的整体健康状况、分析数据趋势并响应网络问题。这些指标还可提供关于扩展和资源分配的决策信息，使其成为高效容量规划和负载管理的关键要素。

重要的是，团队应仔细筛选并持续分析要跟踪的指标，因为有的指标可以帮助团队在潜在问题发生之前进行预测。

团队可以建立指标阈值，一旦突破阈值就会触发预警，通知 IT 人员当前存在或即将出现的问题。指标还能帮助可观测性工具检测随时间积累的问题（如操作系统句位泄漏），并在其影响客户体验之前提前识别。

不过，指标通常只能提供有限的情境信息，因此往往需要关联日志和跟踪记录，才能让开发人员全面了解系统事件。高分辨率指标也会生成大量数据，且难以有效存储和管理。因此，可观测性通常需要高质量的长期存储解决方案，以处理指标数据并确保其可用于分析。

日志是指系统内发生的离散事件不可篡改的详尽记录，有助于团队了解系统问题的“原因”。

日志文件可存储有关系统行为和应用程序进程的详细信息，包括：

• 事件时间戳
• 事务 ID
• IP 地址和用户 ID
• 事件和流程详情
• 错误消息
• 连接尝试
• 配置变更

事件日志可以采用二进制、非结构化（如纯文本）或结构化（如 JSON）格式。所有日志文件在相应情境中都很实用，但结构化日志记录可在生成时处理结构文本和元数据，因此更易于解析和分析。

可观测性工具中的日志记录功能可汇总来自操作系统、网络设备、内部和第三方应用程序以及物联网 (IoT) 设备的日志文件，从而帮助开发团队诊断错误并了解系统故障。当发生错误、安全漏洞或合规问题时，日志会提供跟踪根本原因和了解具体问题所需的详细信息。

日志为系统事件和问题提供了宝贵的洞察分析，但仅凭日志难以描绘完整图景。与指标一样，可观测性工具必须分析日志数据并将其与指标和跟踪相关联，才能最大限度发挥其价值。与指标一样，日志也会显著增加数据量，因此企业通常需要投资专业日志管理工具以平衡数据负载。

此外，全面的事件日志记录会将重要信息隐藏于相关度较低的数据之下，从而产生“噪音”，并增加 IT 人员识别问题的难度。这就是为什么现代可观测性解决方案要依赖 AI 和机器学习 (ML) 驱动的自动化工作流来完善预警实践，并区分关键预警和噪音。

跟踪结合了指标和日志的部分功能，可跨网络组件映射数据以显示请求的工作流。它们代表着请求遍历网络的端到端旅程，可捕获处理请求所涉及的各组件的路径和生命周期。简而言之，跟踪可以帮助站点可靠性工程师 (SRE) 和软件工程团队了解系统事件和问题出现的“位置”及“方式”。

跟踪数据可以包括：

• 网络事件和运营的持续时间
• 数据包在架构中的流动
• 请求遍历网络服务的顺序
• 系统错误的根本原因

跟踪（即分布式跟踪）在微服务架构中很有用，其中请求可以在到达目的地之前遍历多个地理上分散的微服务。通过它可以深入了解不同组件和服务之间的依赖关系和交互，并帮助 IT 团队了解用户完成特定操作需要的时间。

可观测性工具中的跟踪功能对于延迟分析至关重要，它可以帮助工程师识别可能给用户带来性能瓶颈的问题组件和性能不佳的服务。

它们可通过说明请求-响应流和网络元素之间的因果关系，推动调试进程。而且，在根本原因分析期间，跟踪可以帮助团队在复杂的工作流中查明网络问题的根源，从而更快速、更准确地解决问题。

与指标和日志不同，跟踪可以提供上下文信息以帮助丰富洞察分析。然而，仅靠跟踪并不能揭示数据趋势或模式。设置分布式跟踪还需要跨服务部署进行代码插桩，这会使过程特别复杂且耗时。如果管理不当，跟踪及其所需的计算能力可能会给环境带来更多延迟。

结合这三大支柱，开发和运营团队就能全面而细致地了解复杂的系统行为。指标用于向团队发出问题预警，跟踪显示其执行路径，日志则提供解决问题所需的情境信息。

三者协同配合，有助于加速问题的识别和解决，从而为团队提供解决问题、优化网络性能和实现全栈可观测性的互补工具。

众所周知，指标、日志和跟踪是可观测性的“中流砥柱”，但这并不排除其他基础组件的存在价值。有的人认为，情境、关联和预警也是可观测性的支柱。

毕竟，上下文通过提供有关网络环境的额外信息（例如拓扑、设备角色和应用程序依赖关系）来丰富指标、日志和跟踪。如果没有上下文，可观测性数据将缺乏可操作的意义。

关联将指标、日志、跟踪和情景化信息联系在一起，以呈现网络堆栈不同层级间事件的连贯视图。如果没有预警，可观测性工具就无法在出现问题时发送提示通知。

然而，剖析正在成为可观测性的又一关键功能。

剖析（又称“持续剖析”）是指运行应用程序并持续收集特定时间点代码执行状态的详细数据的过程。例如，剖析可以显示 Java 线程是处于“运行”还是“等待”状态。或者，如果应用程序存在内存泄漏问题，剖析可以帮助人员确认哪部分代码在过度消耗资源。

因此，剖析可以作为 X 射线进入单个系统组件的内部工作。

剖析有助于查明低级问题，如影响单个功能或代码块的问题。它可以帮助 IT 团队识别占用的代码路径，定位并弃用未使用的路径，从而为未来事件和交互确定关键路径的优先级。

尽管剖析未被纳入三大支柱，但其技术能力已取得显著演进。扩展型伯克利数据包过滤器 (eBPF)（适用于 Linux内核）等项目已简化剖析器的开发流程，为开发团队带来更高效的剖析体验。

开发团队可以使用跟踪、采样和仪器剖析，更深入、更细致地查看应用程序代码。剖析与可观测性的其他支柱结合运用时，还能提供针对应用性能的实时洞察分析，从而加快软件开发生命周期并帮助企业优化 DevOps 战略。