【IT老齐069】日志收集架构
【IT老齐069】日志收集架构
标准ELK

- 优点:部署最简单组件使用最少
- 缺点:由于 Logstash 同时兼顾了收集和解析的工作所以比较耗 CPU 和 内存资源,只适合服务器资源丰富的场景,否则容易容易造成性能下降甚至影响应用本身的正常工作
TCP推送

- 优点:对比架构一各个应用服务器不需要额外部署其他组件减少了应用服务器的负载压力
- 缺点:基于SDK开发,有代码入侵使应用与 Logstash 耦合,不易扩展。
EFK
Filebeat是用千转发和集中日志数据的轻量级传送工具。Filebeat监视您指定的日志文件或位置,收集日志事件,并将它们转发到Elasticsearch或 Logstash进行索引


- 优点:代码无入侵并且对应用服务器的资源占用少,是目前最常用的互联网应用日志架构
- 缺点:日志数据共享困难,FileBeat 只能配置一个 output 源
KEFK

- 优点:性能最好,而且消息队列易于共享数据
- 缺点:组件最多,维护成本大
拓展
Loki+promtail ,loki 前面怼一层redis 做查询缓存,收集起来的日志可以存本地,也可以怼到oss或者s3. 查询界面用grafana 一套下来资源占用很少。也可以重复利用已有的组建。后期cdc etl 可以直接取s3
注意
- 对于运维团队来说需要和业务进行沟通,如日志的存放目录,收集器的配置定义,异常日志怎么收集,然后做一个自动化脚本方便添加机器的时候自动安装
- 需要考虑如果使用了logback 通过网络写日志,要不要双写,因为有存在断网的情况
- 考虑是否需要分布式的日志收集,如果需要那就考虑下有没有一个强大的运维团队来支撑,如果没有能不能通过定时拉去日志的方式来供研发同学查看

浙公网安备 33010602011771号