update some description

Author: chluknight1224

content/zh/docs/concepts/observability-primer.md

@@ -8,7 +8,7 @@ cSpell:ignore: webshop
 
 ## 什么是可观测性？ {#what-is-observability}
 
-可观测性让你能够从外部理解一个系统，它允许你在不了解系统内部运作的情况下，对该系统提出问题。更重要的是，
+可观测性让你能够从外部理解一个系统，它允许你在不了解系统内部运作的情况下提出有关该系统的问题。更重要的是，
 它能帮你轻松排查和处理新出现的问题，也就是所谓的"未知的未知"。它还能帮你回答"为什么会发生这种情况？"这样的问题。
 
 要对你的系统提出这些问题，你的应用程序必须进行适当的插桩。也就是说，应用程序代码必须能够发出[信号](/docs/concepts/signals/)，
@@ -35,11 +35,11 @@ cSpell:ignore: webshop
 
 分布式链路让你能够观察请求如何在复杂的分布式系统中传播。它提高了应用程序或系统健康状况的可见性，并让你能够调试那些难以在本地重现的行为。对于分布式系统来说，分布式链路是必不可少的，因为这些系统通常存在不确定性问题，或者过于复杂而无法在本地重现。
 
-要理解分布式链路，你需要了解其各个组成部分的角色：日志、span（跨度）和 trace（链路）。
+要理解分布式链路，你需要了解其各个组成部分的角色：日志（logs）、跨度（spans）和 链路（traces）。
 
 ### 日志
 
-**日志** 日志是由服务或其他组件发出的带时间戳的消息。与[链路](#分布式链路)不同，它们不一定与特定的用户请求或事务相关联。在软件中几乎到处都能找到日志。长期以来，开发人员和运维人员一直依靠日志来洞察系统行为。
+一条日志是由服务或其他组件发出的带时间戳的消息。与[链路](#分布式链路)不同，它们不一定与特定的用户请求或事务相关联。在软件中几乎到处都能找到日志。长期以来，开发人员和运维人员严重依赖日志来洞察系统行为。
 
 日志样例：
 
@@ -61,7 +61,7 @@ I, [2021-02-23T13:26:23.505892 #22473]  INFO -- : [6459ffe1-ea53-4044-aaa3-bf902
 
 ### Span 属性
 
-Span 属性是附加在 span 上的额外信息。这些属性为我们提供了更多关于操作上下文的细节。
+Span 属性是附加在 span 上的元数据。这些属性为我们提供了更多关于操作上下文的细节。
 
 下面的表格列出了一些 span 属性的例子：
 

content/zh/docs/what-is-opentelemetry.md

@@ -24,8 +24,8 @@ OpenTelemetry 专注于遥测数据的生成、采集、管理和导出。 OpenT
 [可观测性](/docs/concepts/observability-primer/#what-is-observability)是通过检查系统输出来理解系统内部状态的能力。
 在软件的背景下，这意味着能够通过检查遥测数据（包括链路、指标和日志）来理解系统的内部状态。
 
-要使系统可观测，必须对其进行仪表化。也就是说，代码必须发出链路、指标或日志。
-然后，仪表化的数据必须发送到可观测性后端。
+要使系统可观测，必须通过在应用程序中添加代码或配置，使得应用程序能够生成遥测数据，如[链路](/docs/concepts/signals/traces/)、[指标](/docs/concepts/signals/metrics/)或[日志](/docs/concepts/signals/logs/)。
+然后，生成的数据必须发送到可观测性后端。
 
 ## 为什么选择 OpenTelemetry？ {#why-opentelemetry}
 
@@ -46,12 +46,12 @@ OpenTelemetry 满足可观测性的需求，并遵循两个关键原则：
 OpenTelemetry 包括以下主要组件：
 
 - 适用于所有组件的[规范](/docs/specs/otel)
-- 定义遥测数据形状的标准[协议](/docs/specs/otlp/)
+- 定义遥测数据结构的标准[协议](/docs/specs/otlp/)
 - 为常见遥测数据类型定义标准命名方案的[语义约定](/docs/specs/semconv/)
 - 定义如何生成遥测数据的 API
 - 实现规范、API 和遥测数据导出的[语言 SDK](/docs/languages)
-- 实现常见库和框架的仪表化的[库生态系统](/ecosystem/registry)
-- 可自动生成遥测数据的自动仪表化组件，无需更改代码
+- 实现常见库和框架的插桩的[库生态系统](/ecosystem/registry)
+- 自动插桩组件，无需更改代码即可生成遥测数据
 - [OpenTelemetry Collector](/docs/collector)：接收、处理和导出遥测数据的代理
 - 各种其他工具，
   如[用于 Kubernetes 的 OpenTelemetry Operator](/docs/platforms/kubernetes/operator/)、
@@ -69,7 +69,7 @@ OpenTelemetry 提供商业支持并直接为此项目做贡献。
 OpenTelemetry 被设计为可扩展的。一些扩展 OpenTelemetry 的例子包括：
 
 - 向 OpenTelemetry Collector 添加接收器以支持来自自定义源的遥测数据
-- 将自定义仪表化库加载到 SDK 中
+- 将自定义插桩库加载到 SDK 中
 - 创建适用于特定用例的 SDK 或 Collector 的[分发](/docs/concepts/distributions/)
 - 为尚不支持 OpenTelemetry 协议（OTLP）的自定义后端创建新的导出器
 - 为非标准上下文传播格式创建自定义传播器
@@ -79,14 +79,16 @@ OpenTelemetry 被设计为可扩展的。一些扩展 OpenTelemetry 的例子包
 ## 历史 {#history}
 
 OpenTelemetry 是[云原生计算基金会 (CNCF)](https://www.cncf.io)的一个项目，是由
-OpenTracing 和 OpenCensus 项目合并而成的。原来这两个项目都是为解决同样的问题而创建的：
+[OpenTracing](https://opentracing.io)) 和 [OpenCensus](https://opencensus.io) 项目合并而成的。原来这两个项目都是为解决同样的问题而创建的：
 缺乏一种标准的方法来为代码进行仪表化并将遥测数据发送到可观测性后端。
 由于这两个项目都无法独立解决这个问题，所以将其合并成立了 OpenTelemetry，
 吸收了双方的优势，提供了统一的解决方案。
 
 如果你目前正在使用 OpenTracing 或 OpenCensus，
 你可以在[迁移指南](/docs/migration/)中了解如何迁移到 OpenTelemetry。
 
+
+
 ## 接下来做什么？ {#what-next}
 
 - 参阅[入门指南](/docs/getting-started/) — 立即开始！