zh-translation: /docs/root/start/sandboxes/zipkin_tracing.rst (envoyp…

…roxy#431)

* finish

* fix

* fix

* fix build

* fix

* fix

docs/root/start/sandboxes/zipkin_tracing.rst

@@ -1,44 +1,33 @@
 .. _install_sandboxes_zipkin_tracing:
 
-Zipkin Tracing
-==============
-
-The Zipkin tracing sandbox demonstrates Envoy's :ref:`request tracing <arch_overview_tracing>`
-capabilities using `Zipkin <https://zipkin.io/>`_ as the tracing provider. This sandbox
-is very similar to the front proxy architecture described above, with one difference:
-service1 makes an API call to service2 before returning a response.
-The three containers will be deployed inside a virtual network called ``envoymesh``.
-
-All incoming requests are routed via the front Envoy, which is acting as a reverse proxy
-sitting on the edge of the ``envoymesh`` network. Port ``8000`` is exposed
-by docker compose (see :repo:`/examples/zipkin-tracing/docker-compose.yaml`). Notice that
-all Envoys are configured to collect request traces (e.g., http_connection_manager/config/tracing setup in
-:repo:`/examples/zipkin-tracing/front-envoy-zipkin.yaml`) and setup to propagate the spans generated
-by the Zipkin tracer to a Zipkin cluster (trace driver setup
-in :repo:`/examples/zipkin-tracing/front-envoy-zipkin.yaml`).
-
-Before routing a request to the appropriate service Envoy or the application, Envoy will take
-care of generating the appropriate spans for tracing (parent/child/shared context spans).
-At a high-level, each span records the latency of upstream API calls as well as information
-needed to correlate the span with other related spans (e.g., the trace ID).
-
-One of the most important benefits of tracing from Envoy is that it will take care of
-propagating the traces to the Zipkin service cluster. However, in order to fully take advantage
-of tracing, the application has to propagate trace headers that Envoy generates, while making
-calls to other services. In the sandbox we have provided, the simple flask app
-(see trace function in :repo:`/examples/front-proxy/service.py`) acting as service1 propagates
-the trace headers while making an outbound call to service2.
-
-
-Running the Sandbox
+Zipkin 追踪（trace）
+=====================
+
+Zipkin 追踪沙盒使用 Zipkin <https://zipkin.io/> 作为追踪提供程序来实现 Envoy 的 :ref:请求追踪功能。
+这个沙盒与前面所讲的前端代理架构非常的相似，但有一点不同的是：在返回响应之前，service1 会对 service2 进行 API 调用。 
+这三个容器将被部署在名为 ``envoymesh`` 的虚拟网络中。
+
+所有传入的请求都通过前端 envoy 进行路由，envoy 充当位于 ``envoymesh`` 网络边缘的反向代理。
+端口 ``8000`` 由 docker compose 暴露（参见 :repo:`/examples/zipkin-tracing/docker-compose.yaml`）。
+请注意，所有 envoy 都配置为收集请求跟踪 (例如 :repo:`/examples/zipkin-tracing/front-envoy-zipkin.yaml`中的 http_connection_manager/config/tracing 配置) 并设置为传递 Zipkin 追踪器生成的 span 到 Zipkin 集群中 (追踪驱动设置在 :repo:`/examples/zipkin-tracing/front-envoy-zipkin.yaml`)。
+
+在将请求路由到合适的 envoy 或应用程序之前，Envoy 会生成合适的用于追踪的 span（父子共享的上下文 span）。
+在高层次上，每个 span 记录上游API调用的延迟以及将 span 与其他相关 span（例如跟踪ID）关联所需的信息。 
+
+从 Envoy 进行跟踪的最重要的好处之一是，它会保证将跟踪信息传播到 Zipkin 服务群集。
+但是，为了充分利用跟踪，应用端必须在调用其他服务的时候传递 Envoy 生成的追踪的请求头信息。
+在我们提供的沙箱例子中，作为 service1 的简单 flask 应用（参见 :repo:`/examples/front-proxy/service.py` 中的跟踪函数）在访问 service2 的时候传递了追踪的请求头信息。
+
+
+运行沙盒
 ~~~~~~~~~~~~~~~~~~~
 
 .. include:: _include/docker-env-setup.rst
 
-Step 3: Build the sandbox
+步骤 3: 构建沙盒
 *************************
 
-To build this sandbox example, and start the example apps run the following commands:
+要构建这个沙盒示例，并启动示例应用程序，请运行以下命令：
 
 .. code-block:: console
 
@@ -55,10 +44,10 @@ To build this sandbox example, and start the example apps run the following comm
     zipkin-tracing_service2_1      /bin/sh -c /usr/local/bin/ ... Up      10000/tcp, 8000/tcp
     zipkin-tracing_zipkin_1        /busybox/sh run.sh             Up      9410/tcp, 0.0.0.0:9411->9411/tcp
 
-Step 4: Generate some load
+步骤 4: 发送请求
 **************************
 
-You can now send a request to service1 via the front-envoy as follows:
+你现在可以通过 envoy 向 service1 发送请求，如下所示：
 
 .. code-block:: console
 
@@ -80,11 +69,11 @@ You can now send a request to service1 via the front-envoy as follows:
     Hello from behind Envoy (service 1)! hostname: f26027f1ce28 resolvedhostname: 172.19.0.6
     * Connection #0 to host 192.168.99.100 left intact
 
-Step 5: View the traces in Zipkin UI
-************************************
+步骤 5: 在 Zipkin UI 中查看追踪
+*******************************************
 
-Point your browser to http://localhost:9411 . You should see the Zipkin dashboard.
-Set the service to "front-proxy" and set the start time to a few minutes before
-the start of the test (step 2) and hit enter. You should see traces from the front-proxy.
-Click on a trace to explore the path taken by the request from front-proxy to service1
-to service2, as well as the latency incurred at each hop.
+使用你的浏览器访问 http://localhost:9411。
+你应该看到 Zipkin 仪表板。
+将服务设置为 “front-proxy”，并将开始时间设置为在测试（步骤 2）开始前几分钟并按回车。
+你应该能看到来自 front-proxy 的跟踪信息。
+单击一个追踪来显示从 front-proxy 到 service1 再到 service2 的路径信息，以及每个跳跃点所产生的延迟。