指标聚合与日志聚合有何不同？日志不能包含指标吗？日志聚合系统不能做与指标聚合系统相同的事情吗？
这些是我经常听到的问题。我也看到供应商将他们的日志聚合系统推销为解决所有可观察性问题的方案。日志聚合是一个有价值的工具，但它通常不是时间序列数据的好工具。
时间序列指标聚合系统中的几个有价值的功能是规则的时间间隔和专门为时间序列数据定制的存储系统。规则的时间间隔允许用户始终如一地得出真实的数学结果。如果日志聚合系统以规则的时间间隔收集指标，它可能会以相同的方式工作。但是，存储系统并未针对指标聚合系统中典型的查询类型进行优化。使用日志聚合工具中的存储系统处理这些查询将需要更多资源和时间。
所以，我们知道日志聚合系统可能不适合时间序列数据，但它有什么用呢？日志聚合系统是收集事件数据的好地方。这些是不规则的但很重要的活动。一个例子可能是 Web 服务的访问日志。这些日志很重要，因为我们想知道什么在访问我们的系统以及何时访问。另一个例子是应用程序错误情况——因为它不是正常的运行状态，它可能在故障排除期间很有价值。
一些关于日志记录的规则
- 务必包含时间戳
- 务必使用 JSON 格式
- 不要记录不重要的事件
- 务必记录所有应用程序错误
- 也许记录警告
- 务必开启日志记录
- 务必以人类可读的形式编写消息
- 不要在生产环境中记录信息数据
- 不要记录任何人类无法读取或响应的内容
云成本
在调查日志聚合工具时，云似乎是一个有吸引力的选择。但是，它可能会带来巨大的成本。当在数百或数千个主机和应用程序中聚合时，日志代表大量数据。在基于云的系统中，数据的摄取、存储和检索成本很高。
从真实系统的参考点来看，大约 500 个节点和几百个应用程序的集合每天产生 200GB 的日志数据。该系统可能还有改进的空间，但即使将其减少一半，在许多 SaaS 产品中，每月也将花费近 10,000 美元。这通常仅包括 30 天的保留期，如果您想查看同比趋势数据，这时间不是很长。
这不是要阻止使用这些系统，因为它们可能非常有价值——尤其是对于较小的组织。目的是指出可能存在巨大的成本，并且当意识到这些成本时可能会令人沮丧。本文的其余部分将重点介绍自托管的开源和商业解决方案。
工具选项
ELK
ELK，是 Elasticsearch、Logstash 和 Kibana 的缩写，是市场上最流行的开源日志聚合工具。Netflix、Facebook、Microsoft、LinkedIn 和 Cisco 都在使用它。这三个组件均由 Elastic 开发和维护。Elasticsearch 本质上是 NoSQL 的 Lucene 搜索引擎实现。Logstash 是一个日志管道系统，可以摄取数据、转换数据并将其加载到 Elasticsearch 等存储中。Kibana 是 Elasticsearch 之上的可视化层。
几年前，Beats 被引入。Beats 是数据收集器。它们简化了将数据传输到 Logstash 的过程。用户无需了解每种日志类型的正确语法，即可安装 Beat，它将正确导出 NGINX 日志或 Envoy 代理日志，以便它们可以在 Elasticsearch 中有效地使用。
在安装生产级 ELK 堆栈时，可能会包含其他一些组件，例如 Kafka、Redis 和 NGINX。此外，通常用 Fluentd 替换 Logstash，我们稍后将讨论 Fluentd。该系统操作起来可能很复杂，这在早期导致了很多问题和抱怨。这些问题在很大程度上已得到修复，但它仍然是一个复杂的系统，因此如果您是规模较小的运营机构，您可能不想尝试它。
话虽如此，但有一些服务可用，因此您不必担心这一点。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 在开源版本中内置了警报，以及其他几个值得注意的功能，如流式传输、消息重写和地理定位。
流式传输功能允许在实时处理数据时将数据路由到特定的流。借助此功能，用户可以在单个流中查看所有数据库错误，并在不同的流中查看 Web 服务器错误。警报甚至可以基于这些流，在新项目添加时或超出阈值时触发。延迟可能是日志聚合系统中最大的问题之一，而流消除了 Graylog 中的这个问题。一旦日志进入，它就可以通过流路由到其他系统，而无需完全处理。
消息重写功能使用开源规则引擎 Drools。这允许针对用户定义的规则文件评估所有传入消息，从而可以删除消息（称为列入黑名单）、添加或删除字段或修改消息。
最酷的功能可能是 Graylog 的地理定位功能，它支持在地图上绘制 IP 地址。这是一个相当常见的功能，Kibana 中也提供此功能，但它增加了很多价值——特别是如果您想将其用作 SIEM 系统。地理定位功能在系统的开源版本中提供。
如果您需要支持，Graylog 公司会对开源版本的支持收费。它还为其企业版提供开放核心模型，该模型提供存档、审计日志记录和额外的支持。支持或托管方面没有太多其他选择，因此如果您不使用 Graylog（公司），您可能会孤立无援。
Fluentd
Fluentd 由 Treasure Data 开发，CNCF 已将其采纳为孵化项目。AWS 和 Google Cloud 推荐使用 C 和 Ruby 编写的 Fluentd。Fluentd 已成为许多安装中 Logstash 的常见替代品。它充当本地聚合器，收集所有节点日志并将它们发送到中央存储系统。它不是日志聚合系统。
它使用强大的插件系统来提供与不同数据源和数据输出的快速简便的集成。由于有 500 多个插件可用，因此您的大多数用例都应得到涵盖。如果它们没有被涵盖，这听起来像是为开源社区做出贡献的机会。
Fluentd 是 Kubernetes 环境中的常见选择，因为它具有低内存需求（仅几十兆字节）和高吞吐量。在像 Kubernetes 这样的环境中，每个 pod 都有一个 Fluentd sidecar，内存消耗将随着每个新创建的 pod 线性增加。使用 Fluentd 将大大降低您的系统利用率。这正在成为用 Java 开发的旨在在每个节点上运行一个工具的常见问题，在这些工具中，内存开销并不是主要问题。
2 条评论