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