你可能会奇怪，为什么要为 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 将是你的自然选择。
