看分布式系统
我们系统中的一个现实是，事情会失败——微小的变化可能会导致许多意想不到的结果，包括影响所有客户的全球中断和故障。这是复杂系统的现实。
这篇博文的出现是因为我需要将我读到的关于可观察性的内容拼凑起来。我提前说这不会是一个非常深入的主题，但如果你对这个主题感兴趣，我强烈建议你阅读参考资料=）
2001 年 Microsoft 运营框架 (MOF) 研究（看看它是多久以前）发现，高绩效公司使用严格的方法来解决问题，雇用 遥测 在生产中以了解可能的促成因素，从而专注于解决问题。
早在 2015 年的 DevOps 报告状态中，我们就有一个“启示”，在这份报告中，我们清楚地表明，高性能公司可以比同行更快地解决生产事件，使用版本控制和 遥测 与主动监控一起实现 MTTR 快速地。
知道 遥测 非常重要，让我们从我们的主题开始，以了解它适合的地方。
什么是可观察性？
根据控制理论，可观察性是一种度量，它描述了一个系统的状态可以从其外部输出的知识中推断出的程度。可观察性和可控性是源自数学和工程的概念，涉及系统的创建和维护。
使用微服务，由于上下文的复杂性，很难实现可观察性。无论是在数据中心还是在云中，为了实现卓越运营和满足业务目标，您都需要了解和改进系统的性能。可观察性解决方案使您能够收集和分析应用程序和基础架构数据，以便您了解它们的内部状态并收到警报、排除故障并解决应用程序可用性和性能问题，从而改善最终用户体验。
监控 == 可观察性？
单词之间存在细微但相关的差异 监视 这是一个动词，你做的事情和 可观察性 这是一个名词，一个系统的属性，也就是说，我们可以说一个系统的可观察性是我们可以从它的输出中了解这个系统的内部状态的程度。
另一方面，监控是我们所做的事情。我们监控系统。我们观察。
可观察性支柱
记录（日志）
事件日志是随时间发生的离散事件的不可变时间戳记录。事件日志通常有 3 种形式，但它们基本相同：时间戳和某些上下文的有效负载。这三种 3 形式是：文本、结构化和二进制。
指标
度量是按时间间隔测量的数据的数字表示。由于数字针对存储、处理、压缩和检索进行了优化，因此指标允许更长的数据保留时间以及更轻松的查询。这使得指标非常适合构建反映历史趋势的仪表板。
追踪
跟踪（或跟踪）是一系列分布式的、因果相关的事件的表示，这些事件对通过分布式系统的端到端请求流进行编码。
我们需要的
日志聚合
您应该将日志聚合工具的实现视为实现微服务架构的先决条件。
一种有用的方法是在日志中使用相关 ID
日志是从系统中获取信息的一种简单易用的好方法，但随着微服务和请求的增多，最终会生成大量数据。
指标聚合
与查看来自不同地方的日志的挑战一样，我们需要找到更好的方法来收集和可视化来自我们系统的数据。
分布式追踪
基本上，微服务架构是一组协同工作以执行某种任务的进程，因此，当我们想要了解我们的系统在生产环境中的实际行为时，我们应该能够看到它们之间的关系。我们的微服务。在这里我强烈建议研究 开放遥测 （以前称为 OpenTracing）。
SLA 是 SLO
SLA 是创建系统的人和使用它的人之间的协议。
SLO 定义了团队致力于提供什么，因此实现 SLO 就是满足 SLA 的要求，以一种简单的方式，我们可以将 slo 视为团队为达到其 SLA 需要做的事情。您可以更深入地研究这个主题。 这里 .
警报
警报是问题 .我们需要通知某人以便采取行动。微服务环境中的挑战是准确地弄清楚 什么样的问题会导致一个人在凌晨三点被叫醒。 您可以更深入地研究这个主题。 这里 .
语义监控
在语义监控中，我们为系统中可接受的语义定义了一个模型。我们的目标不仅仅是确保我们正在生成 遥测 围绕应用程序的运行状况，还衡量我们实现组织目标的程度。系统必须具备哪些属性才能让我们认为它以可接受的平均值工作？在很大程度上，语义监控需要改变我们的行为。 我们需要不断地问这个问题，而不是检查错误：系统的行为是否符合我们的预期？ 可能有帮助的问题示例：
- 新客户可以注册吗？
- 我们是否以正常费率运送订单？
最大的挑战之一是就该模型的外观达成共识。我们怎么看， 我们不是在谈论诸如“CPU 使用率不应超过 95%”之类的低端问题； 我们正在对我们的系统进行高级别的声明。这是产品负责人应该介入的时候——但作为操作员，确保与产品负责人的讨论真正发生可能是你的工作。
将创建指标作为日常工作的一部分
您需要每个人都轻松创建指标。为此，我们必须拥有必要的基础设施和库，以使某人尽可能轻松地为任何功能创建遥测。通过将生产遥测技术作为我们日常工作的一部分，我们不仅能够在问题发生时及时发现问题，而且能够设计我们的工作，以便及早发现设计和运营中的问题。
识别症状和原因
您的监控系统必须解决两个问题：什么坏了，为什么？ “坏了”表示症状； “为什么”表示一个（可能是中间的）原因，例如：
- 我的回答很慢，这是一种症状，能够导致某些银行的 CPU 过载。
监视症状的优点之一是它们是持久的，这意味着无论底层系统架构如何变化，如果系统停止正常工作，即使不更新系统，您也会收到适当的警报。
监测标准
为如何监控微服务设定一个标准（这里我不是在谈论 SLI）。有一些可以作为起点，它们是：
担心你的尾巴
区分缓慢的平均请求和非常缓慢的请求“尾部”的最简单方法是收集按延迟分组的请求计数（适用于呈现直方图），而不是实际延迟：在 0ms 和 10ms ms 之间花费了多少请求， 10 毫秒到 30 毫秒之间，30 毫秒到 100 毫秒之间，100 毫秒到 300 毫秒之间，等等？将直方图阈值大致呈指数分布（在本例中为大约 3 倍）通常是可视化请求分布的一种简单方法。
结论
正如我们所看到的，我们应该考虑很多方面。您需要确保您可以使用这些信息来询问有关您的系统的问题。 您能自信地说系统对您的用户正常运行吗？ 随着时间的推移，有必要收集更多信息并改进工具以提高应用程序的可观察性。
分布式系统理解起来可能很复杂，它们越分散，解决这种性质产生的问题就越困难。随着您的微服务架构变得越来越复杂，知道如何预测可能发生的问题将变得更加困难。因此，必须改变您的思维方式，远离主要是监控活动的活动，并朝着使您的系统更易于观察的方向发展。
强烈考虑采用基于这些规则的 SLO 和警报，以减少警报疲劳并让您的注意力集中在适当的焦点上。一定要投资于企业级遥测、应用程序、基础设施、客户端软件（前端）、部署管道……
最重要的是，它是关于接受在系统到达生产环境之前并不是所有的事情都是已知的。提高你应对未知的能力
参考
[1] https://en.wikipedia.org/wiki/Observability
现场可靠性工作手册（第 2 章）
现场可靠性工程（第 6 章）
DevOps 手册（第 14 章）
构建微服务：设计细粒度系统（第 10 章）
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/7626/30320108
标签：请求,系统,监控,分布式系统,日志,观察,我们 From： https://www.cnblogs.com/amboke/p/16645212.html