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等。

相关推荐
Code季风22 分钟前
深入理解微服务中的服务注册与发现(Consul)
java·运维·微服务·zookeeper·架构·go·consul
小马哥编程43 分钟前
【iSAQB软件架构】架构决策记录-ADR
数据库·架构·系统架构·设计规范
木鱼时刻43 分钟前
容器与 Kubernetes 基本概念与架构
容器·架构·kubernetes
萧鼎1 小时前
深度探索 Py2neo:用 Python 玩转图数据库 Neo4j
数据库·python·neo4j
m0_653031362 小时前
腾讯云认证考试报名 - TDSQL数据库交付运维专家(TCCE MySQL版)
运维·数据库·腾讯云
power 雀儿2 小时前
集群聊天服务器---MySQL数据库的建立
服务器·数据库·mysql
zhuyasen3 小时前
定义即代码!这个框架解决了90%的Go开发者还在低效开发项目的问题
架构·go·gin
LCG元3 小时前
云原生微服务间的异步消息通信:最终一致性与系统容错的架构实战
微服务·云原生·架构
骑着王八撵玉兔3 小时前
【性能优化与架构调优(二)】高性能数据库设计与优化
数据库·性能优化·架构
想要入门的程序猿4 小时前
Qt写入excel
数据库·qt·excel