其他银行不清楚，但是我们是采用纯应用日志方式实现的全链路，和网络流量没有任何关系，其他探针方式实现也不是基于网络流量获取的，通过在应用侧部署探针方式获取应用交易情况，之前银行都是通过网络流量旁路方式进行APM，但是这种基于网络旁路实现的平台不适合微服务和云，不破不立，...
目前，各大银行纷纷将数字化转型作为战略目标推动企业架构升级，传统企业架构也逐渐从单体架构到微服务架构迁移，而新兴零售和对公场景的兴起，也进一步拓展了企业架构的规模和复杂性，可独立部署和运行的服务越来越多，弹性扩缩容、灰度发布的需求也逐渐增多，随之而来，保障业务连续性...
(more)我们的规划路径是，首先要制定统一的日志规范和标准，需要考虑的因素非常多，比如有应用需求、业务需求、监控需求、智能化需求、数据化需求等等；再接着要建立统一的日志平台，在日志平台上实现统一日志检索、业务逻辑告警、问题告警、全链路追踪等功能；之后可以实现一些数字化需求...
日志平台本身并不重要，在早期日志量不大的时候可以采用elk开源框架搭建，日志量达到一定量级可以替换成商业化产品，日志平台建设的最难点是要形成统一的日志规范，把后续的全链路平台，智能运维平台考量进去，形成统一的日志改造标准，让所有应用开发人员都能接纳和执行，并且对现有的...
匿名用户
硬件日志一般发送给原厂，厂商加密打不开，只能原厂打开！
有一些日志审计系统上线后，通过日志审计平台看！
上面的回答已经说的很详细，作为日志分析领域的厂商 日志易 也对splunk很佩服。老牌的日志分析厂商，如果非要在splunk与ELK之间选择，还是使用splunk吧。ELK 在入库、搜索方面完全不是splunk对手，可以说不是在一个层级上。另外也建议关注一下 日志易，目前在某些方面比splunk...
整体上涉及容器平台应用日志管理规范1、应用日志和中间件日志的日志路径均进行规范化配置2、容器启动挂载卷，应用日志和中间件日志均规范化输出至日志挂载卷3、挂载卷：1）存储分散管理，容器挂载SLAVE节点的磁盘卷，由于容器重启后漂移，节点管理困难；2）存储集中管理，各SLAVE节点挂载...
elk 常用组件, 上层业务封装还需要求其他组件完成日志分析 elk + redis + mysql 热点数据 , 热点分析等等, 看你的业务是什么模式和 开发人员偏好
