Logan分布式改造&OSS上传优化

Logan分布式改造&OSS上传优化

背景

logan是美团开源的一个日志回捞系统，日志文件在默认在本地存储，到上报用户增多时，单机性能到达瓶颈，需要升级架构，改造为分布式。

问题

• 日志文件的共享
• 防止重复解析日志文件

解决方案

• 日志文件存储方式采用对象存储OSS
• 解析日志文件增加redis分布式锁

详情

客户端上报的日志分为两种，1是手动回捞的日志，2是客户端奔溃上报日志。日志文件是加密的压缩文件，上传到服务端以后，需要进行解压解密，然后上传存储到oss。日志文件解密解压过程，是以‘\1’为结尾读取日志文件，在这一过程中可能会进行几百次的读取。上传OSS采用的是append，每解压一段日志就上传一段日志到OSS文件。然而，上线以后新的问题又出现了。。。

系统报504

排查504问题花费了2天时间，排查思路，nignx上设置的超时时间是120秒，504超时可能是由于网络原因导致没有响应超时，于是开始模拟在弱网环境下的上传，尽管网很慢上传时间已经超过120s，但是依然上传成功，没有报出504。查看线上日志，排查504上传文件记录，发现虽然返回的是504但是在OSS上已经成功上传了。到这里可能不是网络原因导致的，有可能是服务端处理超时。到底怎样的情况下会超时了？？想到了是不是文件太大，于是与客户端核实上传日志文件有没有大小限制，得到肯定答复10M，到这里我也不敢相信他们说的，于是开始上OSS上查看上传的文件大小，发现解压以后最大的文件为30多M，可能他们说的是对的。。

开始验证大文件上传，找了一个6M大小的日志原始文件，上传到线上环境结果报了504，看来排查对方向了。接下来开始本地开始验证，本地测试上传时间确实超过120s，终于稳定复现问题了，也看到了希望，下一步开始排查为什么慢，于是乎增加日志打印，看看慢在了哪些地方，和保存本地方式进行了对比，发现时间都耗费在了上传OSS上，文件保存本地整个过程耗时4s，上传OSS整个耗时3分钟左右。这次终于找到问题所在了，每次读取完成都需要上传到OSS，而每次上传OSS都需要耗时20-30ms，文件越大上传次数越多。

优化OSS上传

创建缓存buffer，当累计到一定量以后开始上传OSS，来减少上传次数。但是每次都new 一个buffer，在并发量大的时候有可能会内存溢出，素以这里采用了对象池来管理缓存buffer。

每个buffer应该设置多到合适？这个问题就需要统计查看我们上传的日志文件大小，查看以后返现百分之九十的文件小于1M。

对象池最大个数如何设置？查看了高峰时的并发量tps177,增加50%富余，tps265，共7台机器，平均每台tps38，只要我们设置的最大个数大于38应该就ok，考虑到机器内存较大，给了个100，也就站100M。

至此上线没有了504。