简介：一篇文章了解观察！
作者：Xijie＆Bai Yan
可以将系统的观察结果和故障分析为系统操作和维护中的重要措施。随着系统，资源单元，资源获取方法和通信方法的发展，系统遇到了巨大的挑战。这些挑战还迫使运营和维护相关技术的发展。在今天的官方开始之前，让我们谈谈过去的过去和当前观察的生活。在整个操作和维护监控的整个开发过程中，监测和观察已经开发了近30年。
在1990年代末，随着计算的逐渐从大型机传输到台式计算机，客户服务器架构的应用开始占上风，每个人都开始关注网络性能和主机资源。此CS是第一个代APM软件。在此期间，操作和维护团队专注于网络性能和主机性能，因为此时的应用程序体系结构仍然非常简单。这次，我们还说这些工具正在监视工具。
在2000年，Internet开发了迅速，并且浏览器已成为新的用户界面。实现Evolution已成为基于浏览器APP-DB的三层体系结构。同时，Java作为企业级软件的第一种编程语言开始占上风。到处编写和运行的概念（写一次，在任何地方运行）大大提高了。但是，代码的生产力，Java虚拟机还阻止了代码操作的详细信息，使调谐行错误更加困难。（应用程序性能监控）。
在2005年之后，分布式应用程序已成为许多公司的首选，例如基于SOA的建筑和ESB应用程序。在同一时间，虚拟化技术逐渐占上风，传统服务器的物理单位已逐渐稀释，并且已经变得逐渐稀释一个无形且无形的虚拟资源模型。诸如消息队列和高速缓存之类的组件也开始应用于生产环境中。在这样的技术环境中，新一代的APM软件诞生了。企业开始跟踪完整的链接，同时监视虚拟资源和三个组件监视，这将得出新一代APM的核心功能。
2010年之后，随着云本机架构开始实现，应用程序体系结构开始逐渐从单个系统变为微服务，并且它们的业务逻辑成为微服务之间的呼叫和请求。在同一时间，虚拟化更加彻底。容器管理平台已被越来越多的企业接受，三方组件逐渐发展为云服务。整个应用程序体系结构已成为云本机架构。服务的通话路径变得更长，无法控制地使流量的方向发展，并且故障检测的难度需要新的观察能力。通过各种可观察的数据，涵盖了完整的解决方案）对测试和维护开发的整个应用寿命过程的持续分析。
可以看出，观察能力已成为本地基础架构。整个观察能力已经从简单的操作和维护状态演变为测试开发状态。Observatory的目的也从支持业务的正常运作到加速业务创新，进一步扩展，允许企业迅速迭代。
从上述过程中，我们可以看到，从监视到APM到观察是一个连续进化的过程。下一步，让我们谈谈这三个过程之间的特定关系。对于更好的解释，在这里介绍了经典的认知模型。世界，我们通常会根据“意识”和“了解”的两个维度对它们进行分割，即“感知”和“理解”。
好吧，首先，我们称之为我们知道和理解的事实。刚刚讨论的主题中，此部分与监视相对应。例如，当操作和维护工作时，服务器的CPU利用率将从开始。这种利用率是一个客观的事实，无论是80％还是90％。这是对监视的解决方法，也就是说，基于知道要监视的内容，制定相应的指标并建立监视市场。
接下来，我们知道但不了解。收集和分析主机上的申请性能。发现在应用程序链接呼叫过程中，高delay日志框架已导致主机上的CPU利用率飙升。这是通过应用程序层分析通过应用程序层分析高利用CPU的原因。
然后，我们了解的是，但我们不知道。它仍然是CPU高利用率的情况。如果通过学习历史数据和相关事件，CPU利用率将在一定时间飙升，则可以实现预警。
最后，我们不知道和理解。这仍然是上述示例。如果CPU的使用是通过监视飙升，则通过APM.发现应用程序日志框架，但是如果分析了此期间用户的访问数据，则发现在上海地区，在上海地区，访问请求通过Apple终端比响应时间高10倍。大量信息日志使某些机器的CPU飙升。这是一个可观察的过程。观察性是解决您不知道的事物（Apple终端访问上海）您不理解（错误的配置日志框架会产生大量信息日志）
总而言之，我们注意监测领域中的指标。这些指标可能关注基础架构层，例如机器和网络的性能指标。APM基于基于应用程序的链接，内存和线程诊断工具，以找到监视索引异常的根本原因。
天文台集中在申请上。通过校正和分析各种可观察到的数据源，例如日志，链接，指标和事件，根本原因更快，直接找到。并提供一个观察到的接口，使用户可以灵活且自由地探索和分析这些观察数据。同时开放了观察能力和云服务，并将实时增强弹性扩展和高可用性。发现问题时，它可以更快地解决相关问题并恢复应用程序服务。
虽然观察能力带来了巨大的业务价值，但它也带来了许多系统构建挑战。这不仅是工具或技术的选择，而且是操作和维护的概念。这包括可观察到的可观察的收集，分析和价值输出数据。
目前，在行业中广泛实施的可观察到的数据包含三个支柱：记录，跟踪（跟踪）和指标监视（指标）。有一些普遍的需要关注。
1）完整的堆栈覆盖范围
基本层，容器层，上面的云服务应用程序，用户终端的相应观察数据以及相应的指标，链接和事件需要收集。
2）统一标准
整个行业都在提高统一标准。首先，指标（指标）和Prometheus已成立了共识，作为本地时代的指标数据标准；尽管数据水平较低，但很难构成数据标准，但是开源新秀（例如Fluentd），例如Fluentd，，Loki也出现在集合，存储和分析方面。另一方面，Grafana的显示标准也越来越清楚。
3）数据质量
作为数据质量的重要组成部分，一方面，需要通过数据标准来定义不同监视系统的数据源，以确保分析的准确性。另一方面，相同的事件可能会导致大型事件重复指标，警报，日志等的数量。通过过滤，降噪和聚集，分析具有分析值的数据以确保数据质量的重要部分。这通常是开源工具和商业化工具之间的差距相对较高的地方大。规则等都决定了可观察到的数据收集的质量。
1）
在当前的观察系统中，应用程序是一个很好的分析角度。首先，应用程序和应用程序是互连的，您可以通过调用链条进行连接。这包括如何在微服务，使用云服务的应用程序之间进行调用以及如何调用要调用可以通过链接关联的三部曲。在同一时间，应用程序也可以用容器层和资源层垂直映射。用于应用程序的中心，当通过水平垂直和垂直方向形成全局可观察的数据。需要找到问题，可以从应用的角度进行统一分析。
2）分区知识
面对大量数据，如何更快，更准确地找到问题。在应用程序中心数据关联外，还需要了解问题的分析领域。对于可观察的工具或产品，最多的是重要的是要连续积累最佳的调查路径，常见的问题定位以及决策链接的根本原因，并巩固相关的经验。这相当于配备经验丰富的操作和维护工程师，用于操作和维护团队，以快速发现问题并定位原因。这也与传统的AIOPS能力不同。
1）统一显示
上述观察结果需要每个级别的覆盖率，并且每层都有相应的观察数据。但是，当前对相关工具的观察非常分散。如何统一这些工具生成的数据已成为一个巨大的挑战。实际上，观察到的数据的统一性相对困难，包括格式，编码规则，字典值和其他问题。当前的主流解决方案是使用Grafana建立统一的监测市场。
2）协作治疗
在统一的显示和统一警报之后，如何使用钉子和公司微信等协作平台来寻找并处理跟踪图表的效率，它逐渐变得需要。
3）云服务联系
天文台已成为云的基础架构。当发现和找到观察平台时，它需要快速与各种云服务链接，以快速扩大容量或负载平衡，以更快地解决问题。
得益于Yun本地开源生态学的蓬勃发展，我们可以轻松构建一个监视系统，例如使用Prometheus + Grafana来构建基本监控，使用Skywalking或Jaeger构建跟踪系统，并使用Elk或Loki来构建日志系统。但是，对于操作和维护团队，不同类型的可观察数据在不同的后端分散了。调查问题仍然需要在多个系统之间跳跃，并且不能保证效率。基于上述，阿里巴巴云还为企业提供了一个停滞的观察平台武器（实际 - 时间监控服务）。作为产品家族，武器，在不同的观察方案中包含各种产品，例如：
上面提到的是，ARMS作为一个停机产品具有很多功能。在目前，该企业的建造类似于ARMS或ARME中的某些产品，例如应用程序监控和前端监视。系统对企业仍然很重要，并希望建立一个基于开源的观察系统，该系统基于开源。在下一个示例中，我们关注Prometheus + Grafana如何构建可观察到的系统。
在武器中，我们可以快速建立格拉法纳的独家例子。可以非常方便地同步武器Prometheus，SLS日志服务和CMS云监控数据源，以快速查看相应的数据源。虽然快速访问各种数据源，但应减少每日数据源管理的工作量，尽量减少尽可能多地减少可能的。
数据完成后，Grafana将自动创建相应的数据市场。进行应用程序监视和容器监视，默认情况下将提供基本数据，例如黄金指示器和接口更改。
可以看出，尽管Grafana帮助每个人都构建了各种数据，但他们看到的仍然分散了。在日常操作和维护过程中，还必须根据应用程序根据业务领域或应用程序创建一个统一的大型磁盘。本质
在建立完整堆栈的统一磁盘时，我们会根据用户体验，应用程序性能，容器层，云服务以及基础资源的尺寸进行准备。
1）用户体验监视
通用PV，UV数据，JS错误率，首先渲染时间，API请求成功率，TOPN页面性能和其他关键数据将尽快提供。
2）应用程序性能监控
以黄金指示灯为代表的数量，错误率和响应时间，并根据不同的应用程序和不同的服务区分。
3）容器层监视
每个POD的性能和用法还列出了这些应用程序创建的部门。这些与部署相关的POD性能信息在本文中介绍。
4）云服务监视
此外，这是相关的云服务监视。这是一个示例的消息队列Kafka。相关数据指标通常与消息服务有关，例如消费积累和消费量。
5）监视节点监视
对于整个主机节点，CPU，POD运行等数据。
这样，这个更广泛的市场涵盖了用户体验层的整体性能监视到基础架构容器层的应用程序层。更重要的是，整个市场都包含所有相关数据。削减了一定的服务后，性能是与服务相关的数据将独立显示。在不同级别（例如容器，应用程序和云服务）中进行填充。当监视Prometheus以收集这些云服务时，它将由云服务中的标签收集。通过标记标签，可以根据不同的业务维度或不同的应用程序来区分这些云服务。当我们进行统一的市场时，我们肯定会遇到许多数据源管理问题。我们提供了全球视图功能，以将此用户名下的所有Prometheus实例汇总在一起，并统一查询。这是应用程序层或云服务信息的信息。
在上述场景中，我们告诉砖块吸引可观察平台的设计方向：基于系统和服务观察的观点，后端的不同数据融合分析，而不是故意强调系统的三个数据的分离支持观察。和互动逻辑以阻止指标的分离，跟踪，记录。建立一个完整的观察闭环，在事故发生前发现异常，事故发生事故发生后事故后未能在事故发生后主动警告，并提供集成的平台，以进行连续监测业务和优化服务绩效。（来源：阿里巴巴云）