Dan Barker 发布的文章

让我们看看可以用在你自己的 NLP 应用中的十几个工具吧。

在过去的几年里，自然语言处理（NLP）推动了聊天机器人、语音助手、文本预测等这些渗透到我们的日常生活中的语音或文本应用程技术的发展。目前有着各种各样开源的 NLP 工具，所以我决定调查一下当前开源的 NLP 工具来帮助你制定开发下一个基于语音或文本的应用程序的计划。

尽管我并不熟悉所有工具，但我将从我所熟悉的编程语言出发来介绍这些工具（对于我不熟悉的语言，我无法找到大量的工具）。也就是说，出于各种原因，我排除了三种我熟悉的语言之外的工具。

R 语言可能是没有被包含在内的最重要的语言，因为我发现的大多数库都有一年多没有更新了。这并不一定意味着它们没有得到很好的维护，但我认为它们应该得到更多的更新，以便和同一领域的其他工具竞争。我还选择了最有可能用在生产场景中的语言和工具（而不是在学术界和研究中使用），而我主要是使用 R 作为研究和发现工具。

我也惊讶地发现 Scala 的很多库都没有更新了。我上次使用 Scala 已经过去了两年了，当时它非常流行。但是大多数库从那个时候就再没有更新过，或者只有少数一些有更新。

最后，我排除了 C++。 这主要是因为我上次使用 C++ 编写程序已经有很多年了，而我所工作的组织还没有将 C++ 用于 NLP 或任何数据科学方面的工作。

Python 工具

自然语言工具包（NLTK）

毋庸置疑，自然语言工具包（NLTK）是我调研过的所有工具中功能最完善的一个。它几乎实现了自然语言处理中多数功能组件，比如分类、令牌化、词干化、标注、分词和语义推理。每一个都有多种不同的实现方式，所以你可以选择具体的算法和方式。同时，它也支持不同的语言。然而，它以字符串的形式表示所有的数据，对于一些简单的数据结构来说可能很方便，但是如果要使用一些高级的功能来说就可能有点困难。它的使用文档有点复杂，但也有很多其他人编写的使用文档，比如这本很棒的书。和其他的工具比起来，这个工具库的运行速度有点慢。但总的来说，这个工具包非常不错，可以用于需要具体算法组合的实验、探索和实际应用当中。

SpaCy

SpaCy 可能是 NLTK 的主要竞争者。在大多数情况下都比 NLTK 的速度更快，但是 SpaCy 的每个自然语言处理的功能组件只有一个实现。SpaCy 把所有的东西都表示为一个对象而不是字符串，从而简化了应用构建接口。这也方便它与多种框架和数据科学工具的集成，使得你更容易理解你的文本数据。然而，SpaCy 不像 NLTK 那样支持多种语言。它确实接口简单，具有简化的选项集和完备的文档，以及用于语言处理和分析各种组件的多种神经网络模型。总的来说，对于需要在生产中表现出色且不需要特定算法的新应用程序，这是一个很不错的工具。

TextBlob

TextBlob 是 NLTK 的一个扩展库。你可以通过 TextBlob 用一种更简单的方式来使用 NLTK 的功能，TextBlob 也包括了 Pattern 库中的功能。如果你刚刚开始学习，这将会是一个不错的工具，可以用于对性能要求不太高的生产环境的应用。总体来说，TextBlob 适用于任何场景，但是对小型项目尤佳。

Textacy

这个工具是我用过的名字最好听的。先重读“ex”再带出“cy”，多读“Textacy”几次试试。它不仅仅是名字读起来好，同时它本身也是一个很不错的工具。它使用 SpaCy 作为它自然语言处理核心功能，但它在处理过程的前后做了很多工作。如果你想要使用 SpaCy，那么最好使用 Textacy，从而不用去编写额外的附加代码就可以处理不同种类的数据。

PyTorch-NLP

PyTorch-NLP 才出现短短的一年，但它已经有一个庞大的社区了。它适用于快速原型开发。当出现了最新的研究，或大公司或者研究人员推出了完成新奇的处理任务的其他工具时，比如图像转换，它就会被更新。总体来说，PyTorch 的目标用户是研究人员，但它也能用于原型开发，或使用最先进算法的初始生产载荷中。基于此基础上的创建的库也是值得研究的。

Node.js 工具

Retext

Retext 是 Unified 集合的一部分。Unified 是一个接口，能够集成不同的工具和插件以便它们能够高效的工作。Retext 是 Unified 工具中使用的三种语法之一，另外的两个分别是用于 Markdown 的 Remark 和用于 HTML 的 Rehype。这是一个非常有趣的想法，我很高兴看到这个社区的发展。Retext 没有涉及很多的底层技术，更多的是使用插件去完成你在 NLP 任务中想要做的事情。拼写检查、字形修复、情绪检测和增强可读性都可以用简单的插件来完成。总体来说，如果你不想了解底层处理技术又想完成你的任务的话，这个工具和社区是一个不错的选择。

Compromise

Compromise 显然不是最复杂的工具，如果你正在找拥有最先进的算法和最完备的系统的话，它可能不适合你。然而，如果你想要一个性能好、功能广泛、还能在客户端运行的工具的话，Compromise 值得一试。总体来说，它的名字（“折中”）是准确的，因为作者更关注更具体功能的小软件包，而在功能性和准确性上有所折中，这些小软件包得益于用户对使用环境的理解。

Natural

Natural 包含了常规自然语言处理库所具有的大多数功能。它主要是处理英文文本，但也包括一些其它语言，它的社区也欢迎支持其它的语言。它能够进行令牌化、词干化、分类、语音处理、词频-逆文档频率计算（TF-IDF）、WordNet、字符相似度计算和一些变换。它和 NLTK 有的一比，因为它想要把所有东西都包含在一个包里头，但它更易于使用，而且不一定专注于研究。总的来说，这是一个非常完整的库，目前仍在活跃开发中，但可能需要对底层实现有更多的了解才能完全发挥效力。

