ELK日志系统技术架构

架构1.0
ELK日志系统技术架构_第1张图片
问题和挑战:
主要配置
1.ES集群中所有节点使用虚拟机
2.索引按照天生成
3.数据节点负责数据的索引
4.通过Nginx将用户的检索请求负载在数据节点

运行状况

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

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

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

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

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

架构3.0
ELK日志系统技术架构_第3张图片
主要优化

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

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

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

架构4.0
ELK日志系统技术架构_第4张图片
主要优化
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等。

你可能感兴趣的:(架构,ELK,日志系统,elk,架构,数据库)