You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by GitBox <gi...@apache.org> on 2020/08/13 07:30:31 UTC

[GitHub] [skywalking-website] chopin-d opened a new pull request #112: Chinese translation of Blog:

chopin-d opened a new pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112


   新增“SkyWalking为超大规模而生”中文翻译。


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng merged pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng merged pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471216909



##########
File path: docs/zh/blog/README.md
##########
@@ -2,7 +2,11 @@
 layout: LayoutBlog
 
 blog:
-
+- title: SkyWalking为超大规模而生
+  name: 2020-08-11-observability-at-scale-skywalking-it-is
+  time: 吴晟.董旭，金蝶医疗. 8 月 13 日，2020
+  short: SkyWalking为超大规模而生。无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+  
 - title: 度量服务网格健康度 -- Apdex得分
   name: 2020-07-26-apdex-and-skywalking
   time: Srinivasan Ramaswamy. 唐昊杰，南京大学在读学生. 7 月 26 日，2020

Review comment:
       ```suggestion
     time: Srinivasan Ramaswamy. [译]唐昊杰，南京大学在读学生. 7 月 26 日，2020
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] chopin-d commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
chopin-d commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r469772879



##########
File path: docs/zh/blog/2020-08-11-Observability-at-Scale.md
##########
@@ -0,0 +1,99 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+
+- 原文链接：https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/

Review comment:
       I have added




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r469765123



##########
File path: docs/zh/blog/2020-08-11-Observability-at-Scale.md
##########
@@ -0,0 +1,99 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟

Review comment:
       Add translator inform, I am only writing the English version.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471186572



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）

Review comment:
       ```suggestion
   - 作者：吴晟
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471216876



##########
File path: docs/zh/blog/README.md
##########
@@ -2,7 +2,11 @@
 layout: LayoutBlog
 
 blog:
-
+- title: SkyWalking为超大规模而生
+  name: 2020-08-11-observability-at-scale-skywalking-it-is
+  time: 吴晟.董旭，金蝶医疗. 8 月 13 日，2020

Review comment:
       ```suggestion
     time: 吴晟. [译]董旭，金蝶医疗. 8 月 13 日，2020
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471215593



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,104 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
+
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
+
+### 为超大规模而生
+
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么支撑超大规模系统要考虑什么呢？
+
+### 拉取vs推送
+
+与数据流向息息相关的：拉取模式和推送模式。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
+
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些数量庞大指标的能力。
+
+此外，度量指标并不是可观测性领域中的唯一关注点，链路跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
+
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。

Review comment:
       ```suggestion
   SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从已经集成Prometheus的服务中获取终端用户的数据，避免重复工程建设，减少资源浪费。另外，比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r469767368



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,99 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：
+就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+
+让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+
+### 为规模而设计
+
+SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+
+### 拉取vs推送
+
+Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
+关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+
+Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+
+此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+
+同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+
+结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+
+### 度量指标分析不仅仅是数学计算
+
+度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
+但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+
+Ops和SRE团队需要提供服务拓扑图，用于NOC仪表板和系统数据流的确认。SkyWalking依靠trace数据，使用STAM（Streaming Topology Analysis Method）方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行分析。进行拓扑分析。这种节点（services）和线路（service relationships）的拓扑和度量数据，无法从简单的度量sdk中提取。
+
+为了解决端点度量收集的局限性，SkyWalking还需要从跟踪数据中进行端点依赖性分析。端点依赖性分析提供包括上游和下游在内的更重要和更具体的信息。这些依赖关系和度量有助于开发团队将性能问题的边界定位到特定的代码块。
+
+### 预计算与查询阶段计算？
+
+查询阶段计算提供了灵活性。在分析阶段，预计算可以提供更好、更稳定的性能。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询阶段计算的范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是在设计阶段减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
+
+
+指标的TTL（Time To L）是另一个重要的业务使用因素。由于预先计算，查询提供了近似线性的性能，使用类似的查询基础设施，组织可以提供更高的TTL，从而提供显而易见的性能扩展。
+
+说到警报，查询阶段计算也意味着警报查询需要基于查询引擎。但在这种情况下，当数据集增加时，查询性能可能不一致。在不同的度量查询中也会发生相同的情况。
+
+### 当前案例
+
+如今，SkyWalking在许多大型企业的超大规模分布式系统中使用，包括阿里巴巴、华为、腾讯、百度、中国电信以及多家银行和保险公司。上线SkyWalking的公司的流量比银行和电信供应商等传统公司还要多。
+
+SkyWalking可以应用于分布式系统各种场景下的一个可观测性平台，这些系统在许多方面都是超大型的：
+
+- 拉勾网，一个在线招聘平台
+  SkyWalking正在观测超过100个服务，500多个JVM实例
+  SkyWalking每天收集和分析40多亿个跟踪数据，用来分析性能，包括30万个端点和依赖关系的指标
+  在整个群集中监控>50k流量/秒
+
+- 永辉超市，线上服务
+  SkyWalking每天分析至少100多亿（3B）的跟踪数据
+  SkyWalking较小的部署，每天分析2亿多个跟踪数据
+
+- 百度，互联网和人工智能公司，k8s部署
+  SkyWalking每天从1400多个pod中收集1T以上的跟踪数据，共120多项服务
+  随着更多服务的增加，规模持续增大
+
+- 贝壳找房(ke.com)，腾讯和软银集团控股的中国在线房地产经纪公司
+
+  很早就使用了SkyWalking，有两名成员已经成为PMC。
+
+  Deployments每天收集160多亿个跟踪数据
+
+- 阿里云效，阿里云上的DevOps服务
+
+  SkyWalking每天收集和分析数十亿个span
+
+  SkyWalking使阿里云的45项服务和~300个实例保持稳定
+
+- 阿里巴巴天猫， 一个从淘宝剥离出来的最大的B2C电商部门
+
+  SkyWalking个性化定制版，每天监控数十亿跟踪数据
+
+  与此同时，他们基于SkyWalking的Agent技术栈，利用其跟踪和上下文传播能力，正在构建一个负载测试平台。

