工作经验分享-vivo链路监控

0. 监控
    1. 监控系统：一个监控系统应该至少有三类输出：紧急警报，工单，日志
    2. 为了更好的满足用户的需求，我们搭建了一套一体化监控系统，从硬件，网络，服务，应用全覆盖链路监控
        1. 紧急警报
            1. 检测中心：配置检测规则（自配/统一）进行检测
            2. 告警中心：对异常信息进行分发/收敛到具体用户
            3. 智能预警能力（研发中）:根据历史记录发生异常趋势快速通知用户避免异常问题发生
        2. 工单
            1. 故障管理平台：对所有故障工单进行同意管理
            2. 故障定位能力（研发中）：根据发生异常快速定位到异常发生点
        3. 监控场景能力（采集、计算、存储、分析）
            1. 基础监控:覆盖主机、容器各项基本指标，硬件层面到各个指标发生异常都可以第一时间进行探查
            2. 拨测监控:网络联通行，服务可达性监控
            3. 通用监控:覆盖服务各种自定义维度监控，满足各种自定义场景监控
            4. 调用链: 服务调用监控，JVM指标监控（具备鹰眼各项基本功能）
            5. 日志监控（SLS）: 使用log agent进行日志收集，并对异常日志进行分析
    3. 一个监控系统能力评价
        1. 准确，稳定，延迟，覆盖面，告警能力，数据分析能力
1. 调用链    
    1. 背景  
        vivo互联网发展速度较快，应用相互依赖较多，故障发生问题难以定位，为了更好的支持业务飞速发展，开始组建调用链团队进行研发工作，之后整体框架进行不断演进。  
        调用链系统研发理论基础是《Drapper, A Large_Scale Distribute System Tracing infranstructure》,参考业界较为成熟的监控系统，不限于鹰眼（EageEye）,分布式服务跟踪系统（SGM），实时应用监控平台（CAT），Zipin，Pinpoint，SkyWalking，博睿等。后面参考SkyWalking的埋点方式进行埋点采集
    2. 架构
        1. 架构概览
            

        2. 演进 
            1. 计算存储层演进（Flink + ES -> kafkaStream/kafka/Druid）
                1. flink/ES
                    1. 稳定：低数据可以短时期保持数据平稳计算输出，但是大量计算，长时间会触发Flink内存缺陷，导致反复重启失败（必然造成短时间延迟），并且延迟会导致产生无数据告警或者告警丢失；
                    2. 延迟：flink流计算时间窗口处理数据，分钟粒度需要double时间输出存储，总体延迟3分钟
                    3. 资源：flink属于较重框架，适用于复杂计算场景。监控场景属于单一场景，造成部分资源浪费
                    4. 瓶颈：ES写入达到瓶颈（扩集群，切模块），流量不能长远发展
                    5. 架构统一：除调用链场景，通用监控使用kakfaStream + druid 抗住大流量数据，为保证架构统一
                2. KafkaStream、kakfa、druid
                    1. 稳定：kakfaStream 只对上报数据进行格式转换，可以长时间稳定运行
                    2. 延迟：摄入时间延迟（1分钟~5秒钟层级）；告警延迟可以达到分钟级别
                    3. 资源：Druid预处理压缩，节省存储资源；Kafka只对格式进行转换，所占资源较低
                3. 切换后的局限性
                    1. 查询延迟
                        1. Druid查询性能不如ES,同一请求在Druid查询效果较差
                            1. 将查询时间打散，大查询切成小查询
                            2. 将存储切dataSource
                            3. 增加提供查询的节点   

   
2. 核心领域概念（Trace、span）  
    1. Trace：相同业务逻辑的调用请求经过的分布式系统完整链路
        1. 使用traceId 标志某一次调用，分布式唯一，串联整个链路，因为某次调用场景会规避逻辑分支，所以不能完整反应trace链路，只有相同的业务逻辑多次请求调用触达的链路，合成后才算一个完整的trace链路
    2. Span：某一次局部请求调用
        1. 一次调用会产生多个Span，span会组成一个不完整的trace，Span需要标记本次调用所在调用链路，以及所在链路所在的链路层级，SpanID同一层级原子自增，跨层级以 . 拼接，如 1.1，1.2属于同一层级，1.2，1.2.1属于跨层级调用

    
3. 调用链采集逻辑   
    1. vivo调用链系统定位是服务层监控，是vivo互联网监控体系中的重要一环，像服务异常，rpc调用耗时，慢SQL等都是基本的监控点。如果埋点采集的数据需要满足调用耗时监控，那么至少在RPC调用及慢SQL监控场景下，将以AOP的形式来实现埋点数据采集。vivo调用链除JVM的指标采集使用java.lang.management.ManagmentFactory,其他都类似以AOP形式来实现，以为为伪代码
    2. 
4. 基本技术原理    
    1. TraceId（30位）    
    2. 全链路透传能力
        1. 跨进程：比如HTTP请求我们可以将数据放入HTTP请求的header中，DUBBO调用可以放到RPCContext中往后传递，MQ场景可以放到消息头中；
        2. 跨线程池的数据传递是无法做到对业务代码入侵的，vivo调用链Agent是通过拦截ThreadPoolExecutor的加载，通过字节码工具修改线程池的ThreadPoolExecuator的字节码来实现的
    3. javaagent
        1. javaagent是一个JVM参数，调用链通过这个参数实现类加载的拦截，修改对应类的字节码，插入数据采集逻辑代码
            1. javaagent参数使用
            2. 了解JDK的instrumentation机制（premain方法，ClassFileformer接口）及MANIFES.MF文件中关于Premain-Class参数配置
            3. 字节码工具使用（ByteBuddy）
            4. 类加载隔离技术原理及应用
5. 调用链的难点与挑战
    1. 数据量大
        1. 采集
            1. 链路概率采集（万一采集）
            2. 全量采集异常链路帮助定位问题
            3. 提高主机链路采集比例（丢弃DB，中间件链路）
        2. 计算
            1. 监控数据呈指数式增长
            2. 增加核数已经达到集群分布式瓶颈
            3. 数据切分逻辑，按组件维度进行计算
        3. 存储
            1. 已经达到摄入瓶颈
            2. 分dataSource、切换Druid
        4. 稳定性
            1. 监控数据异常突增
        5. 延迟性
            1. 数据延迟
            2. 告警延迟
    2. 对数据挖掘
        1. 异常数据挖掘
        2. 故障快速定位