更新可观测内容

Observability/signals.md

@@ -8,8 +8,8 @@
 	<img src="../assets/observability.jpg"  align=center />
 </div>
 
-- **Metrics（度量）**：传统监控和告警领域的代名词，用来计算事件发生数量的数据集，例如服务 QPS、API 响应延迟、某个接口的失败数等。呈数字化指标出现，特征是具有时间属性、且可聚合，这样既能做常见的监控告警，也可以用来做趋势分析。Metrics 提供的信息可用于系统整体行为和监控状况的分析，它不一定能揭示问题根本原因，但可以作为发现问题的起点。一个典型例子是你收到一条告警”请求成功率跌到了 10%“，你意识到不妙，立即开始处理，结合其他 Signals 找到 root cause，从而解决问题。
-- **Logging（日志）**：程序员最熟悉的也是最古老又最具体的 Signal，描述一系列离散的事件，特别是非预期的行为、异常情况。在缺乏有力的 APM 系统时，Logging 数据通常是工程师在定位问题时最直接的手段。如果说 Metrics 告诉你应用程序出现问题，那么 Logging 就告诉你为什么出现问题。日志的采集、存储和查询需要消耗大量资源，应用中通常采样使用。
+- **Metrics（度量）**：传统监控和告警领域的代名词，用来计算事件发生数量的数据集，例如服务 QPS、API 响应延迟、某个接口的失败数等。呈数字化指标出现，特征是具有时间属性、且可聚合，这样既能做常见的监控告警，也可以用来做趋势分析。度量可用于系统整体行为和监控状况的分析，它不一定能揭示问题根本原因，但可以作为发现问题的起点。一个典型例子是你收到一条告警”请求成功率跌到了 10%“，你意识到不妙，立即开始处理，结合其他 Signals 找到 root cause，从而解决问题。
+- **Logging（日志）**：程序员最熟悉同时是处理的难度最大、技术挑战性最高的 Signal。日志描述一系列离散的事件，特别是非预期的行为、异常情况。在缺乏有力的 APM 系统时，分析日志数据是工程师定位问题时最直接的手段。如果说 Metrics 告诉你应用程序出现问题，那么 Logging 就告诉你为什么出现问题。
 
 - **Tracing（追踪）**：分布式系统中多个服务之间或多或少存在依赖，Tracing 通过有向无环图的方式记录分布式系统依赖中发生事件之间的因果关系，从而可以轻松分析出请求中异常点。与日志相同的是会消耗大量的资源，通常也需要根据采样的方式减少数据量。与日志不同的是，追踪技术依赖特定网络协议和语言，这种依赖使得追踪工具需要以插件或者探针的形式进行深度集成，对业务具有一定的侵入性。