集中式日志log收集综述

最新推荐文章于 2024-09-02 09:06:49 发布

weixin_34261739

最新推荐文章于 2024-09-02 09:06:49 发布

阅读量181

点赞数

文章标签： ui 运维数据库

原文链接：https://my.oschina.net/HeAlvin/blog/378643

版权

2019独角兽企业重金招聘Python工程师标准>>>

前言

日志对于一个系统来说十分重要，系统管理员可以从日志中获悉系统的运行状况，是否发生异常等。实际上，一般进程都会以某种格式产生日志，且日志一般是输出到本地的文件中。一旦系统中的节点增加到多个节点，管理和访问这些日志会变得复杂。如果没有合适的工具，要从上百个节点上的上百个日志文件中搜索出错误日志会变得很困难。常见解决思路是建立集中式日志收集系统(Centralized Logging)，将所有节点上的日志统一收集，管理，访问。

解决方案

Rsync

最简单的方法是将日志文件拷贝到某个服务器上，可以通过配置cron和rsync来实现。实现很简单直接，但是由于cron是固定时间间隔执行，所以无法保证实时的日志访问。也因为是简单的文件拷贝，无法做日志聚类。

Syslog

另外的方法是使用syslog，很多人使用 rsyslog或者 syslog-ng，他们是syslog的不同实现。syslog服务允许进程将日志消息发送给他们，他们会根据配置文件来决定如何存储日志。

部署方法是在一台中心服务器上安装syslog守护进程，配置其他服务器推送日志到中心服务器上。这里有一篇教程Centralized Logging Use Rsyslog。

基本上所有linux发行版都自带了syslog，所以用起来十分方便。不过作为集中式日志收集服务，如何实现高吞吐和高可用是关键。

分布式日志收集器

新的解决方案主要设计来处理高容量，高吞吐的日志、事件收集。他们绝大多数是更通用的事件流（event stream）处理服务，只是将日志处理看其中一个使用场景。每个系统都由自己特点和独到之处，不过架构上都十分相近。他们一般都包括一个logging客户端/agent在特定的服务器上。agent将日志转发到消息收集集群上，消息收集集群再将消息存放到存储集群中。这种架构和传统Syslog相比的优势是消息收集集群和存储集群都可以横向扩展，对于不断增长的吞吐量和日志量都可以通过加机器的方式来扩展。

对于这种架构，开源界有这些软件：

Scribe - Scribe是由Facebook开源的，主打可扩展性和可靠性的日志聚合服务，由C++编写，使用Thrift通信协议，但是实际上可以支持任何语言。
Flume - Flume是apache的项目，旨在收集，聚合，移动大量的日志数据，最终将数据存放到HDFS上。
logstash - Logstash允许你从各种源头灵活地整合，分析，索引日志。它内置了许多输入源，比如file，syslog；过滤器，比如grep，split，multiline等；还有输出端，比如elasticsearch，mongodb等。另外他还内置了一个Web UI来查看和搜索日志。可以参考入门教程
Chukwa - Chukwa是另外一个apache项目用来将日志放到HDFS中。
fluentd - 和logstash类似，也支持各种输入和输出，虽然不支持任何存储层，但是可配置。另外，它的设计原则是方便安装和低开销。
kafka - 由LinkIn开发的用来处理他们的活动流（activity stream），现在是apache的孵化项目。虽然kafka可用作为日志收集器，不过不是他的主要使用场景。需要配置Zookeeper来管理集群。
Graylog2 - 提供UI来搜索和分析日志。日志存储在Mongodb或者ElasticSearch中。为了解决syslog消息的一些短板：消息限制1024字节、无结构消息体。graylog2支持GELF格式，如果需要记录很长的堆栈信息，可以看看这个格式。