commit Chinese version of white paper. #57
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@chenmudu I'll be happy to do a proofreading on the Chinese version! Thanks for translating! |
JohnWu20
reviewed
Aug 11, 2021
whitepaper-zh.md
Outdated
|
|
||
| ## 介绍 | ||
|
|
||
| 随着云计算、微服务和分布式系统的普及，新的多应用程序通常会被设计、构建以及运行在云上。虽然提供了一种新的方式来构建更具有弹性、性能、安全性的应用程序, 但随之而来的是增加了能够支撑应用工作的基础设施的控制的潜在成本。系统管理员、开发者和软件使用者必须知道关于应用在生产中的状态以及在应用之下的底层基础设施的运行状况。除此之外,他们应该在软件之外可以观测到这些信号, 而不需要例如在代码中添加新的仪器或在生产中正在运行的代码中添加断点。 |
There was a problem hiding this comment.
Suggested change
| 随着云计算、微服务和分布式系统的普及，新的多应用程序通常会被设计、构建以及运行在云上。虽然提供了一种新的方式来构建更具有弹性、性能、安全性的应用程序, 但随之而来的是增加了能够支撑应用工作的基础设施的控制的潜在成本。系统管理员、开发者和软件使用者必须知道关于应用在生产中的状态以及在应用之下的底层基础设施的运行状况。除此之外,他们应该在软件之外可以观测到这些信号, 而不需要例如在代码中添加新的仪器或在生产中正在运行的代码中添加断点。 | |
| 随着云计算、微服务和分布式系统的普及，新多应用程序通常会被设计、构建以及运行在云上。虽然提供了一种新的方式来构建更具有弹性、性能、安全性的应用程序, 但随之而来的是增加了能够支撑应用工作的基础设施的控制的潜在成本。系统管理员、开发者和软件使用者必须知道关于应用在生产中的状态以及在应用之下的底层基础设施的运行状况。除此之外,他们应该在软件之外可以观测到这些信号, 而不需要例如在代码中添加新的仪器或在生产中正在运行的代码中添加断点。 |
JohnWu20
reviewed
Aug 11, 2021
whitepaper-zh.md
Outdated
|
|
||
| 这些应用需要设计和构建一些包含和促使外部用户可以观测到的方式(埋点)。例如, 无论这个实体是另外一个应用还是一个无法访问数据中心的人.这些需要更早,并且从设计开始, 而且这通常需要额外的代码或者插桩方式以及对应的仪表盘. 对于许多组织来说, 这种文化和处理流程变化往往意味着挑战和阻碍。除此之外,在市场上还存在许多方式和工具可以提供不同的方法来达到较为合理的可观测性水平. | ||
|
|
||
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始他们的可观测性路程”以及在“实现更多可观测性系统的转变存在着更多的动力”。一旦达到了一个令人满意的可观测性水平， 毫无疑问是令人满意的。但刚开始可能感觉会是一项艰巨的任务！文化变化，不同的工具，不同的目标，不同的方法。所以太多的细节可能会让这段旅程变得相当混论和痛苦。这篇 paper 的目的是提供清晰的说明，以便更多的软件和使用团队可以在他们的系统中获取到可观测性的好处。 |
There was a problem hiding this comment.
Suggested change
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始他们的可观测性路程”以及在“实现更多可观测性系统的转变存在着更多的动力”。一旦达到了一个令人满意的可观测性水平， 毫无疑问是令人满意的。但刚开始可能感觉会是一项艰巨的任务！文化变化，不同的工具，不同的目标，不同的方法。所以太多的细节可能会让这段旅程变得相当混论和痛苦。这篇 paper 的目的是提供清晰的说明，以便更多的软件和使用团队可以在他们的系统中获取到可观测性的好处。 | |
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始他们的可观测性路程”以及在“实现更多可观测性系统的转变存在着更多的动力”。能够达到了一个令人满意的可观测性水平， 毫无疑问是很有利的。但刚开始可能感觉会是一项艰巨的任务！文化变化，不同的工具，不同的目标，不同的方法。所以太多的细节可能会让这段旅程变得相当混论和痛苦。这篇 paper 的目的是提供清晰的说明，以便更多的软件和使用团队可以在他们的系统中获取到可观测性的好处。 |
JohnWu20
reviewed
Aug 11, 2021
whitepaper-zh.md
Outdated
|
|
||
| 毫无疑问，可观测性是当今系统的一个令人向往的特性。每个人都在说，对吧？你们当中的一些人可能已经开始了你的可观测旅程，而其他人正在阅读这份儿白皮书，因为每个人都在说你应该让你的系统具备可观测性。事实上，"可观测性"已经成为一个流行的词汇，就像其他的词汇一样，每个人都希望在提议它的同时再其之上留下自己的印记，你听到的可能和他的起源有一些不同的定义。如果你想让你的游戏更具备可观测性，让我们来试着明确它的最初目的。 | ||
|
|
||
| ”在控制理论中，可观测性是一种如何从当前外部输出的知识中推断衡量其内部状态的一种方法“[9]。它是一个系统系统的功能, 通过这个系统, 人类以及可以观测、理解并依据当前系统的状态做出不同的举动.。所以是的, 从定义上来看很简单，但是在没有目标的情况下，决定系统应该有哪些输出就变得及其复杂了，那时候就开始变得糟糕了. |
There was a problem hiding this comment.
Suggested change
| ”在控制理论中，可观测性是一种如何从当前外部输出的知识中推断衡量其内部状态的一种方法“[9]。它是一个系统系统的功能, 通过这个系统, 人类以及可以观测、理解并依据当前系统的状态做出不同的举动.。所以是的, 从定义上来看很简单，但是在没有目标的情况下，决定系统应该有哪些输出就变得及其复杂了，那时候就开始变得糟糕了. | |
| ”在控制理论中，可观测性是一种如何从当前外部输出的知识中推断衡量其内部状态的一种方法“[9]。它是一个系统系统的功能, 通过这个系统, 人类以及可以观测、理解并依据当前系统的状态做出不同的举动。所以是的, 从定义上来看很简单，但是在没有目标的情况下，决定系统应该有哪些输出就变得及其复杂了，那时候就开始变得糟糕了. |
JohnWu20
reviewed
Aug 11, 2021
whitepaper-zh.md
Outdated
|
|
||
| 在一开始的时候，抄袭别人的作品是很容易的，这是开源带来的好处之一，同时也是缺点之一。 在网上有很多这样的例子: helm charts, Ansible playbooks, Terraform modules。仅仅运行其中一个脚本, 你就可以在几分钟之内完成一套可观测性技术栈的搭建并让他运行起来。这很简单，对其他人来说也有用，所以对我也是有用的，对吗？ 我们并不是想要鼓励你不要使用这些脚本，但是你需要注意的是: 可观测性不仅仅是去使用这些看起来好看和闪亮的工具。你必须意识到你的系统会产生什么样的结果，更加重要的是，你需要在脑海里有一个目标。你可能会想：“ 噢, 我想收集这个特殊的数据, 因为你永远不知道, 可能在未来会需要它。” 然后你对另外一些数据有类似的想法，一个接着一个，然后你意识到你正在建立一个数据湖。 | ||
|
|
||
| 可观测性可以用在系统开发生命周期内的所有阶段。你可以在测试新特性、监测产品弹性、了解客户使用如何时候用你的产品或依据数据驱动去制定产品规划路线。一旦你确定了目标之后，就会考虑输出一些数据，或者我们喜欢将它成为 "信号"。 |
There was a problem hiding this comment.
Suggested change
| 可观测性可以用在系统开发生命周期内的所有阶段。你可以在测试新特性、监测产品弹性、了解客户使用如何时候用你的产品或依据数据驱动去制定产品规划路线。一旦你确定了目标之后，就会考虑输出一些数据，或者我们喜欢将它成为 "信号"。 | |
| 可观测性可以用在系统开发生命周期内的所有阶段。你可以在测试新特性、监测产品弹性、了解客户使用如何时候用你的产品或依据数据驱动去制定产品规划路线。一旦你确定了目标之后，就会考虑输出一些数据，或者我们喜欢将它称为 "信号"。 |
JohnWu20
reviewed
Aug 11, 2021
whitepaper-zh.md
Outdated
|
|
||
| ## 可观测性信号 | ||
|
|
||
| 如之前所述，信号是由系统产生的输出数据，人类或机器可以从中推断内容。这些信号是什么会因为系统而异，也取决于你想要达成的目标。它可能是你想要在某个时刻测量的东西，例如温度或者 RAM usage，或者在分布式系统中你想要追踪的众多组件发生的事件。你可能想知道在某个随机时间点，系统的哪个功能消耗了较多的 CPU、Mem 或者磁盘等资源，或者在特定的时间点，系统是如何崩溃的。虽然一些信号可能一起来还原业务现场，但是其他信号在系统的某些方面非常专业。他们可以一起使用，提供观察同一个技术的不同方式。或者正如我们对初学者的建议，你可以从一个或几个信号开始，然后逐步完善其他技术。 |
There was a problem hiding this comment.
Suggested change
| 如之前所述，信号是由系统产生的输出数据，人类或机器可以从中推断内容。这些信号是什么会因为系统而异，也取决于你想要达成的目标。它可能是你想要在某个时刻测量的东西，例如温度或者 RAM usage，或者在分布式系统中你想要追踪的众多组件发生的事件。你可能想知道在某个随机时间点，系统的哪个功能消耗了较多的 CPU、Mem 或者磁盘等资源，或者在特定的时间点，系统是如何崩溃的。虽然一些信号可能一起来还原业务现场，但是其他信号在系统的某些方面非常专业。他们可以一起使用，提供观察同一个技术的不同方式。或者正如我们对初学者的建议，你可以从一个或几个信号开始，然后逐步完善其他技术。 | |
| 如之前所述，信号是由系统产生的输出数据，人类或机器可以从中推断内容。这些信号是什么会因为系统而异，也取决于你想要达成的目标。它可能是你想要在某个时刻测量的东西，例如温度或者 RAM 使用情况，或者在分布式系统中你想要追踪的众多组件发生的事件。你可能想知道在某个随机时间点，系统的哪个功能消耗了较多的 CPU、Mem 或者磁盘等资源，或者在特定的时间点，系统是如何崩溃的。虽然一些信号可能一起来还原业务现场，但是其他信号在系统的某些方面非常专业。他们可以一起使用，提供观察同一个技术的不同方式。或者正如我们对初学者的建议，你可以从一个或几个信号开始，然后逐步完善其他技术。 |
JohnWu20
reviewed
Aug 11, 2021
whitepaper-zh.md
Outdated
|
|
||
| 如之前所述，信号是由系统产生的输出数据，人类或机器可以从中推断内容。这些信号是什么会因为系统而异，也取决于你想要达成的目标。它可能是你想要在某个时刻测量的东西，例如温度或者 RAM usage，或者在分布式系统中你想要追踪的众多组件发生的事件。你可能想知道在某个随机时间点，系统的哪个功能消耗了较多的 CPU、Mem 或者磁盘等资源，或者在特定的时间点，系统是如何崩溃的。虽然一些信号可能一起来还原业务现场，但是其他信号在系统的某些方面非常专业。他们可以一起使用，提供观察同一个技术的不同方式。或者正如我们对初学者的建议，你可以从一个或几个信号开始，然后逐步完善其他技术。 | ||
|
|
||
| 你可能听过"可观测性三大支柱”， 即 metrics, logs, traces. 我们喜欢把它们当作是"主要的信号量"，而不是"三大支柱"，原因有两个：（1）支柱隐含的意义是如果有一个缺失，整个结构就会蜕化而崩溃，这是不正确的。人们可以安全的使用两个甚至于一个信号, 仍然可以实现可观测性目标。（2）去年开始，越来越多的信号在开源社区流行起来，比如 applicaiton profiles 和 crash dumps，而现存的工具和方法仍旧不能满足科技行业的所有需求。在不久的将来可能会出现新的信号，对这个话题感兴趣的人应该密切关注。 |
There was a problem hiding this comment.
Suggested change
| 你可能听过"可观测性三大支柱”， 即 metrics, logs, traces. 我们喜欢把它们当作是"主要的信号量"，而不是"三大支柱"，原因有两个：（1）支柱隐含的意义是如果有一个缺失，整个结构就会蜕化而崩溃，这是不正确的。人们可以安全的使用两个甚至于一个信号, 仍然可以实现可观测性目标。（2）去年开始，越来越多的信号在开源社区流行起来，比如 applicaiton profiles 和 crash dumps，而现存的工具和方法仍旧不能满足科技行业的所有需求。在不久的将来可能会出现新的信号，对这个话题感兴趣的人应该密切关注。 | |
| 你可能听过"可观测性三大支柱”， 即 metrics, logs, traces. 我们喜欢把它们当作是"主要的信号"，而不是"三大支柱"，原因有两个：（1）支柱隐含的意义是如果有一个缺失，整个结构就会蜕化而崩溃，这是不正确的。人们可以安全的使用两个甚至于一个信号, 仍然可以实现可观测性目标。（2）去年开始，越来越多的信号在开源社区流行起来，比如 applicaiton profiles 和 crash dumps，而现存的工具和方法仍旧不能满足科技行业的所有需求。在不久的将来可能会出现新的信号，对这个话题感兴趣的人应该密切关注。 |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| ### Metrics | ||
|
|
||
| Metrics是数据的数值表现。他们主要分为两类: 已经是数值的数据和被转换为数值的数据。前者的典型案例是 温度，后者则是过程的计数。这与 logs 或者 traces 不同，后者侧重于单个事件的记录或信息。 |
There was a problem hiding this comment.
Suggested change
| Metrics是数据的数值表现。他们主要分为两类: 已经是数值的数据和被转换为数值的数据。前者的典型案例是 温度，后者则是过程的计数。这与 logs 或者 traces 不同，后者侧重于单个事件的记录或信息。 | |
| Metrics是数据的数值表现。他们主要分为两类: 已经是数值的数据和被转换为数值的数据。前者的典型案例是 温度，后者则是 process counter。这与 logs 或者 traces 不同，后者侧重于单个事件的记录或信息。 |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| 日志在不同的场景下都很有用 - metrics, traces, 安全, debug。保存关于应用和系统相关的所有事件记录，可以确定甚至重现出导致出现特定情况的分步操作。这些记录在去做根因分析时非常有价值，这些分析提供了在故障发生时，了解应用或者系统的信息。 | ||
|
|
||
| 存储在日志中的信息与文本内容无关，所以很难从中获取到有意义的信息。在过去的 30 年里，很多人尝试将 schema 应用到日志里，但是都没有特别成功。原因在于 schema 让提供一些相关信息变得更加容易。 一般是将日志文件中的文本信息通过解析、分段 和分析来实现的。日志里的数据也可以转换成其他的可观测性信号，包括 metrics 和 traces。一旦数据被转换为 metrics，就可以用来了解随着时间变化的内容。日志数据还可以通过日志分析技术来进行可视化和分析。 |
There was a problem hiding this comment.
Suggested change
| 存储在日志中的信息与文本内容无关，所以很难从中获取到有意义的信息。在过去的 30 年里，很多人尝试将 schema 应用到日志里，但是都没有特别成功。原因在于 schema 让提供一些相关信息变得更加容易。 一般是将日志文件中的文本信息通过解析、分段 和分析来实现的。日志里的数据也可以转换成其他的可观测性信号，包括 metrics 和 traces。一旦数据被转换为 metrics，就可以用来了解随着时间变化的内容。日志数据还可以通过日志分析技术来进行可视化和分析。 | |
| 存储在日志中的信息与文本内容无关，所以很难从中获取到有意义的信息。在过去的30年里，很多人尝试将 schema 应用到日志里，但是都没有特别成功。原因在于 schema 让提供一些相关信息变得更加容易。 一般是将日志文件中的文本信息通过解析、分段 和分析来实现的。日志里的数据也可以转换成其他的可观测性信号，包括 metrics 和 traces。一旦数据被转换为 metrics，就可以用来了解随着时间变化的内容。日志数据还可以通过日志分析技术来进行可视化和分析。 |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| ### 实现多信号的可观测性 | ||
|
|
||
| 具备多信号的可观测性是可行的，已经有很多人实现了他。然而，当你后退一步去查看实现这一目标必须做些什么的时候，你会发现一些主要的挑战、错失掉的机会/效率低下: |
There was a problem hiding this comment.
Suggested change
| 具备多信号的可观测性是可行的，已经有很多人实现了他。然而，当你后退一步去查看实现这一目标必须做些什么的时候，你会发现一些主要的挑战、错失掉的机会/效率低下: | |
| 具备多信号的可观测性是可行的，已经有很多人实现了它。然而，当你后退一步去查看实现这一目标必须做些什么的时候，你会发现一些主要的挑战、错失掉的机会或者低效率: |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
|  | ||
|
|
||
| 虽然这种级别的相互联系对于某些用例来说已经足够好了，但我们可能忽略了一个重要的问题：大规模集群下的系统。在这样的系统中，程序不会处理少量的请求。他们为完全不同的目的请求和小伙执行数万亿次操作。 即便我们可以从单个进程中获取到所有的 logs 和 traces，即使是一秒钟，如何从但是正在处理的数千个并发请求中到与你的目标相关的请求、操作或者 trace id。强大的 logging 语言 [LogQL](https://grafana.com/docs/loki/latest/logql/) 允许你筛选 logs 用于获取 log level、error statuses, message, code file等详细信息。但是，这要求你了解可用字段、格式以及它是如何映射到处理过程中的。 |
There was a problem hiding this comment.
Suggested change
| 虽然这种级别的相互联系对于某些用例来说已经足够好了，但我们可能忽略了一个重要的问题：大规模集群下的系统。在这样的系统中，程序不会处理少量的请求。他们为完全不同的目的请求和小伙执行数万亿次操作。 即便我们可以从单个进程中获取到所有的 logs 和 traces，即使是一秒钟，如何从但是正在处理的数千个并发请求中到与你的目标相关的请求、操作或者 trace id。强大的 logging 语言 [LogQL](https://grafana.com/docs/loki/latest/logql/) 允许你筛选 logs 用于获取 log level、error statuses, message, code file等详细信息。但是，这要求你了解可用字段、格式以及它是如何映射到处理过程中的。 | |
| 虽然这种级别的相互联系对于某些用例来说已经足够好了，但我们可能忽略了一个重要的问题：大规模集群下的系统。在这样的系统中，程序不会处理少量的请求。他们为完全不同的目的请求和小伙执行数万亿次操作。 即便我们可以从单个进程中获取到所有的 logs 和 traces，但是如何从正在处理的数千个并发请求中得到与你的目标相关的请求、操作或者 trace id， 即使是一秒钟的数据量？强大的 logging 语言 [LogQL](https://grafana.com/docs/loki/latest/logql/) 允许你筛选 logs 用于获取 log level、error statuses, message, code file等详细信息。但是，这要求你了解可用字段、格式以及它是如何映射到处理过程中的。 |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| 如果针对某些 endpoint 的大量错误或者高延迟的警报让你知道所有受影响的 request IDs，不是一件更好的事儿吗？这样的警报可能基于 _metrics_并且这类 metrics 在某些请求流期间增加，很可能这时候也产生了 _logs 或 traces_，并且为其也分配了 _request, operation 或 trace ID_, 对吗? | ||
|
|
||
| 这听起来很棒，但正如我们所知，这些 metrics 或者聚合多个请求结果的 logs 在设计上是聚合的。因为成本和关注点的原因，我们不能通过聚合中的所有(有时候是数千个)请求 ID，但有一个是有用的事实，关于这些我们可以利用的请求，有一个有用的事实。 在这样的一个聚合 metrics 或 logs 的上下文中，所有相关的请求 ..... 有点儿相等! 因此，可能不需要保留所有的 ID，我们可以只附加上一个，代表一类实例的案例。这就是我们所说的 _exemplar_. |
There was a problem hiding this comment.
Suggested change
| 这听起来很棒，但正如我们所知，这些 metrics 或者聚合多个请求结果的 logs 在设计上是聚合的。因为成本和关注点的原因，我们不能通过聚合中的所有(有时候是数千个)请求 ID，但有一个是有用的事实，关于这些我们可以利用的请求，有一个有用的事实。 在这样的一个聚合 metrics 或 logs 的上下文中，所有相关的请求 ..... 有点儿相等! 因此，可能不需要保留所有的 ID，我们可以只附加上一个，代表一类实例的案例。这就是我们所说的 _exemplar_. | |
| 这听起来很棒，但正如我们所知，这些 metrics 或者聚合多个请求结果的 logs 在设计上是聚合的。因为成本和关注点的原因，我们不能通过聚合中的所有(有时候是数千个)请求 ID，但有一个是有用的事实，关于这些我们可以利用的请求，有一个有用的事实。 在这样的一个聚合 metrics 或 logs 的上下文中，所有相关的请求 ..... 有点儿相等! 因此，可能不需要保留所有的 ID，我们可以只附加上一个，代表一类实例的案例。这就是我们所说的 _exemplar_。 |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| Exemplars 在开源领域有点儿新颖，所以让我们来看看目前有哪些可能的，以及如何去采用他们。向 log 系统添加 exemplar 是非常简单的，我们可以以 `exemplar-request=<traceID>` key-value 的格式为聚合多个请求的 logs 添加一个 exemplar。 | ||
|
|
||
| 为 metrics 系统添加 exemplars 则是另外一回事儿了，可能值得我将来单独去写一篇文章，但是你可以想象，我们通常不能直接将 request ID 或 trace ID 立即添加到 metrics series 元数据中(例如 prometheus labels)。 这是因为它会用一个 sample 创建另外一个具备一次性、独特的 series(导致没有边界的 "基数")。然而，在开源中，最近我们可以使用[OpenMetrics 称为 Exemplar](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#exemplars) 定义的一种相当新颖的模式。他是可以附加到 (任何) series sample中去，在主(高度indexed)标签之外的内容。 这是它在 Open Metrics 文本格式中的样子, 如Prometheus： |
There was a problem hiding this comment.
Suggested change
| 为 metrics 系统添加 exemplars 则是另外一回事儿了，可能值得我将来单独去写一篇文章，但是你可以想象，我们通常不能直接将 request ID 或 trace ID 立即添加到 metrics series 元数据中(例如 prometheus labels)。 这是因为它会用一个 sample 创建另外一个具备一次性、独特的 series(导致没有边界的 "基数")。然而，在开源中，最近我们可以使用[OpenMetrics 称为 Exemplar](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#exemplars) 定义的一种相当新颖的模式。他是可以附加到 (任何) series sample中去，在主(高度indexed)标签之外的内容。 这是它在 Open Metrics 文本格式中的样子, 如Prometheus： | |
| 为 metrics 系统添加 exemplars 则是另外一回事儿了，可能值得我将来单独去写一篇文章，但是你可以想象，我们通常不能直接将 request ID 或 trace ID 立即添加到 metrics series 元数据中(例如 prometheus labels)。 这是因为它会用一个 sample 创建另外一个具备一次性、独特的 series(导致没有边界的 "基数")。然而，在开源中，最近我们可以使用[OpenMetrics 称为 Exemplar](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#exemplars) 定义的一种相当新颖的模式。它是可以附加到 (任何) series sample中去，在主(高度indexed)标签之外的内容。 这是它在 Open Metrics 文本格式中的样子, 如Prometheus： |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
| foo_created 1520430000.123 | ||
| ``` | ||
|
|
||
| 一旦定义好, 他们就会被 OpenMetrics 兼容的抓取工具(例如 Prometheus)与 metrics samples(确保在你的 客户端埋点启用 OpenMetrics 格式) 一起被抓取. 之后，你可方便的通过由 [Prometheus 社区定义的 _Exemplars API_](https://prometheus.io/docs/prometheus/latest/querying/api/#querying-exemplars)来查询这些样本: |
There was a problem hiding this comment.
Suggested change
| 一旦定义好, 他们就会被 OpenMetrics 兼容的抓取工具(例如 Prometheus)与 metrics samples(确保在你的 客户端埋点启用 OpenMetrics 格式) 一起被抓取. 之后，你可方便的通过由 [Prometheus 社区定义的 _Exemplars API_](https://prometheus.io/docs/prometheus/latest/querying/api/#querying-exemplars)来查询这些样本: | |
| 一旦定义好, 它们就会被 OpenMetrics 兼容的抓取工具(例如 Prometheus)与 metrics samples(确保在你的 客户端埋点启用 OpenMetrics 格式) 一起被抓取. 之后，你可方便的通过由 [Prometheus 社区定义的 _Exemplars API_](https://prometheus.io/docs/prometheus/latest/querying/api/#querying-exemplars)来查询这些样本: |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
|  | ||
|
|
||
| ### 可观测性数据上的告警 |
There was a problem hiding this comment.
Suggested change
| ### 可观测性数据上的告警 | |
| ### 可观测数据告警 |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| 对损耗率发出告警是一种更加复杂的方法，可能会产生更多可以操作的告警。首先，让我们先更详细的定义什么是 消耗率和错误预算。 | ||
|
|
||
| 所有 SLO 定义中都有一个错误预算的概念。通过声明 99.9% 的 SLO， 你表示的是 0.1% 的故障率(即你的错误预算)对于预定义的时间 (SLO窗口) 是可以接受的。消耗率是相对于 SLO，服务消耗错误预算的速度。所以，例如，如果由一个 "服务使用的消耗率为1，则意味着它消耗错误预算的速度使你在 SLO 的时间窗口结束的时候，预算恰好为0"。在30天的时间窗口内，SLO 为99.9%。 0.1% 的恒定错误率恰好使用了所有的错误预算：消耗率为1。[8] |
There was a problem hiding this comment.
Suggested change
| 所有 SLO 定义中都有一个错误预算的概念。通过声明 99.9% 的 SLO， 你表示的是 0.1% 的故障率(即你的错误预算)对于预定义的时间 (SLO窗口) 是可以接受的。消耗率是相对于 SLO，服务消耗错误预算的速度。所以，例如，如果由一个 "服务使用的消耗率为1，则意味着它消耗错误预算的速度使你在 SLO 的时间窗口结束的时候，预算恰好为0"。在30天的时间窗口内，SLO 为99.9%。 0.1% 的恒定错误率恰好使用了所有的错误预算：消耗率为1。[8] | |
| 所有 SLO 定义中都有一个错误预算的概念。通过声明 99.9% 的 SLO， 你表示的是 0.1% 的故障率(即你的错误预算)对于预定义的时间 (SLO窗口) 是可以接受的。消耗率是相对于 SLO，服务消耗错误预算的速度。所以，例如，如果由一个 “服务使用的消耗率为1，则意味着它消耗错误预算的速度使你在 SLO 的时间窗口结束的时候，预算恰好为0。在30天的时间窗口内，SLO 为99.9%。 0.1% 的恒定错误率恰好使用了所有的错误预算：消耗率为1”。[8] |
JohnWu20
reviewed
Aug 12, 2021
whitepaper-zh.md
Outdated
|
|
||
| 尚未添加的功能是 增加用于记录规则和告警的 exemplars 的能力，这些可能附加 exemplars 的情况下聚合更多的 metrics。这个提议已经被提出来了，但是工作尚未完成。同样，我们为 Prometheus 的进一步迭代讨论的 向下采样技术必须考虑 向下采样 exemplars。 | ||
|
|
||
| * 在 UI 中的本地关联支持. |
There was a problem hiding this comment.
Suggested change
| * 在 UI 中的本地关联支持. | |
| * 在 UI 中的本地关联支持。 |
JohnWu20
reviewed
Aug 12, 2021
Yes, we should keep to the same style. This is my oversight and I will fix it in the next commit. Thank you for your advice and patience. ♥ |
|
@JohnWu20 @lichunli-amzn Some minor bugs that were not easily detect have been fixed. If you have time, could you review it? Thanks a lot. |
|
That's amazing job! My worry for now is that we still have review period for English version, so it might change a bit. However this gives amazing value already, so maybe we can merge and iterate? 🤗 |
Direct PR is great, let's have at least one LGTM from Chinese speaker/reader contributor then we can merge (: |
|
cc @JohnWu20 @raptorsun can you help? (: |
yup 😉 |
|
Sure, will review later today! |
lubingfeng
reviewed
Sep 7, 2021
whitepaper-zh.md
Outdated
| * 基础设施工程师 | ||
| * 软件开发者 | ||
|
|
||
| 这篇 paper 涉及到上述的角色，是希望可以交付既具备可观测性和与客户现存的可观测系统集成的软件，同时达到可以证明可靠性，安全性和透明度的水平。负责设计和实现这类软件的其他人员，例如项目经理、产品经理和架构师，也可能对这篇 paper 感兴趣。因为可观测性是一个多学科主题，计算机科学、信息系统、工程学(或相关学科)的学生和对可观测性领域感兴趣的人也可以在这里找到有用的信息。 |
whitepaper-zh.md
Outdated
|
|
||
| 云计算帮助了大小不一的科技公司优化了成本、规模，并设计出更加高效的产品，但同时也带来了复杂性。由于基础设施变成远程的、短暂的、全球分布，系统管理员不再像以前那样对数据中心拥有较强的的控制力。以前存在和拥有管理员及开发者目标不一致的企业文化的公司，是时候做出改变了，他们现在必须作为一个单一的团队一起工作，以此来构建可靠的软件。 | ||
|
|
||
| 在可观测性系统的设计以及开发中，他需要将遥感测试数据发送或暴露给第三方，通常是一套工具集，负责从暴露出的这些数据中提取出有意义的信息。遥感数据通常以 metrics 、 logs、traces、具备结构化的 events，profiles 和系统崩溃时候的 dumps 文件的形式出现，这些数据被软件工程团队长期使用。 |
whitepaper-zh.md
Outdated
|
|
||
| 毫无疑问，可观测性是当今系统的一个令人向往的特性。每个人都在说，对吧？你们当中的一些人可能已经开始了你的可观测旅程，而其他人正在阅读这份儿白皮书，因为每个人都在说你应该让你的系统具备可观测性。事实上，"可观测性"已经成为一个流行的词汇，就像其他的词汇一样，每个人都希望在提议它的同时再其之上留下自己的印记，你听到的可能和他的起源有一些不同的定义。如果你想让你的游戏更具备可观测性，让我们来试着明确它的最初目的。 | ||
|
|
||
| ”在控制理论中，可观测性是一种如何从当前外部输出的知识中推断衡量其内部状态的一种方法“[9]。它是一个系统系统的功能, 通过这个系统, 人类以及可以观测、理解并依据当前系统的状态做出不同的举动.。所以是的, 从定义上来看很简单，但是在没有目标的情况下，决定系统应该有哪些输出就变得及其复杂了，那时候就开始变得糟糕了. |
whitepaper-zh.md
Outdated
|
|
||
|  | ||
|
|
||
| 所有的信号都有不同的收集和测量方式，他们花费不同的资源来获取、存储和分析。同时提供不同的方法来观测相同的系统。选择其中一部分或者全部选择，就像工程学中的其他任务一样，是一个权衡的游戏。在下一节中, 我们将深入研究每个信号, 从人们最喜欢的 metrics，logs 和 traces 开始，然后是两个存在可能性的新的信号: applicaiton profiles 和 crash dumps。 |
There was a problem hiding this comment.
我没有修改这句, 我觉得这里用 applicaiton 还是比较好一点。@lubingfeng 你觉得呢。
There was a problem hiding this comment.
why not？applicaiton is not even a word.
There was a problem hiding this comment.
才发现多了一个字母 applicaiton -> application
whitepaper-zh.md
Outdated
| 日志级别是可以用来标识每条日志数据的重要性。其中一组日志级别是 ERROR，INFO 和 DEBUG。其中 ERROR 是最不详细的日志级别，DEBUG 则是最详细的日志级别。 | ||
|
|
||
| 1. __ERROR__ 传递故障发生的原因以及相关详细信息。 | ||
| 2. __WARNING__ 是一个需要注意的高级别消息, 虽然它不是一个失败。 |
raptorsun
reviewed
Sep 8, 2021
whitepaper-zh.md
Outdated
| @@ -0,0 +1,553 @@ | |||
| # 可观测性白皮书 | |||
|
|
|||
| _这是一项正在进行的工作。_ 从事于白皮书工作的的人们, 请在 [Issues](https://github.com/cncf/tag-observability/issues/new) 和 [Pull Requests](https://github.com/cncf/tag-observability/pulls) 探讨白皮书。 讨论正发生在 [CNCF’s slack](https://slack.cncf.io/) (#tag-observability channel)中。 | |||
There was a problem hiding this comment.
建议译为：
本白皮书正在编撰中。请编撰者在Issues 和 Pull Requests 讨论相关事宜。 实时讨论请移步 CNCF’s slack (#tag-observability channel)。
raptorsun
reviewed
Sep 8, 2021
whitepaper-zh.md
Outdated
|
|
||
| ## 概要 | ||
|
|
||
| 随着系统复杂度以及每时每刻我们需要处理的数据不断增长，我们需要更好的可观测性来让我们明确当前系统的负载状态。在可观测性工具之上，现在更多的是希望每个负责将软件作为服务运行的工程师都能够理解如何去监视和观察他们的应用程序。更高的用户期望和更严格的服务水平目标， 工程师们相比以前，需要更快的 debug并找到问题的根本原因。 |
There was a problem hiding this comment.
建议译为：
随着系统复杂度以及数据处理量不断增长，为了了解系统的负载状态，我们需要系统有更好的可观测性。除了使用工具提高可观测性之外，运营软件服务的工程师们被越来越多地要求深入理解如何监控他们负责的应用程序。 面对用户更高的期望和更严格的服务水平要求（SLO）， 工程师们必须要更快地排除故障并找到问题的根本原因。
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
|
|
||
| ## 可贡献内容 | ||
|
|
||
| 这份白皮书仍然不是完整的！如果你想帮助我们，我们仍然想包括以下几个主题： |
There was a problem hiding this comment.
Suggested change
| 这份白皮书仍然不是完整的！如果你想帮助我们，我们仍然想包括以下几个主题： | |
| 本白皮书仍有待完善！我们需要您的帮助来完成以下几个主题： |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
|
|
||
| 这份白皮书仍然不是完整的！如果你想帮助我们，我们仍然想包括以下几个主题： | ||
|
|
||
| * *提高你的可观测性——“投资回报”* - 实现细粒度的可观测性可能非常的昂贵，尤其是如果做的很天真。通常， 我们建议从简单开始，并使用更多的信号、更多粒度和数据大小进行迭代。让我们在新的章节中讨论这些建议。我们还列举了我们应如何迭代以及必须满足哪些标准才能进行可观测性扩展。 |
There was a problem hiding this comment.
Suggested change
| * *提高你的可观测性——“投资回报”* - 实现细粒度的可观测性可能非常的昂贵，尤其是如果做的很天真。通常， 我们建议从简单开始，并使用更多的信号、更多粒度和数据大小进行迭代。让我们在新的章节中讨论这些建议。我们还列举了我们应如何迭代以及必须满足哪些标准才能进行可观测性扩展。 | |
| * *提高你的可观测性——“投资回报比”* - 实现细粒度的可观测性可能代价高昂，尤其是设计中缺乏周到考虑的时候。 我们建议从简单开始，并使用更多的信号、更多粒度和数据大小进行迭代。让我们在新的章节中讨论这些建议。我们还列举了我们应如何迭代以及必须满足哪些标准才能进行可观测性扩展。 |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
|
|
||
| * *提高你的可观测性——“投资回报”* - 实现细粒度的可观测性可能非常的昂贵，尤其是如果做的很天真。通常， 我们建议从简单开始，并使用更多的信号、更多粒度和数据大小进行迭代。让我们在新的章节中讨论这些建议。我们还列举了我们应如何迭代以及必须满足哪些标准才能进行可观测性扩展。 | ||
| * 用户案例 | ||
| * *数据可视化和探索* - 构建仪表盘非常容易，但是构建“好的” 仪表盘是另外一回事。我们先告诉您构建仪表盘的最佳时间，并解释如何依据我们想要实现的目标不同而选择不同的构建方式。例如，分析例是数据，实时监控。 |
There was a problem hiding this comment.
Suggested change
| * *数据可视化和探索* - 构建仪表盘非常容易，但是构建“好的” 仪表盘是另外一回事。我们先告诉您构建仪表盘的最佳时间，并解释如何依据我们想要实现的目标不同而选择不同的构建方式。例如，分析例是数据，实时监控。 | |
| * *数据可视化和探索* - 构建仪表盘非常容易，但是构建“好的” 仪表盘是另外一回事。我们先告诉您构建仪表盘的最佳实践，并解释如何依据目标的具体情况而选择合适的构建方式。例如：分析历史数据，实时监控。 |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
| * *提高你的可观测性——“投资回报”* - 实现细粒度的可观测性可能非常的昂贵，尤其是如果做的很天真。通常， 我们建议从简单开始，并使用更多的信号、更多粒度和数据大小进行迭代。让我们在新的章节中讨论这些建议。我们还列举了我们应如何迭代以及必须满足哪些标准才能进行可观测性扩展。 | ||
| * 用户案例 | ||
| * *数据可视化和探索* - 构建仪表盘非常容易，但是构建“好的” 仪表盘是另外一回事。我们先告诉您构建仪表盘的最佳时间，并解释如何依据我们想要实现的目标不同而选择不同的构建方式。例如，分析例是数据，实时监控。 | ||
| * 围绕可观测性的空白 |
There was a problem hiding this comment.
Suggested change
| * 围绕可观测性的空白 | |
| *可观测性领域的空白 |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
| * 用户案例 | ||
| * *数据可视化和探索* - 构建仪表盘非常容易，但是构建“好的” 仪表盘是另外一回事。我们先告诉您构建仪表盘的最佳时间，并解释如何依据我们想要实现的目标不同而选择不同的构建方式。例如，分析例是数据，实时监控。 | ||
| * 围绕可观测性的空白 | ||
| * *机器学习、异常检测和分析*。 - 关于机器学习/分析 在可观测性领域是否有用，存在一些非常强烈和反对的意见，我们需要有经验的人向社区解释他在哪里以及为什么有用，在哪里以及为什么不能用。 |
There was a problem hiding this comment.
Suggested change
| * *机器学习、异常检测和分析*。 - 关于机器学习/分析 在可观测性领域是否有用，存在一些非常强烈和反对的意见，我们需要有经验的人向社区解释他在哪里以及为什么有用，在哪里以及为什么不能用。 | |
| * *机器学习、异常检测和分析*。 - 关于机器学习/分析 在可观测性领域是否有用，存在一些非常强烈和反对的意见，我们需要有经验的人向社区解释应该用在哪里以及为什么有用，不应该用在哪里以及为什么不能用。 |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
| * *数据可视化和探索* - 构建仪表盘非常容易，但是构建“好的” 仪表盘是另外一回事。我们先告诉您构建仪表盘的最佳时间，并解释如何依据我们想要实现的目标不同而选择不同的构建方式。例如，分析例是数据，实时监控。 | ||
| * 围绕可观测性的空白 | ||
| * *机器学习、异常检测和分析*。 - 关于机器学习/分析 在可观测性领域是否有用，存在一些非常强烈和反对的意见，我们需要有经验的人向社区解释他在哪里以及为什么有用，在哪里以及为什么不能用。 | ||
| * *监控流 APIs* - 目前有两种非常知名的监控方法。USE方法监控计算资源，RED 方法监控基于请求的服务。这两种方法都不适用于流式 APIs，随着远程过程调用 (RPC) 的普及，我们需要提出一种明确的方法去监控他们。 |
There was a problem hiding this comment.
Suggested change
| * *监控流 APIs* - 目前有两种非常知名的监控方法。USE方法监控计算资源，RED 方法监控基于请求的服务。这两种方法都不适用于流式 APIs，随着远程过程调用 (RPC) 的普及，我们需要提出一种明确的方法去监控他们。 | |
| * *监控流 APIs* - 目前有两种非常知名的监控方法。USE方法监控计算资源，RED 方法监控基于请求的服务。这两种方法都不适用于流式 APIs，随着远程过程调用 (RPC) 的普及，我们需要提出一种明确的方法论去监控他们。 |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
| * 围绕可观测性的空白 | ||
| * *机器学习、异常检测和分析*。 - 关于机器学习/分析 在可观测性领域是否有用，存在一些非常强烈和反对的意见，我们需要有经验的人向社区解释他在哪里以及为什么有用，在哪里以及为什么不能用。 | ||
| * *监控流 APIs* - 目前有两种非常知名的监控方法。USE方法监控计算资源，RED 方法监控基于请求的服务。这两种方法都不适用于流式 APIs，随着远程过程调用 (RPC) 的普及，我们需要提出一种明确的方法去监控他们。 | ||
| * *eBPF* - eBPF 是一项革命性的技术，可以在 Linux 内核中运行沙箱程序，而无需更改内核源码或者加载内核模块。通过一些创新，他可以帮助我们实现长期以来的梦想，即在不增加额外的仪器情况下去观测系统。尽管这种可能性无穷无尽，但是 eBPF 并不是那么受欢迎。我们想告诉读者 eBPF 和 相关工具是如何改变可观测性领域的游戏规则，以及为什么他们仍然不是那么受欢迎。 |
There was a problem hiding this comment.
Suggested change
| * *eBPF* - eBPF 是一项革命性的技术，可以在 Linux 内核中运行沙箱程序，而无需更改内核源码或者加载内核模块。通过一些创新，他可以帮助我们实现长期以来的梦想，即在不增加额外的仪器情况下去观测系统。尽管这种可能性无穷无尽，但是 eBPF 并不是那么受欢迎。我们想告诉读者 eBPF 和 相关工具是如何改变可观测性领域的游戏规则，以及为什么他们仍然不是那么受欢迎。 | |
| * *eBPF* - eBPF 是一项革命性的技术，可以在 Linux 内核中运行沙箱程序，而无需更改内核源码或者加载内核模块。通过一些创新，他可以帮助我们实现长期以来的梦想，即在不增加额外的监控点情况下去观测系统。尽管有无限可能，但是 eBPF 还未被广泛应用。我们想告诉读者 eBPF 和 相关工具是如何改变可观测性领域的游戏规则，以及为什么他们仍为被广泛使用。 |
raptorsun
reviewed
Sep 9, 2021
whitepaper-zh.md
Outdated
| * *机器学习、异常检测和分析*。 - 关于机器学习/分析 在可观测性领域是否有用，存在一些非常强烈和反对的意见，我们需要有经验的人向社区解释他在哪里以及为什么有用，在哪里以及为什么不能用。 | ||
| * *监控流 APIs* - 目前有两种非常知名的监控方法。USE方法监控计算资源，RED 方法监控基于请求的服务。这两种方法都不适用于流式 APIs，随着远程过程调用 (RPC) 的普及，我们需要提出一种明确的方法去监控他们。 | ||
| * *eBPF* - eBPF 是一项革命性的技术，可以在 Linux 内核中运行沙箱程序，而无需更改内核源码或者加载内核模块。通过一些创新，他可以帮助我们实现长期以来的梦想，即在不增加额外的仪器情况下去观测系统。尽管这种可能性无穷无尽，但是 eBPF 并不是那么受欢迎。我们想告诉读者 eBPF 和 相关工具是如何改变可观测性领域的游戏规则，以及为什么他们仍然不是那么受欢迎。 | ||
| * *观测短暂存活的系统*。- Faas/Serveless 空间的可观测性仍然很弱，我们想告诉我们的读者为什么观测这种系统是如此的困难。基于 pull 和 push 模型如何与他们进行交互，以及为什么性能开销一直是一个问题。 |
There was a problem hiding this comment.
Suggested change
| * *观测短暂存活的系统*。- Faas/Serveless 空间的可观测性仍然很弱，我们想告诉我们的读者为什么观测这种系统是如此的困难。基于 pull 和 push 模型如何与他们进行交互，以及为什么性能开销一直是一个问题。 | |
| * *观测短暂存活的系统*。- Faas/Serveless 领域的可观测性仍然很弱，我们想解释给读者为什么观测这种系统是如此的困难。基于 pull 和 push 模型如何与他们进行交互，以及为什么性能开销一直是一个问题。 |
raptorsun
reviewed
Sep 9, 2021
| [Simone Ferlin]: https://github.com/sferlin | ||
| [Tim Tischler]: @ | ||
| [Wiard van Rjj]: https://github.com/wiardvanrij | ||
|
|
There was a problem hiding this comment.
@raptorsun 我在下面加上了中文翻译贡献者，你看下是否可以 😀。
|
@chenmudu @lubingfeng @JohnWu20 @lichunli-amzn 我的修改建议都提完了。有劳各位再校对一下。 |
🎉 This update fixes everyone's suggestions. Thanks a lot. If there are no other problems, I think we can use LGTM to promote the merger of this pull request. ❤ |
raptorsun
reviewed
Sep 10, 2021
whitepaper-zh.md
Outdated
|
|
||
| 在构建应用的时候，我们要为外部实体的观测提供便利，这个外部实体可以是另一个应用，也可以是一个不在数据中心内部的人员。这需要在程序构建的早期阶段就开始考虑，这通常意味着编写更多的代码，自动化基础设施的操作，还有对关键指标的监控。 对于多数组织而言，这种工作理念和流程的转换往往充满挑战、困难重重。 尽管如此，市面上有很多工具和方案能从不同的角度把软件的可观测性提高到一个合理的水平。 | ||
|
|
||
| learPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始提高他们系统的可观测性努力”以及在“就目前的趋势看来，越来越多的人把提高可观测性作为他们系统设计的目标之一”。能够系统的可观测能力能够达到了一个令人满意的水平，这带来的益处是显而易见的。不过，着手构建高可观测行的系统绝非一日之功。工作理念的改变，工具、目标、工作方法的变化，诸如此类细节都需要考虑到位，进而增加了项目的难度。这篇白皮书旨在提供清晰的说明，以便更多的软件开发和运维团队可以从提高他们系统的可观测性中获益。 |
There was a problem hiding this comment.
少个C
Suggested change
| learPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始提高他们系统的可观测性努力”以及在“就目前的趋势看来，越来越多的人把提高可观测性作为他们系统设计的目标之一”。能够系统的可观测能力能够达到了一个令人满意的水平，这带来的益处是显而易见的。不过，着手构建高可观测行的系统绝非一日之功。工作理念的改变，工具、目标、工作方法的变化，诸如此类细节都需要考虑到位，进而增加了项目的难度。这篇白皮书旨在提供清晰的说明，以便更多的软件开发和运维团队可以从提高他们系统的可观测性中获益。 | |
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始提高他们系统的可观测性努力”以及在“就目前的趋势看来，越来越多的人把提高可观测性作为他们系统设计的目标之一”。能够系统的可观测能力能够达到了一个令人满意的水平，这带来的益处是显而易见的。不过，着手构建高可观测行的系统绝非一日之功。工作理念的改变，工具、目标、工作方法的变化，诸如此类细节都需要考虑到位，进而增加了项目的难度。这篇白皮书旨在提供清晰的说明，以便更多的软件开发和运维团队可以从提高他们系统的可观测性中获益。 |
谢谢老兄这么及时的修改。 最后Merge前把 Clearpath的首字母 C 加上就好了。 👍 |
|
This is so impressive! Thanks a lot to everyone that worked on the translation ❤️ From my side, I think it is fine to merge (if all translators have already approved). As we modify the original, I'll ping you folks to change the Chinese version too. Does that sound reasonable? |
|
Thanks @ArthurSens and I'm glad to see this coming together! |
Chinese version should change with the original version, I am happy to do so, please feel free to @chenmudu . |
|
LGTM, I think it's time for us to merge this pr. @ArthurSens There hasn't been any problem feedback for several days. |
|
LGTM,cool. |
|
Maybe take another 👀 on my suggestions. @chenmudu @lichunli-amzn @raptorsun @JohnWu20 |
just1900
reviewed
Sep 23, 2021
whitepaper-zh.md
Outdated
|
|
||
| 在构建应用的时候，我们要为外部实体的观测提供便利，这个外部实体可以是另一个应用，也可以是一个不在数据中心内部的人员。这需要在程序构建的早期阶段就开始考虑，这通常意味着编写更多的代码，自动化基础设施的操作，还有对关键指标的监控。 对于多数组织而言，这种工作理念和流程的转换往往充满挑战、困难重重。 尽管如此，市面上有很多工具和方案能从不同的角度把软件的可观测性提高到一个合理的水平。 | ||
|
|
||
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始提高他们系统的可观测性努力”以及在“就目前的趋势看来，越来越多的人把提高可观测性作为他们系统设计的目标之一”。能够系统的可观测能力能够达到了一个令人满意的水平，这带来的益处是显而易见的。不过，着手构建高可观测行的系统绝非一日之功。工作理念的改变，工具、目标、工作方法的变化，诸如此类细节都需要考虑到位，进而增加了项目的难度。这篇白皮书旨在提供清晰的说明，以便更多的软件开发和运维团队可以从提高他们系统的可观测性中获益。 |
There was a problem hiding this comment.
Suggested change
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “ 75%的团队尚未开始或刚开始提高他们系统的可观测性努力”以及在“就目前的趋势看来，越来越多的人把提高可观测性作为他们系统设计的目标之一”。能够系统的可观测能力能够达到了一个令人满意的水平，这带来的益处是显而易见的。不过，着手构建高可观测行的系统绝非一日之功。工作理念的改变，工具、目标、工作方法的变化，诸如此类细节都需要考虑到位，进而增加了项目的难度。这篇白皮书旨在提供清晰的说明，以便更多的软件开发和运维团队可以从提高他们系统的可观测性中获益。 | |
| ClearPath Strategies 和 Honeycomb.io 进行的社区研究[4]报告显示 “75%的团队尚未开始或刚开始提高他们系统的可观测性”以及在“就目前的趋势看来，越来越多的人把提高可观测性作为他们系统设计的目标之一”。一旦系统的可观测能力能够达到一个令人满意的水平，这带来的益处是显而易见的。不过，着手构建高可观测性的系统绝非一日之功。工作理念的改变，工具、目标、工作方法的变化，诸如此类细节都需要考虑到位，进而增加了项目的难度。这篇白皮书旨在提供清晰的说明，以便更多的软件开发和运维团队可以从提高他们系统的可观测性中获益。 |
能够系统的可观测能力能够达到了一个令人满意的水平，语病
whitepaper-zh.md
Outdated
| * 基础设施工程师 | ||
| * 软件开发者 | ||
|
|
||
| 本白皮书可以帮助上述岗位的人员为客户交付一套既本身具有高度的可观测性，同时又能和客户已有的监控系统集成的，具有实用级的可靠性，安全性和透明度的软件产品。负责设计和实现这类软件的其他人员，例如项目经理、产品经理和架构师，也可能对这篇 白皮书 感兴趣。因为可观测性是一个多学科主题，计算机科学、信息系统、工程学(或相关学科)的学生和对可观测性领域感兴趣的人也可以在这里找到有用的信息。 |
There was a problem hiding this comment.
Suggested change
| 本白皮书可以帮助上述岗位的人员为客户交付一套既本身具有高度的可观测性，同时又能和客户已有的监控系统集成的，具有实用级的可靠性，安全性和透明度的软件产品。负责设计和实现这类软件的其他人员，例如项目经理、产品经理和架构师，也可能对这篇 白皮书 感兴趣。因为可观测性是一个多学科主题，计算机科学、信息系统、工程学(或相关学科)的学生和对可观测性领域感兴趣的人也可以在这里找到有用的信息。 | |
| 本白皮书可以帮助上述岗位的人员为客户交付一套既具有高度的可观测性，同时又能和客户已有的监控系统集成的，具有生产级的可靠性，安全性和透明度的软件产品。负责设计和实现这类软件的其他人员，例如项目经理、产品经理和架构师，也可能对这篇 白皮书 感兴趣。因为可观测性是一个多学科主题，计算机科学、信息系统、工程学(或相关学科)的学生和对可观测性领域感兴趣的人也可以在这里找到有用的信息。 |
感觉这样读起来更通顺一些
whitepaper-zh.md
Outdated
|
|
||
| ## 可观测性是什么 | ||
|
|
||
| 毫无疑问，可观测性是当今系统的一个令人向往的特性。每个人都在说，对吧？你们当中的一些人可能已经开始了你的可观测旅程，而其他人正在阅读这份儿白皮书，因为每个人都在说你应该让你的系统具备可观测性。事实上，“可观测性”已经成为一个流行的词汇，就像其他的词汇一样，每个人都希望在提议它的同时再其之上留下自己的印记，你听到的可能和他的起源有一些不同的定义。如果你想让你的游戏更具备可观测性，让我们来试着明确它的最初目的。 |
There was a problem hiding this comment.
Suggested change
| 毫无疑问，可观测性是当今系统的一个令人向往的特性。每个人都在说，对吧？你们当中的一些人可能已经开始了你的可观测旅程，而其他人正在阅读这份儿白皮书，因为每个人都在说你应该让你的系统具备可观测性。事实上，“可观测性”已经成为一个流行的词汇，就像其他的词汇一样，每个人都希望在提议它的同时再其之上留下自己的印记，你听到的可能和他的起源有一些不同的定义。如果你想让你的游戏更具备可观测性，让我们来试着明确它的最初目的。 | |
| 毫无疑问，可观测性是当今系统的一个令人向往的特性。每个人都在说，对吧？你们当中的一些人可能已经开始了你的可观测旅程，而其他人正在阅读这份儿白皮书，因为每个人都在说你应该让你的系统具备可观测性。事实上，“可观测性”已经成为一个流行的词汇，就像其他的词汇一样，每个人都希望在提议它的同时在其之上留下自己的印记，因此你听到的可能和它起初的含义有所不同。如果你想加深在可观测性上的理解，让我们先来试着明确它的最初目的。 |
If you're going to level up your game on observability, let's try to make it clear its original purpose.原文翻译有误
whitepaper-zh.md
Outdated
|
|
||
| 毫无疑问，可观测性是当今系统的一个令人向往的特性。每个人都在说，对吧？你们当中的一些人可能已经开始了你的可观测旅程，而其他人正在阅读这份儿白皮书，因为每个人都在说你应该让你的系统具备可观测性。事实上，“可观测性”已经成为一个流行的词汇，就像其他的词汇一样，每个人都希望在提议它的同时再其之上留下自己的印记，你听到的可能和他的起源有一些不同的定义。如果你想让你的游戏更具备可观测性，让我们来试着明确它的最初目的。 | ||
|
|
||
| “在控制论中，可观测性是衡量一个系统仅凭对其外部的输出来判断其内部运行状态的精确程度的指标。”[9]。通俗地讲，这是系统提供给人员或者机器用来观察理解系统状态并作出反应的功能。要实现这个定义上看似简单的”可观测性“， 对于缺乏明确目标的人而言，选取哪些系统输出的确是令人头疼的问题。 |
There was a problem hiding this comment.
Suggested change
| “在控制论中，可观测性是衡量一个系统仅凭对其外部的输出来判断其内部运行状态的精确程度的指标。”[9]。通俗地讲，这是系统提供给人员或者机器用来观察理解系统状态并作出反应的功能。要实现这个定义上看似简单的”可观测性“， 对于缺乏明确目标的人而言，选取哪些系统输出的确是令人头疼的问题。 | |
| “在控制论中，可观测性是衡量一个系统仅凭其外部的输出来判断其内部运行状态的精确程度的指标。”[9]通俗地讲，这是系统提供给人员或者机器用来观察理解系统状态并作出反应的功能。要实现这个定义上看似简单的”可观测性“，对于缺乏明确目标的人而言，选取哪些系统输出的确是令人头疼的问题。 |
whitepaper-zh.md
Outdated
|
|
||
| “在控制论中，可观测性是衡量一个系统仅凭对其外部的输出来判断其内部运行状态的精确程度的指标。”[9]。通俗地讲，这是系统提供给人员或者机器用来观察理解系统状态并作出反应的功能。要实现这个定义上看似简单的”可观测性“， 对于缺乏明确目标的人而言，选取哪些系统输出的确是令人头疼的问题。 | ||
|
|
||
| 在一开始的时候，抄袭别人的作品是很容易的，这是开源带来的好处之一，同时也是缺点之一。 在网上有很多这样的例子: helm charts, Ansible playbooks, Terraform modules。仅仅运行其中一个脚本, 你就可以在几分钟之内完成一套可观测性技术栈的搭建并让他运行起来。这很简单，对其他人来说也有用，所以对我也是有用的，对吗？ 我们并不是想要鼓励你不要使用这些脚本，但是你需要注意的是: 可观测性不仅仅是去使用这些看起来好看和闪亮的工具。你必须意识到你的系统会产生什么样的结果，更加重要的是，你需要在脑海里有一个目标。你可能会想：“ 噢, 我想收集这个特殊的数据, 因为你永远不知道, 可能在未来会需要它。” 然后你对另外一些数据有类似的想法，一个接着一个，然后你意识到你正在建立一个数据湖。 |
There was a problem hiding this comment.
Suggested change
| 在一开始的时候，抄袭别人的作品是很容易的，这是开源带来的好处之一，同时也是缺点之一。 在网上有很多这样的例子: helm charts, Ansible playbooks, Terraform modules。仅仅运行其中一个脚本, 你就可以在几分钟之内完成一套可观测性技术栈的搭建并让他运行起来。这很简单，对其他人来说也有用，所以对我也是有用的，对吗？ 我们并不是想要鼓励你不要使用这些脚本，但是你需要注意的是: 可观测性不仅仅是去使用这些看起来好看和闪亮的工具。你必须意识到你的系统会产生什么样的结果，更加重要的是，你需要在脑海里有一个目标。你可能会想：“ 噢, 我想收集这个特殊的数据, 因为你永远不知道, 可能在未来会需要它。” 然后你对另外一些数据有类似的想法，一个接着一个，然后你意识到你正在建立一个数据湖。 | |
| 在一开始的时候，抄袭别人的作品是很容易的，这是开源带来的好处之一，同时也是缺点之一。 在网上有很多这样的例子: helm charts, Ansible playbooks, Terraform modules。仅仅运行其中一个脚本, 你就可以在几分钟之内完成一套可观测性技术栈的搭建并让他运行起来。这很简单，对其他人来说也有用，所以对我也是有用的，对吗？ 我们并不是想要鼓励你不要使用这些脚本，但是你需要注意的是：可观测性不仅仅是去使用这些看似光鲜亮丽的工具。你必须意识到你的系统会产生什么样的结果，更加重要的是，你需要在脑海里有一个目标。你可能会想：“噢，我想收集这个特殊的数据，因为你永远不知道，可能在未来会需要它。“然后你对另外一些数据有类似的想法，一个接着一个，最后你才意识到你正在建立一个数据湖。 |
标点符号
whitepaper-zh.md
Outdated
|
|
||
| 当然，这只是最基本的。Prometheus 在2021年初完成了完成的基础涉及和逻辑的建设以便支持 scraping， 存储,，查询甚至于在 remote write 中去复制这些数据。[Thanos][Thanos](http://thanos.io/) 已经开始支持 exemplars，Grafana 也是。 | ||
|
|
||
| 值得一提的是,OpenTelemtry 也从 Open Census 那里继承了一些 exemplars。这些与 Open Metrics one 非常相似，只是仅仅附加到了 histogrm buckets 中。然而，我们目前还不知道有谁在使用或者依赖于 Otel metrics 协议中的这一部分，以及相关实现。 像[GO](https://github.com/open-telemetry/opentelemetry-go/issues/559)。这意味着，如果你想拥有稳定的相关性，一个已经运行的生态系统，Open Metrics 可能是前进的方向。另外，[Open Telemetry 也慢慢采用了 [Open Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/openmetrics-guidelines.md)。 |
There was a problem hiding this comment.
Suggested change
| 值得一提的是,OpenTelemtry 也从 Open Census 那里继承了一些 exemplars。这些与 Open Metrics one 非常相似，只是仅仅附加到了 histogrm buckets 中。然而，我们目前还不知道有谁在使用或者依赖于 Otel metrics 协议中的这一部分，以及相关实现。 像[GO](https://github.com/open-telemetry/opentelemetry-go/issues/559)。这意味着，如果你想拥有稳定的相关性，一个已经运行的生态系统，Open Metrics 可能是前进的方向。另外，[Open Telemetry 也慢慢采用了 [Open Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/openmetrics-guidelines.md)。 | |
| 值得一提的是,OpenTelemtry 也从 Open Census 那里继承了一些 exemplars。这些与 Open Metrics one 非常相似，只是仅仅附加到了 histogrm buckets 中。然而，我们目前还不知道有谁在使用或者依赖于 Otel metrics 协议中的这一部分，以及相关实现。 像[GO](https://github.com/open-telemetry/opentelemetry-go/issues/559)。这意味着，如果你想拥有稳定的相关性，一个已经运行的生态系统，Open Metrics 可能是前进的方向。另外，[Open Telemetry 也慢慢采用了 Open Metrics](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/openmetrics-guidelines.md)。 |
nit: duplicated brace
whitepaper-zh.md
Outdated
| (消耗率 * 告警窗口大小) / 时间周期 | ||
| ``` | ||
|
|
||
| 所以，如果30天内的错误预算花费超过1小时，那么5%的消耗率就需要达到36。 告警规则变为： |
There was a problem hiding this comment.
Suggested change
| 所以，如果30天内的错误预算花费超过1小时，那么5%的消耗率就需要达到36。 告警规则变为： | |
| 所以，以时间周期为30天，告警窗口大小为一小时来计算，那么一小时内5%的错误预算消耗，就意味着消耗率需达到36(5% * 30 days * 24 hours)。 告警规则变为： |
5%的消耗率有点表意不明。
whitepaper-zh.md
Outdated
|
|
||
| * 棘手的 trace 采样案例 | ||
|
|
||
| 去收集所有请求的全部 trace 和 span 可能代价巨大。因此，项目定义了不同的采样规则，只允许“采样”(去收集)那些以后可能有用的 trace。因为分辨重要样本难度很大，所以常常出现复杂的采样规则。主要的问题是确保 log 系统中的样本（Examplar）或直接的 trace ID 等关联点指向采样的 traces。如果我们的前端给了一个没有任何trace留存的 exemplar 链接，那将用户体验就很糟糕了。 |
There was a problem hiding this comment.
Suggested change
| 去收集所有请求的全部 trace 和 span 可能代价巨大。因此，项目定义了不同的采样规则，只允许“采样”(去收集)那些以后可能有用的 trace。因为分辨重要样本难度很大，所以常常出现复杂的采样规则。主要的问题是确保 log 系统中的样本（Examplar）或直接的 trace ID 等关联点指向采样的 traces。如果我们的前端给了一个没有任何trace留存的 exemplar 链接，那将用户体验就很糟糕了。 | |
| 去收集所有请求的全部 trace 和 span 可能代价巨大。因此，项目定义了不同的采样规则，只允许“采样”(去收集)那些以后可能有用的 trace。因为分辨重要样本难度很大，所以常常出现复杂的采样规则。主要的问题是确保 log 系统中的样本（Exemplar）或直接的 trace ID 等关联点指向采样的 traces。如果我们的前端给了一个没有任何trace留存的 exemplar 链接，那将用户体验就很糟糕了。 |
nit: typo
whitepaper-zh.md
Outdated
|
|
||
| 去收集所有请求的全部 trace 和 span 可能代价巨大。因此，项目定义了不同的采样规则，只允许“采样”(去收集)那些以后可能有用的 trace。因为分辨重要样本难度很大，所以常常出现复杂的采样规则。主要的问题是确保 log 系统中的样本（Examplar）或直接的 trace ID 等关联点指向采样的 traces。如果我们的前端给了一个没有任何trace留存的 exemplar 链接，那将用户体验就很糟糕了。 | ||
|
|
||
| 虽然可以在 UI 方面去改进这种体验(例如在展示 exemplar之前检查 trace 是否存在)，但这是本不应该发生的状况，而且增加了系统的复杂性。理想情况是，我们先检查样本（examplar）的相关trace都被记录在案，然后再将 样本（exemplar） 注入到 metrics 系统。使用了预先采样法时，OpenTelemetry API 允许通过诸如 “IsSampled” 方法来获取采样信息。如果我们讨论滞后采样（tail-based）或后期分析筛选有用的trace的时候，这个问题就出现了。我们还没有更好的想法来解决这个烦人的小问题。如果你采用全采样或预先决策采样(通过比例采样，或者用户制定规则采样)，这就不是问题了。 |
There was a problem hiding this comment.
Suggested change
| 虽然可以在 UI 方面去改进这种体验(例如在展示 exemplar之前检查 trace 是否存在)，但这是本不应该发生的状况，而且增加了系统的复杂性。理想情况是，我们先检查样本（examplar）的相关trace都被记录在案，然后再将 样本（exemplar） 注入到 metrics 系统。使用了预先采样法时，OpenTelemetry API 允许通过诸如 “IsSampled” 方法来获取采样信息。如果我们讨论滞后采样（tail-based）或后期分析筛选有用的trace的时候，这个问题就出现了。我们还没有更好的想法来解决这个烦人的小问题。如果你采用全采样或预先决策采样(通过比例采样，或者用户制定规则采样)，这就不是问题了。 | |
| 虽然可以在 UI 方面去改进这种体验(例如在展示 exemplar之前检查 trace 是否存在)，但这是本不应该发生的状况，而且增加了系统的复杂性。理想情况是，我们先检查样本（exemplar）的相关trace都被记录在案，然后再将 样本（exemplar） 注入到 metrics 系统。使用了预先采样法时，OpenTelemetry API 允许通过诸如 “IsSampled” 方法来获取采样信息。如果我们讨论滞后采样（tail-based）或后期分析筛选有用的trace的时候，这个问题就出现了。我们还没有更好的想法来解决这个烦人的小问题。如果你采用全采样或预先决策采样(通过比例采样，或者用户制定规则采样)，这就不是问题了。 |
nit: typo
whitepaper-zh.md
Outdated
|
|
||
| * Exemplars 是这个生态系统中的新事物 | ||
|
|
||
| Prometheus 的用户体验特别好，因为应用程序开放 Prometheus/OpenMetrics 接口已经是标准做法。各类软件都用这种简单的机制来添加大量有用的 metrics。然而 Prometheus exemplars 和 OpenTelemetry tracing 方兴未艾，所以人们需要时间来适应 exemplar 的用法，这是一种二级插桩测量法（用二级监视点 Examplar 来汇总一级监视点采集的数据，比如metric, log, trace等）。 |
There was a problem hiding this comment.
Suggested change
| Prometheus 的用户体验特别好，因为应用程序开放 Prometheus/OpenMetrics 接口已经是标准做法。各类软件都用这种简单的机制来添加大量有用的 metrics。然而 Prometheus exemplars 和 OpenTelemetry tracing 方兴未艾，所以人们需要时间来适应 exemplar 的用法，这是一种二级插桩测量法（用二级监视点 Examplar 来汇总一级监视点采集的数据，比如metric, log, trace等）。 | |
| Prometheus 的用户体验特别好，因为应用程序开放 Prometheus/OpenMetrics 接口已经是标准做法。各类软件都用这种简单的机制来添加大量有用的 metrics。然而 Prometheus exemplars 和 OpenTelemetry tracing 方兴未艾，所以人们需要时间来适应 exemplar 的用法，这是一种二级插桩测量法（用二级监视点 Exemplar 来关联一级监视点采集的数据，比如metric, log, trace等）。 |
nit: typo
Cool, I'll modify it later. @just1900 |
just1900
reviewed
Sep 30, 2021
whitepaper-zh.md
Outdated
|
|
||
| ___insert image with all 5 signals here___ | ||
|
|
||
| ### Metrics | ||
|
|
||
| Metrics是数据的数值表现。他们主要分为两类: 已经是数值的数据和被转换为数值的数据。前者的典型案例是 温度，后者则是 process counter。这与 logs 或者 traces 不同，后者侧重于单个事件的记录或信息。 | ||
|
|
||
| 转换过的数据丢失了细节，例如 process counter 会丢失有关特定增量发生时间的信息，这种权衡使 metrics 变成最有效的信号之一：你可以选择提取什么以及如何去提取，这减少了关于为保留、发射、转发、存储和处理的负载，还减少了人们的心里压力，因为可以简明地展示当前状况， 它大大减轻了运维人员的思考负担。 | ||
| 转换过的数据丢失了细节，例如 process counter 会丢失有关特定增量发生时间的信息，但这种权衡使 metrics 变成最有效的信号之一：领域专家需要选择提取什么以及如何去提取，而这减轻了关于如何保留、转换、传输、存储和处理数据的负担。同时它还减轻了运维人员的心理负担，因为人们可以借此快速的了解当前状况。 |
There was a problem hiding this comment.
change 心理负担 to 心智负担
@raptorsun @chenmudu how do you guys think?
|
@JohnWu20 @lubingfeng @raptorsun @just1900 |
|
LGTM |
yeya24
reviewed
Nov 1, 2021
There was a problem hiding this comment.
Can we integrate with https://github.com/tidb-incubator/zh.md?
I can see some formats issue here so would be great to have a linter for chinese
| * 基础设施工程师 | ||
| * 软件开发者 | ||
|
|
||
| 本白皮书可以帮助上述岗位的人员为客户交付一套既具有高度的可观测性，同时又能和客户已有的监控系统集成的，具有生产级的可靠性，安全性和透明度的软件产品。负责设计和实现这类软件的其他人员，例如项目经理、产品经理和架构师，也可能对这篇 白皮书 感兴趣。因为可观测性是一个多学科主题，计算机科学、信息系统、工程学(或相关学科)的学生和对可观测性领域感兴趣的人也可以在这里找到有用的信息。 |
|
|
||
| 插桩(组件埋点)在分布式追踪中扮演者重要的角色，它负责创建数据点本身以及将 context 在服务间进行传递。如果没有 context 传播，我们就无法将传入的 HTTP 请求与它的下游 HTTP 请求或消息的生产者及消费者连接起来。 | ||
|
|
||
| 插桩在分布式追踪有两个主要目的：Context 传播 和 span mapping。大多数情况下, 通常可以使用与 Http 客户端/服务器端 集成的库透明地进行传播。在这一部分中，可以使用像 OpenTelemetry API/SDKS 、Open Tracing 及 Open Census 等项目、工具和技术。 |
There was a problem hiding this comment.
Is it better to translate propogation to 传递?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here, @ArthurSens . I don't know whether the process of directly create pull request is correct or not. This is the translated content. Could you check it out if you have time? Of course, anyone can.
Thank you and look forward to your reply.