今天准备谈下基于ESB或API网关的服务运行监控分析，对于服务运行分析和监控本身也属于服务治理或微服务治理的一个关键内容。
为何基于ESB或API网关？
当所有的接口服务和API接入到ESB或API网关的时候，由于是一种中心化的集成架构模式，因此总线更加容易采集到每一次服务运行详细的性能数据，而这些性能数据则是我们进行服务运行分析监控的基础。
如果重新给微服务治理一个定义，应该如下：
微服务治理是针对企业组织和业务目标，制订一套标准的管理，业务，技术，过程规范体系，实现微服务从需求，设计，开发上线，运行，下线的全生命周期管理能力。同时构建一套完整的度量指标体系，通过实时的日志和性能数据采集，持续的监控服务运行监控状态，并执行相应的限流，预警等管控策略，以确保微服务的持续健康，可靠和高效运行。
在前面谈微服务治理的时候，我将微服务治理核心内容分为设计态和运行态。
而整个运行态的核心内容即是服务运行监控分析，通过服务运行监控分析结合指定好的服务度量和KPI体系，进行服务的持续性能优化和管控。在运行期还有一个关键思维的转变就是不是简单的发生问题故障后的运维治理，而是应该基于监控预警分析下的主动的技术运营和SLA服务等级提升。
因此服务运行监控分析本身是提升微服务治理管控能力的一个关键。
在谈具体的服务运行监控分析前，还是先分析下服务运行监控和整个治理框架中的其它核心模块之间的一些集成关系。通过集成关系的梳理，可以更方便理解服务运行监控分析在整个治理框架中的重要作用。
对于整体集成关系如下图：
对于服务运行监控本身可以分为两个层面，一个是最基本的服务运行分析，其中包括了服务运行实例查询，异常日志查询等。其次是基于服务运行实例进行的多维度服务运行统计分析。
服务运行监控可以应用到服务告警预警中，即服务运行统计分析加上告警规则设置来进行具体的服务运行告警和预警处理。
对于限流熔断功能，本身也涉及到具体的限流熔断规则配置，因此也需要使用服务运行监控统计分析数据，只是这里的运行统计分析时间间隔往往更短，比如小时级或分钟级别。
服务运行监控如果实时发现了服务运行故障或异常，或者服务运行响应缓慢的情况，那么就需要进行详细的问题分析和排查。如果确认了是服务本身的问题，就需要对服务进行服务设计和优化变更，或者对出现的Bug故障进行修复。
其次服务运行监控分析可以形成整个服务运行全生命周期的闭环管理，即通过服务运行统计分析和KPI度量体系，发现服务持续优化的点，调整原有的服务SLA等级设置。如果服务非服务自身原因导致的服务运行期性能下降，还需要考虑是否进行IT基础设施和资源扩展。
对于服务运行监控，首先还是应该分析数据模型框架。
对于ESB服务运行监控，从SOA服务管控和治理层面来看，经常会涉及到的KPI性能指标并不多，主要还是体现在运行次数，运行时间等关键的维度，如果考虑到指标本身之间的关联关系方便分析，那么还需要增加服务运行的并发数(分钟级），服务调用的数据量等关键指标。
举例来说，当我们发现服务调用变慢了，即服务运行时间明显增加了，那么我们需要分析是否是该服务本身的并发量是否增加了，还是说服务本身调用的数据量增加了，还是说其它服务调用的并发量和数据量增加了导致该服务的资源被占用等。这些都是可能需要涉及到关联分析的地方。
对于服务运行数据框架，核心还是服务运行实例数据。因此可以先看下服务运行实例数据可以采集和记录到的关键数据项包括：
以上信息即是单个服务运行实例可以记录到的一些关键信息。如果单独从服务运行监控来说，有以上数据已经可以进行服务日志查询，异常信息查询。
但是从服务统计分析来说，就还必须扩展数据的聚合维度。而对于数据的聚合维度，我们可以从静态维度，动态维度和实例维度三个方面展开。
基于这个思路即可构建下图的核心数据模型框架：
静态维度聚合
静态维度聚合包括了服务提供方系统，消费方系统，对于业务系统本身又属于某一个业务域，或者属于某个业务组织，这个是关键的系统分类。
对于ESB集群来说，本身服务实例是运行在某个集群节点上面的，同时对于集群本身也存在集群分组，构成一个层次关系。
最后服务属于完整的服务目录库，服务本身有分类，比如我们常说的业务域，服务类型等都可以是关键的服务分类信息。
动态维度展开
对于动态维度，实际上又可以分为两类，一个是应用到实时服务运行监控，一个是拥有非实时的服务运行统计分析的。
对于实时监控往往需要做到至少分钟级的服务运行心跳监控和数据汇总分析，这个数据本身也是进行后续类似服务预警，服务限流熔断的一个关键基础数据。因此实时监控的时间周期可以从分钟到小时到天的粒度即可。
而对于非实时的统计分析，往往需要能够分析到年这个跨度，因此对于时间周期维度最小单位到天即可，即从天到月到年的汇总。
当然准实时监控统计形成的按天数据本身刚好作为非实时统计分析的最细粒度数据输入。
实例数据聚合
对于实例数据本身也可以进行聚合，最简单的就是Count计数聚合，其中类似服务运行次数，单位时间的并发数，服务成功失败率，异常数等都基于Count计数。
而对于服务运行时间，服务运行报文量，则不是简单的Count计数，而是可以分析具体的最大值，最小值，平均值等多个汇总数据。比如我们常说的服务运行时间，实际上分析某个周期的服务平均运行时长更有意义。
经过以上分析，我们看到一个最底层的服务运行日志信息，就有了按时间维度，按组织，服务类型，系统等多个维度进行维度分析和统计的可能。而这些恰好又是我们进行自定义报表和维度分析的基础。所有的统计分析基本都会基于以上基础运行信息展开进行。
同时我们看到，为了做完整的服务运行和性能分析，我们最好还需要对中间件资源池(应用服务器和数据库服务器）的CPU，内存利用率，存储使用量等关键指标进行实时的性能分析和监控。在实际的性能分析和监控中往往也是首先会从CPU和内存告警上第一时间反应出服务当前运行出现异常（如大并发，超大数据传输等），然后我们在通过实际的日志监控分析功能快速的查看当前服务运行的并发情况，传递的数据量情况等。
前面已经谈到服务运行监控分析，包括了实时查询和监控，也包括了非实时的定时统计分析。在这里先谈下实时和准实时查询分析。
对于服务运行实例，最基本的就是应该有相应的服务实例查询功能。
对于每一次接口服务的调用都会产生服务运行实例日志信息，这些日志信息应该在ESB或API网关平台通过Log的方式进行记录。
业务系统可以通过实例ID，服务名称，调用状态，时间段等条件对服务实例日志信息进行查询，同时对于查询到的实例日志信息还可以详细查看具体的消息报文输入和输出信息。
对于主流的ESB或API网关Log功能的实现，可以看到在进行服务代理和封装过程中会增加Log插件，通过Log插件来拦截日志并写入到分布式文件存储或数据库中。而日志的持久化写入本身需要和服务调用解耦，因此日志写入一般都采用消息中间件来实现解耦和异步性能提升。
其次就是服务运行心跳监控，在项目实践中我们会对服务运行指标进行分钟级心跳监控。
其中主要监控服务运行的并发量，数据量，运行时长等几个关键数据指标。
在前面已经谈到过以上几个指标本身存在勾稽关系，比如发现服务运行平均时长增加，那么很可能是服务并发量增加或调用数据量增加导致。其次，如果发现服务调用的消息报文数据量猛增，那么很可能导致服务运行时长增加。
因此需要对以上几个关键指标进行实时监控，时刻监控是否发生了峰值突变情况。
当发现了峰值或突变的时候，我们就需要进行预警，并分析发生大并发或大数据量调用的原因并及时采取相应的流量管控措施，以确保整个ESB平台的稳定性。
在前面的数据模型中可以看到，服务运行本身的统计分析是要给多维度的统计过程。
服务运行记录本身是一个按时间持续产生的动态数据，因此最容易考虑到的就是基于动态的时间维度对服务运行实例信息进行汇总。
比如从最细粒度的分钟，汇总到小时，天，月，年的各种时间维度。即对于服务运行次数，分钟级的峰值并发，运行时长等关键性能指标都可以按时间趋势进行汇总后展示，类似下图：
但是对于以上数据是基于所有的服务调用实例记录进行聚合计算。
而实际上从前面数据模型可以看到，对于服务运行实例本身还是组织单位，服务提供方，服务消费方，服务分类等进一步的静态细分维度。因此这些静态细分维度+上面的时间趋势将形成进一步的数据下钻展示。这个功能实际和BI里的支持数据钻取功能类似。
在前面介绍了最基本的服务运行查询，服务统计分析后，再来看下基于实际的业务场景驱动，需要如何对服务运行进行多维度的聚合分析。
在前面已经谈到，当你第一次就按时间趋势去动态展现数据的时候，那么对于静态维度则是固定死的，比如只能看整个ESB集群，或一个组织，或一个系统的动态时间趋势数据。
而且这个动态趋势数据还很难同时展示多个KPI指标。
比如对于运行时长和运行报文量，两个的衡量单位不一样，即使用双坐标方式在一个图表上展示其整体的可读性也会很差。
即动态趋势很难形成一个多维度组合的分析统计表。
从组织维度的多维分析思考
因此多维度的聚合分析一开始可以先按组织，按系统等静态的维度进行统计分析，而统计的时间区间先进行固定的查询条件作为输入。
比如我们希望查询子公司1当前的服务运行性能指标情况。而对于子公司1本身提供了5个系统，上100个接口服务的接入。那么第一层可以先分系统统计各个系统的关键KPI指标。
在分析该KPI指标的时候，会发现SCM系统提供的服务运行平均时长达到5秒，超过了我们实际的服务运行时长预期，那么我们就可以进一步下钻分析究竟问题出现在哪里？
对于单个指标异常的下钻，实际可以采用按静态维度和动态维度两个不同维度同时下钻的方法以快速的定位和发现问题服务。如上图，通过静态展开可以到具体的接口服务粒度，基于动态可以展开到服务运行的具体到天粒度的时间周期。
即通过上图的可视化展示，可以快速的发现具体是哪个服务，哪几个关键的时间点服务调用出现了问题。这将极大的方便我们对服务运行进行快速的诊断和分析。
从业务系统多维分析思考
对于注册和接入API接口服务到ESB或API网关的业务系统或微服务来说，可以思考下对于业务系统究竟希望在管控治理平台上看到哪些服务KPI性能数据。
在前面谈服务运行数据模型的时候，可以看到要给业务系统既可能是服务运行的提供方，也可能是服务运行的消费方。要给业务系统可以接入自己的服务到平台，同时也可以消费和调用平台提供的API接口服务。
因此对于业务系统来说，首先就要分两类来看，是看自己提供的服务运行情况和性能，还是看自己消费的服务运行情况和性能。
在这里仅仅拿提供服务运行性能来分析。
即业务系统账号登录后可以详细看到某个时间周期自己提供的服务具体的KPI性能指标，当发现性能问题的时候可以进一步展开。
在静态上可以按具体的服务消费方进一步展开，确定究竟是哪个消费方服务调用频繁或服务调用性能缓慢。而在动态上仍然可以进一步按时间周期展开，确定具体的并发峰值出现时间点。
服务交互矩阵
对于一个业务系统来说，是否可以看到其提供的所有服务被各个业务系统消费的KPI指标情况？在前面的维度展示方式，基本都需要通过进一步的下钻才能够展示完整信息。
在这里可以设计类似服务交互矩阵的方式进行关键KPI指标展示，即上图中的服务维度和消费方维度可以作为交互矩阵图中的两个坐标轴进行构图。
在服务交互矩阵中，单元格中的统计指标一般只能够展示一个。比如同时展示运行次数指标，或者同时展示并发数指标等。
维度展开和下钻的思路
简单来说，服务统计分析的过程是进行数据聚合的过程，但是对于实际的服务运行分析和诊断则是需要进行下钻展开的过程。
下面给出一些可行的服务运行分析下钻展开路径。
以上即是最常用的一些可用服务多维度组合方式，供参考。
对于服务运行数据分析实际上是一个需要采用各种统计学方法进行的过程。在这里先举一些简单的场景来进行说明，后续再单独写文章进行详细分析。
场景1：服务耗时分布偏差和毛刺现象
对于毛刺现象是在运维里面的一种场景说法，即诊断监控的某个KPI性能指标出现的某个时间点或时间段异常高的情况。
对于服务运行时长的分析往往就存在这种毛刺现象而影响到正常的分析结果。比如我们监控两个服务，服务A和服务B，发现两个服务平均运行时长都是30S。
对于30秒的运行时长在预定规则里面已经属于明显的服务运行性能问题需要进行分析。但是两个服务平均时长缓慢的原因并不同。
服务A是所有的服务运行都缓慢，基本围绕30S正态分布。
服务B是在存在少量的服务实例耗时特别长，比如5分钟，而其他服务运行实例都在1S内完成，在服务运行量不大的情况下导致整体服务平均时长变慢。
而这两种情况分析和解决思路往往并不通，对于服务B缓慢往往仅仅是个例，这种特殊个例受到总线，网络，业务系统提供方多条件影响，只要不对所有服务造成影响实际并不需要特殊处理。但是对于服务A这种整体性能下降，则必须引起高度的重视，往往就涉及到提供服务需要进一步进行性能优化，或当前资源需要扩容等。
如何简单屏蔽这种现象？
最简单的方法就是你可以类似比赛打分去掉最低分，去掉最高分的做法。即对于服务运行实例数据统计，只统计95%耗时长的服务的平均耗时。具体是95%还是90%，则根据我们具体的服务治理和SLA管控要求来指定。
场景2：服务耗时双波峰分布
在我们最近的服务运行性能分析中，发现了另外一种特殊情况。即对于服务耗时性能数据出现了双波峰的分布情况。
即对某一个时间段的数据进行观察，会发现实际的服务耗时分布存在两个波峰，那么这种两个波峰的数据分布式如何造成的？
对于这种双波峰的分布，经过排查实际上存在两种情况。
其一是跟某个特定的服务消费方相关，该消费方访问该服务运行时长都比较长。其二是跟某个特定的服务查询条件相关，即在该特定的服务查询条件下会导致服务运行耗时长。
因此经过具体的分析我们就可以进一步诊断出具体的细节问题点并有针对性的进行服务性能优化改进工作。
对于具体的基于数据统计学思路的服务运行分析后续再展开详细描述。
对于本文相关的延伸阅读可参考：
从传统服务链监控到端到端流程监控技术实现
大型ESB服务总线平台服务运行分析和监控预警实践
从商用报表谈自定义报表和可视化监控大屏设计
数据可视化-监控大屏呈现和拓扑图绘制工具总结
页面更新：2024-03-14
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号
