日志的价值目前在大部分银行没有很好的发挥作用,作为获取业务和应用最好的数据源,日志分析的价值巨大,目前银行使用日志的场景主要分为以下几个方面,第一可以根据应用日志,进行业务的交易情况分析决策,业务监控大屏展示,业务
没有全局流水号,没办法将业务场景进行串联,关联不了业务交易,不管是基于日志方式还是三方探针方式,全局流水号是必须的条件。
我们单位是根据google的dapper规范按照自身的特点进行了字段的制定,包括链路追踪的基本字段要求,比如全局流水号,应用标识,节点标识,时间戳,还预留了一定的字段考虑后续的灰度发布、应用自身其他需求,制定规范的时候不光要考
全链路追踪和ESB本身不发生冲突,可以两种实施方案,第一种可以将ESB作为链路本身的一个节点考虑,通过日志报文或者探针监控ESB节点的状态,第二种就是将ESB作为技术平台进行透传,和网络设备,负载均衡设备一样,不在全链路中进行
我们的规划路径是,首先要制定统一的日志规范和标准,需要考虑的因素非常多,比如有应用需求、业务需求、监控需求、智能化需求、数据化需求等等;再接着要建立统一的日志平台,在日志平台上实现统一日志检索、业务逻辑告警、问
我补充下,还有一种方式是通过应用日志的改造,不用三方探针,和底层环境无任何依赖。
通过日志采集的全链路追踪功能,本身就没有传统的网络旁路方式的APM实时性高,但还是可以通过采用高性能的日志分析平台、投入硬件配置来达到秒级的延时,对实时的交易监控还是可以接受的。
elk是日志平台的标准架构,能够满足基本的采集、传输和分析,如果有其他的需求可能需要其他平台,比如全链路功能,比如智能运维平台。日志是原始数据,好比是是食材,你需要什么口味就需要什么调料和厨具。
日志的规则和标准和日志平台产品本身没有任何关系,日志的采集信息是通过应用改造实现的,应用按将那些信息放到日志中,之后日志平台通过这些信息进行查询分析。
根据我行的实施经验,主要从以下三个方面,给出一些拙见,首先是要优化日志分析的协议,我们最初采用的是开源的ElasticSearch,当每天日志量超过1T级别之后,搜索日志变动非常困难,我们采用了厂商经过优化之后的处理引擎,性能问题
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30