2020 年最值得推荐的 7 种 Kubernetes 日志管理工具

你可能会奇怪，为什么要为 Kubernetes 的日志管理工具而烦恼？

Kubernetes 是容器编排市场的主导者，经常被用来托管微服务。微服务的每个实例都会生成大量的日志事件，并且这些事件很快就会变得难以管理。但是，更糟糕的是，当问题发生时，由于服务之间的复杂的交互以及几乎无穷无尽的可能故障模式，很难找到问题根源。这种潜在的问题推动了 Kubernetes 日志管理工具的流行。

但是为什么我们有如此多的工具呢？是否存在一种完美的工具，能够满足每一种需求，并尽可能高效、快速地进行监控、日志记录和根源分析？你可能已经猜到了，答案是否定的。

大多数 Kubernetes 日志管理工具都是 ELK 的变体，具有相似的功能并且具有相似的局限性。这些工具可以帮助你访问日志并搜索信息，但问题是，你需要知道要查找的内容。这些工具中的大多数还需要解析规则和警报规则才能正常工作。但我遇到了一个例外，它不需要手动创建规则就可以自动检测问题。

下面是我列出的 2020 年 Kubernetes 最佳日志管理工具清单。

1 Zebrium

你认为会先出现其他工具吗？还是 Prometheus 或者 ELK？没有，我将 Zebrium 放在第一位，是因为我看到这个东西有潜力成为 Kubernetes 日志管理的下一个大杀器。

最近，这家新成立的初创公司被评为“Gartner 2020 年最值得关注的 25 家企业软件初创公司”，并被评为“Forbes 人工智能 50 强：美国最有前途的人工智能公司”。

谈到成功，Zebrium 最近还帮助 Sweetwater 将事件跟踪时间 从 3 小时缩短到仅仅几分钟。Zebrium 甚至能发现以前没有注意到的隐藏问题。这个功能非常棒，因为它能够在问题影响客户之前就发现问题。

那又是什么让 Zebrium 的方法在竞争中脱颖而出呢？嗯，他们利用人工智能来发现问题，并自动找出问题根源，而所有其他的工具都依靠用户手动添加规则。Zebrium 还可以用作一个独立的日志管理平台，也可以与 ELK Stack（他们称之为 ZELK 栈）或其他日志管理器集成。

这听起来像是梦想成真，所以我在一个非常简单的项目上对它进行了测试。在这个测试中，Zebrium 自动检测到网络调用超时的问题。而我并没有为此建立任何规则，也没有手动监视系统。Zebrium 刚刚通过其基于机器学习算法就发现了这个问题，并立即通知了我。

还需要指出的是，我并非专业的 DevOps 工程师，况且我也没有在更大的项目中测试过 Zebrium。

优点

• 易于上手；只需复制 / 粘贴自定义的 helm 或 kubectl 命令即可。

• 自动检测问题和问题根源，无需手动添加规则。

• 可以用作独立的日志管理工具，也可以作为现有日志管理工具（如 ELK 栈）的机器学习附加组件。

缺点

• 没有竞争对手那么出名。

• 免费套餐每天限 500MB，有效期 3 天。

• 支持 Kubernetes、Docker 和大多数常用平台，但对 Windows 尚未提供原生支持。

官网：https://www.zebrium.com/

2 Sematext

这是一个用于日志管理和应用程序性能监视的解决方案。Sematext 提供了系统状态的全栈可见性。

Sematext 并不仅限于 Kubernetes 日志，它还根据度量标准和日志对 Kubernetes 进行监控和报警。收集的日志针对几种不同的已知日志格式自动解析 / 结构化，并且用户还可以提供自定义日志的模式。它还公开了 Elasticesarch API，因此，你可以使用任何支持 Elasticsearch 的工具，比如 FileBeat 以及带有 Sematext 的 Logstash。你可以将它用作 ELK 的变体，也可以与原生 Sematext 生态系统一起使用。该工具有助于创建特定的规则来监视特定的案例并捕获异常情况。客户端可以控制和监控所有服务，这要归功于 Sematext 全面实时仪表板。

优点

• 与其他 Sematext Cloud 工具集成（如 Experience 和 Infrastructure Monitoring）集成。

• 可配置的超时控制通过组织日志被接收来控制成本。

• ELK 的灵活性。

缺点

• Sematext 小工具和 Kibana 无法在一个仪表板上混合使用。

• 需要在日志传递程序中进行自定义解析，Sematext 仅在服务器端解析 Syslog 和 JSON。

• 尽管他们计划改进跟踪功能，但跟踪功能较弱。

官网：https://sematext.com/

3 Grafana Loki

Kubernetes 日志监视工具列表的第三位并不是 ELK，而是 Loki。受 Prometheus 的启发，Loki 是一个多租户、高可用的日志聚合工具。该工具可以帮助收集日志，但用户需要为其构建手动规则。Loki 和 Grafana、Prometheus 和 Kubernetes 一起使用。Loki 可以让你的内部流程更加高效。举例来说，它为 Paytm Insider 节省了  75% 的记录和监控成本。由于没有对日志内容进行索引，而只是为每个事件流索引一组标签，因此 Loki 实现了很高的效率。

优点

• 大型生态系统。

• 丰富的格式化功能。

• 由于日志内容没有被索引，所以效率很高。

缺点

• 没有针对 Kubernetes 日志管理进行优化。

• 构建规则需要大量的手工工作。

• 缺少内容索引可能会限制搜索性能。

官网：https://grafana.com/oss/loki/

4 Elastic Stack