Nlp.js

Nlp.js 建立在其他几个 NLP 库之上，包括 Franc 和 Brain.js。它为许多 NLP 组件提供了一个很好的接口，比如分类、情感分析、词干化、命名实体识别和自然语言生成。它也支持一些其它语言，在你处理英语之外的语言时能提供一些帮助。总之，它是一个不错的通用工具，并且提供了调用其他工具的简化接口。在你需要更强大或更灵活的工具之前，这个工具可能会在你的应用程序中用上很长一段时间。

Java 工具

OpenNLP

OpenNLP 是由 Apache 基金会管理的，所以它可以很方便地集成到其他 Apache 项目中，比如 Apache Flink、Apache NiFi 和 Apache Spark。这是一个通用的 NLP 工具，包含了所有 NLP 组件中的通用功能，可以通过命令行或者以包的形式导入到应用中来使用它。它也支持很多种语言。OpenNLP 是一个很高效的工具，包含了很多特性，如果你用 Java 开发生产环境产品的话，它是个很好的选择。

Stanford CoreNLP

Stanford CoreNLP 是一个工具集，提供了统计 NLP、深度学习 NLP 和基于规则的 NLP 功能。这个工具也有许多其他编程语言的版本，所以可以脱离 Java 来使用。它是由高水平的研究机构创建的一个高效的工具，但在生产环境中可能不是最好的。此工具采用双许可证，具有可以用于商业目的的特定许可证。总之，在研究和实验中它是一个很棒的工具，但在生产系统中可能会带来一些额外的成本。比起 Java 版本来说，读者可能对它的 Python 版本更感兴趣。同样，在 Coursera 上最好的机器学习课程之一是斯坦福教授提供的，点此访问其他不错的资源。

CogCompNLP

CogCompNLP 由伊利诺斯大学开发的一个工具，它也有一个相似功能的 Python 版本。它可以用于处理文本，包括本地处理和远程处理，能够极大地缓解你本地设备的压力。它提供了很多处理功能，比如令牌化、词性标注、断句、命名实体标注、词型还原、依存分析和语义角色标注。它是一个很好的研究工具，你可以自己探索它的不同功能。我不确定它是否适合生产环境，但如果你使用 Java 的话，它值得一试。

你最喜欢的开源 NLP 工具和库是什么？请在评论区分享文中没有提到的工具。

via: https://opensource.com/article/19/3/natural-language-processing-tools

作者：Dan Barker 选题：lujun9972 译者：zxp 校对：wxy

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

本文是一篇简单指南：介绍一些顶级的开源的持续集成、持续交付和持续部署（CI/CD）工具。

虽然持续集成、持续交付和持续部署（CI/CD）在开发者社区里已经存在很多年，一些机构在其运维部门也有实施经验，但大多数公司并没有做这样的尝试。对于很多机构来说，让运维团队能够像他们的开发同行一样熟练操作 CI/CD 工具，已经变得十分必要了。

无论是基础设施、第三方应用还是内部开发的应用，都可以开展 CI/CD 实践。尽管你会发现有很多不同的工具，但它们都有着相似的设计模型。而且可能最重要的一点是：通过带领你的公司进行这些实践，会让你在公司内部变得举足轻重，成为他人学习的榜样。

一些机构在自己的基础设施上已有多年的 CI/CD 实践经验，常用的工具包括 Ansible、Chef 或者 Puppet。另一些工具，比如 Test Kitchen，允许在最终要部署应用的基础设施上运行测试。事实上，如果使用更高级的配置方法，你甚至可以将应用部署到有真实负载的仿真“生产环境”上，来运行应用级别的测试。然而，单单是能够测试基础设施就是一项了不起的成就了。配置管理工具 Terraform 可以通过 Test Kitchen 来快速创建更短暂和冥等的的基础设施配置，这比它的前辈要强不少。再加上 Linux 容器和 Kubernetes，在数小时内，你就可以创建一套类似于生产环境的配置参数和系统资源，来测试整个基础设施和其上部署的应用，这在以前可能需要花费几个月的时间。而且，删除和再次创建整个测试环境也非常容易。

当然，作为初学者，你也可以把网络配置和 DDL（ 数据定义语言 data definition language ）文件加入版本控制，然后开始尝试一些简单的 CI/CD 流程。虽然只能帮你检查一下语义语法或某些最佳实践，但实际上大多数开发的管道都是这样起步的。只要你把脚手架搭起来，建造就容易得多了。而一旦起步，你就会发现各种管道的使用场景。

举个例子，我经常会在公司内部写新闻简报，我使用 MJML 制作邮件模板，然后把它加入版本控制。我一般会维护一个 web 版本，但是一些同事喜欢 PDF 版，于是我创建了一个管道。每当我写好一篇新闻稿，就在 Gitlab 上提交一个合并请求。这样做会自动创建一个 index.html 文件，生成这篇新闻稿的 HTML 和 PDF 版链接。HTML 和 PDF 文件也会在该管道里同时生成。除非有人来检查确认，这些文件不会被直接发布出去。使用 GitLab Pages 发布这个网站后，我就可以下载一份 HTML 版，用来发送新闻简报。未来，我会修改这个流程，当合并请求成功或者在某个审核步骤后，自动发出对应的新闻稿。这些处理逻辑并不复杂，但的确为我节省了不少时间。实际上这些工具最核心的用途就是替你节省时间。

关键是要在抽象层创建出工具，这样稍加修改就可以处理不同的问题。值得留意的是，我创建的这套流程几乎不需要任何代码，除了一些轻量级的 HTML 模板，一些把 HTML 文件转换成 PDF 的 nodejs 代码，还有一些生成索引页面的 nodejs 代码。

