一、背景
公司软件系统、硬件繁多，没有进行统一管理和监控，急需一个统一的监控系统进行全盘监控和管理。进行系统故障预警和告警，保障系统健康稳定运行。
如今的服务通常由很多不同系统模块组成，他们之间相互调用并通过API调用外部服务。每个交互是如何被执行的通常是一个黑盒。怎样跟踪和监控这些模块之间的调用流并提供清晰的视图来定位问题区域和潜在瓶颈。如何能够在多个系统同时异常时，快速定位到异常的根源。 二、总体方案
1.
监控内容
各个系统日志监控、方法监控、JVM监控、中间件监控、中间件监控（ZK、ES、Kafka）、数据库监控、硬件监控（服务器等） 2.
技术选型
Flume+Kafka+Spark+Elasticsearch+自研UI 埋点+pinpoint+zipkin 支持 3.
监控项目版本划分
V1.1：实现日志收集，检索和分析功能 V1.2：实现硬件资源管理 V1.3：实现方法调用跟踪 V1.4：实现调用链路跟踪 4.
监控平台架构图
日志 监控 系统 应用异常监控（method调用异常） 应用性能监控 中间件监控（zk、 es、kafka） 中间价 系统资源监控
服务器监控
告警系统：针对监控的数据进行异常告警（mail、短信等方式） 5.
云化监控平台设想
5.1目前有很多系统或者应用都是虚拟机应用，云容器应用是后期发展趋势，企业私有云能够帮助企业实现节约项目实施成本。
目前设计的监控平台为了兼容云应用系统，需要考虑云统一监控系统方案。
目前主流的云平台采用kubernetes+docker技术实现。Kubenetes实现对docker容器的统一管理和调度以及编排操作，统一监控平台怎样去支持云平台应用的监控？
统一监控平台 方法调用监控 埋点JAR Pinpoint ZipKin 告警系统 日志监控 ES Spark Kafka Flume JVM监控 特殊组件监控 RestAPI health接口 硬件监控 各个子系统（业务日志、系统应用组件、JVM ...）
统一监控平台 UI ES集群 Spark RDD (core) Collector Kafka
Kafka Kafka Kubernetes+Docker 云平台应用 自研agent Pinpoint Pinpoint 虚拟机平台应用 自研agent Flume
埋点 Heapster Fluentd 埋点 埋点 埋点 应用1 应用n 应用1 应用n 统一监控系统架构图
1. Kafka是一个大型的消息队列缓冲区，是个集群模式的消息缓冲区，可以存大量的缓冲数据，如果我们的流量较大的时候会用到kafka做一个消息缓冲作用，形成一些原始的交易数据。缓冲完之后，会再进入到实时计算框架spark streaming中，spark streaming会消费kafka里面的这些数据，从spark streaming这一段的分支，分别是做监控的思路
2. K8s支持应用实例根据资源进行自动扩容和缩容 3. K8s支持应用快速灰度发布和回滚 4. K8s 支持...
三、日志监控方案
raw data
1. 丰富的采集数据源支持
Spark ES集群 自研UI Flume Kafka File文件（tail,dir） es、kafka，http post 2. 统一日志格式解析 3. 日志存储和老化 4. 日志搜索和分析
5. Traceid的组成部分，包括IPv4、毫秒时间、顺序数、标志位、进程PID五部分。
四、监控代码埋点
优点：代码埋点的优点是一方面使用者控制精准，可以非常精确地选择什么时候发送数据；同时使用者可以比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。
缺点：埋点代价比较大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必须是技术人员才能完成；其次是更新的代价比较大，每一次更新埋点方案，都必须改代码。
在埋点时输出日志到本地，通过日志Agent读取日志，然后再通过实时计算的处理层主动拉取日志再进行处理。该方案直接复用应用机器存储日志，并且采用拉模式防止流量冲击过大。
利用消息队列的方式，埋点层主动发送消息，消息队列对消息进行存储，数据处理层从消息队列上订阅消息。这种方案可做到数据不丢，且主动推送可以提高实时性，环境适应性强；但这种解决方案的成本是比较高的。
五、全链路性能监控
全链路性能监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。
一个请求完整的调用链可能如下图，经过多个系统服务，调用关系:
关注各个调用的各项性能指标，比如吞吐量(TPS)，响应时间及错误记录等 吞吐量:根据拓扑可相应计算组件、平台、物理设备的实际吞吐量。
QPS（TPS）= 并发数/平均响应时间
响应时间:包括整体调用的响应时间和各个服务的相应时间等
错误记录:根据服务返回统计单位时间异常次数
Zipkin调用链路
一条链路通过Trace Id唯一标识，Span标识发起的请求信息，各span通过parent id 关联起来
Zipkin span数据流
六、方法（Method）调用监控,pinpoint
Pinpoint-Collector：收集各种性能数据
Pinpoint-Agent：和自己运行的应用关联起来的探针 HBase Storage：收集到的数据存到HBase中
Pinpoint-Web：将收集到的数据显示成WEB网页形式
七、JVM监控
JVM 指标： 堆内存
heap_init：堆内存初始字节数 heap_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 数量 GcPsMarkSweepTime：垃圾收集 PS MarkSweep 时间 GcPsScavengeTime：垃圾收集 PS Scavenge 时间 JVM 线程数
ThreadCount：线程总数量
八、特殊组件监控
组件Rest接口数据 九、硬件监控 十、遗留问题
1. 2. 3.
kafka证书（SSL） flume fluentd 二者合一 Kafka的生产和消费封装
4.
负载均衡
因篇幅问题不能全部显示，请点此查看更多更全内容