Review comment:
       Use different formats in the cases. Please use the local env to check the final format.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471216265



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,104 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
+
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
+
+### 为超大规模而生
+
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么支撑超大规模系统要考虑什么呢？
+
+### 拉取vs推送
+
+与数据流向息息相关的：拉取模式和推送模式。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
+
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些数量庞大指标的能力。
+
+此外，度量指标并不是可观测性领域中的唯一关注点，链路跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
+
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
+
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊场景。
+
+### 度量指标分析并不仅仅是数学统计
+
+度量指标依赖于数学理论和计算。Percentile（百分位数）是用于反映响应时间的长尾效应。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪还为跟踪提供了详细的信息，以及可分析的高价值指标。
+
+运维团队（OPS）和系统稳定性（SRE）团队通过服务拓扑图，用来观察网络情况（当做NOC dashboard使用）、确认系统数据流。SkyWalking依靠trace（跟踪数据），使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量指标数据，无法通过sdk轻而易举的拿到。
+
+![](https://skywalking.apache.org/assets/img/topology-v8.3e6120f9.png)
+
+为了解决端点度量指标收集的局限性，SkyWalking还要从跟踪数据中分析端点依赖关系，从而拿到链路上游、下游这些关键具体的信息。这些依赖关系和度量指标信息，有助于开发团队定位引起性能问题的代码块。
+
+![](https://skywalking.apache.org/assets/img/endpoint-dependency-v8.1d737ddc.png)
+### 预计算还是查询时计算？
+
+相比查询时计算的灵活性，预计算可以提供更好、更稳定的性能，这在分析场景下尤为重要。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询时计算的使用范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是：在设计阶段，要减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
+
+使用SkyWalking的另一个重要因素是：指标的有效期，TTL（Time To Live）。由于采用了预先计算，查询提供了近似线性的高性能。这也帮助“查询系统”这类基础设施系统，提供更好的性能扩展。
+
+说到警报，使用查询时计算方案，也意味着警报查询需要基于查询引擎。但在这种情况下，随着数据集增加，查询性能会随之下降，其他指标查询也是一样的结果。

Review comment:
       ```suggestion
   关于警报，使用查询时计算方案，也意味着警报查询需要基于查询引擎。但在这种情况下，随着数据集增加，查询性能会随之下降，其他指标查询也是一样的结果。
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] chopin-d commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
chopin-d commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471192202



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）

Review comment:
       OK




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471216048



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,104 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
+
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
+
+### 为超大规模而生
+
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么支撑超大规模系统要考虑什么呢？
+
+### 拉取vs推送
+
+与数据流向息息相关的：拉取模式和推送模式。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
+
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些数量庞大指标的能力。
+
+此外，度量指标并不是可观测性领域中的唯一关注点，链路跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
+
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
+
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊场景。
+
+### 度量指标分析并不仅仅是数学统计
+
+度量指标依赖于数学理论和计算。Percentile（百分位数）是用于反映响应时间的长尾效应。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪还为跟踪提供了详细的信息，以及可分析的高价值指标。
+
+运维团队（OPS）和系统稳定性（SRE）团队通过服务拓扑图，用来观察网络情况（当做NOC dashboard使用）、确认系统数据流。SkyWalking依靠trace（跟踪数据），使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量指标数据，无法通过sdk轻而易举的拿到。
+
+![](https://skywalking.apache.org/assets/img/topology-v8.3e6120f9.png)
+
+为了解决端点度量指标收集的局限性，SkyWalking还要从跟踪数据中分析端点依赖关系，从而拿到链路上游、下游这些关键具体的信息。这些依赖关系和度量指标信息，有助于开发团队定位引起性能问题的代码块。

Review comment:
       ```suggestion
   为了解决端点度量指标收集的局限性，SkyWalking还要从跟踪数据中分析端点依赖关系，从而拿到链路上游、下游这些关键具体的信息。这些依赖关系和度量指标信息，有助于开发团队定位引起性能问题的边界，甚至代码块。
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471215703



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,104 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
+
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
+
+### 为超大规模而生
+
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么支撑超大规模系统要考虑什么呢？
+
+### 拉取vs推送
+
+与数据流向息息相关的：拉取模式和推送模式。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
+
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些数量庞大指标的能力。
+
+此外，度量指标并不是可观测性领域中的唯一关注点，链路跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
+
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
+
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊场景。

Review comment:
       ```suggestion
   结论：SkyWalking的推送模式是原生方式，但拉取式模式也适用于某些特殊场景。
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471212873



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）
 - 翻译：董旭 金蝶医疗
 - 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
 
-SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
-它是为应对当前系统管理所面临的困难而构建的：
-就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
 
-SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
 
-让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
 
-### 为规模而设计
+### 为规模而生
 
-SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么规模要考虑什么呢？
 
 ### 拉取vs推送
 
-Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
-关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+拉取模式和推送模式，与数据流的方向息息相关。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
 
-Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些指标的能力。
 
-此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+此外，度量指标并不是可观测性领域中的唯一关注点，跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
 
-同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
 
-结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊情况。
 
-### 度量指标分析不仅仅是数学计算
+### 度量指标分析并不是数学计算
 
-度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
-但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+度量指标依赖于数学理论和计算。Percentile（百分率）是用来度量响应情况的指标。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪除了为跟踪提供了详细的信息，还要提供可分析的高价值指标。

Review comment:
       ` for identifying the long tail issue`, 这里指的是长尾效应

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）
 - 翻译：董旭 金蝶医疗
 - 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
 
-SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
-它是为应对当前系统管理所面临的困难而构建的：
-就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
 
-SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
 
-让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
 
-### 为规模而设计
+### 为规模而生
 
-SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么规模要考虑什么呢？
 
 ### 拉取vs推送
 
-Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
-关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+拉取模式和推送模式，与数据流的方向息息相关。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
 
-Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些指标的能力。
 
-此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+此外，度量指标并不是可观测性领域中的唯一关注点，跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
 
-同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
 
-结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊情况。
 
-### 度量指标分析不仅仅是数学计算
+### 度量指标分析并不是数学计算
 
-度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
-但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+度量指标依赖于数学理论和计算。Percentile（百分率）是用来度量响应情况的指标。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪除了为跟踪提供了详细的信息，还要提供可分析的高价值指标。
 
-Ops和SRE团队需要提供服务拓扑图，用于NOC仪表板和系统数据流的确认。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行分析。进行拓扑分析。这种节点（services）和线路（service relationships）的拓扑和度量数据，无法从简单的度量sdk中提取。
+运维团队（OPS）和系统稳定性（SRE）团队需要通过服务拓扑图，观察NOC仪表板和确认系统数据流。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量数据，无法从简单的度量sdk中提取。
 
 ![](https://skywalking.apache.org/assets/img/topology-v8.3e6120f9.png)
 
-为了解决端点度量收集的局限性，SkyWalking还需要从跟踪数据中进行端点依赖性分析。端点依赖性分析提供包括上游和下游在内的更重要和更具体的信息。这些依赖关系和度量有助于开发团队将性能问题的边界定位到特定的代码块。
+为了解决端点度量收集的局限性，SkyWalking还要从跟踪数据中分析端点依赖。链路上游、下游这些关键具体的信息，可以通过端点依赖分析拿到。这些依赖关系和度量信息，有助于开发团队定位引起性能问题的代码块。
 
 ![](https://skywalking.apache.org/assets/img/endpoint-dependency-v8.1d737ddc.png)
 ### 预计算与查询阶段计算？
 
-查询阶段计算提供了灵活性。在分析阶段，预计算可以提供更好、更稳定的性能。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询阶段计算的范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是在设计阶段减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
+相比查询时计算的灵活性，预计算可以提供更好、更稳定的性能，这在分析场景下尤为重要。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询时计算的使用范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是：在设计阶段，要减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
 
+使用SkyWalking的另一个重要因素是：指标的有效期，TTL（Time To Live）。由于采用了预先计算，查询提供了近似线性的高性能。这也帮助查询系统（基础设施）提供更好的性能扩展。
 
-指标的TTL（Time To L）是另一个重要的业务使用因素。由于预先计算，查询提供了近似线性的性能，使用类似的查询基础设施，组织可以提供更高的TTL，从而提供显而易见的性能扩展。
+说到警报，使用查询时计算方案，也意味着警报查询需要基于查询引擎。但在这种情况下，随着数据集增加，查询性能会随之下降，其他指标查询也是一样的结果。
 
-说到警报，查询阶段计算也意味着警报查询需要基于查询引擎。但在这种情况下，当数据集增加时，查询性能可能不一致。在不同的度量查询中也会发生相同的情况。
+### 目前使用案例
 
-### 当前案例
+如今，SkyWalking在许多大型企业的超大规模分布式系统中使用，包括阿里巴巴、华为、腾讯、百度、中国电信以及多家银行和保险公司。上线SkyWalking公司的流量，比银行和电信运营商这种传统公司还要大。

Review comment:
       China Telecom -> 中国通讯企业，没有可以想指中国电信，只是恰巧名字一样。

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）
 - 翻译：董旭 金蝶医疗
 - 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
 
-SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
-它是为应对当前系统管理所面临的困难而构建的：
-就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
 
-SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
 
-让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
 
-### 为规模而设计
+### 为规模而生
 
-SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么规模要考虑什么呢？
 
 ### 拉取vs推送
 
-Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
-关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+拉取模式和推送模式，与数据流的方向息息相关。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
 
-Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些指标的能力。
 
-此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+此外，度量指标并不是可观测性领域中的唯一关注点，跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
 
-同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
 
-结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊情况。
 
-### 度量指标分析不仅仅是数学计算
+### 度量指标分析并不是数学计算
 
-度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
-但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+度量指标依赖于数学理论和计算。Percentile（百分率）是用来度量响应情况的指标。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪除了为跟踪提供了详细的信息，还要提供可分析的高价值指标。
 
-Ops和SRE团队需要提供服务拓扑图，用于NOC仪表板和系统数据流的确认。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行分析。进行拓扑分析。这种节点（services）和线路（service relationships）的拓扑和度量数据，无法从简单的度量sdk中提取。
+运维团队（OPS）和系统稳定性（SRE）团队需要通过服务拓扑图，观察NOC仪表板和确认系统数据流。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量数据，无法从简单的度量sdk中提取。

Review comment:
       service -> 服务，ervice relationships->服务依赖

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）
 - 翻译：董旭 金蝶医疗
 - 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
 
-SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
-它是为应对当前系统管理所面临的困难而构建的：
-就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
 
-SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
 
-让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
 
-### 为规模而设计
+### 为规模而生
 
-SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么规模要考虑什么呢？
 
 ### 拉取vs推送
 
-Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
-关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+拉取模式和推送模式，与数据流的方向息息相关。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
 
-Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些指标的能力。
 
-此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+此外，度量指标并不是可观测性领域中的唯一关注点，跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
 
-同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
 
-结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊情况。
 
-### 度量指标分析不仅仅是数学计算
+### 度量指标分析并不是数学计算
 
-度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
-但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+度量指标依赖于数学理论和计算。Percentile（百分率）是用来度量响应情况的指标。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪除了为跟踪提供了详细的信息，还要提供可分析的高价值指标。

Review comment:
       `reasonable average response time and successful rate are good SLO(s). But those are not all`. 合理的平均响应时间和成功率阈值都是很好的SLO指标。

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -1,79 +1,75 @@
 ## SkyWalking为超大规模而生
-- 作者：吴晟
+- 作者：吴晟（SkyWalking创始人）
 - 翻译：董旭 金蝶医疗
 - 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
 
-SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
-它是为应对当前系统管理所面临的困难而构建的：
-就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
 
-SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
 
-让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
 
-### 为规模而设计
+### 为规模而生
 
-SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么规模要考虑什么呢？
 
 ### 拉取vs推送
 
-Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
-关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+拉取模式和推送模式，与数据流的方向息息相关。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
 
-Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些指标的能力。
 
-此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+此外，度量指标并不是可观测性领域中的唯一关注点，跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
 
-同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
 
-结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊情况。
 
-### 度量指标分析不仅仅是数学计算
+### 度量指标分析并不是数学计算
 
-度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
-但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+度量指标依赖于数学理论和计算。Percentile（百分率）是用来度量响应情况的指标。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪除了为跟踪提供了详细的信息，还要提供可分析的高价值指标。
 
-Ops和SRE团队需要提供服务拓扑图，用于NOC仪表板和系统数据流的确认。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行分析。进行拓扑分析。这种节点（services）和线路（service relationships）的拓扑和度量数据，无法从简单的度量sdk中提取。
+运维团队（OPS）和系统稳定性（SRE）团队需要通过服务拓扑图，观察NOC仪表板和确认系统数据流。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量数据，无法从简单的度量sdk中提取。

Review comment:
       NOC 是我们日常指的监控大屏




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r469766522



##########
File path: docs/zh/blog/2020-08-11-Observability-at-Scale.md
##########
@@ -0,0 +1,99 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+
+- 原文链接：https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/

Review comment:
       This link should include the skywalking official website link, at least.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r469795546



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,102 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：
+就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。

Review comment:
       ```suggestion
   就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
   ```

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,109 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。

Review comment:
       ```suggestion
   SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
   ```

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,102 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：
+就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+
+让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。
+
+### 为规模而设计
+
+SkyWalking诞生时间要追溯到2015年，当时它的主要使用场景是监控中国顶级电信公司、中国联通和中国移动的第一代分布式核心系统。2013-2014年，电信公司计划用分布式系统取代传统的单体架构应用。从第一天开始，支持超大型分布式系统和可扩展性就是SkyWalking首要的设计目标。所以，规模要考虑什么呢？
+
+### 拉取vs推送
+
+Pull和push模式与数据流的方向有关。如果Agent（探针）收集数据并将其推送到后端进行进一步分析，我们称之为“推送”模式。
+关于拉还是推的争论已经持续了很长时间。可观测性系统的关键是使agent的成本最小化，并使其能普遍适用于不同类型的可观测性数据。
+
+Agent将在数据收集后的短时间内发送出去。这样，我们就不必担心本地缓存过载了。一个典型的例子是端点（HTTP的URI，gRPC的服务）度量指标。任何服务都可以轻松地拥有数百个甚至数千个端点。APM系统必须具有这些度量分析能力。
+
+此外，度量指标并不是可观测性领域中唯一的东西；跟踪和日志也很重要。SkyWalking设计用于在生产环境中提供100%的采样率跟踪功能。显然，推送模式是唯一的解决方案。
+
+同时，使用了推送模式并不意味着SkyWalking不能进行数据拉取。在最近的8.x版本中，SkyWalking支持从Prometheus-instrumented服务获取数据，以减少终端用户的重复性建设。此外，拉模式流行的做法是基于MQ的传输，Kafka消费者是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器使用拉取模式。
+
+结论：推模式是本机方式（Agent），但拉式模式也适用于某些特殊情况。
+
+### 度量指标分析不仅仅是数学计算
+
+度量指标依赖于数学理论和计算。Percentile是识别响应慢的一个很好的指标，合理的平均响应时间和成功率是很好的SLO（s）。
+但这些并不是全部。分布式跟踪不仅为跟踪提供了详细的信息，还提供了可以分析的高价值指标。
+
+Ops和SRE团队需要提供服务拓扑图，用于NOC仪表板和系统数据流的确认。SkyWalking依靠trace数据，使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行分析。进行拓扑分析。这种节点（services）和线路（service relationships）的拓扑和度量数据，无法从简单的度量sdk中提取。
+
+![](https://skywalking.apache.org/assets/img/topology-v8.3e6120f9.png)
+
+为了解决端点度量收集的局限性，SkyWalking还需要从跟踪数据中进行端点依赖性分析。端点依赖性分析提供包括上游和下游在内的更重要和更具体的信息。这些依赖关系和度量有助于开发团队将性能问题的边界定位到特定的代码块。
+
+![](https://skywalking.apache.org/assets/img/endpoint-dependency-v8.1d737ddc.png)
+### 预计算与查询阶段计算？
+
+查询阶段计算提供了灵活性。在分析阶段，预计算可以提供更好、更稳定的性能。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询阶段计算的范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是在设计阶段减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
+
+
+指标的TTL（Time To L）是另一个重要的业务使用因素。由于预先计算，查询提供了近似线性的性能，使用类似的查询基础设施，组织可以提供更高的TTL，从而提供显而易见的性能扩展。

Review comment:
       ```suggestion
   指标的有效期，TTL（Time To Live）是另一个重要的业务使用因素。由于预先计算，查询提供了近似线性的性能，使用类似的查询基础设施，组织可以提供更高的TTL，从而提供显而易见的性能扩展。
   ```

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,109 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：
+就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。

Review comment:
       ```suggestion
   SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(service mesh)架构下，它都可以提供高性能且一致性的监控。
   ```

##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,109 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking是Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。
+它是为应对当前系统管理所面临的困难而构建的：
+就像在一个干草堆中可以找到一根针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务一一对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在mesh架构下，它都可以使用轻量级负载提供一致性的监控。
+
+让我们来看看SkyWalking是如何演进解决规模可观测性问题的，并从一个纯粹的链路跟踪系统发展成为一个功能丰富的可观测性平台，用于分析每天百亿级跟踪数据。

Review comment:
       ```suggestion
   让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
   ```
   翻译要注意中文语言习惯。




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471216416



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,104 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
+
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
+
+### 为超大规模而生
+
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么支撑超大规模系统要考虑什么呢？
+
+### 拉取vs推送
+
+与数据流向息息相关的：拉取模式和推送模式。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
+
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些数量庞大指标的能力。
+
+此外，度量指标并不是可观测性领域中的唯一关注点，链路跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
+
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
+
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊场景。
+
+### 度量指标分析并不仅仅是数学统计
+
+度量指标依赖于数学理论和计算。Percentile（百分位数）是用于反映响应时间的长尾效应。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪还为跟踪提供了详细的信息，以及可分析的高价值指标。
+
+运维团队（OPS）和系统稳定性（SRE）团队通过服务拓扑图，用来观察网络情况（当做NOC dashboard使用）、确认系统数据流。SkyWalking依靠trace（跟踪数据），使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量指标数据，无法通过sdk轻而易举的拿到。
+
+![](https://skywalking.apache.org/assets/img/topology-v8.3e6120f9.png)
+
+为了解决端点度量指标收集的局限性，SkyWalking还要从跟踪数据中分析端点依赖关系，从而拿到链路上游、下游这些关键具体的信息。这些依赖关系和度量指标信息，有助于开发团队定位引起性能问题的代码块。
+
+![](https://skywalking.apache.org/assets/img/endpoint-dependency-v8.1d737ddc.png)
+### 预计算还是查询时计算？
+
+相比查询时计算的灵活性，预计算可以提供更好、更稳定的性能，这在分析场景下尤为重要。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询时计算的使用范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是：在设计阶段，要减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
+
+使用SkyWalking的另一个重要因素是：指标的有效期，TTL（Time To Live）。由于采用了预先计算，查询提供了近似线性的高性能。这也帮助“查询系统”这类基础设施系统，提供更好的性能扩展。
+
+说到警报，使用查询时计算方案，也意味着警报查询需要基于查询引擎。但在这种情况下，随着数据集增加，查询性能会随之下降，其他指标查询也是一样的结果。
+
+### 目前使用案例
+
+如今，SkyWalking在许多大型企业的超大规模分布式系统中使用，包括阿里巴巴、华为、腾讯、百度、中国电信以及多家银行和保险公司。上线SkyWalking公司的流量，比银行和电信运营商这种传统公司还要大。
+
+在很多行业中，SkyWalking是被应用于超大型分布式系统各种场景下的一个可观测性平台：
+
+- 拉勾网，一个在线招聘平台
+
+  - SkyWalking正在观测超过100个服务，500多个JVM实例
+  
+  - SkyWalking每天收集和分析40多亿个跟踪数据，用来分析性能，其中包括30万个端点和依赖关系的指标
+  
+  - 在整个群集中监控>50k流量/秒
+
+- 永辉超市，线上服务
+
+  - SkyWalking每天分析至少100多亿（3B）的跟踪数据
+  
+  - 其次，SkyWalking用较小的部署，每天分析2亿多个跟踪数据
+
+- 百度，互联网和人工智能公司，k8s部署
+
+  - SkyWalking每天从1400多个pod中，从120多个服务收集1T以上的跟踪数据
+  
+  - 随着更多服务的增加，规模会持续增大
+
+- 贝壳找房(ke.com)，腾讯和软银集团控股的中国在线房地产经纪公司
+
+  - 很早就使用了SkyWalking，有两名成员已经成为PMC
+
+  - Deployments每天收集160多亿个跟踪数据
+
+- 阿里云效，阿里云上的DevOps服务
+
+  - SkyWalking每天收集和分析数十亿个span
+
+  - SkyWalking使阿里云的45项服务和~300个实例保持稳定
+
+- 阿里巴巴天猫， 一个从淘宝剥离出来的最大的B2C电商部门
+
+  - SkyWalking个性化定制版，每天监控数十亿跟踪数据
+
+  - 与此同时，他们基于SkyWalking的Agent技术栈，利用其跟踪和上下文传播能力，正在构建一个负载测试平台

Review comment:
       ```suggestion
     - 与此同时，他们基于SkyWalking的Agent技术栈，利用其跟踪和上下文传播能力，正在构建一个全链路压测平台
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [skywalking-website] wu-sheng commented on a change in pull request #112: Chinese translation of Blog:

Posted by GitBox <gi...@apache.org>.
wu-sheng commented on a change in pull request #112:
URL: https://github.com/apache/skywalking-website/pull/112#discussion_r471216374



##########
File path: docs/zh/blog/2020-08-11-observability-at-scale-skywalking-it-is.md
##########
@@ -0,0 +1,104 @@
+## SkyWalking为超大规模而生
+- 作者：吴晟
+- 翻译：董旭 金蝶医疗
+- 原文链接：[Tetrate.io blog](https://www.tetrate.io/blog/observability-at-scale-skywalking-it-is/)
+
+SkyWalking做为Apache的顶级项目，是一个开源的APM和可观测性分析平台，它解决了21世纪日益庞大、分布式和异构的系统的问题。它是为应对当前系统管理所面临的困难而构建的：就像大海捞针，SkyWalking可以在服务依赖复杂且多语言环境下，获取服务对应的指标，以及完整而有意义的性能视图。
+
+SkyWalking是一个非常全面的平台，无论你的微服务是否在服务网格(Service Mesh)架构下，它都可以提供高性能且一致性的监控。
+
+让我们来看看，SkyWalking是如何解决大规模集群的可观测性问题，并从一个纯粹的链路跟踪系统，发展成为一个每天分析百亿级跟踪数据，功能丰富的可观测性平台。
+
+### 为超大规模而生
+
+SkyWalking的诞生，时间要追溯到2015年，当时它主要应用于监控顶级电信公司（例如：中国联通和中国移动）的第一代分布式核心系统。2013-2014年，这些电信公司计划用分布式系统取代传统的单体架构应用。从诞生那天开始，SkyWalking首要的设计目标，就是能够支持超大型分布式系统，并具有很好可扩展性。那么支撑超大规模系统要考虑什么呢？
+
+### 拉取vs推送
+
+与数据流向息息相关的：拉取模式和推送模式。Agent（客户端）收集数据并将其推送到后端，再对数据进一步分析，我们称之为“推送”模式。究竟应该使用拉取还是推送？这个话题已经争论已久。关键因素取决于可观测性系统的目标，即：在Agent端花最小的成本，使其适配不同类型的可观测性数据。
+
+Agent收集数据后，可以在短时间内发送出去。这样，我们就不必担心本地缓存压力过大。举一个典型的例子，任意服务都可以轻松地拥有数百个甚至数千个端点指标（如：HTTP的URI，gRPC的服务）。那么APM系统就必须具有分析这些数量庞大指标的能力。
+
+此外，度量指标并不是可观测性领域中的唯一关注点，链路跟踪和日志也很重要。在生产环境下，SkyWalking为了能提供100%采样率的跟踪能力，数据推送模式是唯一可行的解决方案。
+
+SkyWalking即便使用了推送模式，同时也可进行数据拉取。在最近的8.x的发版本中，SkyWalking支持从Prometheus-instrumented services获取终端用户的数据，这样就减少了所谓的“一次性工程”建设，减少资源浪费。比较常见的是基于MQ的传输构建拉取模式，Kafka消费者就是一个比较典型的例子。SkyWalking的Agent端使用推送模式，OAP服务器端使用拉取模式。
+
+结论：SkyWalking的推送模式是首选方式，但拉取式模式也适用于某些特殊场景。
+
+### 度量指标分析并不仅仅是数学统计
+
+度量指标依赖于数学理论和计算。Percentile（百分位数）是用于反映响应时间的长尾效应。服务具备合理的平均响应时间和成功率，说明服务的服务等级目标(SLO）很好。除此之外，分布式跟踪还为跟踪提供了详细的信息，以及可分析的高价值指标。
+
+运维团队（OPS）和系统稳定性（SRE）团队通过服务拓扑图，用来观察网络情况（当做NOC dashboard使用）、确认系统数据流。SkyWalking依靠trace（跟踪数据），使用[STAM（Streaming Topology Analysis Method）](https://wu-sheng.github.io/STAM/)方法进行分析拓扑结构。在服务网格环境下，使用ALS（Envoy Access Log Service）进行拓扑分析。节点（services）和线路（service relationships）的拓扑结构和度量指标数据，无法通过sdk轻而易举的拿到。
+
+![](https://skywalking.apache.org/assets/img/topology-v8.3e6120f9.png)
+
+为了解决端点度量指标收集的局限性，SkyWalking还要从跟踪数据中分析端点依赖关系，从而拿到链路上游、下游这些关键具体的信息。这些依赖关系和度量指标信息，有助于开发团队定位引起性能问题的代码块。
+
+![](https://skywalking.apache.org/assets/img/endpoint-dependency-v8.1d737ddc.png)
+### 预计算还是查询时计算？
+
+相比查询时计算的灵活性，预计算可以提供更好、更稳定的性能，这在分析场景下尤为重要。回想一下我们的设计原则：SkyWalking是为了一个大规模的分布式系统而设计。查询时计算的使用范围非常有限，大多数度量计算都需要预先定义和预先计算。支持大数据集的关键是：在设计阶段，要减小数据集。预计算允许将原始数据合并到下游的聚合结果中，用于查询，甚至用于警报检查。
+
+使用SkyWalking的另一个重要因素是：指标的有效期，TTL（Time To Live）。由于采用了预先计算，查询提供了近似线性的高性能。这也帮助“查询系统”这类基础设施系统，提供更好的性能扩展。
+
+说到警报，使用查询时计算方案，也意味着警报查询需要基于查询引擎。但在这种情况下，随着数据集增加，查询性能会随之下降，其他指标查询也是一样的结果。
+
+### 目前使用案例
+
+如今，SkyWalking在许多大型企业的超大规模分布式系统中使用，包括阿里巴巴、华为、腾讯、百度、中国电信以及多家银行和保险公司。上线SkyWalking公司的流量，比银行和电信运营商这种传统公司还要大。
+
+在很多行业中，SkyWalking是被应用于超大型分布式系统各种场景下的一个可观测性平台：
+
+- 拉勾网，一个在线招聘平台

Review comment:
       公司属性，建议使用更中文化的习惯。甚至因为大家已经熟悉，没必要翻译后面的描述。




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org