Hello folks，我是 Luga，今天我们来分享一下与云原生体系有关的话题- 云原生可观测性-Observability。 作为一个“核心”体系，可观测性在监控分布式微服务应用程序和云基础设施的可见性和控制自动化层面具有举足轻重的意义。
— 01 —
Observability-可观测性概述
在过去的几年里，可观察性一直备受关注。在越来越多的公司转向基于微服务的架构后，它一直是一个流行语，但随着协调这些微服务的复杂性增加，组织发现在生产中和生产后进行监控和故障排除变得更加困难。
随着分布式系统架构变得更加复杂，跟踪和响应多云环境中的问题，更具挑战性。当应用程序或服务的数量在这些庞大的多云环境中达到某个临界点时，我们将无法追踪哪些运行在何处以及它们的性能如何。持续检查这些海量高速数据流以识别生产中的已知和未知问题显得至关重要。这正是可观测性和监控发挥作用的时候，对于IT、运营、QA 和 SRE 团队来说，可观察性提供了一个有用的解决方案，可以充分了解其多样化和复杂系统的每个组件。
根据 Gartner 关于软件交付世界变化速度的预测，“到 2024 年，实施分布式系统架构的企业中有 30% 将采用可观测性技术来提高数字业务服务性能，而 2020 年这一比例还不到 10%。”
同时，随着 Kubernetes 容器云编排平台的驱动下，软件系统正在向复杂的云原生、开源和基于微服务的结构进行革命性转变。软件系统已成为任何组织的组成部分。随着组织的发展，软件系统也在发展并在本质上变得更加复杂。随着多个组件在分布式系统中执行任务时发挥作用，监控系统变得更加困难。监控系统涉及查看系统的健康状况、识别应用程序问题、跟踪请求的完整端到端流程等。不同的组件可能有不同种类的监控工具和警报机制来监控、发现、识别和调试任何问题。
— 02 —
Observability-可观测性与 Monitor-监控
可观测性和监控听起来有些相似，但其实往往并不是一回事。尽管可观测性和监控通常可以互换使用，但它们并不是对等的。当某些事情运行不正常时，监控会通知您，而可观测性则可以帮助我们找出问题本质所在。
监控和可观测性存在于一种共生关系中，两者密不可分。事实上，实现可见性以发现异常并确定它们对我们的服务的影响远远超出了人类的能力。可以在不观察的情况下进行监控，但这会大大削弱我们快速分析和解决问题的能力。
当我们对系统进行更多更改时，更有可能发生混乱。监控和可观测性工具确保我们可以在开发速度提高时保持操作稳定性。系统的可观测性取决于：
1、系统的简单性
2、性能指标的表示
3、监控工具识别正确指标的能力
通常，具体来说，监控是观察系统随时间推移的性能的行为。监控工具收集和分析系统数据并将其转化为可操作的见解。从根本上说，应用程序性能监控 (APM)等监控技术可以告诉我们系统是运行还是关闭，或者应用程序性能是否存在问题。监控数据聚合和关联还可以帮助您对系统做出更大的推断。例如，加载时间可以告诉开发人员一些关于网站或应用程序用户体验的信息。
另一方面，可观测性衡量系统的内部状态可以从其外部输出的知识中推断出来的程度。它使用监控产生的数据和见解来全面了解我们的业务系统，包括其运行状况和性能。那么，系统的可观测性部分取决于我们所设定的监控指标对系统性能指标的解释能力。
另一个重要的区别是监控要求我们提前知道监控的重点。而可观测性则让我们可以通过观察系统在一段时间内的表现并提出相关问题来确定什么是重要的。
— 03 —
Observability-可观测性 3 大支柱
图示：Observability-可观测性3大支柱
Log - 日志
Log - 日志是指应用程序在运行某些代码行时生成的结构化和非结构化文本行。日志记录应用程序内的事件，可用于发现错误或系统异常。它们提供了几乎每个系统组件的各种详细信息。日志通过创建输出使可观察性过程成为可能，该输出允许开发人员通过简单地分析日志并识别错误或安全警报的来源来排除代码故障。
通常来讲，日志主要包含如下三种格式，具体：
1、纯文本
2、结构化的
3、二进制
在实际的业务场景活动中，纯文本是最常见的，但结构化日志，包括额外的数据和元数据并且更容易查询正变得越来越流行。当系统出现问题时，日志通常也是我们首先挖掘的地方。
通常而言，所输出的日志是能够表明系统中是否发生了某些异常事件。大多数时间日志都有一个时间戳、一个指示器（类似于信息、警告、错误等），以及一条解释实际发生情况的消息等。
Metrics - 指标
Metrics - 指标以数字方式表示说明应用程序随时间运行的数据。它们由一系列属性组成，例如名称、标签、值和显示有关系统整体性能和可能发生的任何事件的信息的时间戳。
与日志不同，指标不记录具体事件，而是返回代表应用程序整体性能的值。在 DevOps 中，指标可用于评估产品在整个开发过程中的性能并识别任何潜在问题。此外，指标是可观察性的理想选择，因为它很容易识别从各种数据点收集的模式，以创建应用程序性能的完整画面。
与日志和跟踪的区别在于，Metrics - 指标总是描述一段时间内发生的事情（例如，以 60 秒为间隔），而日志和跟踪可以准确地告诉我们事情发生的时间（例如，从 12:03:47.326 开始并于 12:03:47.811 结束）。另一方面，收集和分析指标往往比日志和跟踪需要耗费的成本高的多。
Tracing - 追踪
虽然日志和指标提供了足够的信息来了解单个系统的行为，但它们很少提供足够的信息来阐明位于分布式系统中的请求的生命周期。这就是 Tracing - 跟踪的用武之地。Tracing - 跟踪表示请求通过所有分布式系统节点的过程。
实施 Tracing - 跟踪可以更轻松地分析和观察系统。通过分析跟踪提供的数据，您的团队可以评估整个系统的总体健康状况，定位和解决问题，发现瓶颈，并选择哪些区域具有高价值及其优化优先级。
Tracing - 跟踪会告诉我们单个请求的整个链路归宿，从外部请求到达所构建的外部 API 的那一刻起，通过跨服务、数据库调用和消息代理的所有跳转，直到将响应发送回客户端。
在实际的业务场景中，Tracing -跟踪的“分布式”部分来自于这样一个事实：即这些跨度可以（并且通常会）由不同的应用程序在不同的服务器上生成，然后所有这些跨度被收集并拼接在一起以显示整个跟踪。
— 04 —
Observability-可观测性能够带来哪些收益？
基于实际的业务场景而言，可观测性通常为最终用户、企业和 IT 团队提供了显着的优势，具体如下：
1、应用程序性能监控
完整的端到端可观察性使企业能够更快地识别性能问题，即使是那些由云原生和微服务架构带来的问题。使用高级可观察性解决方案可以自动执行更多任务，这将提高 Ops 和 Apps 团队的生产力和创造力。
2、DevSecOps 和 SRE
可观测性是应用程序和支持它的基础架构的基本特征，而不仅仅是实施创新工具的结果。软件的设计者和开发者必须让它易于观察。然后，在软件交付生命周期中，DevSecOps和 SRE 团队可以使用和理解可观察到的数据来创建更强大、更安全、更具弹性的应用程序。
3、监控基础设施、云和 Kubernetes
使用可观测性的几个好处之一是它有助于基础设施监控。它使基础架构和运营 (I&O) 团队可以利用可观察性解决方案提供的改进上下文来增加应用程序的正常运行时间和性能，减少识别和修复问题所需的时间，检测云延迟问题并优化资源利用率以改进管理他们的 Kubernetes 环境和现代云架构。
4、最终用户体验
积极的用户体验可以明显提高企业的声誉和效益，赋予其市场竞争优势。公司可以通过在最终用户发现问题之前识别和解决问题并在他们提出要求之前实施改进来提高客户满意度和保留率，从而赢得市场及行业地位。
— 05 —
如何实施 Observability-可观测？
要实现可观测性，最为核心的要素莫过于建立自己的可观测性平台模型，基于模型所定义，创建自己的工具、利用开源软件或购买营利性可观察性解决方案来创建可观测系统。
基于不同企业各自业务特性以及组织架构实际情况，可观测性模型的建立往往千差万别，但终归逃不过以如下几个关键步骤：
1、确定预期的业务目标
通过减少基础架构支出、支持增长容量规划或提高关键业务 KPI（例如平均恢复时间），强大的可观察性配置可以帮助增加底线收入。通过为支持人员提供额外的上下文数据，它可以提高透明度甚至创造积极的客户体验。但是，这些目标中的每一个的可观察性配置可能非常不同。创建可观察性策略以在确定主要业务目标后实现它们。
2、关注正确的指标
设计良好的可观察性方法不是在问题出现时对其做出响应，而是使人们能够预测可能的错误或故障的开始，然后查明其根本原因的位置。追求透明度涉及多个数据收集和分析过程以及其他监控和测试技术。
3、事件日志
对于架构和开发团队，事件日志提供了有关分布式系统可观察性的重要数据源。为事件日志设计的工具，如 Prometheus、Middleware 和 Splunk，捕获和存储事件。这些事件可能包括应用程序的成功结束、重大系统故障、意外停机或导致过载的流量涌入。因为它为开发人员提供了重要的取证信息以发现有缺陷的组件或有问题的组件交互，这对于调试和错误处理尤为重要。
- 4、可访问的数据可视化
当团队成功收集可观察性数据时，必须将其压缩为可用和可共享的格式。这通常是通过使用各种工具对数据进行可视化表示来实现的。从那里，团队成员可以传播或与从事该计划的其他团队共享该信息。
5、选择合适的可观察平台
通常，我们在选择或建设合适的可观测平台时，可参考以下因素；
– 工具是否免费？
– 此工具是否使用开源代理 ？
– 是否具备利用该工具的技术知识？
– 此工具可以处理的数据规模？
综上所述，尽管 Log-日志、Mertics-指标以及 Tracing-跟踪在本质上是独一无二的并且有不同的目的，但它们仍然能够相互补充。当一起使用时，能够最大限度地提供对整个分布式系统的深刻见解，从而帮助帮助团队构建更好的系统。
