译者|崔浩策划|YunZhao本文主要关注信息系统的可观察性，尤其是如何将可观察性应用到大规模信息系统中，使其在大规模分布式组织中产生奇效。什么是可观察性？根据维基百科：“通过系统的外部输出推断和测量系统的内部状态。在控制理论中，线性系统的可观察性和可控性在数学上是对偶的。”简单来说，可观察性就是通过外部输出来描述系统内部状态。可观察性的三大支柱1.指标数据传感器通过时间序列提供低延迟的快速反馈，反映系统性能指标。2.Trace通过跟踪数据的流向，找到错误发生的位置。3.日志以文本数据的方式描述低应用层发生的事件。从以上三点可以得出，系统的可观测性是从数据采集开始的。无论系统复杂还是简单，数据收集都是分析和行动的基础。如何让系统可观察在分布式、云计算和微服务的世界里，让系统可观察是非常困难的。从用户交互的角度分析系统时，实施可观察性变得更加容易。用户在面对系统时应该知道系统的运行状态：好还是坏，工作还是不工作，运行成功还是失败？现实世界中有很多例子也可以验证这一点，比如每天都会经历的事情：你今天感觉怎么样？你可以去上班吗？你的车准备好了吗？我们并没有真正考虑这些事情，因为它们只是自然发生的。但是，如果要在系统中回答这些问题，就需要指标来支持。例如，要知道我们是否健康，我们需要测量温度、压力并提供血液分析结果。要判断汽车是否准备就绪，您需要查看控制面板是否正常工作。假设系统中有很多组件，系统的整体状态就是各个组件状态的聚合（所有组件状态的二元相乘就是这种聚合的结果）。收集指标、日志和跟踪数据如果上述假设成立，了解系统的整体状态需要从每个组件收集指标。同时，还需要知道历史状态以及状态在时间间隔内的变化情况。为了实现这个目标，意味着需要不断地从组件中收集状态数据。一旦你有了这些指标数据，你就可以构建漂亮的仪表板视图。Nginxingresscontrollerdashboard炫酷的dashboard会让领导觉得你的工作很有意义，那么需要哪些指标来说明系统的状态呢？同时，如何从众多指标中筛选出对用户体验和业务运营至关重要的指标？主要指标查看一些可能成为主要指标的数据，如KPI、衡量数据等，我们发现接下来的三个指标尤为重要，因为它们直接影响用户体验和业务运营。1.错误率是表明事情没有按预期进行的主要指标。当用户的请求未成功响应时，通常会出现错误率。2、响应时间是指从用户提出请求到得到反馈的时间。3.资源利用率表示资源分配和闲置情况，如内存、CPU、磁盘等资源的利用率，可以表示系统在没有外部帮助的情况下的工作时间。第四大支柱：事件毫无疑问，仪表盘确实是一个很好的监控工具，但是我们需要时刻关注它吗？虽然您可以这样做，但这并不是测试系统的最有效方法。我们可以很容易地检测到系统的一举一动，并让指标工具在应用程序不健康时通知您：这些是“事件”。首先，需要从指标输出中发现并定义系统的不良状态。这时候可以关注系统在极端条件下（高负载下）的行为。可以使用JMeter或者Gatling等工具在测试环境中模拟高负载，达到观察的效果。通过这种方式，您可以更好地了解应用程序的功能以及哪些指标对系统至关重要。然后您可以为这些指标设置自动警报。警报是一个强大的工具，因为我们不必一直监视仪表板，我们只在需要时才打开它们。这让我开始思考人体如何处理问题，我们从不关注身体的某个部位并确保它们正常工作。相反，如果一切顺利，这些身体部位就会正常运作，如果出现问题，大脑就会收到疼痛信号。这种疼痛信号就像是系统的报警通知，提醒我们身体的某个部位出现了问题。问题事件的订阅和提醒市面上的系统监控工具比较成熟，支持email、Slack、webhook等方式发送告警信息。并且可以通过配置将告警信息发送给管理员、用户、操作员，实现责任到人。另一种告警方式是通过HTTPwebhook将告警事件发送到专门的可观察性服务，让该服务执行下一步，例如灾难恢复、ML训练或通知其他相关服务。注意：使用警报将提高资源利用率并自动化系统的整体控制。告警结构说完事件告警，再说说告警信息的结构：告警信息到底包括什么？在这里我们可以从用户的角度寻找答案。一般来说，发生告警后，是运营商或开发商去解决问题。因此，告警信息的内容需要帮助了解问题的严重程度、原因和范围，以协助上述人员解决问题。(1)Severity表示资源所处的状态，从而定义采取行动的重要性：服务面临饥饿，即不采取行动将无法工作。这个指标甚至可以在用户抱怨响应时间和错误之前帮助避免问题。(2)描述用于指出警告/错误消息所指示的问题的可能原因。包括traceId将有助于从现有监控工具中获取更多信息。(3)位置区域、集群、应用程序或组件名称标识问题发生的位置和爆炸半径。(4)爆炸半径爆炸半径是一个军事名词，但是用在现实生活中却没有违和感。定义问题的范围并将警报事件路由到正确的团队，而爆炸半径有助于识别受影响的应用程序、团队和组件。这样报警信息就不会发送给范围外的团队，避免分散其他团队的注意力，让团队知道报警的范围是严格定义的，所以当收到报警的团队会增加他们的参与并专注于解决问题。动作着重于如何解决告警事件中包含的问题。需要在此处提供有价值的线索和文档以帮助解决问题。例如：某些问题可能需要手动操作，无法通过应用程序代码或配置更改来修复。例如，一个偶尔重复出现的问题可能已经发生过很多次，SRE团队已经知道如何解决它。这些知识应记录在产品中（即生产事件日志）并存档，并在成员之间共享。添加与解决问题相关的文档作为对警报消息的引用将有助于有效地解决问题。Tracetrace的目的是为了快速找到问题发生的地方。使用Jaeger、Honeycomb的Zipkin等工具快速识别组件、应用程序名称，甚至准确的方法调用。日志记录日志记录可能是程序员开创的第一个可观察性技术，作为一种通过查找有关程序错误和故障的详细信息来解决问题的方法。应用内发生的所有事件都以文本或JSON的形式存储在日志文件中，可以通过日志工具查询，如Splunk、ElasticSearch，其中全文搜索引擎有助于关键词查询。它还包含有关问题的详细信息，以及在问题发生的最后的可观察点，工程师可以从中找到解决问题的答案。远程调试技术也可以在没有日志帮助的情况下使用，但这是另一个话题，超出了本文的范围。总结尽管可观察性在系统中并不作为一个功能存在，但它起着非常重要的作用。可观察性的好坏将直接影响用户体验。良好的可观察性可以快速反馈系统的运行状态，提前发现并通知潜在问题，甚至在用户面对问题之前。没有良好的可观察性作为基础，当系统出现问题时，再采取任何补救措施都是徒劳的。因为当用户面临系统问题时，他们可能已经用脚投票选择使用其他服务和产品。因此，有必要提高系统的可观察性，以便能够为用户创造更好的产品和服务。原文链接：https://dzone.com/articles/systems-observability-1译者介绍崔浩，社区编辑，资深架构师，18年软件开发和架构经验，10年分布式架构经验。他曾经是惠普的技术专家。乐于分享，撰写了多篇阅读量超过60万的热门技术文章。《分布式架构原理与实践》作者。最新一期科技精选月《CTO悟道》现已上线！更多精彩技术干货、知识和见解等你来揭晓，下载链接：https://www.51cto.com/journalDetail/5.html?down=3
