ELK日志系统技术架构

架构1.0

问题和挑战：
主要配置
1.ES集群中所有节点使用虚拟机
2.索引按照天生成
3.数据节点负责数据的索引
4.通过Nginx将用户的检索请求负载在数据节点

运行状况

1. 部分索引节点负载非常高
   2.索引速度非常慢，经常出现Kafka堵塞情况
   3.查询响应非常慢
   4.并发访问数为10左右时， ES已经不能支撑

原因分析
1.部分虚拟机在同一个物理机上，数据节点间的资源竞争非常激烈
2.数据节点同时承担索引和检索，负荷重
3.索引时有非必须的字段被索引（比如_all）
4.按天生成的索引太大
5.单索引

架构2.0

主要优化
1.引入client节点，将检索的请求从数据节点转移到client节点。同时client
节点通过river从kafka中拉数据将数据导入ES
2.移除在同一物理机上的虚拟机，并增加了一批物理机
3.关闭_all字段
4.并且索引按照小时生成
5.根据日志类型划分不同的索引文件

运行状况
1.非大促期间，索引和检索速度基本能达到秒级，但是大促期间，出现日志
量膨胀以及访问人数过多时，索引和检索速度很慢
2.随着集群规模的增加，运维的工作量也急剧增加

原因分析
1.多种类型的日志（例如偏统计分析的web日志，偏检索的应用日志）混在
一个大集群中,不同的日志间相互影响
2.缺少必要的降级功能

架构3.0

主要优化

1. 根据日志类型，将大集群拆分成不同的小集群
   2.将data节点替换成物理机
   3.提供按照系统、文件路径、等级等应对大促期间的日志洪峰系统进行降级
   的功能

运行状况
1.非大促期间，索引和检索速度达到秒级。大促期间，通过必要的降级，能够保证重要系统的索引和检索速度达到秒级。

存在的问题
1.随着业务量的快速增长,简单的按照分析类型进行集群拆分已不能满足要求,并且增加机器资源容量并不是线性增加。
2.用户希望保留7天以前以及大促期间数据,集群容量以及性能也存在严重问题

架构4.0

主要优化
1.在③的基础上同时支持按照业务划分以及数据类型划分集群
2.使用不同的硬件划分Hot/Cold节点,业务低谷将历史数据迁移到Cold节点
3.针对Exception等重点关注且长期保留分析的数据单独存储。

架构5.0
升级为elasticsearch7.1.1，引入Cross Cluster Search。

总结：这套ELK技术架构是几年前我在两家公司主导的，核心能力如下，几年没碰这套架构了，应该与时俱进优化：

1.近4000系统的应用日志、每天10TB+/450亿条数据， 24小时不间断索引服务，峰值500W/s写入能力， 秒级检索能力。

2.近1000仪表盘覆盖完整的基于日志监控能力，保障日常和大促时段线上系统的平稳运行。
包含：（1）.CDN全量和异常日志的监控 。（2）.核心链路（购物车、四级页等） Web日志监控。（3）.应用服务器、操作系统内核等日志监控。（4）.核心数据链路日志监控。

3.涉及技术栈：MySql、redis、spring boot 、spring cloud、分布式服务、apm、Flume、Fluentd、Filebeat、Kafka、elasticsearch、nginx、kibana、hadoop、Spark、Storm、Flink等。