统一监控平台方案

1、统一监控平台方案一、背景公司软件系统、硬件繁多，没有进行统一管理和监控，急需一个统一的监控系统进行全盘监控和管理。进行系统故障预警和告警，保障系统健康稳定运行。如今的服务通常由很多不同系统模块组成，他们之间相互调用并通过API调用外部服务。每个交互是 如何被执行的通常是一个黑盒。怎样跟踪和监控这些模块之间的调用流并提供清晰的视图来定位问题区域 和潜在瓶颈。如何能够在多个系统同时异常时，快速定位到异常的根源。二、总体方案1.监控内容各个系统日志监控、方法监控、JVM监控、中间件监控、中间件监控（ZK、ES、Kafka）、数据库监控、硬件监控（服务器等）2.技术选型2.技术选型Flume+Kafk

2、a+Spark+Elasticsearch+ 自研 UI埋点+pinpoint+zipkin 支持3.监控项目版本划分3.监控项目版本划分V1.1 :实现日志收集，检索和分析功能V1.2 :实现硬件资源管理V1.3 :实现方法调用跟踪V1.4 :实现调用链路跟踪4.监控平台架构图应用异常监控（method调用异常）日 志 监 控 系 统应用性能监控中间件监控中间价4.监控平台架构图应用异常监控（method调用异常）日 志 监 控 系 统应用性能监控中间件监控中间价es、kafka）系统资源监控服务器监控各个子系统（业务日志、系统应用组件、JVM .）告警系统：针对监控的数据进行异常告警（ma

3、il、短信等方式）5.云化监控平台设想5.1目前有很多系统或者应用都是虚拟机应用，云容器应用是后期发展趋势，企业私有云能够帮 助企业实现节约项目实施成本。目前设计的监控平台为了兼容云应用系统，需要考虑云统一监控系统方案。目前主流的云平台采用kubernetes+docker技术实现。Kubenetes实现对docker容器的统一管理 和调度以及编排操作，统一监控平台怎样去支持云平台应用的监控？Spark RDD (core)统一监控系统架构图UI1JKubernetes+Docker 云平台应用自研agentxrSpark RDD (core)统一监控系统架构图UI1JKubernetes+D

4、ocker 云平台应用自研agentxrL应用1应用n虚拟机平台应用Kafka是一个大型的消息队列缓冲区，是个集群模式的消息缓冲区，可以存大量的缓冲数据，如果我们 的流量较大的时候会用到kafka做一个消息缓冲作用，形成一些原始的交易数据。缓冲完之后，会再进入 到实时计算框架spark streaming中，spark streaming会消费kafka里面的这些数据，从spark streaming 这一段的分支，分别是做监控的思路K8s支持应用实例根据资源进行自动扩容和缩容K8s支持应用快速灰度发布和回滚K8s 支持.三、日志监控方案丰富的采集数据源支持File 文件（tail,dir）e

5、s、 kafka, http post统一日志格式解析日志存储和老化日志搜索和分析Traceid的组成部分，包括IPv4、毫秒时间、顺序数、标志位、进程PID五部分。四、监控代码埋点优点：代码埋点的优点是一方面使用者控制精准，可以非常精确地选择什么时候发送数据；同时使 用者可以比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。缺点：埋点代价比较大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必 须是技术人员才能完成；其次是更新的代价比较大，每一次更新埋点方案，都必须改代码。在埋点时输出日志到本地，通过日志Agent读取日志，然后再通过实时计算的处理层主动拉取日

6、志 再进行处理。该方案直接复用应用机器存储日志，并且采用拉模式防止流量冲击过大。利用消息队列的方式，埋点层主动发送消息，消息队列对消息进行存储，数据处理层从消息队列上 订阅消息。这种方案可做到数据不丢，且主动推送可以提高实时性，环境适应性强；但这种解决方案的成 本是比较高的。五、全链路性能监控全链路性能监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展 现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。一个请求完整的调用链可能如下图，经过多个系统服务，调用关系：现览器请求关注各个调用的各项性能指标，比如吞吐量（TPS），响应时间及错误

7、记录等 吞吐量:根据拓扑可相应计算组件、平台、物理设备的实际吞吐量。QPS（TPS）=并发数/平均响应时间响应时间:包括整体调用的响应时间和各个服务的相应时间等错误记录:根据服务返回统计单位时间异常次数Eariid =日Trace H-M 9pn tl-BTwe Ikl- X14 - CTm Idid-iCfceni SeiiH * IpTfamEariid =日Trace H-M 9pn tl-BTwe Ikl- X14 - CTm Idid-iCfceni SeiiH * IpTfam Id K 由F*% id 蛆 Cienl fcfllrm Id- K 0ce Id 三 F CltntR

8、ociwdZipkin调用链路一条链路通过Trace Id唯一标识，Span标识发起的请求信息，各span通过parent id关联起来Zipkin span 数据流Zipkin span 数据流六、方法（Method）调用监控,pinpointPinpoint-Collector：收集各种性能数据Pinpoint-Agent：和自己运行的应用关联起来的探针HBase Storage：收集到的数据存到HBase中Pinpoint-Web:将收集到的数据显示成WEB网页形式ErfwOarg 祁刑 n 色 cuina come-mois.iprodgthjy占1扩理尊工 tirg 版mnglraf

9、ngm.M!口.巽由回巾0关败33Q EmhuaweLC!微conlrcJ|flrp-irnAicteori：noier 洌忙o况0 suR.nel.w.praiwoi tuip hHptirfconriMUGP gtrllnpwi.risas0 crg pache calajnajccce 制！indarcIhastvNhi史 In.UserAahilste祚i10 spnngamancet.sffvEfiTraimeMr.9 期0w2 wnLhuafAei.mmapLLsaTcnirD定虹.G 成功i息 tstli目垣七、JVM监控JVM指标：堆内存heap_init：堆内存初始字节数 h

10、eap_max :堆内存最大字节数 heap_commited：堆内存提交字节数 heap_used :堆内存使用字节数 非堆内存non_heap_init:非堆内存初始字节数 non_heap_max:非堆内存最大字节数 non_heap_commited：非堆内存提交字节数 non_heap_used:非堆内存使用字节数 直接缓冲区direct_capacity :直接缓冲区总大小（字节） direct_used :直接缓冲区巳使用大小（字节） 内存映射缓冲区mapped_capacity :内存映射缓冲区总大小（字节） mapped_used：内存映射缓冲区巳使用大小（字节） GC （垃圾收集）累计详情GcPsMarkSweepCount:垃圾收集 PS MarkSweep 数量 GcPsScavengeCount：垃圾收集 PS Scavenge 数量 GcPsMarkSweepT