这其中一些东西可能看起来有点复杂，但其中大部分都源自我使用的不同工具的教学文档。而且很多开发人员也会乐意跟你合作，因为他们在完工时会发现这些东西也挺有用。上面我提供的那些代码链接是给 DevOps KC（LCTT 译注：一个地方性 DevOps 组织） 发送新闻简报用的，其中大部分用来创建网站的代码来自我在内部新闻简报项目上所作的工作。

下面列出的大多数工具都可以提供这种类型的交互，但是有些工具提供的模型略有不同。这一领域新兴的模型是用声明式的方法例如 YAML 来描述一个管道，其中的每个阶段都是短暂而幂等的。许多系统还会创建有向无环图（DAG），来确保管道上不同的阶段排序的正确性。

这些阶段一般运行在 Linux 容器里，和普通的容器并没有区别。有一些工具，比如 Spinnaker，只关注部署组件，而且提供一些其他工具没有的操作特性。Jenkins 则通常把管道配置存成 XML 格式，大部分交互都可以在图形界面里完成，但最新的方案是使用领域专用语言（DSL）（如 Groovy）。并且，Jenkins 的任务（job）通常运行在各个节点里，这些节点上会装一个专门的 Java 代理，还有一堆混杂的插件和预装组件。

Jenkins 在自己的工具里引入了管道的概念，但使用起来却并不轻松，甚至包含一些禁区。最近，Jenkins 的创始人决定带领社区向新的方向前进，希望能为这个项目注入新的活力，把 CI/CD 真正推广开（LCTT 译注：详见后面的 Jenkins 章节)。我认为其中最有意思的想法是构建一个云原生 Jenkins，能把 Kubernetes 集群转变成 Jenkins CI/CD 平台。

当你更多地了解这些工具并把实践带入你的公司和运维部门，你很快就会有追随者，因为你有办法提升自己和别人的工作效率。我们都有多年积累下来的技术债要解决，如果你能给同事们提供足够的时间来处理这些积压的工作，他们该会有多感激呢？不止如此，你的客户也会开始看到应用变得越来越稳定，管理层会把你看作得力干将，你也会在下次谈薪资待遇或参加面试时更有底气。

让我们开始深入了解这些工具吧，我们将对每个工具做简短的介绍，并分享一些有用的链接。

GitLab CI

GitLab 可以说是 CI/CD 领域里新登场的玩家，但它却在权威调研机构 Forrester 的 CI 集成工具的调查报告中位列第一。在一个高水平、竞争充分的领域里，这是个了不起的成就。是什么让 GitLab CI 这么成功呢？它使用 YAML 文件来描述整个管道。另有一个功能叫做 Auto DevOps，可以为较简单的项目用多种内置的测试单元自动生成管道。这套系统使用 Herokuish buildpacks 来判断语言的种类以及如何构建应用。有些语言也可以管理数据库，它真正改变了构建新应用程序和从开发的开始将它们部署到生产环境的过程。它原生集成于 Kubernetes，可以根据不同的方案将你的应用自动部署到 Kubernetes 集群，比如灰度发布、蓝绿部署等。

除了它的持续集成功能，GitLab 还提供了许多补充特性，比如：将 Prometheus 和你的应用一同部署，以提供操作监控功能；通过 GitLab 提供的 Issues、Epics 和 Milestones 功能来实现项目评估和管理；管道中集成了安全检测功能，多个项目的检测结果会聚合显示；你可以通过 GitLab 提供的网页版 IDE 在线编辑代码，还可以快速查看管道的预览或执行状态。

GoCD

GoCD 是由老牌软件公司 Thoughtworks 出品，这已经足够证明它的能力和效率。对我而言，GoCD 最具亮点的特性是它的价值流视图（VSM）。实际上，一个管道的输出可以变成下一个管道的输入，从而把管道串联起来。这样做有助于提高不同开发团队在整个开发流程中的独立性。比如在引入 CI/CD 系统时，有些成立较久的机构希望保持他们各个团队相互隔离，这时候 VSM 就很有用了：让每个人都使用相同的工具就很容易在 VSM 中发现工作流程上的瓶颈，然后可以按图索骥调整团队或者想办法提高工作效率。

为公司的每个产品配置 VSM 是非常有价值的；GoCD 可以使用 JSON 或 YAML 格式存储配置，还能以可视化的方式展示数据等待时间，这让一个机构能有效减少学习它的成本。刚开始使用 GoCD 创建你自己的流程时，建议使用人工审核的方式。让每个团队也采用人工审核，这样你就可以开始收集数据并且找到可能的瓶颈点。

Travis CI

我使用的第一个软件既服务（SaaS）类型的 CI 系统就是 Travis CI，体验很不错。管道配置以源码形式用 YAML 保存，它与 GitHub 等工具无缝整合。我印象中管道从来没有失效过，因为 Travis CI 的在线率很高。除了 SaaS 版之外，你也可以使用自行部署的版本。我还没有自行部署过，它的组件非常多，要全部安装的话，工作量就有点吓人了。我猜更简单的办法是把它部署到 Kubernetes 上，Travis CI 提供了 Helm charts，这些 charts 目前不包含所有要部署的组件，但我相信以后会越来越丰富的。如果你不想处理这些细枝末节的问题，还有一个企业版可以试试。

假如你在开发一个开源项目，你就能免费使用 SaaS 版的 Travis CI，享受顶尖团队提供的优质服务！这样能省去很多麻烦，你可以在一个相对通用的平台上（如 GitHub）研发开源项目，而不用找服务器来运行任何东西。

Jenkins

Jenkins 在 CI/CD 界绝对是元老级的存在，也是事实上的标准。我强烈建议你读一读这篇文章：“Jenkins: Shifting Gears”，作者 Kohsuke 是 Jenkins 的创始人兼 CloudBees 公司 CTO。这篇文章契合了我在过去十年里对 Jenkins 及其社区的感受。他在文中阐述了一些这几年呼声很高的需求，我很乐意看到 CloudBees 引领这场变革。长期以来，Jenkins 对于非开发人员来说有点难以接受，并且一直是其管理员的重担。还好，这些问题正是他们想要着手解决的。

