本文来自微信公众号“twt企业IT社区（talkwithtrend.com）”，【作者】赵海，金融企业高级主管。
【摘要】打破传统数据中心各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等脚本来实现一些日志收集、分析等工作。究其原因在于自己定义的脚本与自己熟悉的环境的天然契合性，而与这些脚本再有天然契合性的就属开源软件了。优秀的脚本可以整合到开源框架中，成为实现整体视图的配件。
五、结语
简言之，企业在每一次面临业务性能问题的时候，往往需要投入大量的人力和时间来解决。从效率上和模式上都相对被动。如果在事前多花一些人力和时间，利用开源框架建立一套自己的性能分析框架，那么后期在面临此类问题的时候，就会显得主动并且高效。
