如果通过日志报文采集方式实现的全链路追踪平台和传统的APM相比来说会有一定的延迟性,需要建设强大的统一日志处理平台,提升日志采集、传输、处理的效率来缩短业务监控的延时性。
1.性能方面:第一要考虑到采集端agent的性能(既要保证对服务器cpu使用率,也要保证采集的速度),第二要考虑解析的速度,优化解析效率,第三要考虑数据入库(es或beaver)性能,结合实际使用情况配置模版或其他优化项,最后整条链路下来所消耗的时间,要考虑集群整体负载,券商的交易高峰压力会比其他行业更为明显。
2.稳定性方面:结合性能方面进行集群的阈值和性能拐点的测试;
3.架构方面:有条件的尽量做到日志的冷热分离;有实际计算指标需求的情况增加flink、spark streaming等组件。
收起如果实现全局应用监控,传统APM性能容量会是一个不小的挑战,如果全面上云后应用实例超W级别后,APM存在一定的瓶颈。
全链路监控本人经验,日超20TB的情况下,如下平台设计可以做到分钟级,已经能很好满足全局应用全链路监控的需求。
在线:Spark Strenming
离线:Spark
时序统计:ES
明细数据:Hbase
实时架构图:Neo4j
其他:Mysql
日志平台是企业的IT技术基础底座,后续的微服务治理、智能化运维等工作的基础平台,大部分企业的日志体系都是基于elk模式搭建的,开源的产品在日志量可控的量级上没有任何问题的凸显,主要有以下三部分的建议,一是如果日志量每天达到T级别就需要对es框架进行优化,但是这部分工作可能需要专业的公司或者团队来完成,一般企业可以采用商业化的产品,比如日志易的beaver,日志处理性能比es要提高2倍以上。二是要对日志进行归档处理,减少在线分析的日志量,根据应用特点在日志平台保留一周左右的日志量,其他历史日志归档到对象存储或者分布式存储上保存。三是可以提升硬件的性能,增加更多日志分析节点或者采用性能较高的服务器作为日志节点。
收起