Jenkins 配置既代码（JCasC）应该可以帮助管理员解决困扰了他们多年的配置复杂性问题。与其他 CI/CD 系统类似，只需要修改一个简单的 YAML 文件就可以完成 Jenkins 主节点的配置工作。Jenkins Evergreen 的出现让配置工作变得更加轻松，它提供了很多预设的使用场景，你只管套用就可以了。这些发行版会比官方的标准版本 Jenkins 更容易维护和升级。

Jenkins 2 引入了两种原生的管道功能，我在 LISA（LCTT 译注：一个系统架构和运维大会） 2017 年的研讨会上已经讨论过了。这两种功能都没有 YAML 简便，但在处理复杂任务时它们很好用。

Jenkins X 是 Jenkins 的一个全新变种，用来实现云端原生 Jenkins（至少在用户看来是这样）。它会使用 JCasC 及 Evergreen，并且和 Kubernetes 整合的更加紧密。对于 Jenkins 来说这是个令人激动的时刻，我很乐意看到它在这一领域的创新，并且继续发挥领袖作用。

Concourse CI

我第一次知道 Concourse 是通过 Pivotal Labs 的伙计们介绍的，当时它处于早期 beta 版本，而且那时候也很少有类似的工具。这套系统是基于微服务构建的，每个任务运行在一个容器里。它独有的一个优良特性是能够在你本地系统上运行任务，体现你本地的改动。这意味着你完全可以在本地开发（假设你已经连接到了 Concourse 的服务器），像在真实的管道构建流程一样从你本地构建项目。而且，你可以在修改过代码后从本地直接重新运行构建，来检验你的改动结果。

Concourse 还有一个简单的扩展系统，它依赖于“资源”这一基础概念。基本上，你想给管道添加的每个新功能都可以用一个 Docker 镜像实现，并作为一个新的资源类型包含在你的配置中。这样可以保证每个功能都被封装在一个不可变的独立工件中，方便对其单独修改和升级，改变其中一个时不会影响其他构建。

Spinnaker

Spinnaker 出自 Netflix，它更关注持续部署而非持续集成。它可以与其他工具整合，比如 Travis 和 Jenkins，来启动测试和部署流程。它也能与 Prometheus、Datadog 这样的监控工具集成，参考它们提供的指标来决定如何部署。例如，在 金丝雀发布 canary deployment 里，我们可以根据收集到的相关监控指标来做出判断：最近的这次发布是否导致了服务降级，应该立刻回滚；还是说看起来一切 OK，应该继续执行部署。

谈到持续部署，一些另类但却至关重要的问题往往被忽略掉了，说出来可能有点让人困惑：Spinnaker 可以帮助持续部署不那么“持续”。在整个应用部署流程期间，如果发生了重大问题，它可以让流程停止执行，以阻止可能发生的部署错误。但它也可以在最关键的时刻让人工审核强制通过，发布新版本上线，使整体收益最大化。实际上，CI/CD 的主要目的就是在商业模式需要调整时，能够让待更新的代码立即得到部署。

Screwdriver

Screwdriver 是个简单而又强大的软件。它采用微服务架构，依赖像 Nomad、Kubernetes 和 Docker 这样的工具作为执行引擎。官方有一篇很不错的部署教学文档，介绍了如何将它部署到 AWS 和 Kubernetes 上，但如果正在开发中的 Helm chart 也完成的话，就更完美了。

Screwdriver 也使用 YAML 来描述它的管道，并且有很多合理的默认值，这样可以有效减少各个管道重复的配置项。用配置文件可以组织起高级的工作流，来描述各个任务间复杂的依赖关系。例如，一项任务可以在另一个任务开始前或结束后运行；各个任务可以并行也可以串行执行；更赞的是你可以预先定义一项任务，只在特定的拉取请求时被触发，而且与之有依赖关系的任务并不会被执行，这能让你的管道具有一定的隔离性：什么时候被构造的工件应该被部署到生产环境，什么时候应该被审核。

以上只是我对这些 CI/CD 工具的简单介绍，它们还有许多很酷的特性等待你深入探索。而且它们都是开源软件，可以自由使用，去部署一下看看吧，究竟哪个才是最适合你的那个。

via: https://opensource.com/article/18/12/cicd-tools-sysadmins

作者：Dan Barker 选题：lujun9972 译者：jdh8383 校对：wxy

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

这些开源的工具能够通过输出帮助用户了解系统的运行状况，并对可能发生的潜在问题作出告警。

你大概已经知道（或猜到） 告警可视化 alerting and visualization 工具是用来做什么的了。下面我们就要来说一下，为什么要讨论这样的工具，甚至某些系统专门将可视化作为特有的功能。

可观察性 Observability 的概念来自 控制理论 control theory ，这个概念描述了我们通过对系统的输入和输出来了解其的能力。本文将重点介绍具有可观察性的输出组件。

告警可视化工具可以对其它系统的输出进行分析，进而对输出的信息进行结构化表示。告警实际上是对系统异常状态的描述，而可视化则是让用户能够直观理解的结构化表示。

常见的可视化告警

告警

首先要明确一下 告警 alert 的含义。在人员无法响应告警内容情况下，不应该发送告警 —— 包括那些发给多个人但只有其中少数人可以响应的告警，以及系统中的每个异常都触发的告警。因为这样会产生告警疲劳，告警接收者也往往会对这些过多的告警采取忽视的态度 —— 直到系统恶化到以少见的方式告警。

例如，如果管理员每天都会收到告警系统发来的数百封告警邮件，他就很容易会忽略告警系统的所有邮件。除非他真的看到问题发生，或者受到了客户或上级的询问时，管理员才会重新重视告警信息。在这种情况下，告警已经失去了原有的意义和用途。

