世界节日元旦节即公历的1月1日,是世界多数国家通称的“新年”。元旦,元,谓“始”,凡数之始称为“元”;旦,谓“日”;“元旦”意即“初始之日”。元旦又称“三元”,即岁之元、月之元、时之元。中国历史上的“元旦”一词最早出现于《晋书》,中国历史上的“元旦”指的是“正月一日”,“正月”的计算方法,在汉武帝时期以前是很不统一的,历代的元旦日期并不一致。从汉武帝起,规定阴历一月为“正月”,把一月的第一天称为元旦,一直沿用到清朝末年。辛亥革命后,为了“行夏正,所以顺农时,从西历,所以便统计”,民国元年决定使用公历(实际使用是1912年),并规定阳历1月1日为“新年”,但并不叫“元旦”。1949年中华人民共和国以公历1月1日为元旦,因此“元旦”在中国也被称为“阳历年”、“新历年”或“公历年”。
一、场景
计算机集群(英语:computer cluster)是一组松散或紧密连接在一起工作的计算机。由于这些计算机协同工作,在许多方面它们可以被视为单个系统。与网格计算机不同,计算机集群将每个节点设置为执行相同的任务,由软件控制和调度。
单机处理到达瓶颈的时候,你就把单机复制几份,这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”,所有节点构成了一个集群。每个节点都提供相同的服务,那么这样系统的处理能力就相当于提升了好几倍(有几个节点就相当于提升了这么多倍)。但问题是用户的请求究竟由哪个节点来处理呢?最好能够让此时此刻负载较小的节点来处理,这样使得每个节点的压力都比较平均。要实现这个功能,就需要在所有节点之前增加一个“调度者”的角色,用户的所有请求都先交给它,然后它根据当前所有节点的负载情况,决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展,当前的系统又支撑不住了,那么给这个集群再增加节点就行了。
但是当你的业务发展到一定程度的时候,你会发现一个问题——无论怎么增加节点,貌似整个集群性能的提升效果并不明显了。这时候,你就需要使用微服务结构了。
一旦采用集群这种架构,不同的用户可能会路由到不通的结点。对于日志型服务来说,这就给后期处理增加了难度,当然也是有对应的处理方案的,如著名的ELK Stack
等等。今天咱们来假设手动排查多个节点下的某个日志,纯属练手,高手请忽略~~
二、开始(Mac)
假设有三个节点node1/2/3,通过日志管理工具全局搜索后下载下来的是三个节点的压缩文件,姑且命名为1.zip、2.zip、3.zip,压缩文件目录都是
log/error/2018/error.log
,日志内容分别为15,610,11~15,现在模拟生成三个节点的日志:
cd ~/Desktop
mkdir test
mkdir -p log/error/2018
touch log/error/2018/error.log
- 执行shell生成log数据
1 | for i in `seq 1 5` |
tar -zcvf 1.zip ./log
,生成1.zip压缩文件echo > log/error/2018/error.log
,清空error.log- 同步骤5,执行脚本
1 | for i in $(seq 6 10) |
tar -zcvf 2.zip ./log
,生成2.zip压缩文件cat /dev/null > log/error/2018/error.log
同步骤5,执行脚本
1 | for i in {11..15} |
tar -zcvf 3.zip ./log
,生成3.zip压缩文件rm -rf log
终于到了正文了,将各个日志输出到res.txt
1 | for i in *.zip |
- cat res.txt
三、扩展
- 清空文件的几种方式
1 | : > filename # 其中的 : 是一个占位符, 不产生任何输出. |