【.com原稿】作者于2016年加入WiFiVPNKey，现任WiFiVPNKey资深架构师。拥有10年互联网研发经验。折腾技术。主要专注于：分布式监控平台、调用链跟踪平台、统一日志平台、应用性能管理、稳定性保障体系建设等领域。在本文中，笔者将与大家分享一些在实时监控领域的实践经验，并介绍WiFiVPNkey如何搭建APM端到端全链路监控平台，提高故障发现能力率、缩短故障处理周期、降低用户投诉率、树立公司良好品牌形象等目标。WiFiVPNKey开发维护团队的烦恼，是从盛大创新院的WiFiVPNKey开始的。截至2016年底，我们的用户总数已超过9亿，月活跃用户已达到5.2亿。用户分布在全球223个国家。可连接全球4亿个热点，日均连接超过40亿次。随着日活跃用户的大规模增长，WiFiVPNKey各产品线的服务团队正在进行一场没有硝烟的战争。越来越多的应用服务面临着流量激增、架构膨胀、性能瓶颈等问题。为了应对和支撑业务的快速发展，我们进入了SOA、微服务、API网关等组件化、服务化时代。随着各个系统微服务的演进，服务数量和机器规模不断增加，线上环境也越来越复杂。工程师们每天都面临着许多苦恼。例如：在线申请失败时，无法实现时间感知；面对在线申请产生的海量日志，问题排查困难；当应用系统内部和系统之间的调用链路出现故障，难以定位等。综上所述，在线应用的性能问题和异常错误已经成为开发人员和运维人员面临的最大挑战，而此类问题的排查往往需要数小时甚至数天的时间，严重影响了效率和业务发展。WiFiVPNkey急需完善监控系统，帮助开发维护人员摆脱烦恼，提升应用性能。根据公司的产品形态和业务发展，我们发现监控系统需要解决一系列问题：面对全球多个地区海量用户的WiFi连接请求，如何保证用户的连接体验？如何通过全链路监控提高用户连接WiFi的成功率？随着微服务的大规模推广和实施，重点WiFi重点产品的服务器系统越来越复杂，发现、定位和处理在线故障的难度也越来越大。如何通过全链路监控提高排错速度？移动出海已进入深度发展的下半场。全链路监控如何应对公司全球化业务发展？◆...在全链路监控初期，为了快速支撑业务发展，我们主要采用开源监控解决方案保证线上系统的稳定性：Cat、Zabbix，随业务发展需要，开源解决方案已经不能满足我们的业务需求，我们迫切需要构建一个符合我们现状的全链路监控体系：多维度监控（系统监控、业务监控、应用监控、日志查询、调用链跟踪等）多实例支持（满足线上应用单台物理机部署多个应用实例等需求）多语言支持（满足各类团队需求监控支持多种开发语言场景，Go、C++、PHP等）多机房支持（满足国内外多机房应用的监控支持，机房数据同步等）多通道alarm（满足多路报警支持、内部系统对接、邮件、掌信、短信等）◆调用链跟踪（满足应用内、应用间调用链跟踪、内部中间件升级等需求.)◆统一日志搜索（实现在线应用日志、Nginx日志等集中日志搜索和控制等）◆...监控目标从“应用”的角度，我们将监控系统分为：应用外，在应用程序内，以及应用程序之间。如下图所示：应用外：主要来自应用所在的运行环境（硬件、网络、操作系统等）应用内：主要来自用户对应用内部不同方面的请求（JVM、URL,Method,SQL等）应用室：主要从分布式调用链跟踪（依赖分析、容量规划等）角度进行监控。系统。监控系统之所以取名罗马，是因为：1、罗马不是一天完善的（在线监控指标的相关指标需要逐步完善）；2.条条大路通罗马（罗马通过各种数据采集方式收集各种监测数据3.根据神话记载，在特洛伊战争之后，特洛伊人的一些后裔伪造了古罗马帝国（一个故事的延续和诞生一个新项目）。完善的监控体系将涵盖IT领域监控对象的方方面面。从国内外各家互联网公司的监控发展来看，很多公司将不同的监控对象分给不同的研发团队进行处理，但这样做会带来一些问题：人力资源浪费、系统重复建设、数据不一致资产、实施全链路监控的难点。目前各家公司在监控领域采用的解决方案如下图所示：如图所示，罗马监控系统希望借鉴各方优秀的架构设计理念，将不同的监控维度融合在一起，实现“监控系统一体化”。”、“全链路”等。高可用架构之道面对每天超过40亿次的WiFi连接请求，每个请求都会经过内部几十个微服务系统，每个微服务的监控维度都会涉及应用外、应用内、应用间等多个应用，目前Roman监控系统每天需要处理近1000亿次的索引数据和近100TB的日志数据，Roma如何处理海量的数据？监控数据量大吗？接下来笔者将从系统架构设计的角度带大家一一分析架构原则监控系统访问用户应用需要满足如下图所示的五点：?性能影响:尽量减少对业务系统性能的影响(CPU,Load,Memory,IO等)?低侵入性：业务系统接入方便（无需编码或极少编码即可实现系统接入）?无内部依赖：不依赖于公司内部核心系统（避免依赖系统故障造成相互依赖）?单元化部署：监控系统需要支持单元化部署（支持单元化多机房部署）?数据集中化：对监控数据进行集中处理、分析、存储等（便于数据统计等）。功能职责及用途描述如下：Roma整体架构分为不同的处理环节：数据采集、数据传输、数据同步、数据分析、数据存储、数据质量、数据展示等，主要用于不同阶段数据流处理的技术栈如下图所示：应用内监控的数据采集主要是通过客户端和代理所在机器上的代理建立TCP长连接来实现的，代理还需要能够通过脚本调度获取系统性能指标数据。面对海量的监控指标数据，罗马监控在每一层通过预聚合的方式进行汇总计算。例如客户端同一个URL请求的指标数据在一分钟内聚合计算，统计结果为一条记录（分钟内相同）请求累加计算，通过占用极少的内存，减少量datatransmission），对于一个访问和使用Rome的系统来说，完全可以根据实例数、索引维度、采集频次对监控数据的规模进行统计计算。通过各层分层预聚合，减少海量数据在网络中的数据传输，降低数据存储成本，节省网络带宽资源和磁盘存储空间。应用内监控的实现原理（如下图）：主要由客户端采集，在应用内部的各个层级进行拦截统计：URL、Method、Exception、SQL等不同维度的指标。应用监控中各维度指标的数据采集流程如下图所示：针对不同的监控维度定义不同的计数器，最终通过JMX规范进行数据采集。数据传输数据传输TLV协议支持二进制、JSON、XML等类型。每台机器上都会部署一个代理（与客户端建立TCP长连接）。代理的主要职责是数据转发和数据收集（日志文件读取、系统监控指标获取等）。agent获取到性能指标数据后，会发送至kafka集群，在每个机房独立部署一个kafka集群，用于监控指标数据的发送缓冲区，方便后端节点执行数据消费和数据存储。为了实现高效的数据传输，我们对报文处理的压缩方式进行了对比分析，最终选择了压缩比高的GZIP方式，主要是为了节省网络带宽，避免大量监控占用机房网络带宽数据。各节点间数据通信时序图如下图所示：建立连接->读取配置->收集调度->上报数据等。数据同步海外运营商较多，公网覆盖质量参差不齐。再加上运营商的互联策略不同，付出的代价将是高时延、高丢包的网络质量。对整体网络质量有正确的预期。比如需要监控海外机房的应用，需要在海外建立站点（主机房），海外主站与国内主站互联。另外，需要对监控指标数据进行分层处理，比如在采集实时、准实时、离线等不同需求的指标数据时进行分类、划分（控制不同需求、不同数据规模等）索引数据调整采样策略）由于各产品线的应用部署在多个机房，为了满足每个应用在多个机房监控的需求，罗马监控平台需要支持在多个机房的应用监控场景多个机房，为了避免每个机房重复部署各个罗马组件，方便监控指标数据统一存储，统一分析等，每个机房的监控指标数据最终都会同步到电脑上机房，最后在机房进行数据分析和数据存储。为了实现多机房数据同步，我们主要使用kafka跨数据中心部署的高可用方案。因为当MirrorMaker节点出现故障时，数据复制延迟比较大，动态添加主题需要重启进程，黑白名单管理是完全静态的。虽然uReplicator针对MirrorMaker做了很多优化，但是经过大量的测试，我们还是遇到了很多问题。我们需要有动态管理MirrorMaker进程的能力，不希望每次都重启MirrorMaker进程。数据存储为了满足不同监控指标数据的存储需求，我们主要使用HBase、OpenTSDB、Elasticsearch等数据存储框架。我们在数据存储上踩过很多坑，主要归纳如下：集群划分：根据各产品线应用的数据规模，合理划分在线存储资源。比如我们的ES集群是按照产品线和核心系统、数据大小等来划分规划和切分的；?性能优化：Linux系统层优化、TCP优化、存储参数优化等；?数据操作：数据批量存储（避免单条记录存储），例如对于HBase数据存储可以通过客户端进行数据缓存，在客户端批量提交，避免客户端与RegionServer频繁建立连接（减少RPC请求的次数）数据质量我们的系统在不断地产生大量的事件，服务之间的链接消息和应用日志，这些数据在被处理之前需要经过Kafka。那么，我们的平台是如何实时审计这些数据的呢？为了监控Kafka数据管道的健康状况，审计流经Kafka的每条消息，我们调研分析了Uber的开源审计系统Chaperone，经过各种此类测试，我们决定通过自研实现需求，主要是因为我们希望在任何节点的任何代码块中都有数据审计的需求，同时需要结合自己的数据管道特性来设计实现一系列的目标：数据完整性和时延；数据质量监控需要接近实时；便于快速定位数据问题（提供诊断信息帮助解决问题）；监控和审计本身是高度可信的；监控平台服务高可用、超稳定；为了满足上述目标，数据质量审计系统的实现原则：按照时间窗口聚合审计数据，统计一定时间内的数据量，尽早发现数据丢失、延迟和重复尽可能准确。同时对去重、迟到、乱序数据有相应的逻辑处理，以及各种容错处理，保证高可用。数据展示为了实现监控指标的数据可视化，我们开发了前端数据可视化项目。同时，我们还集成了外部第三方开源数据可视化组件（grafana、kibana）。我们在集成过程中遇到的问题：权限控制问题（内部系统SSO集成）主要通过自研权限代理系统，去除kibana官方提供的相关插件，改进自研ES集群解决监控插件等核心功能及实现系统监控我们的系统监控主要使用OpenTSDB作为数据存储，Grafana作为数据展示。对于TSDB数据存储层，我们通过读写分离来降低存储层的压力。在TSDB与Grafana集成的过程中，我们也遇到了数据分组展示的问题（查询海量索引数据下分组字段值，通过建立独立的索引项进行数据查询），如下图所示某台机器系统的监控效果：应用监控对于每一个Java应用，我们提供不同的监控类型用于应用内指标数据的指标。业务监控对于业务监控，我们可以通过编码埋点、日志输出、HTTP接口等不同方式收集业务监控指标，支持多维度的数据报表展示，如下图所示：我们的业务监控是通过自助服务让所有应用方方便的访问，如下图监控项定义：日志查询为了支持研发人员在线排查问题，我们开发了统一的日志查询平台，方便研发人员查询在海量日志中定位问题。未来展望随着新兴IT技术的快速发展，罗曼监控系统的未来演进：?多语言支持：满足多语言监控需求（性能监控、业务监控、日志搜索等）?智能监控：提高及时报警安全、准确等避免告警风暴（ITOA、AIOps）容器化监控：随着容器化技术的验证和落地，容器化监控打开布局；综上所述，Roma是一个可以对应用进行深度监控的全链条监控平台，主要涵盖应用外、应用内、应用间等不同维度的监控目标，如应用监控、业务监控、系统监控、中间件监控、统一日志搜索、调用链跟踪等，可以帮助开发者进行快速故障诊断、性能瓶颈定位、架构排序、依赖分析、容量评估等任务。【原创稿件，合作网站转载请注明原作者和出处为.com】
