# sweet-logging-server

**Repository Path**: tk230/sweet-logging-server

## Basic Information

- **Project Name**: sweet-logging-server
- **Description**: 分布式下的日志处理程序 Sweet 的服务端代码。包含收集，存储，查询三部分。
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 2
- **Created**: 2021-02-25
- **Last Updated**: 2021-02-25

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

### 分布式下的日志采集，存储，查询程序 Sweet Logging
    为分布式下的业务系统提供日志采集，集中存储，查询服务
 **一、 系统架构图** 
![输入图片说明](https://git.oschina.net/uploads/images/2017/0912/141218_7da38bd3_971173.png "Flow Chart Demo.png")

 **二、设计思路** 

 **1.日志客户端** 

客户端根据 slf4j api 来实现。日志客户端，根据一个配置文件自动初始化。初始化参数包括日志收集器的地址，本地缓存队列大小等等。队列长度有上限是考虑到，如果远程的日志采集器处理太慢，不能让客户端的 日志无限制积压。万一队列满了，也不能阻塞写线程。因此只能考虑写入本地文件这样的策略。

 **2.日志收集器与日志的按时间戳排序** 

日志收集器需要快速处理日志数据，包括反序列化，入队，排序，调用存储服务批量存储。因为考虑到分布式环境下的不同机器性能差异，网络状况等因素，送达收集器的日志在时间上不能保持有序。因此用到了有序队列类保证顺序。另外，为了防止队列中的数据全部储存完之后，收到时间早于上次存储的日志的时间。队列再批量存储中不会清空，每次总是留下一部分时间最晚的数据。    

 **3.日志的存储** 

日志采用文件存储，但是为了保证查询性能，存储一条日志的同时会存储两条索引。因此，存储分为数据，和索引两部分。索引分为两种，一种是时间区间索引，一种是Hash索引。时间区间索引一条是16Byte，前8个Byte是时间戳，后8个是数据在文件中的存储位置。这样算的话，一千万数据，最大需要152M内存的索引存储开支。但是时间戳相同的日志会被算作一条索引，因此实际时间区间索引的数量可能远小于日志总数。而Hash索引的总数和数据量是一致的。但是一条Hash索引只需要12Byte的存储空间。因此一千万数据量的话，Hash索引需要114M的空间开支。
    
 **4.日志的查询** 

日志查询器在初始化时会读取索引文件，创建内存索引树，并定期更新索引。查询的方式是通过时间区间，获取日志在数据文件中的存储位置区间，然后采用扫描，过滤的方式读取的，对于内存的匹配，支持 hash 比较。

 **三、收集，存储性能测试** 
   1. 测试环境：三个 VMware 虚拟机（centOS 6.5 1核 1G内存） + 本地（window 10 i7 8G内存 已运行VMware）
   2. 测试方法：日志采集和查询服务部署在虚拟机（sweet-test-01），测试服务APPServer B1, B2分别部署在
      sweet-test-03，sweet-test-04中。本地运行APPServer A，发起对B1、B2的随机调用。A、B1、B2每次调用或者被调用，都会输出一段0.1K的日志，这个日志需要被日志采集器收集存储。另外，根据实际情况，考虑通过独立程序运行for循环打印日志进行加压，加压强度用线程睡眠来操控。最后，通过在StorageService中添加计算存储速度的方式，获得程序的整体性能指标。

具体情况如下图：
![输入图片说明](https://git.oschina.net/uploads/images/2017/0912/140950_fbad60b5_971173.png "Flow Chart Demo2.png")

   3.测试结果
    
   1)不进行加压：AppServer A 不间隔的调用B1或者B2十万次，日志存储端监测到的写入速度是平均2800条日志/秒
   
   2)通过独立程序加压，无间隔for循环打印日志：日志存储端写入速度是平均4万条日志/秒

 **四、查询性能** 

  查询方面，能提供索引查询的有两种方式，包括时间区间索引查询和等于方式的关键字查询。暂时没实现高效的模糊查询。

具体测试情况如下：

日志数据总量：305万条
日志数据文件大小：377M
时间区间索引总数：32920条 占用空间 504k
Hash索引总数：305万条 占用空间 34.9M

查询耗时：

时间区间查询：30-40 ms
等于方式的关键字查询（查询最后条数据，相当于会扫描全部数据）：40-50 ms

   **五、性能瓶颈分析**  

   通过对SweetQueue,StoreageService这两个点位的单独测试分析，发现StoreageService处理速度高于60万条日志/秒。SweetQueue不太稳定，大约30万上下的每秒日志处理速度。单节点压测显示是 7 万左右的处理速度。通过以上分析总结，当前瓶颈应该在网络IO的处理这一块上。