Linux日志压缩利器
由于现有的日志量越来越多了,原先一直用的gzip进行压缩的,默认的级别,可最近看着是越来越不行,是有必要进行新的选择。
选择的方向是就是zstd
在CentOS中直接
1 | sudo yum install zstd -y |
就可以安装完成
由于是日志文件,我们单个分割是57MB的大文件
由于现有的日志量越来越多了,原先一直用的gzip进行压缩的,默认的级别,可最近看着是越来越不行,是有必要进行新的选择。
选择的方向是就是zstd
在CentOS中直接
1 | sudo yum install zstd -y |
就可以安装完成
由于是日志文件,我们单个分割是57MB的大文件
线上有一个topic碰到突增,但是限制于topic的分区太少,消费实在太慢,导致影响到用户的感受。
首先我们看下这个topic
1 | ./bin/kafka-topics.sh --zookeeper prod-zk1:2181 --describe --topic Events |
我们看到这个topic就10个分区,但是副本数却有些是2,有些是1。这种是否可以直接增加分区呢,答案是不行的。
你要这个时候增加分区就会报
1 | requirement failed: All partitions should have the same number of replicas. |
最近碰到一个kafka流量引发的故障。期初的现象是我们有些consumer超时。于是去看了下kafka broker的日志
1 | [2020-XX-XX YY:35:51,703] WARN [ReplicaFetcherThread-0-0], Error in fetch kafka.server.ReplicaFetcherThread$FetchRequest@712892d4 (kafka.server.ReplicaFetcherThread) |
这里写着id为0的broker连接超时啊。那就重启id 0的broker了。可重启了之后发现如下日志了
1 | [2020-XX-YY 14:13:27,728] INFO Partition [Event,196] on broker 1: Shrinking ISR for partition [Event,196] from 1,2 to 1 (kafka.cluster.Partition) |
这里你看这一会儿Shrinking,一会儿Expanding。而且间隔时间相当的短,现在想来是很快的连接超时了。
这时候明显大家就慌了,远程办公就这点不好啊.
上篇有提到firewalld和iptables的区别。那就比较好奇firewalld的其他状态。
首先测试了22端口,这个端口在firewalld里是开放的,但是实际上机器上没有监听这个端口。这里我们看到,实际服务器返回的也是一个TCP-RESET。
然后又测试了一个被firewalld屏蔽的端口,实际服务器上也没有监听这个端口。这里我们可以看到返回的是ICMP的destination unreachable。
接着我们测试了一个被firewalld屏蔽的端口,实际服务器上监听了这个端口。这里我们可以看到返回的也是ICMP的destination unreachable。
最后我们直接屏蔽某个端口,发现也一样是返回ICMP的destination unreachable。
1 | <rule family="ipv4"> |
在iptables中,我们一般封闭端口都是使用DROP参数,这样client端是不知道服务器已经DROP掉对应请求了,会继续进行等待,直到超时。
而像nc这种软件会根据这个其实是可以检测到服务器是否开启了这些端口。
但是我发现使用firewalld封闭后,用nc测试直接显示refused的
1 | $ nc 202.96.209.5 29327 -v |
而用iptables的话必须得是
1 | # iptables -A INPUT -p tcp -m tcp --dport 29327 -j REJECT --reject-with tcp-reset |
本文是「kafka权威指南」的第三章笔记。
在设置生产者之前我们先看看整个生产者到kafka broker的流程是怎么样的。
这个图是原文里的。
可以看到一个标准的ProducerRecord是必须要包含Topic和Value,然后Partition和Key是可选的。
从图中也可以看到,生产者需要把Key,Value序列化成数组,然后再去网络上传输。
如果record里有包含了Partition了,那就不需要分区器干活了,如果没有包含,那分区器就会根据record对象的key来选择一个分区。
选好分区之后,那生产者就知道往哪个topic和分区里发送记录了。然后这个记录就被添加到一个记录批次里,这个批次里所有消息都会被发送到相同的topic和分区上,这是由一个独立线程来处理的。
不知道从什么时候开始,就非常害怕爆炸了。
记得小时候我堂兄结婚,他们家放高升(二踢脚),好像直接把我吓的关屋里了,有没有钻床底下有点记不清了。
还有一次是在我爷爷家,不知道谁放了一个哑巴高升,可到最后居然落到我旁边表弟的头上就炸了,那场景我至今都可以很清晰回想起来。
要说怕这些吧,可还经常玩,可随着年龄的增加是越来越不敢玩了。
明明小时候经常放鞭炮的,还经常拿手里点着了直接扔出去放呢,但也失手过几次在手里直接炸了。
可现在看到气球有时候就比较恐惧,特别是当它飘向某个尖锐物体的时候,或者眼看着某人一脚踩下去的时候,都会有一种揪心的恐惧。
kafka现在是所有队列组件里最常用的,虽然跟Rabbitmq这些相比还缺乏一些特性,但是它实在是成长的太快了,而且支持集群化,这个是最赞的,同时由于使用0拷贝,日志追加,所以它的磁盘效率非常高。
但是kafka的运维难度前期并不大,但是在后期主要的难点是在扩容,缩容阶段。主要是因为磁盘IO,网络IO的原因。导致了很多瓶颈点产生。
本文是读了「kafka权威指南」第二章的一个摘要总结。
kafka是把所有消息都写入到磁盘,这个参数可以指定多个目录进行消息写入。而写入的原则是最少使用原则。
但是我们在实际使用中,不建议写多个,宁愿使用raid,LVM条带方式来扩展单目录的写入速度。
话说这两天肺炎疫情突然紧张起来,可每个地区的行动力真的差别很大,有放羊的,也有跟踪到户的。
已知的什么河南,北京,上海这些基本都是跟踪到户。连小小球幼儿园老师都要要求大家每天上报情况和方位。而西城有些社区已经不让大家出门了,有事情社区来帮你解决,实在不行的社区还派车给你。就是为了防止无畏的扩散。
刚刚看了当年小汤山医院7天建成的故事,这基本上就是个奇迹,也只有在集中资源办大事的国度才可以完成。连图纸都没有,材料也没有的情况下,7天就建成了。
而当年新市长王岐山主要的工作也是切断传染源,整片整片的隔离。扩散才得到遏制,而随着夏天的到来,病毒的存活条件也不行了,这场战斗终于是结束了。下岗一个卫生部部长,一个北京市市长。
想到我司迁移邮箱的事情,邮件全体发送一次,QQ群每日提醒,微信群每日提醒,可至今依然有30%的账号没有任何迁移。
按说文档也不能说不详细,毕竟让行政,HR部门的女生都根据文档执行过了,已经非常详尽了。可还是无动于衷,而公司老板也是如此。这就实在让人难以想象了。