mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
d0fce06ef2
@ -0,0 +1,149 @@
|
||||
分布式跟踪系统的四大功能模块如何协同工作
|
||||
======
|
||||
|
||||
> 了解分布式跟踪中的主要体系结构决策，以及各部分如何组合在一起。
|
||||
|
||||
|
||||
|
||||
早在十年前，认真研究过分布式跟踪基本上只有学者和一小部分大型互联网公司中的人。对于任何采用微服务的组织来说，它如今成为一种筹码。其理由是确立的：微服务通常会发生让人意想不到的错误，而分布式跟踪则是描述和诊断那些错误的最好方法。
|
||||
|
||||
也就是说，一旦你准备将分布式跟踪集成到你自己的应用程序中，你将很快意识到对于不同的人来说“<ruby>分布式跟踪<rt>Distributed Tracing</rt></ruby>”一词意味着不同的事物。此外，跟踪生态系统里挤满了具有相似内容的重叠项目。本文介绍了分布式跟踪系统中四个（可能）独立的功能模块，并描述了它们间将如何协同工作。
|
||||
|
||||
### 分布式跟踪：一种思维模型
|
||||
|
||||
大多数用于跟踪的思维模型来源于 [Google 的 Dapper 论文][1]。[OpenTracing][2] 使用相似的术语，因此，我们从该项目借用了以下术语：
|
||||
|
||||
![Tracing][3]
|
||||
|
||||
* <ruby>跟踪<rt>Trace</rt></ruby>：事物在分布式系统运行的过程描述。
|
||||
* <ruby>跨度<rt>Span</rt></ruby>：一种命名的定时操作，表示工作流的一部分。跨度可接受键值对标签以及附加到特定跨度实例的细粒度的、带有时间戳的结构化日志。
|
||||
* <ruby>跨度上下文<rt>Span context</rt></ruby>：携带分布式事务的跟踪信息，包括当它通过网络或消息总线将服务传递给服务时。跨度上下文包含跟踪标识符、跨度标识符以及跟踪系统所需传播到下游服务的任何其他数据。
|
||||
|
||||
如果你想要深入研究这种思维模式的细节，请仔细参照 [OpenTracing 技术规范][1]。
|
||||
|
||||
### 四大功能模块
|
||||
|
||||
从应用层分布式跟踪系统的观点来看，现代软件系统架构如下图所示：
|
||||
|
||||
![Tracing][5]
|
||||
|
||||
现代软件系统的组件可分为三类：
|
||||
|
||||
* **应用程序和业务逻辑**：你的代码。
|
||||
* **广泛共享库**：他人的代码
|
||||
* **广泛共享服务**：他人的基础架构
|
||||
|
||||
这三类组件有着不同的需求，驱动着监控应用程序的分布式跟踪系统的设计。最终的设计得到了四个重要的部分：
|
||||
|
||||
* <ruby>跟踪检测 API<rt>A tracing instrumentation API</rt></ruby>：修饰应用程序代码
|
||||
* <ruby>线路协议<rt>Wire protocol</rt></ruby>：在 RPC 请求中与应用程序数据一同发送的规定
|
||||
* <ruby>数据协议<rt>Data protocol</rt></ruby>：将异步信息（带外）发送到你的分析系统的规定
|
||||
* <ruby>分析系统<rt>Analysis system</rt></ruby>：用于处理跟踪数据的数据库和交互式用户界面
|
||||
|
||||
为了更深入的解释这个概念，我们将深入研究驱动该设计的细节。如果你只需要我的一些建议，请跳转至下方的四大解决方案。
|
||||
|
||||
### 需求，细节和解释
|
||||
|
||||
应用程序代码、共享库以及共享式服务在操作上有显著的差别，这种差别严重影响了对其进行检测的请求操作。
|
||||
|
||||
#### 检测应用程序代码和业务逻辑
|
||||
|
||||
在任何特定的微服务中，由微服务开发者编写的大部分代码是应用程序或者商业逻辑。这部分代码规定了特定区域的操作。通常，它包含任何特殊、独一无二的逻辑判断，这些逻辑判断首先证明了创建新型微服务的合理性。基本上按照定义，**该代码通常不会在多个服务中共享或者以其他方式出现。**
|
||||
|
||||
也即是说你仍需了解它，这也意味着需要以某种方式对它进行检测。一些监控和跟踪分析系统使用<ruby>黑盒代理<rt>black-box agents</rt></ruby>自动检测代码，另一些系统更想使用显式的白盒检测工具。对于后者，抽象跟踪 API 提供了许多对于微服务的应用程序代码来说更为实用的优势：
|
||||
|
||||
* 抽象 API 允许你在不重新编写检测代码的条件下换新的监视工具。你可能想要变更云服务提供商、供应商和监测技术，而一大堆不可移植的检测代码将会为该过程增加有意义的开销和麻烦。
|
||||
* 事实证明，除了生产监控之外，该工具还有其他有趣的用途。现有的项目使用相同的跟踪工具来驱动测试工具、分布式调试器、“混沌工程”故障注入器和其他元应用程序。
|
||||
* 但更重要的是，若将应用程序组件提取到共享库中要怎么办呢？由上述内容可得到结论：
|
||||
|
||||
#### 检测共享库
|
||||
|
||||
在大多数应用程序中出现的实用程序代码（处理网络请求、数据库调用、磁盘写操作、线程、并发管理等）通常情况下是通用的，而非特别应用于某个特定应用程序。这些代码会被打包成库和框架，而后就可以被装载到许多的微服务上并且被部署到多种不同的环境中。
|
||||
|
||||
其真正的不同是：对于共享代码，其他人则成为了使用者。大多数用户有不同的依赖关系和操作风格。如果尝试去使用该共享代码，你将会注意到几个常见的问题：
|
||||
|
||||
* 你需要一个 API 来编写检测。然而，你的库并不知道你正在使用哪个分析系统。会有多种选择，并且运行在相同应用下的所有库无法做出不兼容的选择。
|
||||
* 由于这些包封装了所有网络处理代码，因此从请求报头注入和提取跨度上下文的任务往往指向 RPC 库。然而，共享库必须了解到每个应用程序正在使用哪种跟踪协议。
|
||||
* 最后，你不想强制用户使用相互冲突的依赖项。大多数用户有不同的依赖关系和操作风格。即使他们使用 gRPC，绑定的 gRPC 版本是否相同？因此任何你的库附带用于跟踪的监控 API 必定是免于依赖的。
|
||||
|
||||
**因此，一个（a）没有依赖关系、（b）与线路协议无关、（c）使用流行的供应商和分析系统的抽象 API 应该是对检测共享库代码的要求。**
|
||||
|
||||
#### 检测共享式服务
|
||||
|
||||
最后，有时整个服务（或微服务集合体）的通用性足以使许多独立的应用程序使用它们。这种共享式服务通常由第三方托管和管理，例如缓存服务器、消息队列以及数据库。
|
||||
|
||||
从应用程序开发者的角度来看，理解共享式服务本质上是黑盒子是极其重要的。它不可能将你的应用程序监控注入到共享式服务。恰恰相反，托管服务通常会运行它自己的监控方案。
|
||||
|
||||
### 四个方面的解决方案
|
||||
|
||||
因此，抽象的跟踪应用程序接口将会帮助库发出数据并且注入/抽取跨度上下文。标准的线路协议将会帮助黑盒服务相互连接，而标准的数据格式将会帮助分离的分析系统合并其中的数据。让我们来看一下部分有希望解决这些问题的方案。
|
||||
|
||||
#### 跟踪 API：OpenTracing 项目
|
||||
|
||||
如你所见，我们需要一个跟踪 API 来检测应用程序代码。为了将这种工具扩展到大多数进行跨度上下文注入和提取的共享库中，则必须以某种关键方式对 API 进行抽象。
|
||||
|
||||
[OpenTracing][2] 项目主要针对解决库开发者的问题，OpenTracing 是一个与供应商无关的跟踪 API，它没有依赖关系，并且迅速得到了许多监控系统的支持。这意味着，如果库附带了内置的本地 OpenTracing 工具，当监控系统在应用程序启动连接时，跟踪将会自动启动。
|
||||
|
||||
就个人而言，作为一个已经编写、发布和操作开源软件十多年的人，在 OpenTracing 项目上工作并最终解决这个观察性的难题令我十分满意。
|
||||
|
||||
除了 API 之外，OpenTracing 项目还维护了一个不断增长的工具列表，其中一些可以在[这里][6]找到。如果你想参与进来，无论是通过提供一个检测插件，对你自己的 OSS 库进行本地测试，或者仅仅只想问个问题，都可以通过 [Gitter][7] 向我们打招呼。
|
||||
|
||||
#### 线路协议： HTTP 报头 trace-context
|
||||
|
||||
为了监控系统能进行互操作，以及减轻从一个监控系统切换为另外一个时带来的迁移问题，需要标准的线路协议来传播跨度上下文。
|
||||
|
||||
[w3c 分布式跟踪上下文社区小组][8]在努力制定此标准。目前的重点是制定一系列标准的 HTTP 报头。该规范的最新草案可以在[此处][9]找到。如果你对此小组有任何的疑问，[邮件列表][10]和[Gitter 聊天室][11]是很好的解惑地点。
|
||||
|
||||
（LCTT 译注：本文原文发表于 2018 年 5 月，可能现在社区已有不同进展）
|
||||
|
||||
#### 数据协议 （还未出现！！）
|
||||
|
||||
对于黑盒服务，在无法安装跟踪程序或无法与程序进行交互的情况下，需要使用数据协议从系统中导出数据。
|
||||
|
||||
目前这种数据格式和协议的开发工作尚处在初级阶段，并且大多在 w3c 分布式跟踪上下文工作组的上下文中进行工作。需要特别关注的是在标准数据模式中定义更高级别的概念，例如 RPC 调用、数据库语句等。这将允许跟踪系统对可用数据类型做出假设。OpenTracing 项目也通过定义一套[标准标签集][12]来解决这一事务。该计划是为了使这两项努力结果相互配合。
|
||||
|
||||
注意当前有一个中间地带。对于由应用程序开发者操作但不想编译或以其他方式执行代码修改的“网络设备”，动态链接可以帮助避免这种情况。主要的例子就是服务网格和代理，就像 Envoy 或者 NGINX。针对这种情况，可将兼容 OpenTracing 的跟踪器编译为共享对象，然后在运行时动态链接到可执行文件中。目前 [C++ OpenTracing API][13] 提供了该选项。而 JAVA 的 OpenTracing [跟踪器解析][14]也在开发中。
|
||||
|
||||
这些解决方案适用于支持动态链接，并由应用程序开发者部署的的服务。但从长远来看，标准的数据协议可以更广泛地解决该问题。
|
||||
|
||||
#### 分析系统：从跟踪数据中提取有见解的服务
|
||||
|
||||
最后不得不提的是，现在有足够多的跟踪监视解决方案。可以在[此处][15]找到已知与 OpenTracing 兼容的监控系统列表，但除此之外仍有更多的选择。我更鼓励你研究你的解决方案，同时希望你在比较解决方案时发现本文提供的框架能派上用场。除了根据监控系统的操作特性对其进行评级外（更不用提你是否喜欢 UI 和其功能），确保你考虑到了上述三个重要方面、它们对你的相对重要性以及你感兴趣的跟踪系统如何为它们提供解决方案。
|
||||
|
||||
### 结论
|
||||
|
||||
最后，每个部分的重要性在很大程度上取决于你是谁以及正在建立什么样的系统。举个例子，开源库的作者对 OpenTracing API 非常感兴趣，而服务开发者对 trace-context 规范更感兴趣。当有人说一部分比另一部分重要时，他们的意思通常是“一部分对我来说比另一部分重要”。
|
||||
|
||||
然而，事实是：分布式跟踪已经成为监控现代系统所必不可少的事物。在为这些系统进行构建模块时，“尽可能解耦”的老方法仍然适用。在构建像分布式监控系统一样的跨系统的系统时，干净地解耦组件是维持灵活性和前向兼容性地最佳方式。
|
||||
|
||||
感谢你的阅读！现在当你准备好在你自己的应用程序中实现跟踪服务时，你已有一份指南来了解他们正在谈论哪部分部分以及它们之间如何相互协作。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/5/distributed-tracing
|
||||
|
||||
作者：[Ted Young][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[chenmu-kk](https://github.com/chenmu-kk)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/tedsuo
|
||||
[1]:https://research.google.com/pubs/pub36356.html
|
||||
[2]:http://opentracing.io/
|
||||
[3]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/uploads/tracing1_0.png?itok=dvDTX0JJ (Tracing)
|
||||
[4]:https://github.com/opentracing/specification/blob/master/specification.md
|
||||
[5]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/uploads/tracing2_0.png?itok=yokjNLZk (Tracing)
|
||||
[6]:https://github.com/opentracing-contrib/
|
||||
[7]:https://gitter.im/opentracing/public
|
||||
[8]:https://www.w3.org/community/trace-context/
|
||||
[9]:https://w3c.github.io/distributed-tracing/report-trace-context.html
|
||||
[10]:http://lists.w3.org/Archives/Public/public-trace-context/
|
||||
[11]:https://gitter.im/TraceContext/Lobby
|
||||
[12]:https://github.com/opentracing/specification/blob/master/semantic_conventions.md
|
||||
[13]:https://github.com/opentracing/opentracing-cpp
|
||||
[14]:https://github.com/opentracing-contrib/java-tracerresolver
|
||||
[15]:http://opentracing.io/documentation/pages/supported-tracers
|
||||
[16]:https://events.linuxfoundation.org/kubecon-eu-2018/
|
||||
[17]:https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
|
||||
@ -1,41 +1,42 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11846-1.html)
|
||||
[#]: subject: (Keep a journal of your activities with this Python program)
|
||||
[#]: via: (https://opensource.com/article/20/1/python-journal)
|
||||
[#]: author: (Kevin Sonney https://opensource.com/users/ksonney)
|
||||
|
||||
使用这个 Python 程序记录你的活动
|
||||
======
|
||||
Jrnl 可以创建可搜索、带时间戳、可导出、加密的（如果需要）的日常活动日志。在我们的 20 个使用开源提升生产力的系列的第八篇文章中了解更多。
|
||||
![Writing in a notebook][1]
|
||||
|
||||
> jrnl 可以创建可搜索、带时间戳、可导出、加密的（如果需要）的日常活动日志。在我们的 20 个使用开源提升生产力的系列的第八篇文章中了解更多。
|
||||
|
||||
|
||||
|
||||
去年，我在 19 天里给你介绍了 19 个新（对你而言）的生产力工具。今年，我换了一种方式：使用你在使用或者还没使用的工具，构建一个使你可以在新一年更加高效的环境。
|
||||
|
||||
### 使用 jrnl 记录日志
|
||||
|
||||
在我的公司，许多人会在下班之前发送一个“一天结束”的状态。在有着许多项目和全球化的团队里，这是一个分享你已完成、未完成以及你需要哪些帮助的一个很好的方式。但有时候我太忙了，以至于我忘了做了什么。这时候就需要记录日志了。
|
||||
在我的公司，许多人会在下班之前在 Slack 上发送一个“一天结束”的状态。在有着许多项目和全球化的团队里，这是一个分享你已完成、未完成以及你需要哪些帮助的一个很好的方式。但有时候我太忙了，以至于我忘了做了什么。这时候就需要记录日志了。
|
||||
|
||||
![jrnl][2]
|
||||
|
||||
打开一个文本编辑器并在你做一些事的时候添加一行很容易。但是在需要找出你在什么时候做的笔记，或者要快速提取相关的行时会有挑战。幸运的是，[jrnl][3] 可以提供帮助，。
|
||||
打开一个文本编辑器并在你做一些事的时候添加一行很容易。但是在需要找出你在什么时候做的笔记，或者要快速提取相关的行时会有挑战。幸运的是，[jrnl][3] 可以提供帮助。
|
||||
|
||||
Jrnl 能让你在命令行中快速输入条目、搜索过去的条目并导出为 HTML 和 Markdown 等富文本格式。你可以有多个日志，这意味着你可以将工作条目与私有条目分开。它将条目存储为纯文本，因此即使 jrnl 停止工作，数据也不会丢失。
|
||||
jrnl 能让你在命令行中快速输入条目、搜索过去的条目并导出为 HTML 和 Markdown 等富文本格式。你可以有多个日志，这意味着你可以将工作条目与私有条目分开。它将条目存储为纯文本，因此即使 jrnl 停止工作，数据也不会丢失。
|
||||
|
||||
由于 jrnl 是一个 Python 程序，最简单的安装方法是使用 **pip3 install jrnl**。这将确保你获得最新和最好的版本。第一次运行它会询问一些问题，接下来就能正常使用。
|
||||
由于 jrnl 是一个 Python 程序，最简单的安装方法是使用 `pip3 install jrnl`。这将确保你获得最新和最好的版本。第一次运行它会询问一些问题，接下来就能正常使用。
|
||||
|
||||
![jrnl's first run][4]
|
||||
|
||||
现在，每当你需要做笔记或记录日志时，只需输入 **jrnl <some text>**，它将带有时间戳的记录保存到默认文件中。你可以使用 **jrnl -on YYYY-MM-DD** 搜索特定日期条目，**jrnl -from YYYY-MM-DD** 搜索在那日期之后的条目，以及用 **jrnl -to YYYY-MM-DD** 搜索自那日期之后的条目。搜索词可以与 **-and** 参数结合使用，允许像 **jrnl -from 2019-01-01 -and -to 2019-12-31** 这类搜索。
|
||||
现在，每当你需要做笔记或记录日志时，只需输入 `jrnl <some text>`，它将带有时间戳的记录保存到默认文件中。你可以使用 `jrnl -on YYYY-MM-DD` 搜索特定日期条目，`jrnl -from YYYY-MM-DD` 搜索在那日期之后的条目，以及用 `jrnl -to YYYY-MM-DD` 搜索到那日期的条目。搜索词可以与 `-and` 参数结合使用，允许像 `jrnl -from 2019-01-01 -and -to 2019-12-31` 这类搜索。
|
||||
|
||||
你还可以使用 **\--edit** 标志编辑日志中的条目。开始之前，通过编辑文件 **~/.config/jrnl/jrnl.yaml** 来设置默认编辑器。你还可以指定使用什么日志文件、用于标签的特殊字符以及一些其他选项。现在，重要的是设置编辑器。我使用 Vim，jrnl 的文档中有一些使用其他编辑器如 VSCode 和 Sublime Text 的[有用提示][5]
|
||||
你还可以使用 `--edit` 标志编辑日志中的条目。开始之前，通过编辑文件 `~/.config/jrnl/jrnl.yaml` 来设置默认编辑器。你还可以指定日志使用什么文件、用于标签的特殊字符以及一些其他选项。现在，重要的是设置编辑器。我使用 Vim，jrnl 的文档中有一些使用其他编辑器如 VSCode 和 Sublime Text 的[有用提示][5]。
|
||||
|
||||
![Example jrnl config file][6]
|
||||
|
||||
Jrnl 还可以加密日志文件。通过设置全局 **encrypt** 变量，你将告诉 jrnl 加密你定义的所有日志。还可在配置文件中的每个文件中设置 **encrypt: true** 来加密文件。
|
||||
|
||||
jrnl 还可以加密日志文件。通过设置全局 `encrypt` 变量，你将告诉 jrnl 加密你定义的所有日志。还可在配置文件中的针对文件设置 `encrypt: true` 来加密文件。
|
||||
|
||||
```
|
||||
journals:
|
||||
@ -46,7 +47,7 @@ journals:
|
||||
encrypt: true
|
||||
```
|
||||
|
||||
如果日志尚未加密，系统将提示你输入对它任何操作的密码。日志文件将加密保存在磁盘上，并免受窥探。[jrnl 文档][7] 中包含其工作原理、使用哪些加密方式等的更多信息。
|
||||
如果日志尚未加密，系统将提示你输入在对它进行任何操作的密码。日志文件将加密保存在磁盘上，以免受窥探。[jrnl 文档][7] 中包含其工作原理、使用哪些加密方式等的更多信息。
|
||||
|
||||
![Encrypted jrnl file][8]
|
||||
|
||||
@ -59,7 +60,7 @@ via: https://opensource.com/article/20/1/python-journal
|
||||
作者：[Kevin Sonney][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,72 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Get your RSS feeds and podcasts in one place with this open source tool)
|
||||
[#]: via: (https://opensource.com/article/20/1/open-source-rss-feed-reader)
|
||||
[#]: author: (Kevin Sonney https://opensource.com/users/ksonney)
|
||||
|
||||
Get your RSS feeds and podcasts in one place with this open source tool
|
||||
======
|
||||
Keep up with your news feed and podcasts with Newsboat in the twelfth in
|
||||
our series on 20 ways to be more productive with open source in 2020.
|
||||
![Ship captain sailing the Kubernetes seas][1]
|
||||
|
||||
Last year, I brought you 19 days of new (to you) productivity tools for 2019. This year, I'm taking a different approach: building an environment that will allow you to be more productive in the new year, using tools you may or may not already be using.
|
||||
|
||||
### Access your RSS feeds and podcasts with Newsboat
|
||||
|
||||
RSS news feeds are an exceptionally handy way to keep up to date on various websites. In addition to Opensource.com, I follow the annual [SysAdvent][2] sysadmin tools feed, some of my favorite authors, and several webcomics. RSS readers allow me to "batch up" my reading, so I'm not spending every day on a bunch of different websites.
|
||||
|
||||
![Newsboat][3]
|
||||
|
||||
[Newsboat][4] is a terminal-based RSS feed reader that looks and feels a lot like the email program [Mutt][5]. It makes news reading easy and has a lot of nice features.
|
||||
|
||||
Installing Newsboat is pretty easy since it is included with most distributions (and Homebrew on MacOS). Once it is installed, adding the first feed is as easy as adding the URL to the **~/.newsboat/urls** file. If you are migrating from another feed reader and have an OPML file export of your feeds, you can import that file with:
|
||||
|
||||
|
||||
```
|
||||
`newsboat -i </path/to/my/feeds.opml>`
|
||||
```
|
||||
|
||||
After you've added your feeds, the Newsboat interface is _very_ familiar, especially if you've used Mutt. You can scroll up and down with the arrow keys, check for new items in a feed with **r**, check for new items in all feeds with **R**, press **Enter** to open a feed and select an article to read.
|
||||
|
||||
![Newsboat article list][6]
|
||||
|
||||
You are not limited to just the local URL list, though. Newsboat is also a client for news reading services like [Tiny Tiny RSS][7], ownCloud and Nextcloud News, and a few Google Reader successors. Details on that and a whole host of other configuration options are covered in [Newsboat's documentation][8].
|
||||
|
||||
![Reading an article in Newsboat][9]
|
||||
|
||||
#### Podcasts
|
||||
|
||||
Newsboat also provides [podcast support][10] through Podboat, an included application that facilitates downloading and queuing podcast episodes. While viewing a podcast feed in Newsboat, press **e** to add the episode to your download queue. All the information will be stored in a queue file in the **~/.newsboat** directory. Podboat reads this queue and downloads the episode(s) to your local drive. You can do this from the Podboat user interface (which looks and acts like Newsboat), or you can tell Podboat to download them all with **podboat -a**. As a podcaster and podcast listener, I think this is _really_ handy.
|
||||
|
||||
![Podboat][11]
|
||||
|
||||
Overall, Newsboat has some really great features and is a nice, lightweight alternative to web-based or desktop apps.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/open-source-rss-feed-reader
|
||||
|
||||
作者：[Kevin Sonney][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/ksonney
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek (Ship captain sailing the Kubernetes seas)
|
||||
[2]: https://sysadvent.blogspot.com/
|
||||
[3]: https://opensource.com/sites/default/files/uploads/productivity_12-1.png (Newsboat)
|
||||
[4]: https://newsboat.org
|
||||
[5]: http://mutt.org/
|
||||
[6]: https://opensource.com/sites/default/files/uploads/productivity_12-2.png (Newsboat article list)
|
||||
[7]: https://tt-rss.org/
|
||||
[8]: https://newsboat.org/releases/2.18/docs/newsboat.html
|
||||
[9]: https://opensource.com/sites/default/files/uploads/productivity_12-3.png (Reading an article in Newsboat)
|
||||
[10]: https://newsboat.org/releases/2.18/docs/newsboat.html#_podcast_support
|
||||
[11]: https://opensource.com/sites/default/files/uploads/productivity_12-4.png (Podboat)
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -1,217 +0,0 @@
|
||||
chenmu-kk is translating .
|
||||
How the four components of a distributed tracing system work together
|
||||
分布式追踪系统的四大功能模块如何协同工作
|
||||
======
|
||||
|
||||
Ten years ago, essentially the only people thinking hard about distributed tracing were academics and a handful of large internet companies. Today, it’s turned into table stakes for any organization adopting microservices. The rationale is well-established: microservices fail in surprising and often spectacular ways, and distributed tracing is the best way to describe and diagnose those failures.
|
||||
早在十年前，认真研究过分布式追踪基本上只有学者和一小部分大型互联网公司中的人。对于任何采用微服务的组织来说，它如今成为一种筹码。其公认的观点是：微服务通常会发生让人意想不到的错误，而分布式追踪则是描述和诊断那些错误的最好方法。
|
||||
|
||||
That said, if you set out to integrate distributed tracing into your own application, you’ll quickly realize that the term “Distributed Tracing” means different things to different people. Furthermore, the tracing ecosystem is crowded with partially-overlapping projects with similar charters. This article describes the four (potentially) independent components in distributed tracing, and how they fit together.
|
||||
也就是说，一旦你准备将分布式追踪集成到你自己的应用程序中，你将很快意识到对于不同的人来说“分布式追踪”一词意味着不同的事物。此外，追踪生态系统挤满了具有相似内容的重叠项目。本文介绍了分布式追踪系统中四个（潜在的）独立的功能模块并描述了它们间将如何协同工作。
|
||||
|
||||
### Distributed tracing: A mental model
|
||||
分布式追踪：一种思维模型
|
||||
|
||||
Most mental models for tracing descend from [Google’s Dapper paper][1]. [OpenTracing][2] uses similar nouns and verbs, so we will borrow the terms from that project:
|
||||
大多数追踪的思维模型来源于[Google的Dapper论文][1]。[OpenTracing][2]会使用相似的术语，因此，我们从那借用了以下术语：
|
||||
|
||||
![Tracing][3]
|
||||
|
||||
* **Trace:** The description of a transaction as it moves through a distributed system.
|
||||
事物在分布式系统运行的过程描述。
|
||||
* **Span:** A named, timed operation representing a piece of the workflow. Spans accept key:value tags as well as fine-grained, timestamped, structured logs attached to the particular span instance.
|
||||
一种命名的定时操作，表示工作流的一部分。 Spans 可接受 key : value 标签以及附加到特定 Span 实例的细粒度、带有时间戳的结构化日志。
|
||||
* **Span context:** Trace information that accompanies the distributed transaction, including when it passes from service to service over the network or through a message bus. The span context contains the trace identifier, span identifier, and any other data that the tracing system needs to propagate to the downstream service.
|
||||
携带分布式事务的追踪信息，包括当它通过网络或消息总线将服务传递给服务时。 span 上下文包含 trace 标识符、 span 标识符以及追踪系统所需传播到下游服务的任何其他数据。
|
||||
|
||||
|
||||
|
||||
If you would like to dig into a detailed description of this mental model, please check out the [OpenTracing specification][4].
|
||||
如果你想要深入研究这种思维模式的细节，请仔细参照[OpenTracing技术规范][1]。
|
||||
|
||||
### The four big pieces
|
||||
四大功能模块
|
||||
|
||||
From the perspective of an application-layer distributed tracing system, a modern software system looks like the following diagram:
|
||||
从应用层分布式追踪系统的观点来看，现代软件系统架构如下图所示：
|
||||
|
||||
![Tracing][5]
|
||||
|
||||
The components in a modern software system can be broken down into three categories:
|
||||
现代软件系统的组件可分为三类：
|
||||
|
||||
* **Application and business logic:** Your code.
|
||||
应用程序和业务逻辑：你的代码。
|
||||
* **Widely shared libraries:** Other people's code.
|
||||
广泛共享库：他人的代码
|
||||
* **Widely shared services:** Other people’s infrastructure.
|
||||
广泛共享服务：他人的基础架构
|
||||
|
||||
|
||||
|
||||
These three components have different requirements and drive the design of the Distributed Tracing systems which is tasked with monitoring the application. The resulting design yields four important pieces:
|
||||
这三类组件有着不同的需求，驱动监控应用程序的分布式追踪系统的设计。最终的设计得到了四个重要的部分：
|
||||
|
||||
* **A tracing instrumentation API:** What decorates application code.
|
||||
追踪测试API：修饰应用程序代码
|
||||
* **Wire protocol:** What gets sent alongside application data in RPC requests.
|
||||
有线协议：在 RPC 请求中与应用程序数据一同发送的规定
|
||||
* **Data protocol:** What gets sent asynchronously (out-of-band) to your analysis system.
|
||||
数据协议：将异步信息（带外）发送到你的分析系统的规定
|
||||
* **Analysis system:** A database and interactive UI for working with the trace data.
|
||||
分析系统：用于处理追踪数据的数据库和交互式用户界面
|
||||
|
||||
|
||||
|
||||
To explain this further, we’ll dig into the details which drive this design. If you just want my suggestions, please skip to the four big solutions at the bottom.
|
||||
为了更深入的解释这个概念，我们将深入研究驱动该设计的细节。如果你只需要我的一些建议，请跳转至下方的四大解决方案。
|
||||
|
||||
### Requirements, details, and explanations
|
||||
需求，细节和解释
|
||||
|
||||
Application code, shared libraries, and shared services have notable operational differences, which heavily influence the requirements for instrumenting them.
|
||||
应用程序代码、共享库以及共享式服务在操作上有显著的差别，这种差别严重影响了对其进行检测的请求操作。
|
||||
|
||||
#### Instrumenting application code and business logic
|
||||
测试应用程序代码和业务逻辑
|
||||
|
||||
In any particular microservice, the bulk of the code written by the microservice developer is the application or business logic. This is the code that defines domain-specific operations; typically, it contains whatever special, unique logic justified the creation of a new microservice in the first place. Almost by definition, **this code is usually not shared or otherwise present in more than one service.**
|
||||
在任何特定的微服务中，由微服务开发者编写的大段代码是应用程序或者商业逻辑。这段代码规定了特定区域的操作。通常，它包含任何特殊、独一无二的逻辑判断，这些逻辑判断首先证明了创建新型微服务的合理性。在几乎所有定义的操作中， 该代码通常不会在多个服务中共享或者以其他方式出现。
|
||||
|
||||
That said, you still need to understand it, and that means it needs to be instrumented somehow. Some monitoring and tracing analysis systems auto-instrument code using black-box agents, and others expect explicit "white-box" instrumentation. For the latter, abstract tracing APIs offer many practical advantages for microservice-specific application code:
|
||||
也即是说你仍需理解它，这也意味着需要以某种方式对它进行测试。一些监控和追踪分析系统使用黑盒代理自动检测代码，另一些系统更想使用显式的白盒检测工具。对于后者，抽象追踪API 提供了许多对于微服务的应用程序代码来说更为实用的优势：
|
||||
|
||||
* An abstract API allows you to swap in new monitoring tools without re-writing instrumentation code. You may want to change cloud providers, vendors, and monitoring technologies, and a huge pile of non-portable instrumentation code would add meaningful overhead and friction to that procedure.
|
||||
抽象API 允许你在不重新编写测试代码的条件下换新的监视工具。你可能想要变更云服务提供商，供应商和监测技术，而一大堆不可移植的检测代码将会为该过程增加有意义的开销和麻烦。
|
||||
* It turns out there are other interesting uses for instrumentation, beyond production monitoring. There are existing projects that use this same tracing instrumentation to power testing tools, distributed debuggers, “chaos engineering” fault injectors, and other meta-applications.
|
||||
事实证明，除了生产监控之外，该工具还有其他有趣的用途。现有的项目使用相同的追踪工具来驱动测试工具、分布式调试器、“混沌工程”故障注入器和其他元应用程序。
|
||||
* But most importantly, what if you wanted to extract an application component into a shared library? That leads us to:
|
||||
但更重要的是，若将应用程序组件提取到共享库中要怎么办呢？由上述内容可得到结论：
|
||||
|
||||
|
||||
|
||||
#### Instrumenting shared libraries
|
||||
测试共享库
|
||||
|
||||
The utility code present in most applications—code that handles network requests, database calls, disk writes, threading, queueing, concurrency management, and so on—is often generic and not specific to any particular application. This code is packaged up into libraries and frameworks which are then installed in many microservices, and deployed into many different environments.
|
||||
在大多数应用程序中出现的实用程序代码（处理网络请求、数据库调用、磁盘写操作、线程、并发管理等）通常情况下是通用的，而非特别应用于某个特定应用程序。这段代码会被打包成库和框架，而后就可以被装载到许多的微服务上并且被部署到多种不同的环境中。
|
||||
|
||||
This is the real difference: with shared code, someone else is the user. Most users have different dependencies and operational styles. If you attempt to instrument this shared code, you will note a couple of common issues:
|
||||
其真正的不同是：对于共享代码，其他人则成为了使用者。大多数用户有不同的依赖关系和操作风格。如果尝试去使用该共享代码，你将会注意到几个常见的问题：
|
||||
|
||||
* You need an API to write instrumentation. However, your library does not know what analysis system is being used. There are many choices, and all the libraries running in the same application cannot make incompatible choices.
|
||||
你需要一个 API 来编写测试工具。然而，你的库并不知道你正在使用哪个分析系统。会有多种选择，并且运行在相同应用下的所有库无法做出不兼容的选择。
|
||||
* The task of injecting and extracting span contexts from request headers often falls on RPC libraries, since those packages encapsulate all network-handling code. However, a shared library cannot not know which tracing protocol is being used by each application.
|
||||
由于这些包封装了所有网络处理代码，因此从请求报头注入和提取 span上下文的任务往往指向RPC库。然而，共享库必须了解到每个应用程序正在使用哪种追踪协议。
|
||||
* Finally, you don’t want to force conflicting dependencies on your user. Most users have different dependencies and operational styles. Even if they use gRPC, will it be the same version of gRPC you are binding to? So any monitoring API your library brings in for tracing must be free of dependencies.
|
||||
最后，你不想强制用户使用相互冲突的依赖项。大多数用户有不同的依赖关系和操作风格。即使他们使用gRPC会使它会成为你正在绑定的相同的gRPC版本？因此任何你的库附带用于追踪的监控API必定是免于依赖的。
|
||||
|
||||
|
||||
|
||||
**So, an abstract API which (a) has no dependencies, (b) is wire protocol agnostic, and (c) works with popular vendors and analysis systems should be a requirement for instrumenting shared library code.**
|
||||
所以，一个无依赖的抽象API，是网络协议的不可知论，并且使用流行的供应商和分析系统应该是一个对于配置共享库代码的请求
|
||||
|
||||
#### Instrumenting shared services
|
||||
配置共享服务
|
||||
|
||||
Finally, sometimes entire services—or sets of microservices—are general-purpose enough that they are used by many independent applications. These shared services are often hosted and managed by third parties. Examples might be cache servers, message queues, and databases.
|
||||
最后，有时整个服务或微服务集合体的通用性足以使许多独立的应用程序使用它们。这种共享式服务通常由第三方托管和管理，例如缓存服务器、消息队列以及数据库。
|
||||
|
||||
It’s important to understand that **shared services are essentially "black boxes" from the perspective of application developers.** It is not possible to inject your application’s monitoring solution into a shared service. Instead, the hosted service often runs its own monitoring solution.
|
||||
从应用程序开发者的角度来看，理解共享式服务本质上是黑盒子是极其重要的。它不可能将你的应用程序监控注入到共享式服务。恰恰相反，托管服务通常会运行它自己的监控方案。
|
||||
|
||||
### **The four big solutions**
|
||||
四大解决方案
|
||||
|
||||
So, an abstracted tracing API would help libraries emit data and inject/extract Span Context. A standard wire protocol would help black-box services interconnect, and a standard data format would help separate analysis systems consolidate their data. Let's have a look at some promising options for solving these problems.
|
||||
因此，一个抽象的追踪应用程序接口将会帮助库发出数据并且注入/抽取 Span Context。一个标准有线协议将会方案帮助黑盒服务相互连接，而且一个标准数据格式将会帮助分离分析系统固化其中的数据。让我们来看一下部分有希望解决这些问题的方案。
|
||||
|
||||
#### Tracing API: The OpenTracing project
|
||||
追踪 API：OpenTracing项目
|
||||
|
||||
#### As shown above, in order to instrument application code, a tracing API is required. And in order to extend that instrumentation to shared libraries, where most of the Span Context injection and extraction occurs, the API must be abstracted in certain critical ways.
|
||||
如你所见，我们需要一个追踪API 来检测应用程序代码。为了将这种工具扩展到大多数进行 Span Context 注入和提取的共享库中，则必须以某种关键方式对API进行抽象。
|
||||
|
||||
The [OpenTracing][2] project aims to solve this problem for library developers. OpenTracing is a vendor-neutral tracing API which comes with no dependencies, and is quickly gaining support from a large number of monitoring systems. This means that, increasingly, if libraries ship with native OpenTracing instrumentation baked in, tracing will automatically be enabled when a monitoring system connects at application startup.
|
||||
[OpenTracing][2]项目主要针对解决库开发者的问题，OpenTracing 是一个与供应商无关的 Tracing API，它没有依赖关系并且能从许多监控系统中迅速获取支持。这意味着，如果库附带内置的本地 OpenTracing 工具，当监控系统在应用程序启动连接时，追踪将会自动启动。
|
||||
|
||||
Personally, as someone who has been writing, shipping, and operating open source software for over a decade, it is profoundly satisfying to work on the OpenTracing project and finally scratch this observability itch.
|
||||
就个人而言，作为一个已经编写、发布和操作开源软件十多年的人，在 OpenTracing 项目上工作并最终解决这个观察性的难题令我十分满意。
|
||||
|
||||
In addition to the API, the OpenTracing project maintains a growing list of contributed instrumentation, some of which can be found [here][6]. If you would like to get involved, either by contributing an instrumentation plugin, natively instrumenting your own OSS libraries, or just want to ask a question, please find us on [Gitter][7] and say hi.
|
||||
除了 API 之外，OpenTracing 项目还维护了一个不断增长的工具列表，其中一些可以在[这里][6]找到。如果你想参与进来，无论是通过提供一个插装插件，对你自己的OSS库进行本地测试，或者仅仅只想问个问题，都可以通过[Gitter][7]向我们打招呼。
|
||||
|
||||
#### Wire Protocol: The trace-context HTTP headers
|
||||
有线协议： trace-context 的HTTP报头
|
||||
|
||||
In order for monitoring systems to interoperate, and to mitigate migration issues when changing from one monitoring system to another, a standard wire protocol is needed for propagating Span Context.
|
||||
为了监控系统能进行交互操作以及减轻监控系统间切换事务时带来的迁移问题，需要标准的有线协议来传播 Span 上下文。
|
||||
|
||||
The [w3c Distributed Trace Context Community Group][8] is hard at work defining this standard. Currently, the focus is on defining a set of standard HTTP headers. The latest draft of the specification can be found [here][9]. If you have questions for this group, the [mailing list][10] and [Gitter chatroom][11] are great places to go for answers.
|
||||
[w3c Distributed Trace Context Community Group][8]在努力制定此标准。目前的焦点是制定一系列标准的HTTP报头。该规范的最新草案可以在[此处][9]找到。如果你对这个组织有任何的疑问， [邮件列表][10] 和 [Gitter 聊天室][11]是很好的解惑地点。
|
||||
|
||||
#### Data protocol (Doesn't exist yet!!)
|
||||
数据协议 （还未出现！！）
|
||||
|
||||
For black-box services, where it is not possible to install a tracer or otherwise interact with the program, a data protocol is needed to export data from the system.
|
||||
对于黑盒服务，在无法安装追踪程序或无法与程序进行交互的情况下，需要使用数据协议从系统中导出数据。
|
||||
|
||||
Work on this data format and protocol is currently at an early stage, and mostly happening within the context of the w3c Distributed Trace Context Working Group. There is particular interest is in defining higher-level concepts, such as RPC calls, database statements, etc, in a standard data schema. This would allow tracing systems to make assumptions about what kind of data would be available. The OpenTracing project is also working on this issue, by starting to define a [standard set of tags][12]. The plan is for these two efforts to dovetail with each other.
|
||||
目前这种数据格式和协议的开发工作尚处在初级阶段，并且大多在w3c分布式追踪上下文工作组的上下文中进行工作。 令人特别感兴趣的是在标准数据模式中定义更高级别的概念，例如 RPC 调用，数据库语句等。这将允许追踪系统对可用数据类型做出假设。OpenTracing 项目也通过定义一套 [标准标签集][12]来解决这一事务。该计划是为了使这两项努力结果相互配合。
|
||||
|
||||
Note that there is a middle ground available at the moment. For “network appliances” that the application developer operates, but does not want to compile or otherwise perform code modifications to, dynamic linking can help. The primary examples of this are service meshes and proxies, such as Envoy or NGINX. For this situation, an OpenTracing-compliant tracer can be compiled as a shared object, and then dynamically linked into the executable at runtime. This option is currently provided by the [C++ OpenTracing API][13]. For Java, an OpenTracing [Tracer Resolver][14] is also under development.
|
||||
注意当前有一个中间地带。对于由应用程序开发者操作但不想编译或以其他方式执行代码修改的“网络设备”，动态链接可以帮助避免这种情况。主要的例子就是服务网格和代理，就像 Envoy 或者 NGINX。针对这种情况，可将兼容 OpenTracing 的追踪器编译为共享对象，然后在运行时动态链接到可执行文件中。目前[C++ OpenTracing API][13]提供了该选项。而 JAVA 的 OpenTracing [追踪器解析][14]也在开发中。
|
||||
|
||||
These solutions work well for services that support dynamic linking, and are deployed by the application developer. But in the long run, a standard data protocol may solve this problem more broadly.
|
||||
这些解决方案适用于支持动态链接的服务，并由应用程序开发者开发。但从长远来看，标准的数据协议可以更广泛地解决该问题。
|
||||
|
||||
#### Analysis system: A service for extracting insights from trace data
|
||||
分析系统：从追踪数据中提取有见解的服务
|
||||
|
||||
Last but not least, there is now a cornucopia of tracing and monitoring solutions. A list of monitoring systems known to be compatible with OpenTracing can be found [here][15], but there are many more options out there. I would encourage you to research your options, and I hope you find the framework provided in this article to be useful when comparing options. In addition to rating monitoring systems based on their operational characteristics (not to mention whether you like the UI and features), make sure you think about the three big pieces above, their relative importance to you, and how the tracing system you are interested in provides a solution to them.
|
||||
最后不得不提的是，现在有足够多的追踪监视解决方案。可以在[此处][15]找到与 OpenTracing 兼容的已知监控系统列表，但除此之外仍有更多的选择。我更鼓励你研究自定义选项，同时发现本文提供的框架在对比选择时是非常有用的。除了根据监控系统的操作特性对其进行评级外，监控系统基于它们的操作特征(更不用提你是否喜欢 UI 和其功能),确保你考虑到了上述三大组件、它们对你的相对重要性以及你感兴趣的追踪系统如何为它们提供解决方案。
|
||||
|
||||
### Conclusion
|
||||
结论
|
||||
|
||||
In the end, how important each piece is depends heavily on who you are and what kind of system you are building. For example, open source library authors are very interested in the OpenTracing API, while service developers tend to be more interested in the Trace-Context specification. When someone says one piece is more important than the other, they usually mean “one piece is more important to me than the other."
|
||||
最后，每个部分的重要性在很大程度上取决于你是谁以及正在建立什么样的系统。举个例子，开源库的作者对 OpenTracing API 非常感兴趣，而服务开发者对 trace-context 规范更感兴趣。当有人说一部分比另一部分重要时，他们的意思通常是“一部分对我来说比另一部分重要”。
|
||||
|
||||
However, the reality is this: Distributed Tracing has become a necessity for monitoring modern systems. In designing the building blocks for these systems, the age-old approach—"decouple where you can"—still holds true. Cleanly decoupled components are the best way to maintain flexibility and forwards-compatibility when building a system as cross-cutting as a distributed monitoring system.
|
||||
然而，事实是：分布式追踪已经成为监控现代系统所必不可少的事物。在为这些系统进行构建模块时，“尽可能分离的”老方法仍然适用。在构建像分布式监控系统一样的跨系统的系统，干净地分离组件是维持灵活性和前向兼容性地最佳方式。
|
||||
|
||||
Thanks for reading! Hopefully, now when you're ready to implement tracing in your own application, you have a guide to understanding which pieces they are talking about, and how they fit together.
|
||||
感谢您的阅读！现在当你准备好在你自己的应用程序中实现追踪服务时，你已有一份指南来了解他们正在谈论哪部分片段以及他们之间如何相互协作。
|
||||
|
||||
Want to learn more? Sign up to attend [KubeCon EU][16] in May or [KubeCon North America][17] in December.
|
||||
想学到更多？报名参加5月份的[KubeCon EU]或者12月份的[KubeCon North America]吧。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/5/distributed-tracing
|
||||
|
||||
作者：[Ted Young][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[chenmu-kk](https://github.com/chenmu-kk)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/tedsuo
|
||||
[1]:https://research.google.com/pubs/pub36356.html
|
||||
[2]:http://opentracing.io/
|
||||
[3]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/uploads/tracing1_0.png?itok=dvDTX0JJ (Tracing)
|
||||
[4]:https://github.com/opentracing/specification/blob/master/specification.md
|
||||
[5]:https://opensource.com/sites/default/files/styles/panopoly_image_original/public/uploads/tracing2_0.png?itok=yokjNLZk (Tracing)
|
||||
[6]:https://github.com/opentracing-contrib/
|
||||
[7]:https://gitter.im/opentracing/public
|
||||
[8]:https://www.w3.org/community/trace-context/
|
||||
[9]:https://w3c.github.io/distributed-tracing/report-trace-context.html
|
||||
[10]:http://lists.w3.org/Archives/Public/public-trace-context/
|
||||
[11]:https://gitter.im/TraceContext/Lobby
|
||||
[12]:https://github.com/opentracing/specification/blob/master/semantic_conventions.md
|
||||
[13]:https://github.com/opentracing/opentracing-cpp
|
||||
[14]:https://github.com/opentracing-contrib/java-tracerresolver
|
||||
[15]:http://opentracing.io/documentation/pages/supported-tracers
|
||||
[16]:https://events.linuxfoundation.org/kubecon-eu-2018/
|
||||
[17]:https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/
|
||||
@ -0,0 +1,71 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Get your RSS feeds and podcasts in one place with this open source tool)
|
||||
[#]: via: (https://opensource.com/article/20/1/open-source-rss-feed-reader)
|
||||
[#]: author: (Kevin Sonney https://opensource.com/users/ksonney)
|
||||
|
||||
使用此开源工具将你的RSS 订阅源和播客放在一起
|
||||
======
|
||||
在我们的 20 个使用开源提升生产力的系列的第十二篇文章中使用 Newsboat 跟上你的新闻 RSS 源和播客。
|
||||
![Ship captain sailing the Kubernetes seas][1]
|
||||
|
||||
去年，我在 19 天里给你介绍了 19 个新（对你而言）的生产力工具。今年，我换了一种方式：使用你在使用或者还没使用的工具，构建一个使你可以在新一年更加高效的环境。
|
||||
|
||||
### 使用 Newsboat 访问你的 RSS 源和播客
|
||||
|
||||
RSS 新闻源是了解各个网站最新消息的非常方便的方法。除了 Opensource.com，我还会关注 [SysAdvent][2] 年度 sysadmin 工具，还有一些我最喜欢的作者以及一些网络漫画。RSS 阅读器可以让我“批处理”阅读内容，因此，我每天不会在不同的网站上花费很多时间。
|
||||
|
||||
![Newsboat][3]
|
||||
|
||||
[Newsboat][4] 是一个基于终端的 RSS 订阅源阅读器，外观感觉很像电子邮件程序 [Mutt][5]。它使阅读新闻变得容易，并有许多不错的功能。
|
||||
|
||||
安装 Newsboat 非常容易，因为它包含在大多数发行版（以及 MacOS 上的 Homebrew）中。安装后，只需在 **~/.newsboat/urls** 中添加订阅源。如果你是从其他阅读器迁移而来，并有导出的 OPML 文件，那么可以使用以下方式导入：
|
||||
|
||||
|
||||
```
|
||||
`newsboat -i </path/to/my/feeds.opml>`
|
||||
```
|
||||
|
||||
添加订阅源后，Newsboat 的界面非常熟悉，特别是如果你使用过 Mutt。你可以使用箭头键上下滚动，使用 **r** 检查某个源中是否有新项目，使用 **R** 检查所有源中是否有新项目，按**回车**打开订阅源，并选择要阅读的文章。
|
||||
|
||||
![Newsboat article list][6]
|
||||
|
||||
但是，你不仅限于本地 URL 列表。Newsboat 还是 [Tiny Tiny RSS][7]、ownCloud 和 Nextcloud News 等新闻阅读服务以及一些 Google Reader 后续产品的客户端。[Newsboat 的文档][8]中涵盖了有关此的详细信息以及其他许多配置选项。
|
||||
|
||||
![Reading an article in Newsboat][9]
|
||||
|
||||
#### 播客
|
||||
|
||||
Newsboat 还通过 Podboat 提供了[播客支持][10]，podboat 是一个附带的应用，它可帮助下载和排队播客节目。在 Newsboat 中查看播客源时，按下 **e** 将节目添加到你的下载队列中。所有信息将保存在 **~/.newsboat** 目录中的队列文件中。Podboat 读取此队列并将节目下载到本地磁盘。你可以在 Podboat 的用户界面（外观和行为类似于 Newsboat）执行此操作，也可以使用 ** podboat -a ** 让 Podboat 下载所有内容。作为播客人和播客听众，我认为这_真的_很方便。
|
||||
|
||||
![Podboat][11]
|
||||
|
||||
总体而言，Newsboat 有一些非常好的功能，并且是一些基于 Web 或桌面应用的不错的轻量级替代方案。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/1/open-source-rss-feed-reader
|
||||
|
||||
作者：[Kevin Sonney][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/ksonney
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/ship_captain_devops_kubernetes_steer.png?itok=LAHfIpek (Ship captain sailing the Kubernetes seas)
|
||||
[2]: https://sysadvent.blogspot.com/
|
||||
[3]: https://opensource.com/sites/default/files/uploads/productivity_12-1.png (Newsboat)
|
||||
[4]: https://newsboat.org
|
||||
[5]: http://mutt.org/
|
||||
[6]: https://opensource.com/sites/default/files/uploads/productivity_12-2.png (Newsboat article list)
|
||||
[7]: https://tt-rss.org/
|
||||
[8]: https://newsboat.org/releases/2.18/docs/newsboat.html
|
||||
[9]: https://opensource.com/sites/default/files/uploads/productivity_12-3.png (Reading an article in Newsboat)
|
||||
[10]: https://newsboat.org/releases/2.18/docs/newsboat.html#_podcast_support
|
||||
[11]: https://opensource.com/sites/default/files/uploads/productivity_12-4.png (Podboat)
|
||||
Loading…
Reference in New Issue
Block a user