Observability:了解可观察性的启蒙书
2022年6月12日 | by mebius
你会在 IT、开发人员和 SRE 角色中发现的一个确定性是,事情总是在变化! DevOps 社区中的一个热门话题是可观察性。 长话短说,你可能想知道它的真正含义以及如何将其添加到你的技能中。 这是一个快速入门,可帮助你走上可观察性之路。
“可观察性”一词从何而来?
可观察性的概念可以追溯到 20 世纪中叶,它最初用于控制理论中,用于描述如何从系统外部输出的知识中推断出系统的内部状态。 匈牙利裔美国电气工程师和数学家 Rudolf E. Kalman 在 1960 年代在几篇关于动态和可观测系统的开创性论文中创造了这个术语。
虽然该术语仍在数学环境中使用,但今天它通常用于基础设施、服务和现代软件应用程序堆栈的环境中。
什么是可观察性?
虽然可观察性是一个在多个学科中使用的术语,但在 IT 运营中,可观察性可以从你的基础架构和应用程序遥测数据中获得洞察力。可观察性有两个部分可以在你的组织中实施。
虽然软件通常带有功能需求,但也经常有非功能需求。 “可用性”、“可扩展性” 和 “可用性” 等概念。可观察性是一种非功能性要求,随着组织采用云技术而变得越来越必要,从而增加了运行时的复杂性。但是,基于日志、指标和跟踪组合的遥测数据可让你了解应用程序、服务和基础架构的执行情况。要真正了解你的应用程序生态系统正在发生什么,你的整个应用程序环境和组件应该是 “可观察的”,正如 60 年前最初的概念所定义的那样。
一旦生成遥测数据,拥有一个可聚合、关联和分析来自应用程序和基础设施的所有遥测数据的可观察性解决方案将为你带来全栈可观察性。可观察性平台是你用来评估和了解环境端到端性能的解决方案。但是,如果没有来自应用程序、服务和基础设施的遥测数据,就没有可观察性。可观察性解决方案为你提供实时和历史视角的可见性。
监控企业中的系统、应用程序和资产一直是 IT 团队的长期实践。团队通常希望密切关注他们最关键的环境,以了解系统是否按预期执行。这通常通过定义要从系统收集的数据点集合来实现,以了解系统运行的状态。指标可以指示故障或错误何时发生;然后工程师分析代码、数据和配置以了解和解决问题。
现代系统如何变得越来越复杂和动态,因为它们为客户解决了苛刻的问题。现代架构通常采用功能强大的方法来解决问题。例如,团队可以选择关系数据库来保存符合 ACID 的事务,同时利用 Elasticsearch 在同一数据集之上提供自由文本搜索功能。组件之间也相互分离,为团队提供了更好的扩展、升级和创新杠杆,而不会影响用户体验。例如,可以使用 Kafka 等消息队列/流平台处理从关系数据库到 Elasticsearch 的数据同步。这意味着保存交易数据的关系数据库可以独立于自由文本搜索组件而发展。
从本质上讲,通过在其架构中构建复杂性,企业可以提高开发人员的生产力、功能速度和创新能力,从而使他们能够代表客户提供卓越和更具竞争力的服务。 可观察性建立在标准监控实践的概念之上。 虽然监控功能会告诉你服务已关闭或处于错误状态,但可观察性功能允许团队通过询问数据问题来主动调试和理解错误,而无需预先定义调查所需的确切数据点。 能够观察你的环境需要深入了解业务的每个堆栈和层,并能够将相关事件和组件关联并拼接在一起。
为什么可观察性对现代 DevOps 很重要?
当数据中心和单片应用程序在地球上漫游时,生产变化很少发生,并且是经过彻底计划的。记录了外部依赖关系,并且可以通过监控一些众所周知的指标来确定整体应用程序的健康状况。随着公司越来越多地数字化和采用 Kubernetes 等云技术,它们大大增加了运行时的复杂性,使可观察性成为关键的 DevOps 计划。
由于当今现代应用程序的分布式特性,没有一个团队或个人能够全面了解所有依赖关系。遥测数据(指标、日志和跟踪)通常孤立在不同的工具中。由于转椅式调查,开发人员和运营团队花费过多时间对问题进行分类,从而导致平均检测时间 (MTTD) 和平均解决时间 (MTTR) 更高。为了解决这种日益增加的应用程序复杂性,你需要更多数据才能真正了解你的环境和用户体验。可观察性是通过从基础设施和应用程序遥测的角度以及可以整合、关联和分析当今云原生应用程序的现代分布式系统架构的性能的平台建立这种思维方式来解决这种复杂性的一种尝试。
可观察性可以为开发人员、DevOps、ITOps 和 SRE 团队解答哪些问题?
可观察性的好处因你所担任的角色而异:如果你从开发人员的角度看待它,那么你可能会以不同于从运营角度看待它的方式看待事物,从企业主的角度来看也会有差异。虽然不是一个详尽的列表,但这里有一些示例 IT 操作、开发人员和 DevOps 问题,你可以使用统一的可观察性解决方案来回答这些问题。
- 我的哪些服务不健康?
- 我们对给定操作的平均响应时间是多少?
- 是什么导致某些用户的加载时间比其他用户更长?
- 最新的更改如何造成延迟或影响应用程序性能?
- 与这项服务的 SLO 相比,我的表现如何?
- 我应该首先尝试调整哪个服务?
- 我的应用程序的整体用户体验是什么?
- 业务表现如何?例如我的电子商务应用程序中是否有太多的购物车遗弃?
通过实施强大的监控和可观察性,团队可以做到以下几点:
- 在涉及多个独立组件和服务的复杂架构中快速检测问题(中断、服务降级、错误等)(这称为平均检测时间,Mean Time to Detection)。
- 快速了解和调试影响您的环境的问题,从而减少解决中断所需的时间(平均解决时间,Mean Time to Resolution)。
- 了解环境中发生错误的前兆或领先指标,采用更加数据驱动的方法进行故障监控。
- 描绘环境不断变化的性质(例如了解更改或补丁发布的含义,或了解新的/不可预见的用户行为)。
观察系统时要考虑的三个主要方面是日志、指标及跟踪。
可观察性与监控有何不同?
监控允许你回答有关你的应用程序生态系统的简单问题,例如 “我的哪些服务器被过度使用?” 或 “哪些应用程序具有高响应时间或延迟?” 并且基于这样一个假设,即依赖关系被很好地理解,并且可以通过监控一些已知指标的变化来确定整体健康状况。这些针对服务器、虚拟机或应用程序服务的测量通常会错过显示特定组件如何与上游服务交互以及它如何影响下游用户体验的上下文。监控的重点是回答已知的未知数。
可观察性解决方案可以帮助你从遥测数据(指标、日志、跟踪)中提取更多信息——让你不仅可以查看分布式系统的内部状态,还可以帮助你发现未知的未知数:可能是你甚至不知道要寻找的错误。通过将元数据添加到你的指标、日志和跟踪中,你现在可以了解这些数据点的上下文以及与应用程序或用户事务相关的问题。例如,想象一个带有订单处理系统的流程:交易失败,但并非每笔交易都失败,这使得调试极具挑战性。如果你正在监控正确的指标,它可能会显示出问题并提醒你。但是,只有在监控指标并违反阈值时才可能通知问题,这在间歇性问题的情况下是极不可能的。在这种情况下,当用户抱怨时,通常可以做的调查很少。由于可观察性拥有所有遥测数据,因此运营团队可以提出问题,这将使相关问题发生关联,并发现在全球范围内,只有使用英镑付款的人会遇到麻烦。然后,这种操作洞察力直接导致识别货币 API 的问题。
投资可观察性计划使你能够以端到端的方式智能地对应用程序问题进行故障排除、诊断和关联,无论你的应用程序环境多么复杂。甚至可以回顾一下应用程序过去的表现与今天的表现。总体目标?分析所有遥测数据以进行交互式调查和可操作的见解的能力。
日志和指标如何在可观察性中发挥作用?
捕获和存储日志和指标通常是实现可观察性和基本监控的第一步。 指标和日志使你可以近乎实时地测量环境中基础架构(CPU、内存、I/O 指标)和应用程序技术的性能,以进行交互式调查。
你的所有日志记录和指标数据也是可观察性数据,你需要将其与其他上下文信息一起以正确的粒度存储在公共数据存储和公共模式中,以使你获得可观察性。 重要的是要考虑高基数和高维度,因为它对可观察性有意义。 对于任何可观察性计划,你都绝对需要日志记录和指标数据,但对于当今的现代云原生应用程序(无论是在 AWS、Azure 还是 Google Cloud 上)而言,仅靠它们是不够的。
应用程序性能监控 (APM) 和分布式跟踪为可观察性增加了什么?
虽然日志和指标提供了一些可见性,但添加分布式跟踪作为你的可观察性计划的一部分,扩展了你的诊断工具箱。通过分布式跟踪“监控应用程序性能” 可帮助你将事务拼接成一个逻辑集合(使用元数据),表示用户在服务或应用程序中的旅程。确保可预测的客户体验的良好开端。
通过检测你的应用程序和服务,你现在可以使用自定义元数据标记和跟踪遥测数据,以协助调试和故障排除。分布式跟踪和 APM 可帮助你了解应用程序中可能存在瓶颈或性能问题的位置,或者从用户的角度了解在线事务。tgcode添加机器学习和 AIOps 甚至可以让你自动发现异常和潜在问题,从而真正优化你的应用程序。
虽然 AtgcodePM 和分布式跟踪可以在事务或应用程序中为你提供帮助,但可观察性通过为你提供整个应用程序生态系统的可见性进一步扩大了范围。鉴于当今分布式软件架构和依赖(可能超额订阅)共享资源(存储、计算、内存、微服务、无服务器功能)的临时云环境的复杂性,这有助于你了解跨应用程序和服务的影响。
可观察性计划需要什么样的遥测数据?
为了使你的可观察性解决方案有效,你需要收集尽可能多的具有高维度和基数的数据——如果你没有数据维度,你将无法回答这些问题。日志、指标和跟踪通常被称为 “可观察性支柱”。捆绑这个庞大的遥测数据集合将是你添加的元数据/维度,以使这一切变得有意义。你添加的元数据对于你的应用程序、它的架构方式以及你希望如何分析它都是独一无二的。
与你将收集的 “遥测数据类型”几乎同样重要的是它的存储方式和存储时间。你始终可以删除不需要的数据,但事后将其添加回来要困难得多。这意味着你的可观察性解决方案将需要经济高效的存储来存储你生成的大量遥测数据,以你需要的粒度和你需要的时间范围内。你还需要能够以你想要的方式访问你的数据,以便进行快速灵活的分析和丰富的可视化。谨慎使用不允许你完全访问和使tgcode用标准化或开源工具(例如:OpenTelemetry)进行未来分析的可观察性数据存储。
什么是未知的未知数,为什么它们在可观察性领域很重要?
虽然监控适用于 “已知未知” 问题,但通常最难解决的问题是那些你甚至不知道要寻找的短暂且不常见的问题。它们可能是由于环境、应用程序或多种因素的变化而产生的。这些类型的问题巩固了以数据方式捕获任何事物的需求。了解和解决 “未知的未知数”。
具有统一且可扩展的数据存储的可观察性平台或解决方案不仅可以让你确定特定问题发生时发生的情况,还可以通过将不同的信号放入上下文中来帮助你了解意外事件何时发生需要进一步探索。这种回顾应用程序和基础设施性能历史的能力是可观察性平台与监控解决方案的关键区别。
可观察性如何帮助提高 IT 运营和开发团队的生产力并消除工具孤岛?
很多时候,组织开始需要日志聚合。他们启动并运行它,然后决定他们也应该开始从不断扩展的基础设施中收集指标,因此他们添加了另一个工具。使用 APM 再次重复此过程。不久之后,他们的应用程序生态系统拥有多种监控工具,以及已经孤立的数据存储,不同的群体可能拥有自己的工具。
虽然绝对可以使用孤立的工具对问题和错误进行分类和解决,但诊断问题的转椅方法(跨多个单一用途工具的故障排除)肯定会使它变得更加困难。你失去了可观察性解决方案提供的相关和上下文方面。还要记住,多个监控工具意味着开销的所有方面也成倍增加:管理、培训和存储,仅举几例。
将所有遥测数据存储在 “正确的可观察性解决方案”中的单个数据存储中,该解决方案可扩展并提供跨开发、阶段和生产的覆盖范围,这是理想的选择。通过正确的研究和调查,找到可让你以经济高效的方式检测和观察 IT 环境中的所有内容的可观察性解决方案是触手可及的。
结论
可观察性有很多方法,鉴于云和云原生技术的演变和采用,我们认为可观察性将继续以迅猛的速度向前发展。最终目标?使用所有遥测数据在你的应用程序环境中实现完整的端到端可观察性。能够从单个仪表板查看你的基础架构、应用程序以及最终用户体验。并且能够在任何时间点将遥测数据与你的特定需求相关联和上下文化,以进行根本原因分析和调试工作。
一个全面的可观察性平台将允许你监控日常应用程序性能、解决已知问题、优化应用程序,甚至发现你在环境发展时完全没有意识到的问题。随着你的 DevOps 团队继续采用更新的技术来加速创新、改善数字体验,从而加快上市时间,选择正确的可观察性平台将使你的能力和组织知识在未来得到长期证明。
如果你想了解更多关于 Elastic Stack 可观测性,请阅读文章 “Observability:Elastic 可观测性是什么?”。
文章来源于互联网:Observability:了解可观察性的启蒙书
相关推荐: Observability:在容器里运行 Elastic Agent – Elastic Stack 8.x
你可以在容器内运行 Elastic Agent — 使用 Fleet Server 或独立运行。 可从 Elastic Docker registry 获取所有版本的 Elastic Agent 的 Docker 映像。如果你想单独安装 Elastic Age…