玩转分布式架构下的可观测性

Posted 2023-04-02 BJ_Bonree

可观测性背景

云原生可观测性是从传统软件监控及数据分析可视化工具中，总结出在云原生领域中，从底层容器基础设施、通用技术组件到业务应用系统全链路监控运维、运营治理等产品化体系化的能力诉求。

可观测性是云原生技术架构的重要特征，确切的体现了云原生的核心理念，自提出就被广泛的认可

实现可观测性需要什么能力？

可观测性的三大支柱Metrics、Trace、Log (指标、链路、日志)：

 当前，在Metrics与logging方面基于原有技术架构有众多较为成熟的解决方案，如聚焦于Metrics的Prometheus+、聚焦于logging的ELK解决方案。但是对于tracing的解决方案，多种多样，如开源的skywalking、jaeger等。

使用开源产品面临的问题有哪些？

由于tracing的解决方案无论从底层技术门槛还是使用者自身业务复杂度都相对较高，采用免费开源的产品在实际使用中会遇到各种问题，如：

采集端探针性能损耗过大，影响现有业务；

需独立配置数据存储，数据量大，成本高；

使用者业务架构不能百分百兼容适配，需二次开发；

....

基于以上原因，使用者更倾向于选择更加成熟的解决方案

Bonree Server通过嵌入Smartagent探针，自动识别后端服务，通过业务拓扑、应用拓扑清晰展现调用逻辑关系，概览系统全局。全面实时获取服务端性能数据，通过应用、组件、集群、容器及代码等逐层深入分析，最终从代码层和环境层帮助企业定位分析自身服务端性能问题，提高云原生服务可观测性。

功能优势

1、分布式链路检索和分析

通过代码级调用跟踪技术，自动绘制服务拓扑，通过traceID和业务数据检索调用链，快速定位慢调用、慢方法、慢SQL和错误调用、方法异常。

 2、拓扑自动发现

支持在系统、应用、服务、接口、实例等各级别进行监控分析。自动拓扑发现，上下游的影响依赖一目了然。

 3、智能告警

通过智能的时序数据异常检测和预测发现问题，可灵活定义告警策略、告警通知渠道。

 4、主机和实例监控

 5、灵活配置

服务和接口识别、自定义热点方法、参数采集、健康度、黑白名单等灵活配置

 

Splunk深度专题：疫情下的可观测

#写在前面#

近日疫情反扑，沪深两大一线城市领衔进入严格管控状态，无数企业被迫全员居家办公，时空交错的运维“新常态”下，IT系统的可观测性精细化深度需求再度成为DevOps领域的“热度话题”。优维专家组结合多年实践经验和国际观点，为大家带来国际最前沿的可观测性深度解析，希望大家能够从价值、技术等多个层面获得一些认知和思考。

---

可观测性，是通过分析系统输出的外部数据来衡量系统运行状态的能力。

如果仅使用外部数据就可以评估运行状态，则系统被认为是“可观测的”。虽然该术语最近流行起来，但该术语其实起源于几十年前的控制理论（自我调节系统的描述和解释），最近它是越来越多地被应用在如何提高分布式 IT 系统的性能方面。在分布式IT系统中，可观测性使用三种类型的监控数据——指标、日志和跟踪——来实现系统的可观测能力，借助可观测能力团队能够找到众多问题的根本原因并优化系统性能。

最近，众多企业，例如AWS，以微服务，无服务或容器技术的形态实现了云原生基础设施架构。这些分布式系统中，事件溯源涉及到公有云，私有云或混合云中的数千个进程，因而传统的监控技术和工具很难准确的跟踪通信链路和相互间的依赖。

团队可以利用可观测性更有效地监控系统，发现和关联处于复杂关系链中的事件，从而追溯到根本原因。此外，系统管理员、IT 运营分析师和开发人员能够利用可观测性了解系统的整个架构。

在本文中，我们将仔细研究可观测性：可观测性的定义、怎么实现可观测性以及团队能从可观测性中获得什么？

01监控和可观测性有什么区别？

监控和可观测性是相互依赖的不同概念。监控是您为提高系统的可观测性而执行的一项操作。可观测性是该系统的属性，如功能或可测试性。

具体来说，监控是随着时间的推移观察系统性能的行为。监控工具收集和分析系统数据，并将其转化为可操作的经验。从根本上说，应用程序性能监控 (APM)等监控技术可以告诉您系统是正常还是宕机，或者应用程序性能是否存在问题。

对监控数据的聚合和关联还可以帮助您对系统做出更大的推断，例如，页面加载时间可以告诉开发人员有关网站或应用程序的用户体验的信息。