告警不是一个持续的信息流或者状态更新。告警的目的在于暴露系统无法自动恢复的问题，而且告警应该只发送给最有可能解决问题的人员。超出这个定义的内容都不应该作为告警，否则将会对实际工作造成不良的影响。

不同的告警体系都会有各自的告警类型，因此不能用优先级（P1-P5）或者诸如“信息”、“警告”、“严重”之类的字眼来一概而论，下面我会介绍一些新兴的复杂系统的事件响应中出现的通用分类方式。

刚才我提到了一个“信息”这个告警类型，但实际上告警不应该是一个信息，尽管有些人可能会不这样认为。但我觉得如果一个告警没有发送给任何一个人，它就不应该是警报，而只是一些在许多系统中被视为警报的数据点，代表了一些应该知晓但不需要响应的事件。它更应该作为告警可视化工具的一部分，而不是会导致触发告警的事件。《实用监控》是这个领域的必读书籍，其作者 Mike Julian 在书中就介绍了他自己关于告警的看法。

而非信息警报则代表告警需要被响应以及需要相关的操作。我将这些告警大致分为内部故障和外部故障两种类型，而对于大多数公司来说，通常会有两个以上的级别来确定响应告警的优先级。系统性能下降就是一种故障，因为其对用户的影响通常都是未知的。

内部故障比外部故障的优先级低，但也需要快速响应。内部故障通常包括公司员工使用的内部系统或仅对公司员工可见的应用故障。

外部故障则包括任何马上会产生业务影响的系统故障，但不包括影响系统更新的故障。外部故障一般包括客户所面临的应用故障、数据库故障和导致系统可用性或一致性失效的网络故障，这些都会影响用户的正常使用。对于不直接影响用户的依赖组件故障也属于外部故障，随着应用程序的不断运行，一旦依赖组件发生故障，系统的性能也会受到波及。这种情况对于使用某些外部服务或数据源的系统来说很常见，尽管这些外部服务或数据源对于可能不涉及到系统的主要功能，但是当系统在处理相关依赖组件的错误时可能会出现较明显的延迟。

可视化

可视化的种类有很多，我就不一一赘述了。这是一个有趣的研究领域，在我这些年的数据分析经历当中，学习和应用可视化方面的知识可以说是相当有挑战性。我们需要将复杂的系统输出通过直观的方式来向他人展示，才能有效地把信息传播出去。Google Charts 和 Tableau 都提供了很多可视化方面的工具。下面将会介绍一些最常见的可视化创新解决方案。

折线图

折线图可能是最常见的可视化方式了，它可以让用户很直观地按照时间维度了解系统的情况。系统中每个单一或聚合的指标都会以一条折线在图表中体现。但当同一个图表中同时存在多条折线时，就可能会对阅读有所影响（如下图所示），所以大多数情况下都可以选择仅查看其中的少数几条折线，而不是让所有折线同时显示。如果某个指标的数值产生了大于正常范围的波动，就会很容易发现。例如下图中异常的紫线、黄线、浅蓝线。

折线图的另一个用法是可以将多条折线堆叠起来以显示它们之间的关系。例如对于通过折线图反映服务器的请求数量，可以单独看到每台服务器上的请求，也可以聚合在一起看。这就可以在同一个图表中灵活查看整个系统以及每个实例的情况了。

热力图

另一种常见的可视化方式是热力图。热力图与条形图比较类似，还可以在条形图的基础上显示某部分在整体中占比的变化情况。例如在查看网络请求延时的时候，就可以使用热力图快速查看到所有网络请求的总体趋势和分布情况，另外，它可以使用不同颜色来表示不同部分的数值。

在以下这个热力图中，通过竖直方向上每个时间段的色块数量分布，可以清楚地看到大部分数据集中在整个范围的中心位置。我们还可以发现，大多数时间段的色块分布都是比较宽松的，而 14:00 到 15:00 这一段则分布得很密集，这样的分布有可能意味着一种不健康的状态。

仪表图

还有一种常见的可视化方式是仪表图，用户可以通过仪表图快速了解单个指标。仪表一般用于单个指标的显示，例如车速表代表汽车的行驶速度、油量表代表油箱中的汽油量等等。大多数的仪表图都有一个共通点，就是会划分出所示指标的对应状态。如下图所示，绿色表示正常的状态，橙色表示不良的状态，而红色则表示极差的状态。下图中间一行模拟了真实仪表的显示情况。

上面图表中，除了常规仪表样式的显示方式之外，还有较为直接的数据显示方式，配合相同的配色方案，一眼就可以看出各个指标所处的状态，这一点与和仪表的特点类似。所以，最下面一行可能是仪表图的最佳显示方式，用户不需要仔细阅读，就可以大致了解各个指标的不同状态。这种类型的可视化是我最常用的类型，在数秒钟之间，我就可以全面地总览系统各方面地运行情况。

火焰图

由 Netflix 的 Brendan Gregg 在 2011 年开始使用的火焰图是一种较为少见地可视化方式。它不像仪表图那样可以从图表中快速得到关键信息，通常只会在需要解决某个应用的问题的时候才会用到这种图表。火焰图主要用于 CPU、内存和相关帧方面的表示，X 轴按字母顺序将帧一一列出，而 Y 轴则表示堆栈的深度。图中每个矩形都是一个标明了调用的函数的堆栈帧。矩形越宽，就表示它在堆栈中出现越频繁。在分析系统性能问题的时候，火焰图能够起到很大的作用，大家不妨尝试一下。

工具的选择

在告警工具方面，有几个商用的工具相当不错。但由于这是一篇介绍开源技术的文章，我只会介绍那些已经被广泛使用的免费工具。希望你也能够为这些工具贡献你自己的代码，让它们更加完善。

告警工具

Bosun

