日志分析架构
日志分析常见架构
备注:本小节非原创,原文地址在参考资料中
基础的ELK架构
- 优点:搭建简易、易于上手。
- 缺点:Logstash消耗资源大,运行占用CPU和内存高,没有消息队列缓存,容易出现数据丢失隐患。
- 应用场景:适用小规模集群方案。
引入消息队列的架构
- 优点:引入消息队列机制,均衡了网络传输,从而降低了网络闭塞尤其是数据丢失的可能性。
- 缺点:依然存储Logstash占用系统资源过多的问题。
- 应用场景:适用较大的集群方案。
引入Logstash-Forwarder架构
- 优点:解决了Logstash占用系统资源过多的问题。Logstash-Forwarder与Logstash间的通信是SSL加密传输,起到安全保障作用。
- 缺点:由于SSL加密传到从而导致的限制性。
- 应用场景:适用较大的集群方案。
引入Beats系列架构
- 优点:提高了扩展性和灵活性,Beats系列也方便进行二次开发。
我的日志分析架构
日志分析架构V1.0
- 配置好Nginx日志格式;
- 使用rsyslog将Nginx日志传输到Kafka中;
- Logstash消费Kafka消息,并对消息进行格式化处理后存储到ES中;
- Kibana对ES中的消息进行图表展示并提供查询功能;
- 同时使用Python ElasticSearch模块对数据进行查询分析,得到一些可疑的IP并将这些可疑IP存储到数据库中;
- 利用情报数据分析可疑到IP,设定规则,当触发规则时,使用ansible批量执行iptables命令封禁该IP;
- 封禁的同时记录该IP触发的规则,封禁时间;
- 根据不同的规则设定不同的封禁时间,当超过封禁时间时,使用iptables解封该IP;
- 为避免误杀,需要提供手动解封的能力;
备注:适用于小公司,且针对CDN、SLB不复杂的网站架构。
日志分析架构V2.0
- 数据层面可以是多种多样的,不一定仅限于access_log,也可以是主机日志、安全设备日志等。
- 采集层推荐使用Beats系列,与ELK融合度高,也便于拓展。
- 分为离线分析与准实时分析两条线,离线分析主要是为了给准实时分析提供规则。
- 准实时分析的结果需要运营人员进行处理。
备注:既适用于常规的日志分析,也适用于风控系统的分析方式