而可观测性是根据系统输出的外部数据来推断系统内部状态的一种方式。它使用监控产生的数据和经验来全面了解您的系统，包括其运行状况和性能。因此，系统的可观测性部分取决于监控指标能否很好的解释系统的性能。

另一个重要的区别是监控要求您预先知道重点监控什么。而可观测性让您可以通过观察系统随时间的变化来提出相关问题，从而得出结论什么是最重要的，需要被监控。

02为什么可观测性很重要？

可观测性之所以重要是因为您可以通过它更好地控制复杂系统。简单系统的运行模块较少，比较容易维护，通常通过监控 CPU、内存、数据库和网络状况就足以了解系统并解决部分线上问题。

分布式系统的互连组件数量要多得多，因此可能发生的故障数量和类型也更多。此外，分布式系统不断变更，每次更改都可能产生新的故障类型。在分布式环境中，理解正在发生的问题是一项巨大的挑战，主要是因为它比简单的系统产生更多的“不知道不知道”。由于传统监控需要“知道不知道”，因此通常无法充分解决这些复杂环境中的问题。

可观测性更适合分布式系统的不可预测性，主要是因为它允许您在问题出现时询问有关系统行为的问题。例如：“为什么X坏了？” 或“现在是什么导致延迟？” ，这些都是可观测性可以回答的问题。

03什么是容器和微服务中的可观测性？

容器和微服务中的可观测性暴露了线上应用程序的状态，所以开发人员可以更好地识别和解决性能问题。

容器服务（例如 Docker、Kubernetes 等）和微服务解决了与日俱增的业务中断风险，以及和巨石架构相关的问题：单个代码库的变更会影响整个应用程序及其依赖。容器和微服务将应用程序分解为独立的服务，允许开发人员修改和重新部署特定服务而不是整个应用程序。

然而，基于容器的架构带来了新的挑战。相互依赖的微服务通常分散在多个主机上，随着基础设施的扩展，线上的微服务数量也会增加。这使得开发人员很难知道线上正在运行什么，从而导致交付周期延长、宕机时间增长等问题。

可观测性解决了这些挑战，提供对分布式系统的可见性。开发人员可以利用可观测性更好地了解应用程序的性能和可用性。在发生故障时，它提供了快速发现、调试或修复问题所需的控制能力。

04可观测性中使用的主要数据是什么？如何使用？

可观测性中使用的主要数据是日志、指标和跟踪。它们通常被称为“可观测性的三大支柱”。

日志：日志是在特定时间发生的事件的文本记录，包括事件发生的时间戳和上下文相关的有效信息。日志有三种格式：纯文本、结构化和二进制。纯文本是最常见的，但结构化日志——包括额外的数据和元数据，更容易查询——正变得越来越流行。当系统出现问题时，日志通常也是最先要被查看的。

指标：指标是在一段时间内测量的数值，包括时间戳、名称、KPI 和值等属性。与日志不同，指标默认是结构化的，这使得查询和存储优化变得更加容易，也可以保存更长时间。

跟踪：一个跟踪表示某请求通过分布式系统的端到端旅程。当请求通过主机时，在其上执行的操作称为“跨度”，每个跨度的编码里都包含了微服务执行操作时的重要信息。一个跟踪都包含一个或多个跨度。您可以通过跟踪查看请求通过分布式系统的全过程，从而确定性能瓶颈或故障的原因。

当系统使用多种工具生成三类数据，或者三类数据相互独立的被运用，并不能实现系统的可观测性。只有在一个完整解决方案中融合了日志、指标和跟踪数据，才能真正实现系统的可观测性，也只有这样，团队才可以利用可观测性了解问题何时发生，以及很快聚焦于分析问题为什么会发生。

05如何实现可观测性？

为了实现可观测性，需要利用合适的系统或工具来收集数据。不论你是自研，使用开源软件或购买商业可观测性解决方案，通常都需要涉及四个组件：

探针：这些探针从容器、服务、应用程序、主机和系统的任何其他组件采集数据，从而实现整个基础架构的可见性。

数据融合：对数据进行处理和关联，创建事件相关的上下文，以及为了实现时序可视化而必须具备的自动化或定制化的数据治理能力。

事件响应：自动化技术。基于事件处理流程和技术经验为相关人员还原中断现场数据。

AiOps：机器学习模型用于自动聚合、关联事件数据并确定其优先级，使您能够过滤掉告警噪音，检测可能影响系统的问题并在发生事件时加快事件响应速度。

06好的可观测性工具的标准是什么？

无论您选择构建自己的解决方案还是使用开源或商业解决方案，所有可观测性工具都应该：

系统集成：如果您的可观测性工具不适用于您当前的技术栈，您的可观测性工作将会失败。确保它们支持您的环境、容器平台、消息中间件和任何其他关键软件中的框架和语言。