如果你的电脑出现问题，得多亏 Stack Exchange 你才能在网上查到解决办法。Stack Exchange 以众包问答的模式运营着很多不同类型的网站。其中就有广受开发者欢迎的 Stack Overflow，以及运维方面有名的 Super User。除此以外，从育儿经验到科幻小说、从哲学讨论到单车论坛，Stack Exchange 都有涉猎。

Stack Exchange 开源了它的告警管理系统 Bosun，同时也发布了 Prometheus 及其 AlertManager 系统。这两个系统有共通点。Bosun 和 Prometheus 一样使用 Golang 开发，但 Bosun 比 Prometheus 更为强大，因为它可以使用 指标聚合 metrics aggregation 以外的方式与系统交互。Bosun 还可以从日志和事件收集系统中提取数据，并且支持 Graphite、InfluxDB、OpenTSDB 和 Elasticsearch。

Bosun 的架构包括一个单一的服务器的二进制文件，一个诸如 OpenTSDB 的后端、Redis 以及 scollector 代理。 scollector 代理会自动检测主机上正在运行的服务，并反馈这些进程和其它的系统资源的情况。这些数据将发送到后端。随后 Bosun 的二进制服务文件会向后端发起查询，确定是否需要触发告警。也可以通过 Grafana 这些工具通过一个通用接口查询 Bosun 的底层后端。而 Redis 则用于存储 Bosun 的状态信息和元数据。

Bosun 有一个非常巧妙的功能，就是可以根据历史数据来测试告警。这是我几年前在使用 Prometheus 的时候就非常需要的功能，当时我有一个异常的数据需要产生告警，但没有一个可以用于测试的简便方法。为了确保告警能够正常触发，我不得不造出对应的数据来进行测试。而 Bosun 让这个步骤的耗时大大缩短。

Bosun 更是涵盖了所有常用过的功能，包括简单的图形化表示和告警的创建。它还带有强大的用于编写告警规则的表达式语言。但 Bosun 默认只带有电子邮件通知配置和 HTTP 通知配置，因此如果需要连接到 Slack 或其它工具，就需要对配置作出更大程度的定制化（其文档中有）。类似于 Prometheus，Bosun 还可以使用模板通知，你可以使用 HTML 和 CSS 来创建你所需要的电子邮件通知。

Cabot

Cabot 由 Arachnys 公司开发。你或许对 Arachnys 公司并不了解，但它很有影响力：Arachnys 公司构建了一个基于云的先进解决方案，用于防范金融犯罪。在之前的公司时，我也曾经参与过类似“了解你的客户（KYC）”的工作。大多数公司都认为与恐怖组织产生联系会造成相当不好的影响，因为恐怖组织可能会利用自己的系统来筹集资金。而这些解决方案将有助于防范欺诈类犯罪，尽管这类犯罪情节相对较轻，但仍然也会对机构产生风险。

Arachnys 公司为什么要开发 Cabot 呢？其实只是因为 Arachnys 的开发人员对 Nagios 不太熟悉。Cabot 的出现对很多人来说都是一个好消息，它基于 Django 和 Bootstrap 开发，因此如果想对这个项目做出自己的贡献，门槛并不高。（另外值得一提的是，Cabot 这个名字来源于开发者的狗。）

与 Bosun 类似，Cabot 也不对数据进行收集，而是使用监控对象的 API 提供的数据。因此，Cabot 告警的模式是拉取而不是推送。它通过访问每个监控对象的 API，根据特定的指标检索所需的数据，然后将告警数据使用 Redis 缓存，进而持久化存储到 Postgres 数据库。

Cabot 的一个较为少见的特点是，它原生支持 Graphite，同时也支持 Jenkins。Jenkins 在这里被视为一个集中式的定时任务，它会以对待故障的方式去对待构建失败的状况。构建失败当然没有系统故障那么紧急，但一旦出现构建失败，还是需要团队采取措施去处理，毕竟并不是每个人在收到构建失败的电子邮件时都会亲自去检查 Jenkins。

Cabot 另一个有趣的功能是它可以接入 Google 日历安排值班人员，这个称为 Rota 的功能用处很大，希望其它告警系统也能加入类似的功能。Cabot 目前仅支持安排主备联系人，但还有继续改进的空间。它自己的文档也提到，如果需要全面的功能，更应该考虑付费的解决方案。

StatsAgg

Pearson 作为一家开发了 StatsAgg 告警平台的出版公司，这是极为罕见的，当然也很值得敬佩。除此以外，Pearson 还运营着另外几个网站以及和 O'Reilly Media 合资的企业。但我仍然会将它视为出版教学书籍的公司。

StatsAgg 除了是一个告警平台，还是一个指标聚合平台，甚至也有点类似其它系统的代理。StatsAgg 支持通过 Graphite、StatsD、InfluxDB 和 OpenTSDB 输入数据，也支持将其转发到各种平台。但随着中心服务的负载不断增加，风险也不断增大。尽管如此，如果 StatsAgg 的基础架构足够强壮，即使后端存储平台出现故障，也不会对它产生告警的过程造成影响。

StatsAgg 是用 Java 开发的，为了尽可能降低复杂性，它仅包括主服务和一个 UI。StatsAgg 支持基于正则表达式匹配来发送告警，而且它更注重于服务方面的告警，而不是服务器基础告警。我认为它填补了开源监控工具方面的空白，而这正式它自己的目标。

可视化工具

Grafana

Grafana 的知名度很高，它也被广泛采用。每当我需要用到数据面板的时候，我总是会想到它，因为它比我使用过的任何一款类似的产品都要好。Grafana 由 Torkel Ödegaard 开发的，像 Cabot 一样，也是在圣诞节期间开发的，并在 2014 年 1 月发布。在短短几年之间，它已经有了长足的发展。Grafana 基于 Kibana 开发，Torkel 开启了新的分支并将其命名为 Grafana。

