日志的处理机制
1 golang日志库可以考虑 tmlog https://github.com/heiyeluren/go-tmlog --黑夜路人@北京
2 老谢，你这个是异步库，一旦log gr 出问题不就坑爹了 可以考虑加上阻塞方式的，效率低点，但是安全 log库不必也没必要追求效率 --于雨@北京
3 行啊，回头再考虑实时写入临时日志 --黑夜路人@北京
4 一般的逻辑处理，瓶颈不可能在log上，务求不丢不乱就行了 --于雨@北京
5 前阵子看过一篇文章，一个老外做的分析，系统性能消耗有不少的部分浪费在同步log上 --郭军@360
6 主要是磁盘io慢啊慢 --黑夜路人@北京
9 确实，我们client的log都出于效率原因从同步实时改成异步分批写入了 --类库@上海-意励
8 log太多了吧，会对io造成压力 --kyle@成都-风际游戏
9 异步的本质都是为了不阻塞当前执行协程 --黑夜路人@北京
10 瓶颈还真有可能在log上 --Xargin@北京-didi
11 可以开启raid卡wb，对比下，如果差异巨大，可能是log导致的 --谭俊青@途牛
12 去年写proxy 日志info级别性能下降蛮多的 还是要少打日志的。业务对性能要求不苛刻就无所谓了 --董泽润@北京-nice
13 不要用文本日志，改成二进制代号 --kingsword@广州-kg
14 采用文本大多是还是为了日志可读，排查问题方便，快吧 --郭军@360
15 有运维朋友原来在微信的，说他们为了解决这个问题，强制要求所有业务都改成代号，解释器啊 --kingsword@广州-kg
16 日志阻塞很严重 --金灶沐@北京-康复中心
17 qq邮箱时期的事情，后来微信也沿用了 异步解决不了io问题，系统io阻塞一样会影响业务线程 --kingsword@广州-kg
18 瓶颈出现在log上是很常见的 鞋日志不能同步写啊 --神仙@上海|杭州-有赞
19 buf啊 批量刷 不行再分桶 批量。。尽量做大不影响flush --金灶沐@北京-康复中心
20 必须有buf --神仙@上海|杭州-有赞
21 buf只能缓冲写 --郭军@360
22 鹅厂日志量大的系统都通过网络发到专门的日志系统 日志量大为啥还要扔给磁盘？ --于雨@北京
23 网络io优于磁盘io？ --类库@上海-意励
24 我们的系统日志很容易成为瓶颈。所以日志系统有一个逻辑，日志如果太频繁，会折叠成一条 --Tiger张虎@深圳-云巴
25 有个想法是，程序里继续写，做个扫描器在编译的时候把所有日志汇总生成日志解释库，然后代码替换了 --kingsword@广州-kg
26 如果不是不能丢的日志，网络上有udp发 --神仙@上海|杭州-有赞
27 我们现在开了三条通道，http，udp，tcp --Tiger张虎@深圳-云巴
28 强制要求所有业务都改成代号，有点不解，求解释下。 --飞蓬@杭州
29 打成代号，是不是像http的200 404这种？ 把错误归类？ --于雨@北京
30 udp会不会像我们做多终端消费那样。 打上唯一递增消息。 服务端接受看信息完整不完整，如果完整就继续接受，不完整就回馈消息。 --金灶沐@北京-康复中心
31 可以这么干 这种就是udp上做可靠传输了 --神仙@上海|杭州-有赞
32 Io带来的开销和延迟，在调用密集型影响巨大 最优是异步加udp，同时考虑上层交换延迟和流量，控制pipeline避免丢包 而且大部分日志库都是同步加锁，异步也有队列争用 --毛剑@上海-bilibili
33 360的视频云就是udt udx fast udx好像 --周洋@北京-360
34 非关键日志，udp直接扔 --谭俊青@途牛
35 写磁盘，靠异步这神油不可能解决根本问题 --于雨@北京
36 是啊，异步加个队列只是缓解峰值写造成的堵塞 --神仙@上海|杭州-有赞
37 udp->udp server(开大点的buffer，也可以做负载均衡)->mq->… --谭俊青@途牛
38 udp->udp server->kafka->es --于雨@北京
39 udp扔过去注意下Incast Congestion --毛剑@上海-bilibili
40 不行的，需要udp server 可以极大程度降低丢包率 --谭俊青@途牛
41 upd最大的问题就是buf要开大 否则就丢包。 --金灶沐@北京-康复中心
42 uber那个log库不错，就是写法太别扭 --于雨@北京
43 可以在发送端做winodow size，类似tcp流控 --毛剑@上海-bilibili
44 我这边有用udp server，几乎不丢包，buffer够大 udp packet -> udp server -> nsq -> ... --谭俊青@途牛
45 tcp的华东窗口就是保证数据可靠性。retry --金灶沐@北京-康复中心
46 暂时还在用毛老师拉的log4go的分支 --于雨@北京
47 做window size 性能就下去了，还不如直接用tcp --谭俊青@途牛
48 udp搞好了，内网情况下10000个包丢三四个正常，不可能有啥影响 正常情况下，不加大buf --于雨@北京
49 但是他们的信息要求准确度非常高也没办法 --金灶沐@北京-康复中心
50 10000 丢3-4个还不高啊？ --谭俊青@途牛
51 @谭俊青@途牛 看场景如果仅仅是accesslog，算pv，uv丢几个无所谓 --郭军@360
52 sndbuf和rcvfuf开成2m，基本上就100%了 不过延迟会比较大 --于雨@北京
53 github.com/thinkboy/log4go --Ryder@厦门-玩美
54 推荐个我的https://github.com/blackbeans/log4go -- Beta版厨子3.0
55 log4go现在源代码都有问题啊 --宋慧庆@北京
56 不是有问题，是我按我的需求加了些东西 -- Beta版厨子3.0
57 Debug实现极其烂 整体总结下就是辣鸡 没有条件分支优化 Debug，模块日志都成本极其高 我们都不用本地日志了 --毛剑@上海-bilibili
58 我们也不用 最早长连接 去写异步kafka 后来udp server 短连接不行就长连接。。长连接不行就upd fmt 到 kafka kafka消费 你信不信我们都这么做了 --金灶沐@北京-康复中心
59 那日志不落盘了？ --Xargin@北京-didi
60 log4go不好用，我们公司自己写了一个https://github.com/antlinker/alog 一直在用 --于鹏飞@济南-蚁动
61 我们日志分种类 落啊 我们有几种日志。这是其中一种。。 --金灶沐@北京-康复中心
62 毛老师，你家的log4go，输出到term的没有receiver提示，debug日志有，能不能改改 貌似行号也没有 --于雨@北京
63 我们内部有版本 早不维护了 我们不用本地日志 目前udp kafka也不用 flume直接sink给需要的hdfs，或者es啥的 除非需要分析，才给Kafka --毛剑@上海-bilibili
64 我们游戏里面的所有玩家行为日志都是扔到Kafka里面 --kyle@成都-风际游戏
65 消费不代表没有后续工作啊。。 任何不都要跟业务需求挂钩吗？ 我们真正的日志落地的 而且到hdfs上 定时落进去。我们kafka也是做核心数据跟踪 --金灶沐@北京-康复中心
66 恩 这样还是挺好 但是看过普通的系统日志什么的 怎么方便？ 比如debug log --宋慧庆@北京
67 现在也不是直接用Kafka了，基于Kafka开发了数据总线，把Kafka协议屏蔽咯，提供了redis pub/sub实现，方便其他需要接入，同时做鉴权 --毛剑@上海-bilibili
68 debug log不会大到影响io性能吧 --kyle@成都-风际游戏、
69 不用kafka后端flume的sink如果挂了，就可能撑爆flume了。。 -- Beta版厨子3.0
70 从没挂过 flume有fallback 可以打本机 然后再用我们自己开发的Retail追踪收集 多flume节点 或者/dev/shm --毛剑@上海-bilibili
71 我们搞过 恩fallback配置了 就是先内存通道再到文件。到文件就已经说明sink慢了。。 主要还是用kafka起到缓冲的作用。。 -- Beta版厨子3.0
72 你们是thrift协议连的flume么 -- Beta版厨子3.0
73 syslog logview以后越来越少用才对，应该用链路追踪系统 --毛剑@上海-bilibili
74 现在用go进行hdfs hbase之类的都是通过thrift协议连的吧 --宋慧庆@北京
75 我们维护了一个hbase client分支 原生实现，各种搞zk，meta 缓存，region迁移啥的代码写了挺多。细节让yonka讲讲 --毛剑@上海-bilibili
76 醉了……只有统计类的日志走Kafka，其他的是写到磁盘上备份而已。为啥要搞这么复杂？ 而且前面说微信的…我现在就在生产机上，没有见到代号啊…… --蒙卓@深圳
77 想有集中的日志平台做查询吧 --Xargin@北京-didi
78 腾讯我在的时候确实是一台一台上去捞日志 -- Beta版厨子3.0
79 如果日志量太大的话，做收集不会影响到网络IO么 --Xargin@北京-didi
80 @蒙卓@深圳 互娱的外网游戏运营收集也是udp --毛剑@上海-bilibili
81 我们是都放在hadoop上了 自己开发的分布式日志收集组件，最后都打到hdfs上 --郭军@360
82 实时收集对网络影响有限，定时收集影响才大。如果实时收集对网络都有影响了，只说明日志打太多了。 --王渊命-bj-Qingcloud
本文分享自微信公众号 - GoCN（golangchina）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/4628563/blog/4772166