ELK 最终名列第四。总的来说，ELK 可能是最为著名的开源日志管理工具。ELK 是 Elasticsearch、Logstash 和 Kibana 的首字母缩写。每个组件负责日志记录过程的不同部分。Elasticsearch 是一个功能强大的、且可扩展的搜索系统，Logstash 聚合和处理日志，Kibana 提供分析和可视化界面，帮助用户理解数据。它们共同为 Kubernetes 提供了全面的日志记录解决方案。请注意，ELK 栈还有许多其他变体（如 EFK 栈：Elasticsearch、Flunentd 和 Kibana）。

许多大公司都在使用 ELK，比如 Adobe、T-Mobile 和 Walmart 等等，因此你可以确定它的健壮性。总的说来，这是一个可靠且经过充分验证的工具。我之所以将它放在第四位，是因为它的复杂性和工作所需的大量资源。

优点

• 该工具广为人知，并拥有一个庞大的社区。

• 非常广泛的平台支持。

• 在 Kibana 中具有丰富的分析和可视化功能。

• 需要对日志进行复杂的分析，并手动定义警报规则。

缺点

• 难以维持规模。

• 需要进行大量调优，特别是对于大型环境。

• 需要大量的资源请求。

• 有些功能需要付费许可。

官网：https://www.elastic.co/what-is/elk-stack

5 Google Operations（前身为 Stackdriver）

Google Operations，也就是你可能知道的 StackDriver，是用于在科技巨擘 Google 的环境中监控、故障排除和提高应用程序性能的原生工具。它收集 Google Cloud 和你的应用程序上的度量指标、日志和跟踪。Google Operations 相当于 AWS 的 CloudWatch，而且和 CloudWatch 一样，它也有日志记录和监控解决方案。

Cloud Logging 与 GKE 深度集成，并将默认情况下添加到你创建的每个 GKE 集群中。你的日志存储在 Logging 的数据存储中，并被索引用于搜索和可视化。Cloud Logging 支持灵活的查询（可保存）、简单的字段探索和直方图可视化，并能与 Google 基础设施的其他工具无缝集成。

优点

• 实时日志管理和分析。

• 度量指标本身就具有可观测性。

• 大量的集成。

缺点

• 由于请求需经过不同级别的 Google Cloud Platform（GCP），因此很难跟踪真正的延迟。

• 仅适用于 GCP 环境。

• 价格体系复杂，很难预估出某些东西的成本。

官网：https://cloud.google.com/products/operations

6 CloudWatch

CloudWatch 是 Amazon Web Service 提供的 AWS 原生产品。它从 AWS 收集监控和运营数据，并在一个自动化仪表板上将其进行可视化。这使你能够查看并关联日志和指标，以了解问题的根本原因。日志可以使用 CloudWatch 自己专门构建的查询语言来分析，该语言支持聚合、过滤器和正则表达式。你也可以通过 Lambda 将日志发送到 Elasticsearch。

总的来说，如果你已经在使用 Amazon 服务，那么 CloudWatch 就是一个很不错的选择。它还可以在混合云架构中使用，并使用代理或 API 来监控内部资源。很多知名公司，如 Airbnb、Deliveroo、9GAG 等，都在使用 CloudWatch。由于 DynamoDB TTL 的存在，它每年还可以为公司节省数百万美元的开支。

优点

• 专门为监视 AWS 资源而构建。

• 具有最高容许实例度量指标（t2 CPU 积分余额）。

• 详细的监视和自动伸缩组。

缺点

• 它只能用于 AWS 服务。

• 仪表板的自定义选项并不多。

• 不支持事务跟踪。

官网：https://aws.amazon.com/cloudwatch/

7 Fluentd

Fluentd 是一个跨平台的开源数据收集器，提供了统一的日志记录层（但它并不是独立的日志管理器）。这是一个非常流行的工具，拥有超过 5000 名用户，包括 Atlassian、Microso 和 Amazon。从客户端来看，我们可以得出高水平的可靠性和性能。此外，Fluentd 还创建了一个统一的日志记录层，帮助你更有效地使用数据，并在软件上对数据进行快速的迭代。这个工具可以帮助你每秒处理 120000 条记录，就像处理 LINE 一样。

优点

• 大型社区和插件生态系统。

• 统一的日志记录层。

• 经验证的可靠性和性能。

• 启动简单，可以在十分钟内完成安装。

缺点

• 配置困难。

• 对转换数据的支持有限。

• 不是完整的日志解决方案。

官网：https://www.fluentd.org/

8 如何选择合格的工具

首先，我应该解释一下我为何没有将 Prometheus 列入名单，因为我肯定你会看到的。这是因为本文主要讨论日志监视工具，而 Prometheus 处理的是度量指标，并不支持日志管理。

因此，如果你厌倦了手动查找日志以查找问题根源，或厌倦了构建和管理警报规则，那么你应该尝试使用 Zebrium 及其基于人工智能和机器学习的算法。这可能会为你节省大量时间，让你从制定大量规则的艰巨任务中解脱出来。这看起来是一种非常有趣的日志记录方法。

不过，如果你正在寻找一些更主流的工具，并且知道要创建哪些警报规则，或者你不信任人工智能，那么可以试试 Loki 或 Sematext，如果你以前没有使用过日志监视工具的话，它们都是非常有效的工具。如果你已经使用 Grafana 或者 Sematext Cloud/Enterprise 产品，它们将会特别有用。

如果你的项目使用 Google 的 GCP 产品，那么，一个很好的、并且相当明显的变体可能就是 Google Operations。

如果你有多个或外来的日志源，可以尝试 Fluentd 的统一日志记录层，但你仍然需要日志记录工具。当然，如果你是 AWS 用户的话，CloudWatch 将是你的自然选择。

作者介绍

Max Shash，DeployPlace 首席营销官。

原文链接

https://dzone.com/articles/7-best-log-management-tools-for-kubernetes-2020