Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

配置 Application Signals

本节包含有关配置 CloudWatch Application Signals 的信息。

跟踪采样率

默认情况下，启用 Application Signals 时，使用 reservoir=1/s 和 fixed_rate=5% 的默认采样率设置启用 X-Ray 集中采样。Amazon Distro for OpenTelemetry（ADOT）SDK 代理的环境变量设置如下。

有关更改采样配置的信息，请参阅以下内容：

如果要禁用 X-Ray 集中采样并改用本地采样，请按如下方式为 ADOT SDK Java 代理设置以下值。以下示例将采样率设置为 5%。

有关更多高级采样设置的信息，请参阅 OTEL_TRACES_SAMPLER。

启用跟踪日志关联

您可以在 Application Signals 中启用跟踪日志关联。这会自动将跟踪 ID 和跨度 ID 注入到相关的应用程序日志中。然后，当您在 Application Signals 控制台中打开跟踪详细信息页面时，与当前跟踪相关的相关日志条目（如果有）会自动出现在页面底部。

例如，假设您注意到延迟图中出现了一个峰值。您可以选择图表上的点来加载该时间点的诊断信息。然后，您可以选择相关的跟踪以获取更多信息。查看跟踪信息时，可以向下滚动以查看与跟踪相关的日志。这些日志可能会显示与导致延迟峰值的问题相关的模式或错误代码。

为了实现跟踪日志关联，Application Signals 依赖于适用于 Java 的 Logger MDC 自动检测 和适用于 Python 的 OpenTelemetry Logging Instrumentation。两者均由 OpenTelemetry 社区提供。Application Signals 使用此功能将跟踪 ID 和跨度 ID 等跟踪上下文注入应用程序日志。要启用此功能，您必须手动更改日志记录配置以启用自动检测。

根据应用程序运行的架构，除了执行本节中的步骤外，您可能还必须设置一个环境变量以启用跟踪日志关联。

启用跟踪日志关联后，

跟踪日志关联设置示例

本节包含在多个环境中设置跟踪日志关联的示例。

Spring Boot for Java

假设您在名为 custom-app 的文件夹中有一个 Spring Boot 应用程序。应用程序配置通常是一个名为 custom-app/src/main/resources/application.yml 的 YAML 文件，可能如下所示：

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...   

要启用跟踪日志关联，请添加以下日志记录配置。

spring:
  application:
    name: custom-app
  config:
    import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/}
    
...    

logging:
  pattern:
    level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p

Logback for Java

在日志记录配置（例如 logback.xml）中，将跟踪上下文 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p 插入到编码器的 pattern 中。例如，以下配置在日志消息之前添加跟踪上下文。

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
  <file>app.log</file>
  <append>true</append>
  <encoder> 
    <pattern>trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n</pattern> 
  </encoder>
</appender>

有关 Logback 中编码器的更多信息，请参阅 Logback 文档中的 Encoders。

Log4j2 for Java

在日志记录配置（例如 log4j2.xml）中，将跟踪上下文 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p 插入到 PatternLayout 中。例如，以下配置在日志消息之前添加跟踪上下文。

<Appenders>
  <File name="FILE" fileName="app.log">
    <PatternLayout pattern="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>
  </File>
</Appenders>

有关 Log4j2 中模式布局的更多信息，请参阅 Log4j2 文档中的 Pattern Layout。

Log4j for Java

在日志记录配置（例如 log4j.xml）中，将跟踪上下文 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p 插入到 PatternLayout 中。例如，以下配置在日志消息之前添加跟踪上下文。

<appender name="FILE" class="org.apache.log4j.FileAppender">;
  <param name="File" value="app.log"/>;
  <param name="Append" value="true"/>;
  <layout class="org.apache.log4j.PatternLayout">;
    <param name="ConversionPattern" value="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>;
  </layout>;
</appender>;

有关 Log4j 中模式布局的更多信息，请参阅 Log4j 文档中的 Class Pattern Layout。

Python

运行应用程序时，将环境变量 OTEL_PYTHON_LOG_CORRELATION 设置为 true。有关更多信息，请参阅 Python OpenTelemetry 文档中的 Enable trace context injection。

管理高基数操作

Application Signals 包括 CloudWatch 代理中的设置，您可以使用这些设置来管理操作的基数和管理指标导出，以优化成本。默认情况下，当服务的不同操作数随着时间的推移超过默认阈值 500 时，指标限制功能将变为活动状态。您可以通过调整配置设置来调整行为。

确定指标限制是否已激活

您可以使用以下方法了解是否发生默认指标限制。如果是，应考虑执行下一节中的步骤，优化基数控制。

优化基数控制

要优化基数控制，可以执行以下操作：

创建用于聚合操作的自定义规则

高基数操作有时可能是由从上下文中提取的不当唯一值引起的。例如，发出路径中包含用户 ID 或会话 ID 的 HTTP/S 请求可能会导致数百个不同的操作。要解决此类问题，建议您使用自定义规则配置 CloudWatch 代理，以重写这些操作。

如果通过单个 RemoteOperation 调用（例如 PUT /api/customer/owners/123、PUT /api/customer/owners/456 和类似的请求）生成大量不同的指标激增，则建议您将这些操作合并到一个 RemoteOperation 中。一种方法是将所有以 PUT /api/customer/owners/ 开头的 PUT /api/customer/owners/{ownerId} 调用标准化为统一的格式，尤其是 RemoteOperation。以下示例对此进行了说明。有关其他自定义规则的信息，请参阅 启用 CloudWatch Application Signals。

{
   "logs":{
      "metrics_collected":{
         "application_signals":{
            "rules":[
               {
                  "selectors":[
                     {
                        "dimension":"RemoteOperation",
                        "match":"PUT /api/customer/owners/*"
                     }
                  ],
                  "replacements":[
                     {
                        "target_dimension":"RemoteOperation",
                        "value":"PUT /api/customer/owners/{ownerId}"
                     }
                  ],
                  "action":"replace"
               }
            ]
         }
      }
   }
}

在其他情况下，高基数指标可能已汇总到 AllOtherRemoteOperations，并且可能不清楚包含哪些具体指标。CloudWatch 代理能够记录已删除的操作。要确定已删除的操作，请使用以下示例中的配置激活日志记录，直到问题再次出现。然后检查 CloudWatch 代理日志（可通过容器 stdout 或 EC2 日志文件访问）并搜索关键字 drop metric data。

{
  "agent": {
    "config": {
      "agent": {
        "debug": true
      },
      "traces": {
        "traces_collected": {
          "application_signals": {
          }
        }
      },
      "logs": {
        "metrics_collected": {
          "application_signals": {
            "limiter": {
              "log_dropped_metrics": true
            }
          }
        }
      }
    }
  }
}

创建指标限制策略

如果默认指标限制配置无法解决服务的基数，则可以自定义指标限制器配置。为此，请在 CloudWatch 代理配置文件中的 logs/metrics_collected/application_signals 部分下添加 limiter 部分。

以下示例将指标限制阈值从 500 个不同指标降低到 100 个。

{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "limiter": {
          "drop_threshold": 100
        }
      }
    }
  }
}