Grafana 着重体现了实用性以及数据呈现的美观性。它天生就可以从 Graphite、Elasticsearch、OpenTSDB、Prometheus 和 InfluxDB 收集数据。此外有一个 Grafana 商用版插件可以从更多数据源获取数据，但是其他数据源插件也并非没有开源版本，Grafana 的插件生态系统已经提供了各种数据源。

Grafana 能做什么呢？Grafana 提供了一个中心化的了解系统的方式。它通过 web 来展示数据，任何人都有机会访问到相关信息，当然也可以使用身份验证来对访问进行限制。Grafana 使用各种可视化方式来提供对系统一目了然的了解。Grafana 还支持不同类型的可视化方式，包括集成告警可视化的功能。

现在你可以更直观地设置告警了。通过 Grafana，可以查看图表，还可以查看由于系统性能下降而触发告警的位置，单击要触发报警的位置，并告诉 Grafana 将告警发送何处。这是一个对告警平台非常强大的补充。告警平台不一定会因此而被取代，但告警系统一定会由此得到更多启发和发展。

Grafana 还引入了很多团队协作的功能。不同用户之间能够共享数据面板，你不再需要为 Kubernetes 集群创建独立的数据面板，因为由 Kubernetes 开发者和 Grafana 开发者共同维护的一些数据面板已经可用了。

团队协作过程中一个重要的功能是注释。注释功能允许用户将上下文添加到图表当中，其他用户就可以通过上下文更直观地理解图表。当团队成员在处理某个事件，并且需要沟通和理解时，这个功能就十分重要了。将所有相关信息都放在需要的位置，可以让整个团队中快速达成共识。在团队需要调查故障原因和定位事件责任时，这个功能就可以发挥作用了。

Vizceral

Vizceral 由 Netflix 开发，用于在故障发生时更有效地了解流量的情况。Grafana 是一种通用性更强的工具，而 Vizceral 则专用于某些领域。 尽管 Netflix 表示已经不再在内部使用 Vizceral，也不再主动对其展开维护，但 Vizceral 仍然会定期更新。我在这里介绍这个工具，主要是为了介绍它的的可视化机制，以及如何利用它来协助解决问题。你可以在样例环境中用它来更好地掌握这一类系统的特性。

via: https://opensource.com/article/18/10/alerting-and-visualization-tools-sysadmins

作者：Dan Barker 选题：lujun9972 译者：HankChow 校对：wxy

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

这几个工具对复杂软件系统中的实时事件做了可视化，能帮助你快速发现性能问题。

分布式追踪系统能够从头到尾地追踪跨越了多个应用、服务、数据库以及像代理这样的中间件的分布式软件的请求。它能帮助你更深入地理解系统中到底发生了什么。追踪系统以图形化的方式，展示出每个已知步骤以及某个请求在每个步骤上的耗时。

用户可以通过这些展示来判断系统的哪个环节有延迟或阻塞，当请求失败时，运维和开发人员可以看到准确的问题源头，而不需要去测试整个系统，比如用二叉查找树的方法去定位问题。在开发迭代的过程中，追踪系统还能够展示出可能引起性能变化的环节。通过异常行为的警告自动地感知到性能的退化，总是比客户告诉你要好。

这种追踪是怎么工作的呢？给每个请求分配一个特殊 ID，这个 ID 通常会插入到请求头部中。它唯一标识了对应的事务。一般把事务叫做 踪迹 trace ，“踪迹”是整个事务的抽象概念。每一个“踪迹”由 单元 span 组成，“单元”代表着一次请求中真正执行的操作，比如一次服务调用，一次数据库请求等。每一个“单元”也有自己唯一的 ID。“单元”之下也可以创建子“单元”，子“单元”可以有多个父“单元”。

当一次事务（或者说踪迹）运行过之后，就可以在追踪系统的表示层上搜索了。有几个工具可以用作表示层，我们下文会讨论，不过，我们先看下面的图，它是我在 Istio walkthrough 视频教程中提到的 Jaeger 界面，展示了单个踪迹中的多个单元。很明显，这个图能让你一目了然地对事务有更深的了解。

这个演示使用了 Istio 内置的 OpenTracing 实现，所以我甚至不需要修改自己的应用代码就可以获得追踪数据。我也用到了 Jaeger，它是兼容 OpenTracing 的。

那么 OpenTracing 到底是什么呢？我们来看看。

OpenTracing API

OpenTracing 是源自 Zipkin 的规范，以提供跨平台兼容性。它提供了对厂商中立的 API，用来向应用程序添加追踪功能并将追踪数据发送到分布式的追踪系统。按照 OpenTracing 规范编写的库，可以被任何兼容 OpenTracing 的系统使用。采用这个开放标准的开源工具有 Zipkin、Jaeger 和 Appdash 等。甚至像 Datadog 和 Instana 这种付费工具也在采用。因为现在 OpenTracing 已经无处不在，这样的趋势有望继续发展下去。

OpenCensus

OpenTracing 已经说过了，可 OpenCensus 又是什么呢？它在搜索结果中老是出现。它是一个和 OpenTracing 完全不同或者互补的竞争标准吗？

这个问题的答案取决于你的提问对象。我先尽我所能地解释一下它们的不同（按照我的理解）：OpenCensus 更加全面或者说它包罗万象。OpenTracing 专注于建立开放的 API 和规范，而不是为每一种开发语言和追踪系统都提供开放的实现。OpenCensus 不仅提供规范，还提供开发语言的实现，和连接协议，而且它不仅只做追踪，还引入了额外的度量指标，这些一般不在分布式追踪系统的职责范围。

使用 OpenCensus，我们能够在运行着应用程序的主机上查看追踪数据，但它也有个可插拔的导出器系统，用于导出数据到中心聚合器。目前 OpenCensus 团队提供的导出器包括 Zipkin、Prometheus、Jaeger、Stackdriver、Datadog 和 SignalFx，不过任何人都可以创建一个导出器。

