在云和容器化的架构下,流量采集方式必然会遇到问题里面提到的 抓包问题,通过日志采集是目前来看比较好的解决方案采用探针部署对系统本身又会造成性能损耗其实是可控的,毕竟是读操作,另外探针如果加上cpu,带宽等控制条件,
目前在linux,windows,容器,arm 架构等前提环境情况下go 语言开发的agent 基本够用的在维护方面,agent的维护需要考虑到几方面:(1)agent的批量部署,批量升级,批量下发策略(2)agent性能的控制,句柄的控制,带宽的控制(3)agent采集
银行日志分析场景就非常多了:1.故障快速溯源:免登录到后台服务器查询日志,在日志平台上实现关键字秒级检索2.全链路追踪:自动追踪单笔交易全链路环节,一键定位故障节点3.业务黄金指标的监控告警和异常检测:按交易类型和渠道
对于应用层,各应用模块可以通过链路追踪方式进行端到端串联 对于逻辑层(数据库,中间件),物理层(虚拟机,物理机,容器),网络层(F5,交换机)可以通过监控单节点性能和日志方式,把性能和日志都发送到统一日志平台,结合时间维度和CMDB信息
建议采用json格式输出,便于扩展,统一时间戳和日志等级; traceid,parentid,spanid可以实现单笔交易的串联,此外建议制定规范的时候明确返回码类型区分业务错误(如余额不足)和系统错误(如数据库连接失败)提供成功率统计的准确性
容器日志有专门容器采集解决方案,当把容器日志采集到日志平台后,后续的链路追踪分析就跟普通虚拟机,物理机是一样的处理方式了
应用日志改造或者业务链追踪是未来必须经历的一个阶段,需要做好长期作战的准备,必须迈出第一步;建议可以先选择新开发的业务作为试点,其他业务系统在需求升级过程中再逐步推广
全链路日志一般可以参考dapper,基于skywalking或者zipkin进行改造,改造后会单独输出一份全链路追踪日志,但对于原有业务日志,大部分都没有流水号,可能只有线程号;因此我们建议在全链路追踪日志里面增加一个扩展字段,把原有业
1.首先要满足日志留存的合规要求,这就要求日志平台能兼容各种数据源的采集,包括虚拟机、容器、数据库,兼容各类操作系统 2.能根据日志类型按需制定留存计划,能进行日志冷温热数据降存处理 3.能实现快速数据检索,快速故障
1.采集速度,采集端的性能消耗,采集端对采集文件大小,采集文件数量的可控性 2.ETL日志清洗的速度 3.搜索引擎的入库速度,搜索速度,大分组统计速度、长周期日志搜索的健壮性、以及日志存储空间
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30