Elastic Stack (原名 ELK Stack):Elasticsearch：一个实时的分布式搜索和分析引擎。Logstash：用于日志收集、处理和转发的工具。Kibana：一个针对 Elasticsearch 的数据可视化工具。这三个组件联合起来，可以收集、存储、处理和可视化日志数据。Graylog: 一款基于Elasticsearch...

日志的规则和标准和日志平台产品本身没有任何关系，日志的采集信息是通过应用改造实现的，应用按将那些信息放到日志中，之后日志平台通过这些信息进行查询分析。

对于 AIX 平台来说，目前确实只能改用其他非 golang 语言编写采集工具了 （实际上 AIX 上目前也有 golang 支持，但是我们验证过自行编译采集端过不去……） ，比如 java、python、perl 等。注意 AIX 上这些语言的版本一般也不太新，所以选型的时候依然要谨慎测试。此外，如果环境内 AI...

1.日志采集后需要考虑海量数据留存问题，这涉及到日志压缩，日志裁剪，不同日志保存不同时间等问题2.另外日志价值不仅在于搜索和留存，通过好的日志分析工具，可以更好挖掘日志价值，如可以做单笔交易快速追踪，交易量/耗时/成功率的实时监控，业务运营分析等等...

根据我行的实施经验，主要从以下三个方面，给出一些拙见，首先是要优化日志分析的协议，我们最初采用的是开源的ElasticSearch，当每天日志量超过1T级别之后，搜索日志变动非常困难，我们采用了厂商经过优化之后的处理引擎，性能问题得到了较大的提升。第二是在线日志量保存7天周期，日常检...

其他银行不清楚，但是我们是采用纯应用日志方式实现的全链路，和网络流量没有任何关系，其他探针方式实现也不是基于网络流量获取的，通过在应用侧部署探针方式获取应用交易情况，之前银行都是通过网络流量旁路方式进行APM，但是这种基于网络旁路实现的平台不适合微服务和云，不破不立，...

tracertid是业务的全局流水号，由前端渠道应用形成，并且将tracertid进行下传到后端应用，业内的规范基本上参照google daaper论文标准，通过应用代码自行改造生成。tracertid是应用生成，和应用架构没有关系，集中式和分布式都可以生成。...

日志平台本身并不重要，在早期日志量不大的时候可以采用elk开源框架搭建，日志量达到一定量级可以替换成商业化产品，日志平台建设的最难点是要形成统一的日志规范，把后续的全链路平台，智能运维平台考量进去，形成统一的日志改造标准，让所有应用开发人员都能接纳和执行，并且对现有的...

我们的做法是在业务层定义一致的描述，在组织内推广，在实现上基于不同的方式实现，譬如C应用会自己输出日志，而Java应用更多采用无侵入的方案，如skywalking进行字节流的采集。

链路日志在高采样率情况下，日志量可达TB/天以上，交易笔数多，分组统计大，如果全靠入库后再进行统计，对搜索引擎的压力会很大，建议考虑引入Flink流处理引擎，在日志ETL过程中就进行流式计算；但链路计算场景会比较较多，计算过程比较复杂，需要用到很多流式计算管道，所以可以考虑在Flink流...