为了调试、维护、分析代码或者仅仅由于规定, 应用程序会记录log。 l常常在出现问题后, 我们才会发现log的重要性。 老练的devops的工程师对记录日志都非常的积极主动, 还会使用诸如 Logstash,Loggy或者Splunk这类的工具帮助自己把日志从应用服务器上拉去的日志服务器, 再在上面做分析和索引。无论日志管理工具多么的分门别类,你至少要使用一个,而不是对一个超过100m的日志文件使用grep命令。
传统的日志管理系统有两部分组成:分发器和收集器。 分发器运行在应用服务器上,用以收集传输日志。 收集器运行在中心服务器, 一个服务器集群或者一个远程的云服务器上,用来长时间的存储和索引日志。 虽然收集器承担了日志管理系统的大部分工作, 分发器必须支持从记录各种服务的日志, 保证不受网络问题的影响, 而且还不能占用太多资源影响到应用本身的运行。
轮询 - 一些收集器定时检查文件是否有变动,这样会不必要的加重cpu的负担
写入本地 - 很多的日志分发器期望日子写到本地磁盘, 以数据库为例, 数据库操作和记录日志会强用有限的资源, 导致性能问题。
潜在的重复、遗漏日志记录行 - 在服务器宕机或者重启的时候,很多的分发器使用文件保存日志内的位置信息。这部分位置信息有可能会不同步, 特别是在切割日志文件的时候。
切割日志文件的噩梦 - 有多种日志切割技术, 每个都在某种程度上需要多个程序之间协同工作。传统的收集器复杂的配置来支持不同的计划方式(译者:这里说的应该是执行时间上的设置)而不考虑原因。这可能会导致很恶劣的竞争状态。
解决上类问题的分发器通常需要整合到应用程序内部。这就需要修改你的应用程序或者麻烦维护人员提供日志的支持(通常是syslog)
LoggerFS 是一个go语言实现的,基于FUSE的文件系统,他普适于各类日志管理系统。因为LoggerFS是个文件系统, 记录日志到 LoggerFS 是一件很简单的事情。(译者: 要做的就是吧文件写到文件系统)。 LoggerFS 彻底消除了上述的各类问题。
在内部LoggerFS实现了部分的文件系统的操作,提供写和权限管理服务。日志数据被缓存在内存里(为了保证可靠性,会定时的记录)并且会根据配置的传输手段传输数据。应用程序(例如 nginx、mongodb或者你自己的服务),只需要简单的通过文件和日志系统交互,而不需要知道背后发生了什么。
特征
后端/聚合器的不可知论(包括多个日志传送)
Loggly, Splunk, Logstash, Rsyslog/Syslog-ng
支持任何基于syslog的日志管理器
ZeroMQ
NSQ传送–在内部使用Autoref.com
通用UDP/TCP
很快:AMQP和redis(后来:Scribe?fluentd?)
标注
添加任意自定义域登录数据(例如,主机名,文件名,PID /进程名称,uid /作者用户名)
提高安全性
不要有读权限的日志文件,这取决于配置,日志接触不到磁盘。
TLS支持(一些传送)
易于使用的任何服务mydaemon 2 > /mnt/ loggerfs / service.error.log 1 > /mnt/ loggerfs / service.log
对于大多数应用程序,指向日志要安装的文件系统同样简单
如果一个服务只写到stdout和stderr会怎么样?重定向到loggerfs:不同于管道的传送者,loggerfs支持独立的启动和停止任意数量的服务。
不能自定义日志文件路径?符号链接到loggerfs:ln -s /mnt/ loggerfs / mydaemon.log /var/log/messages rigid_path.log ; mydaemon
你也可以链接整个目录获取多个文件。
不能禁用日志循环?配置loggerfs忽略循环的文件。
日志:
-名称:排除循环日志
模式:.*.[0-9] +(.gz)?
忽略:yes
未来的开发
我们希望构建使用方便和可靠的日志托运功能将使帮助团队使用我们的日志管理系统。
目前,我们正在修饰代码和编写测试,准备发布最初版的开源LoggerFS。如果你有兴趣参与进来,请告知我们。 我们也可以在取名上采用一些建议——目前我在想”SlumberjackFS“(结尾语:睡着也能知道你的日志是安全的)。
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务