可观察性是2019年软件基础架构的主要趋势之一。
最近它引起了很多关注。
什么是可观察性？
关于这个词有很多讨论和笑话。 例如：
- 为什么称之为监控？ 那已经不够性感了。
- 可观察性，因为将Ops重命名为DevOps还不够糟糕，现在它们也正在大力发展监控功能。
- DevOps的新Chuck Norris。
- 我是一名工程师，可以帮助向组织中的其他工程师提供监视。
- >太好了，这是8万美元。
- 我是一名架构师，可以帮助为基于云的本地基于容器的应用程序提供可观察性。
- >太棒了！ 30万美元！
辛迪（Cindy Sridharan）如果有监视和可观察性之间的区别是什么？
回望...
多年前，我们主要在物理服务器上运行我们的软件。 我们的应用程序是基于LAMP或其他堆栈构建的整体。 检查正常运行时间就像发送常规ping并检查应用程序的CPU /磁盘使用情况一样简单。
范式转移
主要的范式转换来自基础架构和体系结构领域。 云架构，微服务，Kubernetes和不变的基础架构改变了公司构建和操作系统的方式。
由于采用了这些新思想，我们构建的系统变得越来越分散和短暂。
虚拟化，容器化和编排框架负责提供计算资源，处理故障会为硬件和网络创建抽象层。
从基础硬件和网络向抽象的转变意味着我们必须集中精力确保应用程序在业务流程的上下文中按预期工作。
什么是监控？
监视实际上是对操作的测试，而对软件开发则是测试。 实际上，测试通常会在沙盒环境中根据一组输入来检查系统组件的行为，这些输入通常带有大量模拟组件。
主要问题是生产中可能出现的问题数量无法以任何方式进行测试。 成熟，稳定的系统中的大多数问题都是未知的，未知的不仅与软件开发本身有关，而且与现实世界有关。
黑匣子vs. 白盒监控
有两种监视方法。
对于黑匣子监控，我们将系统或系统的一部分视为黑匣子，并在外部进行测试。 这可能意味着检查API调用，加载时间或系统不同部分的可用性。 在这种情况下，有关系统的信息量和对系统的控制是有限的。
白盒监视是指从系统内部获取信息的情况。 这不是一个革命性的想法，但最近引起了很多关注。
因此，“可观察性”只是白盒监视的另一个名称？ 不完全是
为什么我们需要一种新型的监控
通常，将监视与可观察性概念区分开，后者被定义为以某种方式收集有关基础架构/应用程序状态和性能跟踪的数据的东西（https://thenewstack.io/monitoring-and -可观察性-差异和原因-/。
或者，根据
honeycomb.io ：
- “您正在根据已知基准检查系统的状态和行为，以确定是否有异常现象。”
- “您可以编写Nagios支票来验证一堆东西是否在已知的良好阈值内。”
- “您可以使用Graphite或Ganglia来构建仪表板，以对有用的图形进行分组。”
- “所有这些都是了解系统未知信息的绝佳工具。”
诸如New Relic，HP和AppDynamics之类的大型产品生态系统已经得到了发展。 所有这些工具都非常适合于低级和中级监视或解决性能问题。
但是，它们不能处理对基数较高的数据的查询，并且在与第三方集成问题或大型复杂系统的行为（与在现代虚拟环境中工作的大量复杂系统有关）有关的情况下，它们的性能会很差。
为什么仪表板没用
实际上，事实并非如此。 但前提是您知道何时何地观看。 否则，最好观看YouTube。
仪表板无法缩放。
想象一下这样一种情况，您有许多与基础架构（例如，cpu_usage /磁盘配额）和应用程序（例如，JVMlocation_speed / GC Runs）等相关的指标。 这些指标的总数很容易增长到数千或数万。 您所有的仪表板均为绿色，但是第三方集成服务中出现问题。 仪表板仍为绿色，但最终用户已受到影响。
您决定将第三方集成服务检查添加到您的监控中，并在电视机上获得更多指标和仪表板。 直到出现下一种情况。
当被问及为什么客户无法打开网站时，响应通常如下所示：
仪表板的意大利化
虽然采用遥测系统的不同部分是一种常见的做法，但通常以在仪表板上绘制一堆意大利面条结束。
这些是GitLab向公众开放的操作指标。这只是整个仪表板大军的一小部分
看起来像挂毯，很容易丢失线程。
日志汇总
绝大多数现代IT公司都使用日志聚合工具，例如ELK Stack或Splunk。 这些工具对于根本原因分析或事后验验非常有用。 它们还可以用来监视某些情况，这些情况可以从日志流中得出。
但是，这是有代价的。 现代系统会生成大量的日志，而流量的增加可能会耗尽ELK资源或提高Splunk登月的费用。
有一些采样技术可以将所谓的无聊日志数量减少几个数量级，并保存所有异常日志。 它可以提供有关正常系统行为的高级概述，以及任何有问题的事件的详细视图。
从日志到事件模型
通常，日志行反映了系统中发生的事件。 例如，建立连接，认证，查询数据库等等。 执行所有阶段意味着一件工作已经完成。 定义事件是一项逻辑工作，可以看作是与特定服务相关的服务级别目标的一部分。 “服务”不仅指软件服务，还指某些物理设备，例如物联网领域的传感器或其他机械。
它也是领域驱动设计原则的非常补充。 服务或域之间的隔离和责任分担使得事件特定于系统每个部分中的每个工作。
例如，登录服务事件可以由具有自己的动态上下文的success_logins和failed_logins分隔。
指标和事件应围绕系统中的流程构建一个故事。
可以通过以下方式对事件进行采样：在正常系统行为的情况下，仅存储其中的一小部分，并按原样存储所有有问题的事件。 基于特定服务的目标，事件被汇总并存储为关键绩效指标。
它可以将服务目标指标及其相关的元数据整合在一起，从而在时刻基础上利用问题之间的联系。
考虑到高基数，此数据揭示了系统中的未知未知数。
这是一种软件工具形式吗？ 是的 但是，当您比较来自调试级别日志记录和完整仪器的数据量时，将日志拆分为事件可以在生产环境中从消防水带中饮用，而不会淹没数据和成本。
“将事件定义为一项工作可能被视为与特定服务的目标有关。”
为什么我们还没有准备好完整的AI解决方案
人工智能是吸引初创企业投资的好词汇。 但是，魔鬼总是存在于细节中。
1.重现性
完全基于机器学习的系统（所谓的完全AI方法）的问题在于，由于它不断学习新的行为，因此没有可重复性。 如果您想了解原因（例如，某种情况导致警报），则无法进行调查，因为模型已经更改。 任何依赖于不断学习行为的解决方案都会遇到这个问题。
当您使用高度细化的数据或指标进行操作时，优化系统本身是必不可少的，但如果没有可重复性，则很难做到这一点。
2.资源消耗
对于任何形式的持续机器学习，您都需要大量的计算资源。 通常，这采取批处理数据集的形式。 对于某些产品，处理200,000个指标的最低要求是v32CPU和64 Gb RAM。 如果要将指标数量增加一倍，则需要另一台满足相同要求的计算机。
3.您还不能扩展深度学习的完全自动化
根据Samreen Hassan Massak（尚未完全完成）撰写的硕士学位论文，数千个指标的训练过程需要数天的“ CPU时间价值或数小时的GPU时间价值”。 您无法扩展预算而不浪费预算。
4.速度
像Amazon Forecast这样的解决方案不能用作批量处理服务，以吸收数据并等待计算结束。
5.清晰度
根据Google的经验：
“最常捕获实际事件的规则应尽可能简单，可预测和可靠。”
landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems当模型或规则不断变化时，您会失去对系统的了解，它就像一个黑匣子。
异常=警报？
假设您有成千上万个指标，并且想要具有良好的可观察性，则需要收集高基数数据。 系统的每个脉动信号都会在您的指标群中产生统计波动。
https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy可以从Etsy的Kale项目中吸取的主要教训是：
关于度量标准异常的警报最终将导致大量警报和手动操作，并使用阈值和手工过滤器。
为什么我们需要流媒体方法
要获得可观察性并将未知未知数引起关注，就需要高度精细的数据，这些数据可以按数据中心，构建版本，服务，平台和传感器类型进行分类。 按任何组合聚合它们在本质上是组合的。
即使您精心设计了指标和事件，最终还是会得到大量的指标和事件。 当以这种规模实时运行时，常规查询或批处理作业将具有显着的延迟和开销。
需要考虑的事情
对无限数据流执行的任何操作都是一项工程上的努力。 您需要处理与分布式系统有关的问题。
在高层监视事件，服务级别目标或KPI时，您需要做出反应，而不是不断查询数据，而应在可水平扩展并实现大吞吐量和速度而又不消耗大量资源的流上进行操作。资源。
某些流框架（例如Apache Storm，Apache Flink和Apache Spark）面向元组处理，而不是直接进行时间序列处理。
分布式系统的语义也存在问题。
假设您在不同的数据中心中有很多部署。 您可能遇到网络问题，并且存储您的KPI指标的代理无法转发它们。 过了一会儿-假设3分钟-代理将该数据发送到系统。 并且此新信息应基于此条件触发操作。 我们是否应该将此数据窗口存储在内存中，并且不仅要检查条件，还要及时检查条件？ 这个不同步窗口应该有多大？ 实时处理数千个指标使这些问题变得非常重要。 对于流处理系统，您不能将所有内容存储在数据库中而不会降低速度。
分布式系统中时间序列数据的实时流分析非常棘手，因为与系统行为有关的事件可能是乱序的，并且基于此数据可能出现的条件取决于事件的顺序。 这意味着可以轻松实现至少一次语义，但是一次很难。
根据Google SRE工作簿的监控策略的理想功能
- “现代设计通常涉及分离收集和规则评估（使用Prometheus服务器之类的解决方案），长期时间序列存储（InfluxDB），警报汇总（Alertmanager）和仪表板（Grafana）。”
- “ Google的基于日志的系统处理大量的高粒度数据。 在事件发生和在日志中可见之间存在固有的延迟。 对于不敏感的分析，可以使用批处理系统处理这些日志，可以使用临时查询进行查询，还可以使用仪表板对其进行可视化。 该工作流程的一个示例是使用Cloud Dataflow处理日志，使用BigQuery进行临时查询，使用Data Studio进行仪表板。
- 相比之下，我们基于指标的监控系统从Google的每项服务中收集了大量指标，提供的粒度信息要少得多，但几乎是实时的。 这些特性在其他基于日志和基于指标的监视系统中是相当典型的，尽管存在例外，例如实时日志系统或高基数指标。”
- “在理想的情况下，监视和警报代码应遵循与代码开发相同的测试标准。 虽然Prometheus开发人员正在讨论开发用于监视的单元测试，但目前还没有广泛采用的系统可以让您执行此操作。”
- “在Google，我们使用特定于域的语言来测试我们的监视和警报，该语言允许我们创建综合时间序列。 然后，我们根据派生的时间序列中的值或特定警报的触发状态和标签存在来编写断言。”
慈善专业人士和Cindy Sridharan感到非常感谢
感谢Sigrid Maasen的帮助