目前业界比较流行的日志采集主要有Fluentd、Logstash、Flume、scribe等,阿里巴巴内部则是LogAgent、阿里云则是LogTail,这些产品中Fluentd占据了绝对的优势并成功入驻CNCF阵营,它提出的统一日志层(Unified Logging Layer)大大的减少了整个日志采集和分析的复杂度。Fluentd认为大多数现存的日志格式其结构化都很弱,这得益于人类出色的解析日志数据的能力,因为日志数据其最初是面向人类的,人类是其主要的日志数据消费者。为此Fluentd希望通过统一日志存储格式来降低整个日志采集接入的复杂度,假想下输入的日志数据比如有M种格式,日志采集Agent后端接入了N种存储,那么每一种存储系统需要实现M种日志格式解析的功能,总的复杂度就是M*N,如果日志采集Agent统一了日志格式那么总的复杂度就变成了M + N。这就是Fluentd的核心思想,另外它的插件机制也是一个值得称赞的地方。Logstash和Fluentd类似是属于ELK技术栈,在业界也被广泛使用,关于两者的对比可以参考这篇文章Fluentd vs. Logstash: A Comparison of Log Collectors
$ls -i a b 523669 a 523669 b $rm -f a $ls -i b 523669 b 因为它会在访问控制规则中打开一个漏洞。能否打开一个文件不仅取决于它自己的访问权限位,还取决于每个包含目录的权限位。(例如,在您的示例中,如果test.txt是模式644,但包含目录test是模式700,则只有root和test的所有者可以打开test.txt)inode编号仅标识文件,而不标识包含目录(文件可能位于多个目录中;请阅读“硬链接”),因此内核无法仅使用inode号执行完整的访问控制检查集。
https://github.com/baixiaoustc/go_code_analysis https://studygolang.com/articles/19607?fr=sidebar
https://www.cnblogs.com/win-for-life/p/13372984.html 竞争条件 一份数据被多个线程共享,可能会产生争用和冲突的情况。这种情况被称为竞态条件,竞态条件会破坏共享数据的一致性,影响一些线程中代码和流程的正确执行。
goproxy.io是一款很好用的Golang Module Proxy,解决了国内用户无法直接下载Golang模块依赖的问题。 本文准备研读一下其开源代码github.com/goproxyio/goproxy,了解下其实现原理。 goproxy工程的主要目录结构如下: