TranslateProject/translated/tech/20180910 3 open source log aggregation tools.md
heguangzhi 5d19bdeef6 Translated
在文章后面修改了 翻译ID
2018-09-19 08:29:31 +08:00

10 KiB
Raw Blame History

3个开源日志聚合工具

日志聚合系统可以帮助我们故障排除并进行其他的任务。以下是三个主要工具介绍。

指标聚合与日志聚合有何不同?日志不能包括指标吗?日志聚合系统不能做与指标聚合系统相同的事情吗?

这些是我经常听到的问题。我还看到供应商推销他们的日志聚合系统作为所有可观察问题的解决方案。日志聚合是一个有价值的工具,但它通常对时间序列数据的支持不够好。

时间序列指标聚合系统中几个有价值的功能为规则间隔与专门为时间序列数据定制的存储系统。规则间隔允许用户一次性地导出真实的数据结果。如果要求日志聚合系统定期收集指标数据,它也可以。但是,它的存储系统没有针对指标聚合系统中典型的查询类型进行优化。使用日志聚合工具中的存储系统处理这些查询将花费更多的资源和时间。

所以,我们知道日志聚合系统可能不适合时间序列数据,但是它有什么好处呢?日志聚合系统是收集事件数据的好地方。这些是非常重要的不规则活动。最好的例子为 web 服务的访问日志。这些都很重要,因为我们想知道什么东西正在访问我们的系统,什么时候访问。另一个例子是应用程序错误记录——因为它不是正常的操作记录,所以在故障排除过程中可能很有价值的。

日志记录的一些规则:

  • 包含时间戳
  • 包含 JSON 格式
  • 不记录无关紧要的事件
  • 记录所有应用程序的错误
  • 记录警告错误
  • 日志记录开关
  • 以可读的形式记录信息
  • 不在生产环境中记录信息
  • 不记录任何无法阅读或无反馈的内容

云的成本

当研究日志聚合工具时,云可能看起来是一个有吸引力的选择。然而,这可能会带来巨大的成本。当跨数百或数千台主机和应用程序聚合时,日志数据是大量的。在基于云的系统中,数据的接收、存储和检索是昂贵的。

作为一个真实的系统大约500个节点和几百个应用程序的集合每天产生 200GB 的日志数据。这个系统可能还有改进的空间,但是在许多 SaaS 产品中即使将它减少一半每月也要花费将近10000美元。这通常包括仅保留30天如果你想查看一年一年的趋势数据就不可能了。

并不是要不使用这些系统,尤其是对于较小的组织它们可能非常有价值的。目的是指出可能会有很大的成本,当这些成本达到时,就可能令人非常的沮丧。本文的其余部分将集中讨论自托管的开源和商业解决方案。

工具选择

ELK

ELK ,简称 Elasticsearch、Logstash 和 Kibana是最流行的开源日志聚合工具。它被Netflix、Facebook、微软、LinkedIn 和思科使用。这三个组件都是由 Elastic 开发和维护的。Elasticsearch 本质上是一个NoSQLLucene 搜索引擎实现的。Logstash 是一个日志管道系统,可以接收数据,转换数据,并将其加载到像 Elasticsearch 这样的应用中。Kibana 是 Elasticsearch 之上的可视化层。

几年前Beats 被引入。Beats 是数据采集器。它们简化了将数据运送到日志存储的过程。用户不需要了解每种日志的正确语法,而是可以安装一个 Beats 来正确导出 NGINX 日志或代理日志以便在Elasticsearch 中有效地使用它们。

安装生产环境级 ELK stack 时,可能会包括其他几个部分,如 Kafka, Redis, and NGINX。此外,用 Fluentd 替换 Logstash 也很常见,我们将在后面讨论。这个系统操作起来很复杂,这在早期导致很多问题和投诉。目前,这些基本上已经被修复,不过它仍然是一个复杂的系统,如果你使用少部分的功能,建议不要使用它了。

也就是说,服务是可用的,所以你不必担心。Logz.io 也可以使用,但是如果你有很多数据,它的标价有点高。当然,你可能没有很多数据,来使用用它。如果你买不起 Logz.io你可以看看 AWS Elasticsearch Service (ES) 。ES 是 Amazon Web Services (AWS) 提供的一项服务,它使得 Elasticsearch 很容易快速工作。它还拥有使用 Lambda 和 S3 将所有AWS日志记录到 ES 的工具。这是一个更便宜的选择,但是需要一些管理操作,并有一些功能限制。

