论文部分内容阅读
1 引言
经过若干年的IT建设，企业内部都存在多则几十个，少则十几个的大大小小应用系统。这些分散系统的运维对于IT要求很高，难度很大，所以各IT部门都计划对于这些系统进行整合。而在迫切需要大规模整合改造统一的同时，企业业务不断地清晰化和发展也要求IT部门领导不断审视业务与IT的融合，从战略SOA架构一直到应用整合再到应用运维，都需要关注IT的业务服务管理(BUSiness ServiceManagement)能力。所以，现阶段如何利用应用系统零改造的业务活动监控工具对现有应用的业务使用情况进行监控是一个重要的手段，一方面保障现阶段应用对业务的支撑，另一方面，获取的最终用户业务使用数据也将是下一阶段大规模应用整合改造的重要依据。
本文利用成熟的网络交换机镜像端口技术和开放的HTTP协议，实现了真正的B／S业务状态监控，并且根据技术特点，实现了皮用无改造的快速部署以及各业务指标的精准监控，保证现阶段的业务应用系统监控，也提供了改造优化依据。
2 技术原理
2.1 网络交换机镜像端口设置
本技术首先用到的就是网络交换机的镜像端口技术。通过交换机的配置，可以将原有的一个或者多个端口的所有流入流出数据都旁路到另外一个空闲的端口。在实际B／S应用系统中，客户与WEB服务集群之间数据交互可能会经过多个交换机和负载均衡器，在这种情况下，只需要挑选其中一个交换机，挑选的条件取决于以下内容：
(1)交换机流量大小，一般核心交换机流量较大，WEB服务器接入的交换机流量较小。
(2)负载均衡的位置，有时候负载均衡会修改最终用户的IP地址，需要打开X-Forward。
2.2 业务数据包还原
把所有用户访问的HTTP和HTTPS数据包全量复制到专用采集设备后，采用开放的协议标准，将采集设备获取的用户使用业务系统所产生的大量数据包，还原成以业务为视角的各类统计信息，从而在不改造现有应用系统的前提下，获取最终用户业务使用体验数据。整个业务还原的过程分以下几个过程：
(1)多维度聚类定义
业务构造的高准确度和高有效度的前提是能够把大量看上去杂乱无序的原始数据包进行准确有效的分类，这些原始数据综合了会话层(Session)、用户登录账号、客户端IP地址、业务URL参数化匹配、HTTP错误、应用错误和时间序列等维度。根据应用系统特点，要实现原始数据包聚类，部分或者全部进行以上维度的聚类定义，是业务还原的基础。
①会话层(Sesslon)，一个用户在一次浏览周期内，所有的操作将在一个会话中完成，将HTTP头中包含相同Session信息的数据包汇总在一起，可以了解该会话过程中访问的所有URL序列。
②用户登录账号，对于大多数应用系统都有用户登录，通过对URL参数或者表单数据的解析，可以把所有URL操作归类到特定的用户账号下。一次用户账号登录必包含于一个会话中。
③客户端IP地址，通过TCP包中源地址的解析可以把网络数据包按客户端IP地址进行归类，对于负载均衡隐藏源lP地址的可以打开X-Forward功能保留源地址。
④业务URL参数化匹配，对某些配置了多域名和多种业务操作渠道的应用系统，可以利用通配符等方式将相关URL聚类。
⑤HTTP错误，根据HTTP响应头中状态代码的解析。获取非200的HTTP错误并归类。
⑥应用错误，根据返回页面的特定信息定义具体的应用错误归类，比如服务器端返回提示信息：登录密码错误。
⑦时间序列，将数据包的访问和到达时间对原始数据包进行排序。
(2)海量数据处理
在聚类定义以后，面对海量的原始网络包数据，BPB采用了多级处理的方式，借鉴于生产流水线的效果，创造一个大管道的数据流，接在管道上的每级处理都是分工明确的专业处理过程，保证了批量快速的处理效果。同时，多级处理可以应用于多台物理主机，连接采用专卡专线专用(没有IP、交换和路由)，达到了物理级的架构弹性。处理过程主要包含了TCP／IP包处理、HTTP头处理、HTTP内容处理等。每一个处理都包含了过滤和归类等动作。
①过滤，从交换机镜像复制下来的全量数据可能包括了很多错包、非监控目标地址、非监控目标协议等，都可以在第一阶段过滤中去除。
②TCP／IP包处理，从交换机镜像复制下来的全量数据可能包括了很多不需要监控的内容，通过TCP／IP包获取源和目的地IP地址、协议等信息，将非监控目标地址、非监控目标协议的数据包直接过滤，将相同源地址归类。
③HTTP头处理，HTTP头相比较于内容小很多，但却包含了大部分的聚合信息，包括Session、URL、HTTP响应状态等，将一些与业务关联不大的资源类的URL比如图片、样式CSS文件过滤，将相同Session、URL、HTTP响应状态以及URL登录账号名的信息归类。
④HTTP内容处理，对于特定URL，需要获取具体的用户表单输入信息、服务器端返回信息等内容，就需要对HTTP内容进行处理。
下图是处理的流程示意图：
(3)业务处理全回放
经过海量处理归类，最后通过对业务的操作页面流的顺序定义，把每个会话、每个用户、每个1P所对应的业务操作进行完全回放，业务操作量和结果的统计信息也能实时展示，方便运维人员了解全量用户的业务体验和单用户的实时回放及错误信息。
①业务定义：将多个URL按时间序列顺序出现的定义为一个业务，同时URL必须是在同1个Session、同一个用户登录账号和同一个客户端IP地址出现。这种定义方式可以以直观和准确业务统计方式代替URL方式，比如以充值代替http：／／xxx／pathl和http：／／×××／path2。同时也需要定义业务错误的信息，比如页面返回包含什么信息时表示业务错误。
②业务汇总统计：统计同一个业务的量、可用性、网络响应和服务器响应时间，单次业务可用表示未出现HTTP错误和应用错误的URL，响应时间则为所有URL响应时间之和。
③业务错误回放：对于出错业务，可以全程回放业务操作过程和具体表单数据，并且将提供服务器端的错误返回页面。
3 功能特点
实现真正的业务监控实际上还有多种手段，比如利用在线测试技术实现业务的模拟监控。通过应用改造实现代码级的业务详细状态监控，那利用网络技术实现业务状态监控的方法的特点是什么呢?
(1)全再现
传统在线测试技术虽然能够实现真正的端到端用户体验。也就是能够最真实地反映最终用户在使用业务时的体验，但由于是单点或者有限模拟点。只能“以点盖面”来了解总体业务状态，而利用网络技术的业务监控可以抓取到所有用户的所有业务操作数据，再利用业务状态还原，可以很好地进行全量用户监控。实现业务全再现。
(2)全自动
连续不间断的网络数据包的抓取和还原，可以实现7×244,时的 全自动业务还原能力，并且通过多维度的告警和展现，使得业务运维做到真正的全自动化。
(3)零改造
利用代码改造当然也可以实现业务的监控，但是对企业目前复杂的应用异构环境，大规模地改造无疑又给运维工作埋下了更多的定时炸弹。即使应用做了改造。实现了业务监控功能，当业务应用出现中断或者错误时，监控功能同样无法正常工作，最多实现一个心跳程序简单判断应用的可用状态。
(4)零影响
即使在应用系统正常运行时，记录更多的日志监控数据意味着更多的业务性能消耗，而通过交换机镜像端口的数据包采集，对于应用系统完全是一个旁路，没有丝毫影响，而对于现有常见交换机的镜像端口转发，即使超过IOOMBPS的流量包转发，对交换机也只是增加不到3％的CPU利用率。
4 技术应用
通过网络技术实现的业务监控数据可以用于实时的业务状态告警以及历史趋势分析，帮助使用者一方面提升实时业务系统的运维监控能力，另一方面也可以帮助系统长期优化，这两个方面的作用都需要通过监控对象和监控指标的多维度分析实现。
(1)监控对象分维。对于整个在线业务系统，前端是包含各个地域的最终用户，后端是利用多台服务器组成的WEB集群，使用过程中则包含各种业务，而当发生错误时则包含了固定的HTTP错误代码和自定义的应用类错误。
(2)监控指标分维。对于每一个监控对象，通过网络数据包还原的业务指标包括业务访问量、业务错误数、业务可用性(业务访问量一业务错误数)／业务访问量×100)、业务响应时长、业务响应网络时长以及业务响应后台处理时长。
通过监控对象与监控指标的组合，在告警应用上可以利用以下内容来帮助日常运维工作：
(1)针对某个业务在某台服务器可用性的告警；
(2)针对某个业务在某个地区可用性的告警；
(3)针对某个业务发生的某个错误数的告警；
(4)针对某个业务的错误在某个服务器上发生的次数的告警；
(5)针对某个地区的总体可用性告警；
(6)针对某个地区发生的某个错误的次数的告警。
而针对历史数据的分析，可以生成指定周期内的以下报表，用于故障的根本原因定位和系统优化参考：
(1)指定业务按地区5分钟报表，显示各地区业务可用性、性能和业务量数据。
(2)指定业务的量与可用性月报，显示该月每一天业务量和可用性数据。
(3)总体服务器可用性排名报表，显示指定时间段内每一个后台服务器的可用性和访问流星。
(4)指定业务的业务量与可用性按服务器排名报表，显示特定业务在每一台服务器上的负载和可用性情况。
(5)服务器错误数分布报表。显示不同HTTP错误类型的比例。
5 总结
经过几十年的IT基础架构理论和建设实践，包含网络在内的各种技术都已经非常成熟，如何利用已有成熟技术来满足新的业务运维监控需要是值得挖掘推广的，本案例利用了成熟的网络交换机镜像端口技术和开放的网络协议实现了对于在线业务系统的监控，其监控结果和应用对实际的运维工作产生了很大的帮助，特别是其全自动、全在现、零影响、零改造的特点，真正符合了监控系统对于被监控业务系统的分离和影响原则，是一种理想的监控手段，也适合在不同企业不同应用内大范围推广。
当然，以本文技术为基础，还可以对所有使用开放式网络协议的业务状态进行监控，这样就可以实现对于业务不同阶段的更深层监控。
经过若干年的IT建设，企业内部都存在多则几十个，少则十几个的大大小小应用系统。这些分散系统的运维对于IT要求很高，难度很大，所以各IT部门都计划对于这些系统进行整合。而在迫切需要大规模整合改造统一的同时，企业业务不断地清晰化和发展也要求IT部门领导不断审视业务与IT的融合，从战略SOA架构一直到应用整合再到应用运维，都需要关注IT的业务服务管理(BUSiness ServiceManagement)能力。所以，现阶段如何利用应用系统零改造的业务活动监控工具对现有应用的业务使用情况进行监控是一个重要的手段，一方面保障现阶段应用对业务的支撑，另一方面，获取的最终用户业务使用数据也将是下一阶段大规模应用整合改造的重要依据。
本文利用成熟的网络交换机镜像端口技术和开放的HTTP协议，实现了真正的B／S业务状态监控，并且根据技术特点，实现了皮用无改造的快速部署以及各业务指标的精准监控，保证现阶段的业务应用系统监控，也提供了改造优化依据。
2 技术原理
2.1 网络交换机镜像端口设置
本技术首先用到的就是网络交换机的镜像端口技术。通过交换机的配置，可以将原有的一个或者多个端口的所有流入流出数据都旁路到另外一个空闲的端口。在实际B／S应用系统中，客户与WEB服务集群之间数据交互可能会经过多个交换机和负载均衡器，在这种情况下，只需要挑选其中一个交换机，挑选的条件取决于以下内容：
(1)交换机流量大小，一般核心交换机流量较大，WEB服务器接入的交换机流量较小。
(2)负载均衡的位置，有时候负载均衡会修改最终用户的IP地址，需要打开X-Forward。
2.2 业务数据包还原
把所有用户访问的HTTP和HTTPS数据包全量复制到专用采集设备后，采用开放的协议标准，将采集设备获取的用户使用业务系统所产生的大量数据包，还原成以业务为视角的各类统计信息，从而在不改造现有应用系统的前提下，获取最终用户业务使用体验数据。整个业务还原的过程分以下几个过程：
(1)多维度聚类定义
业务构造的高准确度和高有效度的前提是能够把大量看上去杂乱无序的原始数据包进行准确有效的分类，这些原始数据综合了会话层(Session)、用户登录账号、客户端IP地址、业务URL参数化匹配、HTTP错误、应用错误和时间序列等维度。根据应用系统特点，要实现原始数据包聚类，部分或者全部进行以上维度的聚类定义，是业务还原的基础。
①会话层(Sesslon)，一个用户在一次浏览周期内，所有的操作将在一个会话中完成，将HTTP头中包含相同Session信息的数据包汇总在一起，可以了解该会话过程中访问的所有URL序列。
②用户登录账号，对于大多数应用系统都有用户登录，通过对URL参数或者表单数据的解析，可以把所有URL操作归类到特定的用户账号下。一次用户账号登录必包含于一个会话中。
③客户端IP地址，通过TCP包中源地址的解析可以把网络数据包按客户端IP地址进行归类，对于负载均衡隐藏源lP地址的可以打开X-Forward功能保留源地址。
④业务URL参数化匹配，对某些配置了多域名和多种业务操作渠道的应用系统，可以利用通配符等方式将相关URL聚类。
⑤HTTP错误，根据HTTP响应头中状态代码的解析。获取非200的HTTP错误并归类。
⑥应用错误，根据返回页面的特定信息定义具体的应用错误归类，比如服务器端返回提示信息：登录密码错误。
⑦时间序列，将数据包的访问和到达时间对原始数据包进行排序。
(2)海量数据处理
在聚类定义以后，面对海量的原始网络包数据，BPB采用了多级处理的方式，借鉴于生产流水线的效果，创造一个大管道的数据流，接在管道上的每级处理都是分工明确的专业处理过程，保证了批量快速的处理效果。同时，多级处理可以应用于多台物理主机，连接采用专卡专线专用(没有IP、交换和路由)，达到了物理级的架构弹性。处理过程主要包含了TCP／IP包处理、HTTP头处理、HTTP内容处理等。每一个处理都包含了过滤和归类等动作。
①过滤，从交换机镜像复制下来的全量数据可能包括了很多错包、非监控目标地址、非监控目标协议等，都可以在第一阶段过滤中去除。
②TCP／IP包处理，从交换机镜像复制下来的全量数据可能包括了很多不需要监控的内容，通过TCP／IP包获取源和目的地IP地址、协议等信息，将非监控目标地址、非监控目标协议的数据包直接过滤，将相同源地址归类。
③HTTP头处理，HTTP头相比较于内容小很多，但却包含了大部分的聚合信息，包括Session、URL、HTTP响应状态等，将一些与业务关联不大的资源类的URL比如图片、样式CSS文件过滤，将相同Session、URL、HTTP响应状态以及URL登录账号名的信息归类。
④HTTP内容处理，对于特定URL，需要获取具体的用户表单输入信息、服务器端返回信息等内容，就需要对HTTP内容进行处理。
下图是处理的流程示意图：
(3)业务处理全回放
经过海量处理归类，最后通过对业务的操作页面流的顺序定义，把每个会话、每个用户、每个1P所对应的业务操作进行完全回放，业务操作量和结果的统计信息也能实时展示，方便运维人员了解全量用户的业务体验和单用户的实时回放及错误信息。
①业务定义：将多个URL按时间序列顺序出现的定义为一个业务，同时URL必须是在同1个Session、同一个用户登录账号和同一个客户端IP地址出现。这种定义方式可以以直观和准确业务统计方式代替URL方式，比如以充值代替http：／／xxx／pathl和http：／／×××／path2。同时也需要定义业务错误的信息，比如页面返回包含什么信息时表示业务错误。
②业务汇总统计：统计同一个业务的量、可用性、网络响应和服务器响应时间，单次业务可用表示未出现HTTP错误和应用错误的URL，响应时间则为所有URL响应时间之和。
③业务错误回放：对于出错业务，可以全程回放业务操作过程和具体表单数据，并且将提供服务器端的错误返回页面。
3 功能特点
实现真正的业务监控实际上还有多种手段，比如利用在线测试技术实现业务的模拟监控。通过应用改造实现代码级的业务详细状态监控，那利用网络技术实现业务状态监控的方法的特点是什么呢?
(1)全再现
传统在线测试技术虽然能够实现真正的端到端用户体验。也就是能够最真实地反映最终用户在使用业务时的体验，但由于是单点或者有限模拟点。只能“以点盖面”来了解总体业务状态，而利用网络技术的业务监控可以抓取到所有用户的所有业务操作数据，再利用业务状态还原，可以很好地进行全量用户监控。实现业务全再现。
(2)全自动
连续不间断的网络数据包的抓取和还原，可以实现7×244,时的 全自动业务还原能力，并且通过多维度的告警和展现，使得业务运维做到真正的全自动化。
(3)零改造
利用代码改造当然也可以实现业务的监控，但是对企业目前复杂的应用异构环境，大规模地改造无疑又给运维工作埋下了更多的定时炸弹。即使应用做了改造。实现了业务监控功能，当业务应用出现中断或者错误时，监控功能同样无法正常工作，最多实现一个心跳程序简单判断应用的可用状态。
(4)零影响
即使在应用系统正常运行时，记录更多的日志监控数据意味着更多的业务性能消耗，而通过交换机镜像端口的数据包采集，对于应用系统完全是一个旁路，没有丝毫影响，而对于现有常见交换机的镜像端口转发，即使超过IOOMBPS的流量包转发，对交换机也只是增加不到3％的CPU利用率。
4 技术应用
通过网络技术实现的业务监控数据可以用于实时的业务状态告警以及历史趋势分析，帮助使用者一方面提升实时业务系统的运维监控能力，另一方面也可以帮助系统长期优化，这两个方面的作用都需要通过监控对象和监控指标的多维度分析实现。
(1)监控对象分维。对于整个在线业务系统，前端是包含各个地域的最终用户，后端是利用多台服务器组成的WEB集群，使用过程中则包含各种业务，而当发生错误时则包含了固定的HTTP错误代码和自定义的应用类错误。
(2)监控指标分维。对于每一个监控对象，通过网络数据包还原的业务指标包括业务访问量、业务错误数、业务可用性(业务访问量一业务错误数)／业务访问量×100)、业务响应时长、业务响应网络时长以及业务响应后台处理时长。
通过监控对象与监控指标的组合，在告警应用上可以利用以下内容来帮助日常运维工作：
(1)针对某个业务在某台服务器可用性的告警；
(2)针对某个业务在某个地区可用性的告警；
(3)针对某个业务发生的某个错误数的告警；
(4)针对某个业务的错误在某个服务器上发生的次数的告警；
(5)针对某个地区的总体可用性告警；
(6)针对某个地区发生的某个错误的次数的告警。
而针对历史数据的分析，可以生成指定周期内的以下报表，用于故障的根本原因定位和系统优化参考：
(1)指定业务按地区5分钟报表，显示各地区业务可用性、性能和业务量数据。
(2)指定业务的量与可用性月报，显示该月每一天业务量和可用性数据。
(3)总体服务器可用性排名报表，显示指定时间段内每一个后台服务器的可用性和访问流星。
(4)指定业务的业务量与可用性按服务器排名报表，显示特定业务在每一台服务器上的负载和可用性情况。
(5)服务器错误数分布报表。显示不同HTTP错误类型的比例。
5 总结
经过几十年的IT基础架构理论和建设实践，包含网络在内的各种技术都已经非常成熟，如何利用已有成熟技术来满足新的业务运维监控需要是值得挖掘推广的，本案例利用了成熟的网络交换机镜像端口技术和开放的网络协议实现了对于在线业务系统的监控，其监控结果和应用对实际的运维工作产生了很大的帮助，特别是其全自动、全在现、零影响、零改造的特点，真正符合了监控系统对于被监控业务系统的分离和影响原则，是一种理想的监控手段，也适合在不同企业不同应用内大范围推广。
当然，以本文技术为基础，还可以对所有使用开放式网络协议的业务状态进行监控，这样就可以实现对于业务不同阶段的更深层监控。