由于目前云、微服务等架构主要都是采用复用硬件设备资源的方式部署,全链路的日志采集(如采用抓流量的方式)某些交易日志可能会因为在设备内流动(如虚机的几个服务器流量不出机头到达不了物理交换机)。如何解决这类问题?
如果采用探针部署,对系统本身又会造成性能损耗,尤其是在高并发高负载的场景。如何解决
在云和容器化的架构下,流量采集方式必然会遇到问题里面提到的 抓包问题,通过日志采集是目前来看比较好的解决方案
采用探针部署对系统本身又会造成性能损耗其实是可控的,毕竟是读操作,另外探针如果加上cpu,带宽等控制条件,对系统的造成的风险也会降低
另外如果考虑到合规留存,故障定位的因素,日志打印、日志集中、日志分析是避免不了的
综上,既然避免不了采集日志,那就解决磁盘IO问题吧
是的。传统的抓流量方式解决不了这个问题。
考虑性能损耗问题的话,相比探针来说,还是建议采用应用自己打日志的方式,因为打日志的行为相对简单,对系统性能带来的损耗非常容易评估计算,打日志时还可以通过内存缓冲区合并一下,减少 IO 次数,损耗就更小了。而探针内部逻辑太多,哪怕你正儿八经做了压测,也保不齐什么超过测试集范围的业务逻辑会触发什么新问题。
其他银行不清楚,但是我们是采用纯应用日志方式实现的全链路,和网络流量没有任何关系,其他探针方式实现也不是基于网络流量获取的,通过在应用侧部署探针方式获取应用交易情况,之前银行都是通过网络流量旁路方式进行APM,但是这种基于网络旁路实现的平台不适合微服务和云,不破不立,建议不要采用老的平台去适配新架构。
收起