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

配置 Application Signals

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

跟踪采样率

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

环境变量 备注

OTEL_TRACES_SAMPLER

xray

OTEL_TRACES_SAMPLER_ARG

endpoint=http://cloudwatch-agent.amazon-cloudwatch:2000

CloudWatch 代理的端点

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

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

环境变量

OTEL_TRACES_SAMPLER

parentbased_traceidratio

OTEL_TRACES_SAMPLER_ARG

0.05

有关更多高级采样设置的信息,请参阅 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 时,指标限制功能将变为活动状态。您可以通过调整配置设置来调整行为。

确定指标限制是否已激活

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

  • 在 CloudWatch 控制台中,依次选择 Application Signals服务。如果您看到名为 AllOtherOperations操作或名为 AllOtherRemoteOperations远程操作,则表示发生指标限制。

  • 如果 Application Signals 收集的任何指标其 Operation 维度的值均为 AllOtherOperations,则说明发生指标限制。

  • 如果 Application Signals 收集的任何指标其 RemoteOperation 维度的值均为 AllOtherRemoteOperations,则说明发生指标限制。

优化基数控制

要优化基数控制,可以执行以下操作:

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

  • 配置您的指标限制策略。

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

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

如果通过单个 RemoteOperation 调用(例如 PUT /api/customer/owners/123PUT /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 } } } } }