依我看这两者有很多重叠的部分，没有哪个一定比另外一个好，但是重要的是，要知道它们做什么事情和不做什么事情。OpenTracing 主要是一个规范，具体的实现和独断的设计由其他人来做。OpenCensus 更加独断地为本地组件提供了全面的解决方案，但是仍然需要其他系统做远程的聚合。

可选工具

Zipkin

Zipkin 是最早出现的这类工具之一。 谷歌在 2010 年发表了介绍其内部追踪系统 Dapper 的论文，Twitter 以此为基础开发了 Zipkin。Zipkin 的开发语言 Java，用 Cassandra 或 ElasticSearch 作为可扩展的存储后端，这些选择能满足大部分公司的需求。Zipkin 支持的最低 Java 版本是 Java 6，它也使用了 Thrift 的二进制通信协议，Thrift 在 Twitter 的系统中很流行，现在作为 Apache 项目在托管。

这个系统包括上报器（客户端）、数据收集器、查询服务和一个 web 界面。Zipkin 只传输一个带事务上下文的踪迹 ID 来告知接收者追踪的进行，所以说在生产环境中是安全的。每一个客户端收集到的数据，会异步地传输到数据收集器。收集器把这些单元的数据存到数据库，web 界面负责用可消费的格式展示这些数据给用户。客户端传输数据到收集器有三种方式：HTTP、Kafka 和 Scribe。

Zipkin 社区 还提供了 Brave，一个跟 Zipkin 兼容的 Java 客户端的实现。由于 Brave 没有任何依赖，所以它不会拖累你的项目，也不会使用跟你们公司标准不兼容的库来搞乱你的项目。除 Brave 之外，还有很多其他的 Zipkin 客户端实现，因为 Zipkin 和 OpenTracing 标准是兼容的，所以这些实现也能用到其他的分布式追踪系统中。流行的 Spring 框架中一个叫 Spring Cloud Sleuth 的分布式追踪组件，它和 Zipkin 是兼容的。

Jaeger

Jaeger 来自 Uber，是一个比较新的项目，CNCF（云原生计算基金会）已经把 Jaeger 托管为孵化项目。Jaeger 使用 Golang 开发，因此你不用担心在服务器上安装依赖的问题，也不用担心开发语言的解释器或虚拟机的开销。和 Zipkin 类似，Jaeger 也支持用 Cassandra 和 ElasticSearch 做可扩展的存储后端。Jaeger 也完全兼容 OpenTracing 标准。

Jaeger 的架构跟 Zipkin 很像，有客户端（上报器）、数据收集器、查询服务和一个 web 界面，不过它还有一个在各个服务器上运行着的代理，负责在服务器本地做数据聚合。代理通过一个 UDP 连接接收数据，然后分批处理，发送到数据收集器。收集器接收到的数据是 Thrift 协议的格式，它把数据存到 Cassandra 或者 ElasticSearch 中。查询服务能直接访问数据库，并给 web 界面提供所需的信息。

默认情况下，Jaeger 客户端不会采集所有的追踪数据，只抽样了 0.1% 的（ 1000 个采 1 个）追踪数据。对大多数系统来说，保留所有的追踪数据并传输的话就太多了。不过，通过配置代理可以调整这个值，客户端会从代理获取自己的配置。这个抽样并不是完全随机的，并且正在变得越来越好。Jaeger 使用概率抽样，试图对是否应该对新踪迹进行抽样进行有根据的猜测。 自适应采样已经在路线图当中，它将通过添加额外的、能够帮助做决策的上下文来改进采样算法。

Appdash

Appdash 也是一个用 Golang 写的分布式追踪系统，和 Jaeger 一样。Appdash 是 Sourcegraph 公司基于谷歌的 Dapper 和 Twitter 的 Zipkin 开发的。同样的，它也支持 Opentracing 标准，不过这是后来添加的功能，依赖了一个与默认组件不同的组件，因此增加了风险和复杂度。

从高层次来看，Appdash 的架构主要有三个部分：客户端、本地收集器和远程收集器。因为没有很多文档，所以这个架构描述是基于对系统的测试以及查看源码。写代码时需要把 Appdash 的客户端添加进来。Appdash 提供了 Python、Golang 和 Ruby 的实现，不过 OpenTracing 库可以与 Appdash 的 OpenTracing 实现一起使用。 客户端收集单元数据，并将它们发送到本地收集器。然后，本地收集器将数据发送到中心的 Appdash 服务器，这个服务器上运行着自己的本地收集器，它的本地收集器是其他所有节点的远程收集器。

via: https://opensource.com/article/18/9/distributed-tracing-tools

作者：Dan Barker 选题：lujun9972 译者：belitex 校对：wxy

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

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

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

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

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

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

日志记录的一些规则：

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

云的成本

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

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

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

工具选择

ELK

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

几年前，引入了 Beats 。Beats 是数据采集器。它们简化了将数据运送到 Logstash 的过程。用户不需要了解每种日志的正确语法，而是可以安装一个 Beats 来正确导出 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 的工具。这是一个更便宜的选择，但是需要一些管理操作，并有一些功能限制。

ELK 套件的母公司 Elastic 提供 一款更强大的产品，它使用 开源核心 open core 模式，为分析工具和报告提供了额外的选项。它也可以在谷歌云平台或 AWS 上托管。由于这种工具和托管平台的组合提供了比大多数 SaaS 选项更加便宜，这也许是最好的选择，并且很有用。该系统可以有效地取代或提供 安全信息和事件管理（SIEM）系统的功能。

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

Graylog

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

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

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

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

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

如果你需要的话，Graylog 公司会提供对开源版本的收费支持。它还为其企业版提供了一个开源核心模式，提供存档、审计日志记录和其他支持。其它提供支持或托管服务的不太多，如果你不需要 Graylog 公司的，你可以托管。

Fluentd

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

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

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

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

作者：Dan Barker 选题：lujun9972 译者：heguangzhi 校对：wxy

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