开源日志工具_3个开源日志聚合工具

开源日志工具

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

这些是我经常听到的问题。 我还看到供应商将其日志聚合系统作为解决所有可观察性问题的解决方案。 日志聚合是一个有价值的工具，但通常不是时序数据的好工具。

时序度量标准聚合系统中的几个重要功能是规则间隔和专门为时序数据定制的存储系统。 规则间隔允许用户一致地得出真实的数学结果。 如果日志聚合系统按固定的时间间隔收集指标，则它可能会以相同的方式工作。 但是，存储系统并未针对指标聚合系统中典型的查询类型进行优化。 使用日志聚合工具中的存储系统，这些查询将花费更多的资源和时间来处理。

因此，我们知道日志聚合系统可能不适合时间序列数据，但是它有什么用呢？ 日志聚合系统是收集事件数据的好地方。 这些是不正常的重要活动。 一个示例可能是Web服务的访问日志。 这些意义重大，因为我们想知道什么在访问我们的系统以及何时访问。 另一个示例是应用程序错误情况-由于它不是正常的操作情况，因此在故障排除期间可能很有用。

少数记录规则：

• 务必包含时间戳记
• JSON中的DO格式
• 不要记录无关紧要的事件
• 记录所有应用程序错误
• 可能记录警告
• 不要打开日志记录
• 以易读的形式编写消息
• 不要在生产中记录信息性数据
• 不要记录人类无法阅读或做出的任何React

云成本

在研究日志聚合工具时，云似乎是一个有吸引力的选择。 但是，这可能会带来巨大的成本。 在数百或数千个主机和应用程序中聚合时，日志代表大量数据。 在基于云的系统中，数据的摄取，存储和检索非常昂贵。

作为来自实际系统的参考，大约500个节点和数百个应用程序的集合每天可产生200GB的日志数据。 该系统可能还有改进的空间，但即使减少一半，在许多SaaS产品中每月也要花费近10,000美元。 这通常包括仅保留30天，如果您希望逐年查看趋势数据，则保留时间不会很长。

这并不是要阻止使用这些系统，因为它们可能非常有价值-特别是对于较小的组织。 目的是指出可能会产生大量成本，并且在实现时可能会令人沮丧。 本文的其余部分将重点介绍自托管的开源和商业解决方案。

工具选项

麋鹿

ELK是Elasticsearch，Logstash和Kibana的缩写，是市场上最受欢迎的开源日志聚合工具。 Netflix，Facebook，Microsoft，LinkedIn和Cisco都在使用它。 这三个组件均由Elastic开发和维护。 Elasticsearch本质上是NoSQL，Lucene搜索引擎的实现。 Logstash是一个日志管道系统，可以提取数据，对其进行转换并将其加载到类似Elasticsearch的存储中。 Kibana是Elasticsearch之上的可视化层。

几年前，引入了Beats。 Beats是数据收集器。 它们简化了将数据传送到Logstash的过程。 用户无需安装每种日志的正确语法，就可以安装Beat，该Beat将正确导出NGINX日志或Envoy代理日志，以便可以在Elasticsearch中有效地使用它们。

在安装生产级ELK堆栈时，可能还包括其他一些部件，例如Kafka ， Redis和NGINX 。 同样，用Fluentd替换Logstash是很常见的，我们将在后面讨论。 该系统的操作可能很复杂，因此在初期就引发了许多问题和投诉。 这些在很大程度上已得到修复，但是它仍然是一个复杂的系统，因此，如果您的操作较小，则可能不想尝试。

就是说，有可用的服务，因此您不必担心。 Logz.io将为您运行它，但是如果您有大量数据，它的定价会有点高。 当然，您可能较小，并且可能没有很多数据。 如果您负担不起Logz.io，则可以查看类似AWS Elasticsearch Service （ES）的东西。 ES是Amazon Web Services（AWS）提供的一项服务，使Elasticsearch快速工作变得非常容易。 它还具有使用Lambda和S3将所有AWS日志获取到ES的工具。 这是一个便宜得多的选择，但是需要一些管理并且有一些限制。

Elastic，堆栈的母公司， 提供了使用开放核心模型的更强大的产品，该模型提供了围绕分析工具和报告的其他选项。 它也可以托管在Google Cloud Platform或AWS上。 这可能是最好的选择，因为这种工具和托管平台的组合提供了比大多数SaaS选项便宜的解决方案，并且仍然提供了很多价值。 该系统可以有效替换或为您提供安全信息和事件管理 （SIEM）系统的功能。

ELK堆栈还通过Kibana提供了出色的可视化工具，但缺少警报功能。 Elastic在付费的X-Pack附加组件中提供了警报功能，但是开源系统没有内置任何功能。 Yelp为这个问题创建了一个解决方案，称为ElastAlert ，并且可能还有其他解决方案。 该附加软件相当强大，但是却增加了本来已经很复杂的系统的复杂性。

Graylog

Graylog的知名度最近有所提高，但是当Lennart Koopmann于2010年创建该公司时就开始了它。两年后，一家同名公司诞生了。 尽管增加了使用量，但它仍然远远落后于ELK堆栈。 这也意味着它具有较少的社区开发功能，但可以使用与ELK堆栈相同的Beats。 Graylog推出了用Go语言编写的Graylog Collector Sidecar，在Go社区中获得了好评。

Graylog在后台使用Elasticsearch， MongoDB和Graylog服务器。 这使得运行起来与ELK堆栈一样复杂，甚至可能更多。 但是，Graylog具有内置在开源版本中的警报，以及其他一些值得注意的功能，例如流传输，消息重写和地理位置。

流功能允许在处理数据时将数据实时实时路由到特定的流。 使用此功能，用户可以查看单个Stream中的所有数据库错误和不同Stream中的Web服务器错误。 当添加新项目或超过阈值时，警报甚至可以基于这些流。 延迟可能是日志聚合系统最大的问题之一，而Streams在Graylog中消除了该问题。 日志一经输入，便可以通过Stream路由到其他系统，而无需完全处理。

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

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

如果需要，该公司Graylog会就开放源代码版本收取支持费用。 它还为其企业版提供了一个开放的核心模型，该模型提供了归档，审核日志记录和其他支持。 没有太多其他支持或托管选项，因此，如果您不使用Graylog（该公司），您可能会独自一人。

流利的

Fluentd是由Treasure Data开发的， CNCF已将其用作孵化项目。 它是用C和Ruby编写的，并且由AWS和Google Cloud推荐。 Fluentd已成为许多安装中Logstash的通用替代品。 它充当本地聚合器，以收集所有节点日志并将其发送到中央存储系统。 它不是日志聚合系统。

它使用了强大的插件系统，可以快速轻松地与不同的数据源和数据输出集成。 由于有超过500个可用的插件，因此应该涵盖大多数用例。 如果不是的话，这听起来像是一个为开源社区做出贡献的机会。

Fluentd由于其低内存需求（仅几十兆字节）和高吞吐量而在Kubernetes环境中是常见的选择。 在像Kubernetes这样的环境中，每个Pod都有Fluentd Sidecar，随着每个新Pod的创建，内存消耗将线性增加。 使用Fluentd将大大降低您的系统利用率。 对于使用Java开发的工具来说，这已经成为一个普遍的问题，这些工具旨在在每个节点上运行一个内存开销不是主要问题的工具。

接下来要读什么

翻译自: https://opensource.com/article/18/9/open-source-log-aggregation-tools

开源日志工具