Skip to content

日志分析架构

日志分析常见架构

备注:本小节非原创,原文地址在参考资料中

基础的ELK架构

elk_architecture_1

  • 优点:搭建简易、易于上手。
  • 缺点:Logstash消耗资源大,运行占用CPU和内存高,没有消息队列缓存,容易出现数据丢失隐患。
  • 应用场景:适用小规模集群方案。

引入消息队列的架构

elk_architecture_2

  • 优点:引入消息队列机制,均衡了网络传输,从而降低了网络闭塞尤其是数据丢失的可能性。
  • 缺点:依然存储Logstash占用系统资源过多的问题。
  • 应用场景:适用较大的集群方案。

引入Logstash-Forwarder架构

elk_architecture_3

  • 优点:解决了Logstash占用系统资源过多的问题。Logstash-Forwarder与Logstash间的通信是SSL加密传输,起到安全保障作用。
  • 缺点:由于SSL加密传到从而导致的限制性。
  • 应用场景:适用较大的集群方案。

引入Beats系列架构

elk_architecture_4

  • 优点:提高了扩展性和灵活性,Beats系列也方便进行二次开发。

我的日志分析架构

日志分析架构V1.0

elk_analysis_iptables_1

  1. 配置好Nginx日志格式;
  2. 使用rsyslog将Nginx日志传输到Kafka中;
  3. Logstash消费Kafka消息,并对消息进行格式化处理后存储到ES中;
  4. Kibana对ES中的消息进行图表展示并提供查询功能;
  5. 同时使用Python ElasticSearch模块对数据进行查询分析,得到一些可疑的IP并将这些可疑IP存储到数据库中;
  6. 利用情报数据分析可疑到IP,设定规则,当触发规则时,使用ansible批量执行iptables命令封禁该IP;
  7. 封禁的同时记录该IP触发的规则,封禁时间;
  8. 根据不同的规则设定不同的封禁时间,当超过封禁时间时,使用iptables解封该IP;
  9. 为避免误杀,需要提供手动解封的能力;

备注:适用于小公司,且针对CDN、SLB不复杂的网站架构。

日志分析架构V2.0

log_analysis_architecture_v2.0

  1. 数据层面可以是多种多样的,不一定仅限于access_log,也可以是主机日志、安全设备日志等。
  2. 采集层推荐使用Beats系列,与ELK融合度高,也便于拓展。
  3. 分为离线分析与准实时分析两条线,离线分析主要是为了给准实时分析提供规则。
  4. 准实时分析的结果需要运营人员进行处理。

备注:既适用于常规的日志分析,也适用于风控系统的分析方式

参考资料

ELK简介及架构分析