Elastic offers 的母公司提供一款更强大的产品,它使用开放核心模型,为分析工具和报告提供了额外的选项。它也可以在谷歌云平台或 AWS 上托管。由于这种工具和托管平台的组合提供了比大多数 SaaS 选项更加便宜,这将是最好的选择并且具有很大的价值。该系统可以有效地取代或提供security information and event management ( SIEM )系统的功能。

ELK 栈通过 Kibana 提供了很好的可视化工具但是它缺少警报功能。Elastic 在付费的 X-Pack 插件中提供了提醒功能但是在开源系统没有内置任何功能。Yelp 已经开发了一种解决这个问题的方法,ElastAlert, 不过还有其他方式。这个额外的软件相当健壮,但是它增加了已经复杂的系统的复杂性。

Graylog

Graylog 最近越来越受欢迎但它是在2010年 Lennart Koopmann 创建并开发的。两年后,一家公司以同样的名字诞生了。尽管它的使用者越来越多,但仍然远远落后于 ELK 栈。这也意味着它具有较少的社区开发特征,但是它可以使用与 ELK stack 相同的 Beats 。Graylog 由于 Graylog Collector Sidecar 使用 Go 编写所以在 Go 社区赢得了赞誉。

Graylog 使用 Elasticsearch、MongoDB 并且 提供 Graylog Server 。这使得它像ELK 栈一样复杂也许还要复杂一些。然而Graylog 附带了内置于开源版本中的报警功能,以及其他一些值得注意的功能,如 streaming 、消息重写 和 地理定位。

streaming 能允许数据在被处理时被实时路由到特定的 Streams。使用此功能用户可以在单个Stream 中看到所有数据库错误,在不同的 Stream 中看到 web 服务器错误。当添加新项目或超过阈值时,甚至可以基于这些 Stream 提供警报。延迟可能是日志聚合系统中最大的问题之一Stream消除了灰色日志中的这一问题。一旦日志进入它就可以通过 Stream 路由到其他系统,而无需全部处理。

消息重写功能使用开源规则引擎 Drools 。允许根据用户定义的规则文件评估所有传入的消息,从而可以删除消息(称为黑名单)、添加或删除字段或修改消息。

Graylog 最酷的功能是它的地理定位功能,它支持在地图上绘制 IP 地址。这是一个相当常见的功能,在 Kibana 也可以这样使用,但是它增加了很多价值——特别是如果你想将它用作 SIEM 系统。地理定位功能在系统的开源版本中提供。

Graylog 如果你想要的话,它会对开源版本的支持收费。它还为其企业版提供了一个开放的核心模型,提供存档、审计日志记录和其他支持。如果你不需要 Graylog (the company) 支持或托管的,你可以独立使用。

Fluentd

FluentdTreasure Data 开发的,CNCF 已经将它作为一个孵化项目。它是用 C 和 Ruby 编写的,并由AWSGoogle Cloud推荐。fluentd已经成为许多装置中logstach的常用替代品。它充当本地聚合器收集所有节点日志并将其发送到中央存储系统。它不是日志聚合系统。

它使用一个强大的插件系统提供不同数据源和数据输出的快速和简单的集成功能。因为有超过500个插件可用所以你的大多数用例都应该包括在内。如果没有这听起来是一个为开源社区做出贡献的机会。

Fluentd 由于占用内存少(只有几十兆字节)和高吞吐量特性,是 Kubernetes 环境中的常见选择。在像 Kubernetes 这样的环境中每个pod 都有一个 Fluentd sidecar ,内存消耗会随着每个新 pod 的创建而线性增加。在这中情况下,使用 Fluentd 将大大降低你的系统利用率。这对于Java开发的工具来说这是一个常见的问题这些工具旨在为每个节点运行一个工具而内存开销并不是主要问题。


via: https://opensource.com/article/18/9/open-source-log-aggregation-tools

作者:Dan Barker 选题:lujun9972 译者:heguangzhi 校对:校对者ID

本文由 LCTT 原创编译,Linux中国 荣誉推出