对用户友好：如果您的可观测性工具难以学习或使用，它们将不会被添加到工作流中——这会让您的可观测性计划止步。

提供实时数据：您的可观测性工具应通过仪表板、报表和实时查询提供重要信息，以便团队能够了解问题及其影响以及如何解决。

支持先进事件处理技术：高效的可观测性工具能够从您的堆栈、技术和操作环境中收集所有与事件相关的信息，并提炼有价值的内容，为事件添加足够的上下文以便团队可以快速解决问题。

聚合数据的可视化：可观测性工具应以易于理解的格式显示内部状态，例如仪表板、交互式摘要和其他让用户快速理解的可视化方式。

提供上下文：当事件发生时，应能提供足够的上下文做支撑，以便您了解系统性能是如何随时间而变化的、发生变化的性能指标之间是否有关联、问题的范围以及受影响服务或组件之间的相互依赖关系。如果可观测性没有提供这种级别的上下文，事件响应就会瘫痪。

使用机器学习：应包括自动处理和管理数据的机器学习模型，以便更快地对异常和安全事件进行预测和响应。

交付业务价值：务必根据重要业务指标（例如部署速度、系统稳定性和客户体验）来评估可观测性工具。

07DevOps 中的可观测性有什么好处？

可观测性允许 DevOps 开发人员在任何时间了解应用程序的内部状态，并可以获取分布式环境中系统故障的更准确信息。主要好处如下：

●更好的可见性：庞大的分布式系统通常使开发人员很难了解线上的服务、应用程序的性能是否能够满足当前业务量、某项服务的相关责任人或系统在最近一次部署之前的样子。可观测性使他们能够实时了解线上系统，从而消除这些障碍。

●更好的告警：可观测性帮助开发人员更快地发现和修复问题，提供更深入的可见性，使他们能够快速确定系统中发生了什么变化，调试修复问题，并确定这些变化可能会引起的问题。

●更好的工作流程：可观测性允许开发人员查看请求的端到端旅程，以及有关特定问题的相关上下文数据，从而简化应用程序的研究和调试过程，优化其性能。

●更少的会议时间：过去，开发人员通过三方公司或应用程序记录下谁负责特定服务或系统在最近部署前几天或几周的样子。通过有效的可观测性，这些信息很容易获得。

●加快开发人员速度：可观测性使监控和故障排除更加高效，消除了开发人员的主要摩擦点。结果是交付速度加快，DevOps 员工有更多时间提出创新想法，以满足业务及其客户的需求。

08可观测性在软件工程中的好处是什么？

与 DevOps 一样，可观测性通过提供对整个基础架构的洞察力而使软件工程师受益，使他们能够看到它是如何因问题、部署新软件或业务规模扩大或缩小而发生变化的。

谁从可观测性中受益？

开发人员和软件工程师受益于可观测性，因为它提供了对其整个架构的可见性，包括第三方和自己研发的应用程序或服务。这不仅使他们能够更轻松地修复并最终预防问题，还有助于更好地了解系统性能以及它如何塑造更好的客户体验。然后，开发人员和工程师都有更多的时间来制定有利于业务的战略计划。

团队也受益，因为可观测性提供了环境的共享视图，随着时间的推移提供了对其架构、健康状况和性能的更全面的理解。可观测性使得开发人员、操作员、工程师、分析师、项目经理和其他团队成员对有关服务、客户和其他系统元素的达成一致认识。此外，可观测性可以创建更准确的事后审查，因为相关人员可以检查实时系统行为的书面记录，而不是将来自孤立的、单独的来源的事件拼凑在一起。数据 - 而不是意见 - 将帮助您的团队了解事件发生的原因，以便他们能够更好地预防和处理未来的事件。

最后，对业务的收益最大。可观测性允许您在不影响系统稳定性的情况下对应用程序和服务进行更改，方法是为您提供工具来了解哪些工作正常，哪些不工作，查明出现的任何问题并快速改进或解决它们。新功能与更少的宕机时间相结合，转化为更快乐的客户和更稳健的底线。

09底线：深入了解您的基础架构

可观测性不仅仅是一个流行词——它是了解整个基础架构状态的重要且有用的方法。云、容器化、微服务和其他技术使系统比以往任何时候都更加复杂。虽然这些技术的最终结果是积极的，但系统的故障排除和管理却充满了困难。更多的交互会导致更多的问题，当它们发生时，更难检测和修复。

幸运的是，这些分布式系统产生了大量的监控数据，如果您可以利用它，可以更清楚地了解它们的性能。有效的可观测性工具具备数据采集和上下文还原的能力，并为您提供适应现代分布式系统的持续发展所需的洞察力。