Hello出行海量日志系统架构演进

标签：soa 架构海量系统日志 Hello ES

本文摘自我的公众号【陶朱公Boy】

文章：《Hello出行海量日志系统架构演进》欢迎大家的关注！

公众号回复关键字”日志“ 进行完整PPT文档的下载！

Hello出行海量日志系统架构演进与调优

正文如下：

日志来源

各个应用的业务日志就是各个业务应用在本地记录的业务运行时日志。
SOA日志主要还是RPC调用的日志。
中间件日志我们内部封装了很多SDK,无论是RPC框架或MQ框架，都通过内部脚手架SDK发起调用。这些中间件打印出来的日志是单独搜集的。
网关日志在内部，无论是APP或WEB后台网站，与其对接的一定都是相应的网关，由网关发起下游各个SOA接口调用，换回数据。网关采用GO开发，日志也单独搜集。

一代日志架构

早期我们第一代的架构也是业界比较常见的方案:ELK。(Elasticsearch、Logstash 和 Kibana)

ELK是Elasticsearch、Logstash、Kibana三大开源框架首字母大写简称(但是后期出现的filebeat(beats中的一种)可以用来替代logstash的数据收集功能，比较轻量级)。市面上也被成为Elastic Stack

ELK优点：

业内主流的日志系统解决方案、技术成熟、文档完备、社区活跃、使用用户数也很多。

ELK不足：

一般情况下Filebeat可满足大部分的日志采集需求，但是仍然避免不了一些特殊的场景需要我们对Filebeat进行定制化开发，当然Filebeat本身的设计也提供了良好的扩展性。
但如果我们要根据自己的业务语义有一些定制化，比如根据文件、IP、APP做一些定向采集等，filebeat满足不了。
我们发现生产场景，海量日志下Filebeat占用资源幅度明显上升。
SOA日志和应用日志耦合在一起，ES成本太高！
Kibana功能繁杂，学习成本比较高

二代架构

改造后的优势

二代架构在一代架构的基础上，我们开发了LogAgent来替换Filebeat，支持更加个性化的搜集策略。
soa日志和应用日志分离，减轻ES压力和缩减ES成本！

替换原ELK方案为Loki。Loki的引入减少了一定的机器的成本。

Loki 是 Grafana Labs 团队最新的开源项目，是一个水平可扩展，高可用性，多租户的日志聚合系统。它的设计非常经济高效且易于操作，因为它不会为日志内容编制索引，而是为每个日志流配置一组标签。项目受 Prometheus 启发，官方的介绍就是：Like Prometheus, but for logs，类似于 Prometheus 的日志系统。

缺点

loki的使用体验和查询性能比较糟糕
分散在多个系统，排查问题比价麻烦

为什么我们要做新日志系统

(1)目前日志系统对开发的影响：

查不到，查不动，日志延迟高
Loki时间跨度超过1小时，必超时，数据量大的应用甚至都不能超过10分钟。soa-detail日志延迟非常高
日志很多，要反复去不同系统找日志
网关日志，soa日志，应用日志，中间件日志都处于不同系统，需要反复跳，排障耗时
日志没法关联，不知道如何串联日志
各类没有关联性，很难根据某个特性，快速找到问题，排障困难

(2)日志系统对基础设施的影响

高成本
非常高的存储成本，ES的成本，Kafka的成本

高风险
海量日志对云上云下专线带宽造成高风险

(3)应用日志

取均值

TPS：70W+45W=115W/S
Byte: 250M+500M=750M

全天量

750M*3600=2.57T

ES实际存储大小

2.57T*10=25.7T

(4)SOA日志

取均值

TPS：200W/s
Byte:1.5G/s

全天量

1.5G*3600=5.27T

ES实际存储大小

5.27T*10=52.7T

新日志系统介绍

系统架构图

HLog标准模板建设

LogAgent定向采集

Flink任务清洗

去除非标准日志
去除重复打印日志
动态降级
写入隔离

存储

应用日志ES集群改造
多集群模式，大小索引动态调整集群及分区，冷热数据区分。
SOA日志剥离ES
下线soa-detail，仅保留soa-mertirc日志作为链路，存储于clickhource
降本
下线Loki,约15000/月，下线soa-detail的ES，约75000/月，最终资源，46台应用日志ES+20台clickhourse,月4500/月。