本文来自微信公众号“twt企业IT社区”。
数据中心运维管理当中，往往系统管理员、存储管理员各有各的运维数据视图。无论是分析故障还是搞性能优化都不能以某个维度的线索数据将各个视图串联起来，不仅效率低下，而且非常被动。本议题在于探讨用开源工具将各个视图整合的意义以及思路。
【栏目主编】赵海某金融系统高级主管：本议题由咪咕视频软件架构师李杰及我本人发表针对议题下关键点的主张，几位专家的主张在方正人寿技术经理李小平、民生银行数据库架构师孔再华及我本人等多位专家的复议后，形成了一定的共识，希望可以对同行有一定的参考。
李杰 咪咕视频软件架构师：
实现统一的可观测性需要一个集中的平台，能够整合不同来源的数据，并提供一致的视图和工具，以便开发和运营团队更好地进行分析和决策。许多公司正在采用跨平台的可观测性解决方案，提高可观测性水平和效率。
随着分布式系统架构变得越来越复杂，跟踪和解决多云环境中的问题变得更具挑战性。当应用程序或服务的数量在庞大的多云环境中达到某个临界点时，我们将难以追踪它们的位置和性能。因此，持续监测海量高速数据流，以便及时识别生产中已知和未知的问题变得至关重要。这就是可观测性和监控的作用所在。对于IT、运营、QA和SRE团队来说，可观测性提供了一个有用的解决方案，可以全面了解多样化和复杂系统的每个组件。
同时，随着Kubernetes容器云编排平台的推动，软件系统正在经历一场革命性的变革，朝着复杂的云原生、开源和基于微服务的结构发展。软件系统已经成为组织的核心组成部分。随着组织的发展，软件系统也变得更加复杂。在分布式系统中，多个组件同时发挥作用，因此监控系统变得更加困难。监控系统的任务包括查看系统的健康状况、识别应用程序问题、跟踪请求的端到端流程等。不同的组件可能使用不同类型的监控工具和警报机制来监测、发现、识别和调试问题。
因此，基于实际的业务场景，如何能够设计一款全方位一体化的全链路监控架构，获取应用数据的纵向视图，并且支撑性能分析便显得尤为重要。
下一代的可观测性平台体系的规划及建设，需要满足如下核心原则，具体如下：
一、统一的可观测性
实现统一的可观测性是首要问题。传统公司通常声称拥有统一的可观测平台，但实际上只是提供了多个选项卡来访问指标、日志、跟踪等数据，无法真正解决问题。开发和运营团队需要一个能够在单个时间线上查看所有数据的中心化平台。只有这样，他们才能追踪相关性，确定问题的根本原因，并快速解决问题。因此，实现统一的可观测性需要一个集中的平台，能够整合不同来源的数据，并提供一致的视图和工具，以便开发和运营团队更好地进行分析和决策。许多公司正在采用跨平台的可观测性解决方案，提高可观测性水平和效率。
二、与供应商无关（OTel）
许多公司寻求不依赖于单一供应商的解决方案，以避免被限制在特定技术栈或供应商的生态系统中。为此，许多科技公司正在为开放遥测（OTel）做出贡献，并将其作为数据收集代理的首选工具。OTel具有互操作性、灵活性和改进的性能监控等诸多优势。使用OTel，公司可以更轻松地集成不同的工具和服务，并在不同的平台上收集和分析数据，无需担心供应商锁定或技术限制。因此，OTel在实现供应商无关的可观测性方面起着重要作用，并将在未来继续发挥重要角色。
三、预测型可观测性
在人工智能时代，自动化和无人化已经成为技术发展的趋势。这使得系统能够完成人类无法完成的任务，例如通过机器学习在错误发生之前预测错误。然而，目前的可观测性解决方案并没有充分利用人工智能技术，这需要更多创新。通过在可观测性平台中添加人工智能层，企业可以在问题发生之前预测问题，并在用户或客户知晓问题之前解决问题。这将有助于提高服务和产品质量，并增强企业的声誉和竞争力。因此，未来的可观测性解决方案需要更多地集成人工智能技术，以实现预测性可观测性。这将需要更多的数据和算法支持，以建立准确的模型和预测系统，并为企业提供更好的决策支持和业务洞察。
四、成本最优化模式
成本优化是可观测性领域面临的关键挑战。尽管云存储成本不断降低，但大多数可观测性公司并没有相应地降低价格，导致客户承担高昂的成本，并且缺乏其他选择。可观测性公司应避免向用户收取不必要的存储费用，仅收集和存储有用的数据，并删除其余的数据。这将有助于降低存储和处理数据的成本，并提高可观测性的效率和性能。为实现成本优化，可观测性平台需要采用智能数据采集和存储策略，优化数据的收集、保留和清理过程，以降低成本并提高资源利用率。
五、安全和隐私保护
在可观测性平台中，安全和隐私保护是至关重要的。公司需要确保采集的数据不会泄露敏感信息，并采取适当的安全措施来保护数据免受未经授权的访问、篡改或泄露。此外，隐私法规也对数据的收集和使用提出了限制，公司需要遵守相关法规和标准，保护用户和客户的隐私权。因此，可观测性平台需要具备强大的安全功能和隐私保护机制，以确保数据的安全性和合规性。
要实现可观测性，最为核心的要素莫过于建立自己的可观测性平台模型，基于模型所定义，创建自己的工具、利用开源软件或自定义开发可观测性解决方案来创建可观测系统。具体设计实现可参考如下图所示。
图1全链路一体化可观测性平台参考架构
通常情况下，设计一个能够获取应用数据纵向视图并支持性能分析的数据观测架构是一项复杂的任务，涉及多个组件和技术。每个企业都有其独特的业务特性和组织结构，因此可观测性模型的建立方式各不相同。然而，采用基于OpenTelemetry和eBPF（Extended Berkeley Packet Filter）的全链路一体化可观测性最佳实践可以提供更强大的监测和追踪能力具体如下：
（1）集成OpenTelemetry和eBPF：首先，将OpenTelemetry和eBPF集成到我们的应用和系统中。OpenTelemetry是一个开源的观测框架，可以帮助我们在应用代码中嵌入追踪和指标采集逻辑。而eBPF作为一个功能强大的内核技术，可用于在系统级别进行观测和监测。通过将这两个工具进行集成，我们可以实现全链路的可观测性。
（2）定义关键指标和追踪点：根据业务需求和关注点，定义关键的性能指标和追踪点。这些指标可以包括请求响应时间、资源利用率、错误率等。借助OpenTelemetry和eBPF，我们可以在应用代码中定义自定义的追踪点和指标采集逻辑，并在系统级别通过eBPF收集关键数据。
（3）分布式追踪和跨进程追踪：利用OpenTelemetry的分布式追踪功能，追踪请求在系统中的流动路径。使用OpenTelemetry的追踪上下文传递机制，确保跨进程和跨服务的请求能够被追踪和监测。通过结合eBPF的功能，可以在系统级别收集分布式追踪数据，提供更全面的观测能力。
（4）使用eBPF进行系统观测：利用eBPF技术，可以在内核级别收集系统的关键指标和事件。使用eBPF可以监测网络流量、系统调用、文件系统访问等。通过分析和监测这些数据，可以获得对系统性能和行为的深入了解，帮助识别潜在的问题和优化机会。
（5）采集和存储数据：使用OpenTelemetry和eBPF收集的指标和追踪数据，可以发送到各种后端存储和分析系统进行处理。例如，可以将数据发送到Prometheus、Grafana、Elasticsearch等工具进行实时监测和可视化。同时，将数据存储到长期存储系统，如InfluxDB、TimescaleDB或数据湖中，以便进行更长期的分析和回溯。
（6）可视化和警报：利用可视化工具和仪表盘，如Grafana，将收集的指标和追踪数据转化为易于理解的图表和图形。创建自定义的仪表盘，以便实时监测系统的状态和趋势。同时，设置警报规则和阈值，以便在系统性能下降或异常情况发生时及时通知相关团队。
持续优化和改进：全链路一体化的可观测性是一个持续的过程，需要不断优化和改进。根据实际运行情况和用户反馈，调整和改进指标设定、追踪点和数据收集策略，以更好地满足业务需求和关注点。
需要注意的是，以上步骤仅提供了一个总体框架，具体实施可能因应用程序的特性和需求而异。在设计数据观测架构时，还应考虑数据保护和隐私等方面的问题，并遵守适用的法律法规。
未来的可观测性将需要更加智能化和自动化。人工智能和机器学习等新技术将成为可观测性的重要组成部分，帮助开发人员和运维人员更好地了解系统和应用程序的运行状态，并自动化地识别和解决问题。同时，随着云原生技术的发展，容器、微服务和无服务器架构等新技术也将对可观测性产生深远的影响。
未来的可观测性还需要更加全面和综合。除了传统的日志管理、度量指标和分布式跟踪等技术，还需要考虑事件管理、故障注入和安全监控等方面的需求。这些技术将有助于建立更全面、更可靠的可观测性系统，帮助企业更好地管理和维护复杂的系统和基础设施。
赵海 某保险集团高级主管：
打破传统数据中心各IT条线的角色边界，以业务和应用要求为目标，以数据流线索为出发点，利用开源软件及相关工具建立一套整合的系统监控和性能分析视图是数据中心运维模式革新的必然趋势。
一、引言
医院的医生可能最难诊断的就是时有时无并且没有明显征兆的慢性病。同理，企业数据中心运维人员最头疼的可能就是性能分析问题了。或许很多人会说性能诊断是高级工程师必备的课程，都会有相应的工具和方法。没错，系统管理员会有成熟的性能分析工具和思路，比如对于IO性能问题，他们会用相应的诊断工具去判断IOPS、吞吐量、响应时间等相关指标；数据库管理员也会针对数据库的性能问题去分析他们的AWR报告；存储管理员会根据自身产品的后台性能分析工具和指标来判断存储的运行状况。可以站在企业的角度，其实关注的是业务和应用层面的性能，一方面，IT层面的良好运行不一定代表上层系统就一定没有问题。另外一方面，当表现为上层性能问题的时候，我们是否可以准确反推到IT的某一个环节呢？因此将传统的相互割裂的性能分析方法有效形成完整的系统性解决方案就需要关联纵向联系。
二、性能分析需要的数据监控视图
企业数据中心要做一个完整的性能分析或者性能解决方案，那么都需要监控哪些指标？简单来讲，我们认为数据从客户端流向服务器端之后的每一个环节都应该是需要监控或者关注的监控视图。毋庸置疑，这里会涉及到数据中心网络、服务器及操作系统、应用及中间件、数据库以及最终数据落盘的存储设备。
1.网络监控视图
传统运维模式下，网络工程师关注性能相关的场景主要为：
（1）网络设备自身的运行指标，例如设备的资源使用情况、繁忙程度、数据吞吐能力等。
（2）负载均衡资源池运行指标，例如资源池分发是否正常，有没有排队或丢失的情况等。
（3）域名解析相关设备的运行指标，域名在哪一级解析出来，解析响应机制及时间是否正常等。
（4）配合应用及数据库工程师进行网络抓包分析，主要看数据包的流向以及滞留时间。
2.操作系统监控视图
传统运维模式下，服务器与系统工程师应该是一个角色。其关注的也主要是服务器及操作系统层面的性能分析场景。根据系统资源类型的不同，他们会分析系统内网络、CPU、内存、IO等相关性能问题。不同资源会有不同的性能诊断工具（每一种操作系统都会有很多性能诊断工具，例如Linux的top、vmstat、iostat、sar）和思路。无论是哪一种类型的资源分析，最终会关注资源使用的效率是否正常，是否有排队、阻塞，是否有与正常情况不符合的异常现象。
3.数据库监控视图
传统运维模式下，数据库工程师做性能分析最得力的工具莫过于数据库本身输出的一些性能报告了。例如Oracle的AWR报告，它是一个数据库层面相对系统性的分析报告。它会从资源、事件、作业等几个维度去统计详细的各类指标，往往数据库工程师会从资源的使用情况追溯到事件的异常，最终追溯到某几个或某一个SQL，然后在对SQL的执行过程以及数据库当中的逻辑对象来判断应用执行层面的问题。
4.存储监控视图
存储监控视图一般都会集成到存储产品本身的管理界面上。同样的思路，存储监控也会从几个维度去监控自身存储设备的性能状况：
（1）资源维度的运行指标，例如控制器的繁忙程度以及利用率情况。
（2）网络接口的运行指标，例如前后端接口的繁忙程度以及均衡程度，吞吐数据的能力。
（3）缓存类资源的运行指标，例如缓存利用率、命中率、换入换出、锁等相关指标。
（4）存储卷的读写情况，包含逻辑卷以及物理卷的读写速度、排队、堵塞等相关指标。
三、性能分析当中的瓶颈问题
按照前文描述，每个工程师都有自己的对于性能诊断分析的工具和方法，似乎很完整。
但是，仔细品味过后，是不是感觉各个IT层面角色的关注点都局限在于自身的层面，每一个层面内部的分析都比较全面完整，从资源层面到作业层面都有相应的工具和思路来判断。但是相互之间的联系就看不到多少了。系统运行商，网络、系统、数据、存储组成了支撑业务运行的整体系统。性能分析上，它们似乎都是相互独立的模块。
传统运维场景下，一旦业务层面或者应用层面感觉到了业务行为的慢或者其他性能问题。通常的模式都是把所有工程师叫到一起，各查各的领域。如果幸运的话，有精通各领域的技术专家最后根据各个层面发现的异常点再去做汇总和梳理分析，最终经过反复排查和测试，可能会定位到问题所在。这种模式应该叫做排查，多少显得有些被动和效率不足，难以适应今天要求效率的互联网时代。
四、如何打通数据纵向联结形成整体视图
其实在谈打通数据纵向联结形成整体视图之前，我们应该明白为什么要这么做，这么做的目的是解决什么问题。前文我们说到了传统性能分析当中的困惑在于从业务或应用层面发现的问题，只能通过排查、汇总、梳理的方式来解决。换一种思路，我们能不能像警察办案一样顺着线索去追查呢？这就需要解决两个问题：首先，什么是线索？其次，谁是刑侦工具？
1.线索
业务运行过程当中，企业的要求有两个：首先，业务连续性；其次，业务效率性。性能问题往往影响在业务的效率上，例如：本来应该秒级完成的业务用了好多分钟，本来应该顺利完成的业务动作一致停留在等待的状态。作为企业的科技人员，首先要明确每一笔业务关联的业务路径和数据行为：
（1）业务路径。所谓业务路径就是这个业务行为表现出来的问题源头在哪里？是如何传导到服务端的？服务端的响应是什么？例如我们拥有应用监控的话，可以监控到服务端收到的每一个时刻点的每一个业务行为，并且可以监控到最终的反馈。这样就可以将问题定位在服务提供端之前还是之后。
（2）数据行为及业务关系视图。所谓数据行为就是这个业务落到IT层面表现出来的行为到底是什么？是读还是写？是读写哪些数据？这个是我们追溯到IT层的基本前提。例如银行的交易系统，往往一个交易行为会涉及多个系统的读写，这个关系视图如果不提前建设起来，那么后面的追溯就无的放矢，就算可以进行也很可能是盲目的或者是错误的。
有了以上的两个前提条件，如果需要继续往下追溯的话。线索是什么呢？我们认为有以下几个维度可以帮助我们将其纵向串联：
（1）数据标识。所谓数据标识在网络和系统层面对接过程中可以通过报文头标识来捕捉追溯，在数据库层面可以通过SQL文标识来捕捉，在系统和存储的对接过程中可以通过Block标识来捕捉追溯。当然具体细节还需要根据不同的设备来具体分析和设计。
（2）时间点。通常来讲，业务的发起时间我们是可以确定的，那么它在IT层面纵向传递的时刻点我们也是可以追溯的。如果我们的运维监控体系足够健全，那么某一个时刻点或者某个时刻片段内，各个层面发生的变化同样可以可以追溯并梳理出来的。
（3）IT层面的逻辑关联性。所谓IT层面的逻辑关联性是指我们为支撑一个业务系统运行，底层的基础架构是如何搭建出来的，各种资源的映射关系是要提前建立出来的。比如数据库当中的某个数据文件映射到操作系统的逻辑物理磁盘分别是什么？操作系统当中的物理磁盘映射到存储当中是哪个逻辑资源池，这个逻辑资源池的缓存机制是什么？组成的物理资源池又是什么？类似这样的逻辑关系是需要提前梳理出来并建立起相应的视图。
2.工具
企业数据中心IT的各个层面都有自己的监控工具，通常有两种方式：一种是通过脚本方式抓日志，另外一种是通过综合监控平台向各个层面以数据的方式展示出来。这里面有个问题，脚本的方式属于事后分析，效率欠佳功能有限。通用产品同样无法适应企业环境的差异性，毕竟不同企业采购的设备以及IT架构的组合方式都会有所差异。
这个时候，我们可以把目光瞄向开源监控软件。开源监控软件的优势在于以下两点：
（1）开放性：开源软件是企业IT人员可以根据自己需求进行独立设计和配置的软件。虽然会非常复杂非常耗费IT人力资源，但是可以完美与客户的差异化需求结合。正如前文所示，我们要实现对企业IT层面监控分析的纵向整合。首先，必须要将梳理出来的应用关系视图、IT基础架构关系视图提前定义到性能分析平台当中。其次，必须要根据自身环境特点将网络与系统层、系统与数据库层、系统与存储层之间的数据线索定义到性能分析流程当中。这些设计只有开源软件可以实现。
（2）灵活性：相对于通用产品，开源软件的灵活性在于其可控可修改性。企业的环境在不断变化，企业的要求在不断变化。这必然要求开源软件能提供的功能和方式要适应变化。比如，当企业的应用或者IT关系视图发生变化时，那么我们是否可以定义一种新的数据类型来支撑它呢？通用产品是做不到的。
（3）脚本语言的天然融合性：很多优秀的运维工程师喜欢自己定义一些Shell、Python等脚本来实现一些日志收集、分析等工作。究其原因在于自己定义的脚本与自己熟悉的环境的天然契合性，而与这些脚本再有天然契合性的就属开源软件了。优秀的脚本可以整合到开源框架中，成为实现整体视图的配件。
五、结语
简言之，企业在每一次面临业务性能问题的时候，往往需要投入大量的人力和时间来解决。从效率上和模式上都相对被动。如果在事前多花一些人力和时间，利用开源框架建立一套自己的性能分析框架，那么后期在面临此类问题的时候，就会显得主动并且高效。
结束语
通过本议题的讨论，我们首先从必要性、可行性方面对数据中心监控以及性能分析视图整合建设的思路进行了论证，接着又从AI等智能工具引入的维度探讨了建设的方法和思路。基本上可以认为通过开源工具、脚本并引入智能化的算法是可以帮助数据中心建立起一套主动的监控及性能分析视图的。
