一流的常州网站优化,十大必做调查网站,集成装修全屋定制,国外建筑公司网站系统可观测性(1)基础概念(Log/Tracing/Metrics) Author: Once Day Date: 2025年2月8日 一位热衷于Linux学习和开发的菜鸟#xff0c;试图谱写一场冒险之旅#xff0c;也许终点只是一场白日梦… 漫漫长路#xff0c;有人对你微笑过嘛… 全系列文章可参考专栏: 十年代码训练… 系统可观测性(1)基础概念(Log/Tracing/Metrics) Author: Once Day Date: 2025年2月8日 一位热衷于Linux学习和开发的菜鸟试图谱写一场冒险之旅也许终点只是一场白日梦… 漫漫长路有人对你微笑过嘛… 全系列文章可参考专栏: 十年代码训练_Once-Day的博客-CSDN博客 参考文章: 分布式系统可观测性之应用业务指标监控 - 掘金 blog-cn/observability-of-distributed-system.md at master · pingcap/blog-cn · GitHub 可观测性和监控概览 | Documentation | Google Cloud What Is Observability? What is OpenTelemetry? | OpenTelemetry 分布式系统可观测性(Observability)系列: Distributed Tracing(一) - 知乎 Metrics, tracing, and logging - Peter Bourgon Observability: the hard parts - Peter Bourgon Google SRE - Site reliability engineering book Google index 文章目录 系统可观测性(1)基础概念(Log/Tracing/Metrics)1. 引言2. 三大支柱(Metrics/Tracing/Logging)3. 可观测性与监控4. 可观测性与运维5. 可观测性项目(OpenTelemetry) 1. 引言
2017年的分布式追踪峰会(2017 Distributed Tracing Summit)结束后Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》系统地阐述了这三者的定义、特征以及它们之间的关系与差异。 文中将可观测性问题映射到了如何处理指标(metrics)、追踪(tracing)、日志(logging)三类数据上。
可观测性(Observability)是近年来在IT领域特别是云原生应用和分布式系统中备受关注的话题。它源于控制论是一个系统能够提供其内部状态信息的能力。这种能力让运维和开发人员能够从外部观察系统的内部工作状态快速检测、定位和解决问题保障系统的稳定运行。
可观测性可以解决什么问题Google SRE Book 第十二章给出了简洁明快的答案快速排障。
在传统的单体应用时代系统通常没那么复杂通过日志分析和监控工具基本可以满足排障需求。但随着架构向微服务和云原生方向演进系统变得高度分布式和动态错综复杂的服务调用链路给问题定位带来巨大挑战。同时开发迭代和业务变化越来越快传统的日志和监控方式难以跟上变化节奏。可观测性应运而生。
可观测性通常由3大支柱组成:
指标(Metrics)系统的各种可度量指标数据例如请求数、延迟、错误率、资源使用等。通常从系统各处收集汇总供聚合分析和可视化。日志(Logging)各种离散的事件记录包括应用日志、审计日志等。需要收集、存储、检索和分析海量的半结构化日志数据。分布式跟踪(Distributed Tracing)记录跨度多个服务的请求执行路径、时间戳等数据。利用这些数据可以发现服务间调用的瓶颈和异常评估系统性能。 上图引用自Metrics, tracing, and logging - Peter Bourgon。 将这三种数据有机结合可以全面地洞察系统行为快速发现和定位问题根源做出相应优化。市面上出现了很多可观测性相关的开源和商业产品例如:
指标监控和警报Prometheus、Grafana、Datadog等。日志管理ELK Stack、Splunk等。分布式跟踪Jaeger、Zipkin、SkyWalking等。
以下是一些关于可观测性原理的推荐书籍和在线资源: 《Distributed Systems Observability》 - Cindy Sridharan著。这是关于可观测性的权威著作系统全面地介绍了可观测性的概念、工具链、最佳实践等。 《Prometheus: Up Running》 - Brian Brazil著。Prometheus是一个广泛使用的开源监控系统,本书详细介绍了如何使用Prometheus进行系统监控和告警。 《Mastering Distributed Tracing》 - Yuri Shkuro著。分布式追踪是可观测性的重要手段,本书深入剖析了分布式追踪的原理和实践。 《Database Reliability Engineering》- Laine Campbell Charity Majors合著。本书讨论了如何对数据库系统进行可靠性设计,可观测性是其中的重要内容。 OpenTelemetry官方文档https://opentelemetry.io/docs/OpenTelemetry 是一个新兴的开源可观测性框架提供了一致的API、SDK等以实现metrics、logs、traces的标准化采集。官网包含了详尽的概念和使用文档。
2. 三大支柱(Metrics/Tracing/Logging)
1指标(Metrics)是对系统某些属性(如请求持续时间、资源利用率等)的数值化表示通常是时间序列数据。Metrics适合用于显示系统的整体健康状况和行为趋势。
关键特征可聚合性即一段时间内可以组合成单个逻辑gauge(计量器)、counter(计数器)或histogram(直方图)。
一些例子队列的当前深度可以建模为gauge更新遵循last-writer-wins(后写入者胜出)语义进行聚合。传入的HTTP请求数可以建模为counter通过简单的加法进行聚合更新。请求的观测持续时间可以建模为histogram更新聚合到各个时间桶中生成统计汇总信息。
2日志(Logging)Logging是以结构化或非结构化的文本形式记录离散的事件。Logging适合用于记录specific domain的事件供事后审计、分析、排障等。
定义特征处理离散的事件。
一些例子应用程序的调试或错误信息通过旋转文件、syslog发送到Elasticsearch(或OK Log)。审计跟踪事件通过Kafka推送到像BigTable这样的数据湖。从服务调用中提取特定请求的元数据发送到像NewRelic这样的错误跟踪服务。
3分布式追踪(Tracing)Tracing记录了一个请求在分布式系统中的端到端路径包括经过的所有服务、每个服务内部的关键操作等。Tracing适合用于理解系统的行为优化性能瓶颈定位异常请求的根因。
定义特征处理请求范围内(request-scoped)的信息即任何可以绑定到系统中单个事务对象生命周期的数据或元数据。
一些例子对远程服务的出站RPC调用的持续时间发送到数据库的实际SQL查询的文本入站HTTP请求的关联ID。
综上三者的侧重点各不相同
指标(Metrics)强调可聚合性用于生成统计信息和图表。日志(Logging)强调离散事件用于记录独立的消息。追踪(Tracing)强调请求上下文信息用于分析和优化分布式系统性能。
同时它们又是相辅相成的指标和追踪数据常常带有一定程度的离散性日志经过聚合也可以生成统计信息。 上图引用自Metrics, tracing, and logging - Peter Bourgon。 虽然在故障定位过程中大部分检测目标与请求或者流量有关但这并不意味着所有检测目标数据都要与追踪上下文生命周期绑定。例如进程的CPU和内存使用率队列的缓存数量和延迟等。因此并非所有指标或日志都适合硬塞进追踪(Tracing)系统这也能避免额外的工作资源消耗。
直接在应用程序中统计指标(Metrics)更有好处可以根据设备或者集群的实时视图进行健康状态评估。相比之下如果将指标(Metrics)硬塞进日志管道可能会迫使我们放弃其中一些优势(灵活性和快速迭代能力)。
在三个领域中指标往往需要最少的资源来管理因为就其性质而言它们的压缩效果相当好。相反日志记录往往非常繁琐其数量往往超过其所报告的生产流量。
因此可以绘制出一种数量或操作开销梯度从指标(低)到日志(高)而追踪可能处于中间位置。
3. 可观测性与监控
可观测性(Observability)是指基于系统暴露的外部数据来理解系统内部发生的情况的能力。通过收集系统运行时的表层数据而不是拆开系统来暴露其内部状态就可以充分理解一个可观测的系统。 举个例子假设房间的灯突然无法打开了。其中一种解决办法就是把墙壁撬开跟踪电线直到找到问题的根源。但这种方法既耗时又把家里破坏的不成样子。而更有效的方法是收集电表系统的可见数据或者灯附近的其他电器的状态。如果数据足够观测那么足以引导找到问题的根源。 在IT系统中可观测性意味着能够根据从复杂环境表面收集的信息来解释环境的内部状态。表层数据包括软件和基础设施日志、跟踪和指标以及CI/CD管道或服务台等互补系统的数据。
为什么在现代复杂的分布式系统中需要可观测性(Observability) 复杂系统本质上是不完全健康和不可预测的。无法预测系统每个部分可能出现的所有故障状态。因此从设计到操作的每个阶段都必须考虑到失败和易于调试。可观测性可以在系统设计时作为一种特性纳入以应对这种不可预测性。 通过可观测性系统可以先在真实环境中测试后再构建。在测试过程中就可以发现一旦部署后会导致警报的失效模式这有助于在问题影响生产环境之前发现和解决问题。 可观测性允许系统增量部署。如果关键指标偏离基线就可以触发回滚。这确保了系统可以在出现问题时快速恢复将影响降到最低。 运行时的可观测性可以报告足够多的关于系统健康和行为的数据点有效反映其内部状态。这使得系统能够被更好地理解、调试和发展这对于复杂的分布式系统至关重要。
Observability的目标则是提供关于无法被监控或者被测试的不可预测的故障和异常的信息。Monitoring的目标是监控可预测的故障和异常并生成警报。
简而言之Monitoring监控的是已知的故障而Observability观测的是未知的故障。 上图引用自What is observability? 监控(Monitoring)是驱动可观测性的一个过程但可观测性远不止监控。监控只告诉你表面发生了什么而可观测性利用数据深入内部获得对系统的理解。监控类似检查脉搏可观测性类似做核磁共振。
可见性(Visibility)是通往可观测性的一步但还不够。可见性意味着孤立地了解系统的离散部分而可观测性通过关联数据提供对整个系统的理解。
可观测性的程度可以用系统可以被调试的程度来衡量。调试通常是一个迭代过程从高级指标开始通过系统各组件报告的各种细粒度上下文进行深入研究正确排除并验证理论是否成立。对于分布式系统调试需要的是证据而不是猜测或假设。
可观测性(Observability)不是灵丹妙药并不能让人们摒弃思考行为它主要是通过数据引导开发人员思考并找到答案。
4. 可观测性与运维
Google SRE(Site Reliability Engineering)手册是Google工程师多年实践经验的结晶是一本关于如何运行和管理大规模分布式系统的宝典。这本书涵盖了SRE工作的方方面面从基本原则到具体实践为我们展示了Google如何确保其服务的可靠性、可维护性和可扩展性。
这本书的核心价值在于它提供了一套完整的、经过实践检验的方法论用于管理现代复杂的分布式系统。它强调以工程的方式来解决运维问题主张通过自动化、数据驱动和持续改进来提高系统的可靠性。同时它也强调人的因素讨论了如何建立良好的工作文化和实践如何在团队中建立共识和协作。
在这些理念中可观测性是一个重要的主题。尽管书中并未明确使用可观测性这个词但其中许多讨论都与可观测性的理念紧密相关。
首先书中强调全面和有效的监控是管理分布式系统的基础。没有对系统行为的深入洞察就无法实现可靠的运维。Google SRE手册详细介绍了Google的监控实践包括如何选择监控指标如何设计监控系统如何设置合理的警报等。这些都是建立可观测性的基础。
其次书中提倡白盒监控即对系统内部的关键指标进行监控而不仅仅依赖于黑盒监控。这与可观测性的理念高度一致。可观测性要求我们不仅要知道系统是否正常工作还要知道为什么需要对系统内部有深入的理解。
再次书中讨论了如何设置SLO和SLI如何建立事件响应机制如何进行混沌工程实验等。这些实践都有助于提高系统的可观测性使我们能够更快地发现问题更准确地定位根因更有效地进行故障处理。
《SRE Book》自2016年发布以来影响了无数企业的可靠性实践。Google也在持续更新这本书的内容目前已发布了第二版《The Site Reliability Workbook》进一步扩展了相关主题。
5. 可观测性项目(OpenTelemetry)
OpenTelemetry是一个开源的、独立于供应商的遥测数据收集和管理框架,旨在帮助实现系统的可观测性。它为创建和管理追踪、指标和日志等遥测数据提供了一套标准化的工具和API。
OpenTelemetry是由OpenTracing和OpenCensus这两个项目合并而成的目标是成为可观测性领域的标准。
OpenTelemetry与供应商和工具无关可以与多种开源和商业的可观测性后端兼容如Jaeger、Prometheus等避免了供应商锁定。OpenTelemetry关注遥测数据的生成、收集、管理和输出让用户能够轻松地监测应用程序或系统而无需考虑其语言、基础设施或运行时环境。遥测数据的存储和可视化则交由其他工具处理。
OpenTelemetry主要由以下几部分组成:
一套规范定义了所有组件的标准。一个标准协议定义了遥测数据的格式。语义约定定义了常见遥测数据类型的标准命名方案。API定义了如何生成遥测数据。SDK实现了规范、API和遥测数据的输出。工具生态系统为常见库和框架提供了检测功能。自动检测组件无需更改代码即可生成遥测数据。OpenTelemetry Collector一个接收、处理和输出遥测数据的代理。
OpenTelemetry的一大特点是高度可扩展。例如可以为Collector添加自定义数据源的接收器为SDK加载自定义检测库为特定用例定制SDK或Collector发行版为不支持OpenTelemetry协议(OTLP)的自定义后端创建新的输出器以及为非标准上下文传播格式创建自定义传播器等。虽然大多数用户可能不需要扩展OpenTelemetry但该项目在几乎每一层都提供了扩展的可能性。
OpenTelemetry是云原生计算基金会(CNCF)的一个项目由OpenTracing和OpenCensus两个先前的项目合并而成。这两个项目都旨在解决代码检测和将遥测数据发送到可观测性后端方面缺乏标准的问题。由于任何一个项目都无法独立完全解决这个问题它们合并成立了OpenTelemetry结合了各自的优势提供了一个统一的解决方案。 Once Day 也信美人终作土不堪幽梦太匆匆...... 如果这篇文章为您带来了帮助或启发不妨点个赞和关注再加上一个小小的收藏⭐ (◕‿◕)感谢您的阅读与支持~~~
