Centralized Logging Architecture Tweet

集中式日志处理需要解决的主要问题是：collection, transport, storage, and analysis。在一些场景下，还需要具备alerting功能。英文原文

collection

应用程序以不同的方式生成日志，有些通过syslog生成，有些生成为文件。在一个运行在linux主机上的web应用会在多个目录产生日志。

如果你通过web界面提供开发者或运维人员快速访问日志解决系统日常问题，你需要能实时监控日志。但是如果你使用复制的方式构建集中式日志管理系统，日志会按固定的执行计划复制，你访问日志的频率与复制的一致。1分钟的定时执行，等待复制，不足以应对网站宕机的应急处理。

另一种场景下，如果你离线分析日志数据，计算指标或者批处理，文件复制将是一个不错的方案。

transport

日志数据会在多个主机上产生。为了保证高效传输和避免数据丢失，需要能可靠和快速传输到中央日志位置的工具。 像 Scribe, Flume, Heka, Logstash, Chukwa, fluentd, nsq 和 Kafka 这些框架都具备从一台主机可靠传输大量数据到另一台主机的能力。尽管这些框架都解决了传输问题，但是他们的实现都不尽相同。

例如，Scribe，nsq 和 Kafka，需要访问他们的API生成日志数据。通常情况是，应用系统直接生成日志，减少延迟和提高可靠性。如果你想生成集中式的日志文件数据，你需要访问他们各自的API以跟踪或流的方式生成日志。如果你能控制应用的日志生成，这样更高效。

Logstash, Heka, fluentd 和 Flume 提供了大量日志来源定义同时支持本地跟踪文件和可靠的传输他们。他们更适合通用的日志收集。当rsyslog 和 Syslog-ng被认为是事实上的日志收集器，但并不是所有的系统都使用syslog。

storage

现在你的日志数据被传输到到一个目的地。你的集中存储系统需要能处理日益增长的数据。

以下几件事情决定了如何存储：

1. 数据存储时长 - 如果日志需要长期，做归档，并且不需要立即分析，选择磁带作为备份是个合适的选择，磁带存储大量数据成本较低廉。如果你需要存储几天或者几个月，选择使用分布式的存储系统，例如HDFS, Cassandara, MongoDB or ElasticSearch。如果你仅仅需要保存几个小时做实时分析，Redis可以很好的工作。

2. 数据量大小 - Google一天的日志价值与ACME钓鱼提供商一天的日志是不同的。当你的数据量较大时，你的存储系统需要能水平扩展。

3. 日志访问方式 - 一些存储不适合实时或批量分析。磁带备份需要花费数小时加载文件，这将使得你无法在生产环境解决系统故障。如果你打算做更多的交互分析，将日志数据存储在ElasticSearch or HDFS 中，将允许你更高效的处理原始数据。一些日志数据巨大只能选择面向批处理的框架。事实上的标准是 Apache Hadoop的HDFS。

analysis

一旦你的日志存储在了集中存储平台，你需要一种方式来分析它们。最常见的方式是面向批处理，定期执行。如果你将数据存储在 HDFS, 比起编写原生的MapReduce工作， Hive 或者 Pig 可以帮助你更加容易的分析数据。

如果你需要分析界面，你可以在 ElasticSearch中存储解析日志数据，用Kibana or Graylog2 这样的前台来查询和核查数据。日志解析可用使用 Logstash, Heka 或者应用系统生成JSON格式的日志数据。这将允许更多的实时交互访问数据，但是这不适合面向批处理。

alerting

常用的方式是错误报告和监控。

大多数的日志信息不是都需要关注的，但是错误信息是需要面对的问题。当错误发生时系统可以发送电子邮件或者异步通知关注着，而不是人为关注事件。像 Sentry or HoneyBadger可以提供系统错误日志服务。同时可以告知你统计错误发生的频次。

另一个用例是监控。例如，你有成百上千的服务器，你需要知道它们返回500状态码。如果你可以解析你的日志文件，统计状态码指标，当指标超过门限时将触发告警。Riemann 是专为这样的检测场景设计的。