# fast-log

**Repository Path**: nongxun/fast-log

## Basic Information

- **Project Name**: fast-log
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-02-02
- **Last Updated**: 2026-03-16

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

文档参考：https://my.oschina.net/1Gk2fdm43/blog/5312538

# 简介

​ 该项目主要为海量日志（秒级GB级）的搜集、传输、存储而设计的全套方案。区别于传统的如ELK系列套件，该项目主要是为了解决超大量级的日志（出入参、链路跟踪日志）从搜集到最后检索查询的中途产生的高昂硬件成本、性能低下等问题。

​ 核心点在于 **性能、成本** 。

​ 主要应用方向为： **用户跟踪** ，即根据特定条件，查询用户请求出入参、中途打印的所有日志，即这个链路的日志。

​
较ELK系列方案（filebeat、mq传输、es存储等常见方案），该框架拥有10倍以上的性能提升，和70%以上的磁盘节省。这意味着，在日志这个功能块上，使用相同的硬件配置，原本只能传输、存储一秒100M的日志，采用该方案，一秒可以处理1GB的日志，且将全链路因日志占用的磁盘空间下降70%。

​
由于该方案着重于极致的吞吐性能和极低的磁盘占用，而对数据全程进行了压缩。故并不适合于需要es关键字模糊查询的场景使用，而仅支持提前设定好的索引字段查询。数据库使用的是clickhouse集群，如果之前没有相关经验的，还涉及了新技术的学习成本，以及需要对部分源码进行改造，故未必适合大部分项目使用。建议关注实现方案和处理超大量级的数据、缓冲、入库等代码逻辑即可，整套思路可适用于多种场景。

​ 该项目适用于日志量极大，且用于节省中转环节如使用kafka等mq进行日志中转的场景。在京东、方舟健客等公司线上使用，由于各公司日志查询时索引字段不同，固必然有一定的开发工作，需要注意。这不是一个开箱即用的项目。

​
关于性能及机器配置简述，目前线上的worker配置主要为8核32g的docker，32g内存是专门定制的参数，因为worker需要靠纯内存来承接和缓冲大量接收的日志，这样的单机每秒可以承接的日志量为160M-200M，因为是压缩后的，对应原始日志约1个G，约1千万行。

clickhouse机器配置为16核64G内存，单机每秒可以稳定写入180M，再高会丢可用率。对应原始日志约1个G。

# 技术架构

1. ### elk方案的问题

技术方案的设计和取舍，往往强受限于成本。当成本高企到难以承受时，将必须导致技术方案的升级换代。那么问题来了，我就是存个日志而已，怎么就成本难以承受了呢？

​ 我们以一个常见的日志传输及存储方案来举例，入下图，暂存就是采用客户端写本地文件存日志，传输即是采用 MQ，消费入库常见的如
ES。下图方案，为了减少部分存储成本，将日志详情存储于压缩更好的 Hbase，仅将查询时需要的一些索引字段放在了 ES。

![up-00275b840de750e4a7af20db10781cd3bac.png](https://oscimg.oschina.net/oscnet/up-00275b840de750e4a7af20db10781cd3bac.png)

​ 这个通用流程中，其实我们很容易就能发现，我们经历了很多读写，每次读写都伴随着磁盘的读写（包括 MQ
也是写磁盘的），和频繁的序列化反序列化，以及翻倍的网络 IO。

![up-6ed1a29a18b27425f5bd6eb2de50392a441.png](https://oscimg.oschina.net/oscnet/up-6ed1a29a18b27425f5bd6eb2de50392a441.png)

​ 我们发现，其实写本地磁盘、和 MQ 都是没有必要的，我们完全可以将日志数据写到本地内存，然后搞个线程，定时通过 UDP 将日志直接发送到
worker 端即可。

![up-433fdb02be43de5c481a250ac5ab920a267.png](https://oscimg.oschina.net/oscnet/up-433fdb02be43de5c481a250ac5ab920a267.png)

### 2.新方案架构

​    ![up-145416d48409c1b2db238a77f92fa8b727b.png](https://oscimg.oschina.net/oscnet/up-145416d48409c1b2db238a77f92fa8b727b.png)

![up-4c6ddc2bdb3f7a82029bbb84099ec570109.png](https://oscimg.oschina.net/oscnet/up-4c6ddc2bdb3f7a82029bbb84099ec570109.png)

client：客户端启动后，从配置中心拉取分配给自己这个模块的 worker 集群的 IP，并轮询将搜集的日志压缩后发送过去，通过 UDP 的方式。

worker：每个模块会分配数量不等的 worker 机器，启动后上报自己的 IP 地址到配置中心。接受到客户端发来的日志后，解析相应的字段，批量写入
clickhouse 数据库。

clickhouse：一个强大的数据库，压缩比很高，写入性能极强，按天分片，查询速度佳。非常适合应用于日志系统这种写入极大，查询较少的系统。

dashboard：可视化界面，从 clickhouse 查询数据展示给用户，具有多条件多维度查询功能。